Design analysis: JavaScript functions for fcli actions

[Copilot]

Research question: Should fcli actions support function definitions callable from steps and exposable as MCP tools? If so, YAML/SpEL vs JavaScript vs other languages?

Recommendation

Add JavaScript function support via GraalVM JS (~3-4MB). Maintains SpEL backward compatibility.

Rationale: JavaScript provides superior IDE tooling (autocomplete, debugging), AI code generation quality, and developer familiarity compared to SpEL string expressions. GraalVM native image compatible with acceptable overhead.

Proposed Syntax

functions:
  calculateRiskScore:
    language: javascript
    mcp: include  # Expose as MCP tool
    params: [issues]
    body: |
      const critical = issues.filter(i => i.friority === 'Critical').length;
      return critical * 10 + fcli.vars.get('baseScore');

steps:
  - var.set:
      score: ${#calculateRiskScore(issues)}

Functions access fcli through bridge API: fcli.vars, fcli.rest, fcli.exec, fcli.spel, fcli.log.

Documents Delivered

• Executive Summary (175 lines): Decision-maker overview, comparison matrix, roadmap
• Design Analysis (1,367 lines): Architecture, security sandbox design, migration strategy, implementation phases (v2.8.0-v2.10.0)
• Index (51 lines): Navigation for doc-resources/

Security

Sandboxed execution with no file system/network/reflection access. Resource limits: CPU time (30s), memory (64MB), statement count. All external operations via validated fcli API.

Implementation Phases

1. v2.8.0: Basic JS execution, sandbox, core API (vars, log)
2. v2.9.0: Full API (rest, exec, spel), MCP tool exposure, IDE tooling
3. v2.10.0: Testing framework, debugging, optimization

Next Steps

Stakeholder review → security validation → implementation planning.

Original prompt

Looking at current fcli *.yaml actions (both build-time and runtime) and MCP server/JSON-RPC server (latter only exists in non-merged PR), would there be any benefit in introducing fcli action syntax for defining functions that can be called from within fcli action steps and/or exposed as MCP/JSON-RPC functions?

If so, should these functions use existing fcli action syntax, or should we also add support for defining functions (or more generically, executing from actions) for example JavaScript code or some other language that can be easilly embedded in fcli.jar and associated GraalVM native images?

If so, how would we allow such JS (or other functions/steps) to access fcli action variables and re-use existing fcli action functionality, for example for executing REST requests or fcli commands?

Would support for a different, more common language provide any benefits from a coding/IDE assistance/AI assistance compared to current fcli action syntax with heavy use of Spring Expression Language?

Any related issues/recommendations/considerations/...?

---

💬 We'd love your input! Share your thoughts on Copilot coding agent in our 2 minute survey.