Vitest

[GeoffreyBooth]

In the recent collaborator summit, one thing that many people mentioned as a blocker for ESM migration was Jest support for ESM. I noticed that Vitest claims to be both “Jest compatible” and to have “out-of-the-box ESM” support. I joined their Discord server to ask what was lacking from Node from their perspective, for them to provide as good an experience in ESM as Jest does in CommonJS: https://discord.com/channels/917386801235247114/918057929670811708/998630895110066226. @sheremet-va answered my questions. The issues mentioned were:

• Being able to set --conditions dynamically at runtime, since Vitest users define these in configuration files (applies to CommonJS too; I encouraged them to open an issue).

• Spawning workers is slow.

• The node:vm support for ESM is still experimental. Currently Vitest transpiles code to CommonJS and runs it through the stable vm API, so they already have a workaround; but presumably it would be nice to not need to transpile if possible. Vitest will always need to do some specifier rewriting as part of its mission (like to do mocks) so it would be only a minor improvement to not need to also convert import to require.

So basically we’re already at parity, though there’s still room for improvement. Regarding the last point, I think Jest currently takes the approach of using the experimental API, which is a pain point for users. If anyone from that team thinks of other issues I’ll update this list.

[sheremet-va]

Hello! I think one of the problems we will encounter, if we were to use esm, is mocking Module methods. As far as I know spec doesn't allow rewriting exported module variables?

[sheremet-va]

To fix some of the described problems we are thinking to add a loader that will only process aliasing inside node_modules, and to use our own module resolution for source files (to support jest-style module mocking, for example).

• I found that we can actually define --conditions when firing up a worker, so it is not an issue. Apologies.
• We have a single server instance in the main thread that is processing all requests, we do not want to create a new server for each loader. I see that you are planning to move loaders off thread - will there be a way or is there a way loader can communicate with the main thread? For reference: fix: apply Vite resolving algorithm to node_modules libraries vitest-dev/vitest#1673

[JakobJingleheimer]

Hello! I think one of the problems we will encounter, if we were to use esm, is mocking Module methods. As far as I know spec doesn't allow rewriting exported module variables?

It is possible with a loader. See https://dev.to/jakobjingleheimer/custom-esm-loaders-who-what-when-where-why-how-4i1o#all-together-now

I see that you are planning to move loaders off thread - will there be a way or is there a way loader can communicate with the main thread?

Yes, there is a test in node that does this via the globalPreload hook: nodejs/node#39240

[sheremet-va]

It is possible with a loader

I don't see how it's possible with provided link? It's not possible to redefine property on Module object. This is how spying works, no? Compiling it to CJS will work, off, but I was thinking we are doing ESM here 😄

Yes, there is a test in node that does this via the globalPreload hook.

Can you point me to that? Our idea is:

• Run script that fires up a Vite server and after that a worker with custom --loader
• Inside resolve hook loader asks from Vite server how to resolve path

I am struggling with the second one. We have a server in another thread, but I don't see how I can pass down a connection to the loader itself.

[JakobJingleheimer]

It is possible with a loader

I don't see how it's possible with provided link? It's not possible to redefine property on Module object.

Ah, I think maybe I misunderstood. For that, you'd need to use a dynamic import in your test file before importing the implementation:

const Module_mocked = await import('node:module')
  .then((original) => {
    // do whatever
    return {
      // your mock here
    };
  });
const implementationToBeTested = await import('./whatever.mjs')
  .then((module) => module.default);

Yes, there is a test in node that does this via the globalPreload hook.

Can you point me to that?

@sheremet-va yes, I just added it to my message as you posted yours 😅