It is possible to use GraalJS instead of Rhino JS for javascript evaluation. GraalJS is fully ECMAScript 2022 compliant while Rhino JS only supports ES5.
This feature is experimental for now, but we intend to make GraalJS the default if all goes well.
ℹ️ Note This only has an effect if present at the top-level flow. It is ignored when included in any subflows.
appId: com.example.app
jsEngine: graaljs
---
# Note: The ?? operator is an example of an ES2020 feature and is not supported by Rhino JS
- inputText: ${null ?? 'foo'}
⚠️ Warning This env var will have no effect when running on Maestro Cloud. Use the Flow config above instead to opt into GraalJS on Maestro Cloud.
export MAESTRO_USE_GRAALJS=true
maestro test my-flow.yaml
There are some differences between the new GraalJsEngine
and the current RhinoJsEngine
implementation that are worth noting. All of the differences below and some others are documented and tested by the GraalJsEngineTest
and RhinoJsEngineTest
tests.
tldr; The variable scoping with the GraalJS implementation is more consistent and understandable
Rhino JS | GraalJS |
---|---|
|
|
Some examples
Example | Rhino JS | GraalJS | |
---|---|---|---|
Redeclaring variables across scripts |
|
- evalScript: ${const foo = null}
- evalScript: ${const foo = null}
| ❌ Variable redeclarations throw an error | ✅ Variable names can be reused across scripts |
| Accessing variables across scripts |
appId: com.example
- evalScript: ${const name = 'joe'}
assertTrue: ${name === 'joe'}
| ✅ Variables are accessible across scripts | ❌ Variables can't be accessed across scripts | | Special character handling |appId: com.example.app env: FOO: \
inputText: ${FOO}
| ❌ Single backslash causes an exception | ✅ Single backslash and all other special chars are handled correctly |