Jasmine 5 ESM config loading across Node.js 16 CI and Node 18+ local

The short answer: there is no official Jasmine compatibility matrix for jasmine.json loading across Node 16, 18, and 20, and the Jasmine CLI will not warn you or inject flags. The practical fix for a mixed-version setup is to stop relying on the CLI to adapt and instead pin the Node floor in your project metadata and CI, treating Node 18.19+ (or 20 LTS) as the minimum for ESM config loading.

Likely explanation vs. confirmed facts

What is well-established:

• Jasmine 5 loads its config through dynamic import(), so config loading inherits whatever ESM support the running Node version provides.
• Node 16 and 17 required --experimental-vm-modules for parts of this path; Node 18.19+ runs ESM without flags; Node 20 removed the old experimental flag entirely.
• The Jasmine CLI does not detect the Node version or add flags itself, so the same repo behaves differently on a Node 16 CI runner than on a Node 18+ laptop.

What is less certain: the exact failure mode you see depends on whether your jasmine.json is plain JSON or a JS module, and on how your CI image invokes Node. A silent "config not found" fallback versus a hard ERR_VM_DYNAMIC_IMPORT_CALLBACK_MISSING-style error are both plausible; check your CI logs before assuming which one you have.

Should Jasmine emit a warning?

Arguably yes, but it does not today, and you should not design around a warning that may never ship. Because the failure surfaces inside Node's module loader rather than in Jasmine's own code, the CLI has limited context to produce a precise message. Treat this as your project's responsibility, not the framework's.

How to declare supported Node versions

The cleanest resolution is to declare the boundary yourself:

1. Set an engines floor in package.json:

   "engines": { "node": ">=18.19" }

2. Pin the same version in CI (node-version: '20' in GitHub Actions, or the equivalent image tag elsewhere) so local and CI cannot drift.
3. Add a .nvmrc or .node-version file so local shells match CI automatically.
4. If you genuinely must keep Node 16 CI alive, invoke Jasmine with the flag explicitly in that job only, e.g. NODE_OPTIONS=--experimental-vm-modules jasmine, and schedule its removal — Node 16 is past end of life and the flag is gone in Node 20.

Verifying the boundary in your repo

Confirm behavior rather than trusting assumptions:

node --version
npx jasmine --version
npx jasmine --config=spec/support/jasmine.json

Then deliberately break the config (rename a spec dir) and run it on each Node version. If the error message or exit code differs between Node 16 CI and Node 18+ local, that confirms the flag-dependent path is your inconsistency source.

One open question

Is your jasmine.json a pure JSON file or a JS config module? If it is pure JSON, moving CI to Node 18.19+ should resolve everything with no flag juggling. If it is a JS module, the dynamic-import path is more sensitive and the engines floor becomes mandatory rather than advisory.