Is require(esm) actually supported?

[hasezoey]

Hello, for a long time now i have a project which is CJS and is unlikely to switch in the near future, but the dependencies have long since moved on to ESM, requiring us to stay on old versions.
Now i have seen for quite some time that NodeJS supports require(ESM), and i can confirm that works, but jest had been the holdback since today, where i had seen that require(esm) is supposedly supported (at least as of 30.5.0).

But regardless of what i try, i cannot get it to work and only encounter the following error:

    Must use import to load ES Module: /mnt/ssd/projects/nodejs/jest-esm/node_modules/camelcase/index.js

    The file contains ESM syntax (import/export) that could not be executed as CommonJS. Either:
      - Configure a transform (e.g. babel-jest) that compiles this file to CommonJS (see https://jestjs.io/docs/code-transformation)
      - If the file is in "node_modules", allow it to be transformed by adjusting "transformIgnorePatterns" (see https://jestjs.io/docs/configuration#transformignorepatterns-arraystring)
      - Use Node v24.9+ where Jest supports require(esm) natively (see https://jestjs.io/docs/ecmascript-modules#require-of-esm)

    > 1 | const {default: camelcase} = require("camelcase")
        |                              ^
      2 |
      3 | module.exports = function test() {
      4 |     return camelcase("TEST TEST");

      at createRequireEsmError (node_modules/jest-runtime/build/index.js:452:17)
      at Object.require (src/index.js:1:30)
      at Object.require (test/testy.test.js:1:14)

I have also seen (in some issues) that the modules may require module-sync in their exports list (instead of just default), but even if i manually add it to camelcase in this case, the error stays the same.

Am i doing something wrong, or is the documentation just misleading?

Reproduction repo

Jest 30.5.1
NodeJS 26.7.0

[portyu9]

Hi @hasezoey

Yes, require(esm) is supported, but there is one additional requirement in Jest: Jest itself still needs to be started with Node's --experimental-vm-modules flag.

Your reproduction currently has:

"scripts": {
  "test": "jest"
}

Change that to:

"scripts": {
  "test": "node --experimental-vm-modules ./node_modules/jest/bin/jest.js"
}

or run Jest with:

NODE_OPTIONS=--experimental-vm-modules npm test

The reason plain Node works while Jest does not is that Jest executes ESM through Node's vm.Module APIs. Even on Node 26, those APIs are still gated behind --experimental-vm-modules.

So Node 24.9+ is required for Jest's synchronous require(esm) implementation, but it does not remove the VM-modules flag requirement.

Adding "module-sync" to camelcase will not fix this particular error because Jest is failing before that distinction becomes relevant.

The documentation is therefore technically correct, although the require(esm) subsection could make it clearer that the earlier ESM activation instructions on the same page still apply.

Please mark this answer as accepted if it helped, thank you.

[hasezoey]

Thanks for the reply.
Yes the require(esm) section makes it seem, at least to me, as if it does not require this experimental flag.
This was as it explicitly notes nodejs 24.9+ and require(esm) being possible on node without a flag, i assumed that jest made it work in the same way and the previous sections only mention the project itself being ESM.
I guess i was just hopeful and selective.

By the way, what did nodejs 24.9 add that 22.12 / 20.19 did not have? Something related to how --experimental-vm-modules works?
(Asking as nodejs notes that require(esm) is possible since 20.19.0)

I guess i wont be able to upgrade to those ESM versions for a long time yet, as the library this would make use them, would then force this experimental option on anyone else.

[portyu9]

Yeah, I think your reading of the docs is pretty understandable. The require(esm) section doesn't repeat the --experimental-vm-modules requirement, while it explicitly compares the behavior to Node's flagless require(esm). The catch is that the activation instructions at the top still apply to Jest's ESM implementation, including this case.

The difference is basically that there are two separate module-loading implementations involved:

• Node's normal CommonJS loader has native require(esm). That became available without --experimental-require-module in Node 22.12 and 20.19.
• Jest does not use Node's normal loader directly for modules under test. It has its own module runtime so it can provide transforms, mocks, isolation, its own require.cache, etc., and its ESM implementation is built on Node's vm.SourceTextModule APIs.

For synchronous require() to work, Jest has to be able to synchronously link/evaluate the entire ESM graph and also know that there is no top-level await.

That's where the newer Node VM APIs matter.

Node 24.8 added things like synchronous:

module.linkRequests(...)
module.instantiate()

and Node 24.9 added:

module.hasTopLevelAwait()
module.hasAsyncGraph()

The last one is particularly relevant: Jest's implementation literally feature-detects SourceTextModule.prototype.hasAsyncGraph to decide whether synchronous ESM evaluation is supported.

So Node 20.19 / 22.12 can do this through the normal Node loader:

const esm = require('some-esm-package')

but those versions don't provide Jest's VM-based loader with all the synchronous machinery Jest needs to reproduce that behavior inside its own runtime.

--experimental-vm-modules is therefore a separate issue from Node's old --experimental-require-module flag. The former enables the VM module APIs Jest uses; Node 24.9 added capabilities to those APIs that finally made Jest's synchronous require(esm) implementation possible.

One important clarification on your last point, though: using this in your library would not force --experimental-vm-modules on consumers of the library.

For example, if your CJS library contains:

const camelcase = require('camelcase')

and camelcase is ESM-only, an application running on Node 20.19+ or 22.12+ can execute that using Node's native require(esm) without --experimental-vm-modules.

The flag is needed because Jest executes the same code through its VM-based module runtime.

So the compatibility constraint for your library itself would mainly become the Node version:

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

assuming the ESM dependency and its dependency graph don't contain top-level await.

Your own Jest tests would currently be the awkward part: to exercise that native-style require(esm) through Jest, you'd need Node 24.9+ plus --experimental-vm-modules.

So if you need to continue supporting older Node versions, then yes, adopting an ESM-only dependency can still be a blocker. But if your concern is specifically imposing --experimental-vm-modules on downstream users, that part fortunately does not propagate to them.

[hasezoey]

But if your concern is specifically imposing --experimental-vm-modules on downstream users, that part fortunately does not propagate to them.

Just for context, the actual package (among some others, but this is the main blocker) in question is mongodb-memory-server, a package made for making testing easier, so i would hazard a guess that it is used in at least 80% of cases only in test environments.
The package in question is already node 20+.

So if i understand correctly, jest only needs --experimental-vm-modules if the dependency is a direct ESM dependency (ex root -> camelcase, but not if it is a nested dependency (ex root -> mongodb-memory-server -> camelcase)?
(where root is the workspace / package where the tests run)

[portyu9]

Not quite — whether the ESM dependency is direct or transitive doesn't change this.

If the dependency chain is:

root
  -> mongodb-memory-server (CJS)
       -> camelcase (ESM)

and mongodb-memory-server is being executed inside Jest, the require() that Jest provides to mongodb-memory-server is still Jest's own require, not Node's native CommonJS loader.

So when mongodb-memory-server does something like:

const camelcase = require('camelcase')

that call comes back through jest-runtime and Jest still has to load/evaluate camelcase as ESM.

In other words, from Jest's point of view these are effectively the same:

root -> camelcase

and:

root -> mongodb-memory-server -> camelcase

The second require() is still happening inside Jest's module runtime.

One potentially confusing part here is transformIgnorePatterns: node_modules being ignored for transformation does not mean those packages are handed off to Node's native module loader. Jest still loads them through its runtime; it just normally doesn't transform their source.

So for Jest's native require(esm) implementation, the transitive case would still need the same VM-module support.

The main exceptions would be if:

• the ESM dependency is transformed to CJS before execution, or
• the code is deliberately loaded outside Jest's module runtime using Node's native loader.

Neither happens merely because the package is a nested dependency.

And that does make the mongodb-memory-server case more relevant than a normal runtime library. Since it is primarily used inside test runners, switching a CJS code path to require() an ESM-only dependency could indeed mean that Jest consumers encounter this even though camelcase is only transitive.

So I would phrase my previous distinction more narrowly: --experimental-vm-modules does not become a general runtime requirement of mongodb-memory-server, but it can become a requirement for consumers executing that dependency chain inside Jest.