Lost of context between tests when using dynamic ESM import

[matthieu88160]

🐛 Bug Report

When using dynamic imports from a class and then make use of this class in two separate test files, the VM environment context seems to be lost in one of the two files.
This lead to an Invariant error in node_modules/jest-runtime/build/index.js:2004:11 without error message due to null condition (the context is used here as a condition).

This comportment creates a test result where one test suite is successful and the other one is failing.

Already opened a thread on stack overflow for this https://stackoverflow.com/questions/65256785/nodejs-import-issue-with-jest

To Reproduce

Steps to reproduce the behavior:

Create a class with a method that will make use of the dynamic ESM import() keyword and execute loading test in two separate testing files.

Full code with failing pipeline is available on this public Gitlab repository : https://gitlab.com/matthieu88160/stryker-issue

Expected behavior

The two test suites should succeed.

Link to repl or repo (highly encouraged)

https://stackoverflow.com/questions/65256785/nodejs-import-issue-with-jest

https://gitlab.com/matthieu88160/stryker-issue

envinfo

  System:
    OS: Linux 4.15 Ubuntu 20.04 LTS (Focal Fossa)
    CPU: (2) x64 Intel(R) Core(TM) i7-7567U CPU @ 3.50GHz
  Binaries:
    Node: 14.15.1 - /usr/local/bin/node
    npm: 6.14.9 - /usr/local/bin/npm
  npmPackages:
    jest: ^26.6.3 => 26.6.3 

[SimenB]

I wonder if this is the same as #9430 (comment) which I was never able to fix... It might be we need to do more stuff synchronously, at least that's what I got out of from the feedback on the upstream issue I created in Node. Similar to that issue, running with --no-cache seems to fix the issue most of the time, so there's some sort of race condition in here.

Will try to get to this soonish 👍 Although if anybody else wants to take a look that'd be great.

[matthieu88160]

Just tried to adjust Jest options with --no-cache, and to avoid multiple processes -w 1 but the test is still failing.

https://gitlab.com/matthieu88160/stryker-issue/-/jobs/907736980

[SimenB]

Yeah, it'll keep failing sporadically. Will need to track it down and fix, it was more an observation than something to remedy the situation

[matthieu88160]

Maybe a lead for this problem:

It seems the NodeEnvironment teardown method triggers the loss of context. When removing the line that triggers the context to be null or when removing the call in runTestInternal then the test is executed (when teardown is called then the failure occurred before the class import).

I still have an issue with this:

 FAIL  test/ComponentLoaderA.test.mjs
  ● ComponentLoader › load › load method is able to load a component from a file

    expect(received).toMatchObject(expected)

    Expected: {"default": [Function ComponentFixture]}
    Received: serializes to the same string

      20 |
      21 |                         modules[0].default.load(file).then(obj => {
    > 22 |                             expect(obj).toBe(modules[1]);
         |                                         ^
      23 |                             resolve();
      24 |                         });
      25 |                     });

      at test/ComponentLoaderA.test.mjs:22:41

[WeiAnAn]

I think this issue is caused by vm module (nodejs/node#36351).
Not Jest bug.

[kalinchernev]

I can confirm the issue and the fact the scenario will fail even when no caching.

[mmbfreitas]

Same issue here, is there some work around that you have used?

What i get here is that in jest-runtime index.js line 532,

const context = this._environment.getVmContext();

this function is returning null, for second test file.

[matthieu88160]

Same issue here, is there some work around that you have used?

Not for now, I sadly not have time to work on it for a while.

What i get here is that in jest-runtime index.js line 532,

const context = this._environment.getVmContext();

this function is returning null, for second test file.

Exactly, it was found in the initial observation. Maybe caused by the Jest tear-down process but this has to be confirmed.

[spiltcoffee]

Same issue here, is there some work around that you have used?

This may depend on how many tests suites you have, but I found setting --maxWorkers= to the number of test suites seemed to work for me as a potential workaround.

I found the problem always appeared if I only had one worker, and the more workers I had, the less often it showed.

[AlonMiz]

Same issue here
BTW in jest 27 the error does have a reasonable message, and a workaround

Error: You need to run with a version of node that supports ES Modules in the VM API. See https://jestjs.io/docs/ecmascript-modules
    at invariant (/node_modules/jest-runtime/build/index.js:2137:11)
    at importModuleDynamically (/node_modules/jest-runtime/build/index.js:1486:11)
    at importModuleDynamicallyWrapper (node:internal/vm/module:448:21)
    at exports.importModuleDynamicallyCallback (node:internal/process/esm_loader:30:14)

were able to follow some of the instructions in the doc. after adding --experimental-vm-modules to the node jest command manually, the test passed.

as I mentioned here,
aelbore/esbuild-jest#48

[github-actions]

This issue is stale because it has been open for 1 year with no activity. Remove stale label or comment or this will be closed in 30 days.

[SimenB]

I think this is a bug in Node, but we should track it still and verify once upstream is fixed

[shellscape]

Just had a user on my repo report the same problem, related to dynamic imports in my package.

[SimenB]

I don't think this is an issue in Jest anymore. There were issues in Node core vm APIs that I believe have since been fixed.

If anybody have a reproduction, please open a new issue - I'd be happy to take a look

[github-actions]

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.
Please note this issue tracker is not a help forum. We recommend using StackOverflow or our discord channel for questions.