jest: runInBand + dynamic imports break in Jest 27.0.0-next.11

On my tests, this issue is fixed on Node >=16.11 issue.zip <- Credits to @fwh1990 , I just simplified the example removing ts and other unrequired code

I don’t think it has been fixed yet. I got this error with Node 17, 18 and 19.

I’m also facing the same issue with --runInBand and it seems like that node.js have fixed it in version 16.11.0, see my GitHub Actions run.

Workaround is to disable runInBand in your project and set maxWorkers and maxConcurrency to value greater or equal test amount, for example in my repository I have maximum 7 tests per project that uses dynamic import, so I’ve set this values to 8 (and probably that’s why tests are pass on my local machine, I have 8 cores on laptop and 16 on desktop) As well I’ve increased timeout and magic happened! My CI is now green, links:

• commit: https://github.com/L2jLiga/fastify-decorators/pull/457/commits/379e280384e5beefc8ecf095c7af5323847ab87c
• GitHub Actions run: https://github.com/L2jLiga/fastify-decorators/runs/4039225530?check_suite_focus=true

@SimenB it seems like that for ESM we have to instantiate new worker per each test file to workaround this issue at least for thoose who use Node.js < 16.11.0

This is almost certainly https://github.com/nodejs/node/issues/36351 or https://github.com/nodejs/node/issues/33439 (either way it’s further upstream: https://bugs.chromium.org/p/v8/issues/detail?id=10284)

Going one step further: by placing console logs within jest-runtime loadEsmModule() function and jest-environment-node constructor and teardown(), I found out a mismatch in environment handling.

Basically, each test file has its own Node environment: it is configured before running tests within the file, and tore down at the end. What happens is

1. env # 1 is created for the test file
2. tests are run, dynamically importing files within the env
3. env # 1 is tore down
4. env # 2 is created for the second test file
5. tests are run, but they are importing files within env # 1, triggering the error
6. env # 2 is tore down

I’ve tried to import all my modules dynamically, to use isolateModule() and resetModules(), but I couldn’t find a way to force the second file using its own environment.

Hi there. I’m also experiencing this issue, and made a stable reproduction repository here

As you can see, I’ve stripped down all my code to the minimum: a module (index.js) dynamically importing another one (internals.js).

As long as I had a single test file importing index.js, everything was fine. As soon as I’ve added another test file on the same guy, the issue happens.

I’ve lost considerable time digging it, without finding any workaround nor root cause, but my gut feeling is that the jest-node-environment is tear down, then reused. Its VMcontext is gone, preventing further dynamic imports to work.

For jest users:

Try running jest --clearCache before running your actual tests (equals to disable jest’s transform cache).

This may help in some situations.

If this works for you, you can turn off jest’s cache ability in jest.config with cache: false.

https://github.com/nodejs/node/issues/35889#issuecomment-1521334188

On my tests, this issue is fixed on Node >=16.11 issue.zip <- Credits to @fwh1990 , I just simplified the example removing ts and other unrequired code

A workaround I’m using is to run each test file separately, rather than telling Jest to run everything in a dir tree. It’s kludgy, but until V8 fixes this, so that Node can fix it, so that Jest can work with it, not a lot of choice if you don’t want to run into caching issues:

  "scripts": {
    "test": "run-s test:jest:*",
    "test:jest": "cross-env NODE_OPTIONS=--experimental-vm-modules jest --verbose=false",
    "test:jest:models": "npm run test:jest -- test/models/model.test.js",
    "test:jest:migration": "npm run test:jest -- test/migration/migration.test.js",
    "test:jest:...": "...",
    "...": "...",
  },
  "devDependencies": {
    "cross-env": "^7.0.3",
    "jest": "^27.2.2",
    "npm-run-all": "^4.1.5",
    "...": "...",
  }

With testing code that relies on dynamic imports:

import { Models } from "../../index.js";
import { User } from "./user.model.js";

describe(`Testing User model`, () => {

  beforeAll(async () => {
    await Models.useDefaultStore(`./data-store`); // this falls through to a dynamic import
    Models.register(User);
  });

  ...
});

with the operative dynamic import in Models:

static async useDefaultStore(path) {
  const { FileSystemStore } = await import("./store/filesystem-store.js");
  Models.setStore(new FileSystemStore(path));
}

But even then, this workaround probably still has pitfalls that I’ve simply not run into (yet).

Again, this is a bug in V8, there is nothing we can do except wait for Google to fix and release it, then Node to update their version of V8 and backport it to v12, v14 and v16