mock.module.restore fails if module is already present in ESM cache

[NiedziolkaMichal]

A typical reason to mock modules, is to replace return value of a function imported from a tested module.
Lets consider two very simple modules:

// main.ts
import { getValue } from "./util.ts";

export function main() {
    return 'received ' + getValue();
}

// util.ts
export function getValue() {
    return "real value";
}

What I would like to do, is mock the getValue always, once or when there are a given input arguments.

Now take a look at the test:

import { it } from 'node:test';
import assert from "node:assert";

it('should return mock value', async (t) => {
    const mock = t.mock.module('./util.ts', {
        namedExports: {
            getValue() {
                return "mock";
            },
        },
    });

    const { main } = await import('./main.ts');

    assert.equal(main(), 'received mock');

    mock.restore();
})

it('should return original value', async () => {
    let { main } = await import('./main.ts');

    assert.equal(main(), 'received real value');
})

The second test fails, because mock wasn't restored.
Now if we switch the tests and put should return original value first, the test should return mock value fails, because mock.module doesn't invalidate modules which already imported the mocked module. Those two issues makes it practically impossible to mock modules, especially with --test-isolation=none.

Using node test runner with default test-isolation is unusable for any large project, due to terrible performance.

[cjihrig]

@nodejs/test_runner it looks like #61767 could land. If that happens, mock.module() should also support violating ESM semantics.

[cjihrig]

In the mean time, even though the OP decided to show up with major jerk energy, here is one way to work around the limitation:

import { it } from 'node:test';
import assert from "node:assert";

it('should return mock value', async (t) => {
    t.mock.module('./util.mjs', {
        namedExports: {
            getValue() {
                return "mock";
            },
        },
    });

    const { main } = await import('./main.mjs?cache=1');

    assert.equal(main(), 'received mock');
})

it('should return original value', async () => {
    let { main } = await import('./main.mjs?cache=2');

    assert.equal(main(), 'received real value');
})

[NiedziolkaMichal]

Sorry, I didn't mean to be rude. I would very much like to see the node test runner as a replacement for jest or vitest.

[JakobJingleheimer]

I think we can actually do this now with a loader and just append a generation query param.

If that other PR doesn't land, the work to facilitate via a loader (which we're already doing) I expect would be fairly simple (I coulda sworn I suggested it somewhere else like a year ago, but haven't circled back to it).

[cjihrig]

I think we can actually do this now with a loader and just append a generation query param.

If we're talking about the same thing, that's already how it works. The issue here is that existing modules are not replaced. In the example here, util.ts is mocked and then main.ts is imported. In the next test, main.ts is imported again. Even though the test runner mock of util.ts has been restored, main.ts is still the same.