How to mock a module loaded using require()

[cefn]

I realised (eventually) that vi.mock silently omits mocking modules which are loaded using require().

Note to self - maybe an unused vi.mock should cause vitest to fail a suite?

Is there a standard answer for mocking CommonJS style imports that is compatible with vitest? I'm assuming that blending jest tooling with vitest is a bad idea so jest.mock isn't a feasible option.

Everything else about my test suite (in a commonJS repository) is working well with no transpilation or build step - I am seamlessly using Typescript to author tests against functions defined using commonjs formalisms. However, the one occasion where I need to mock a required module is turning out to be very costly. To fulfil the requirements of vi.mock I have to introduce import and export keywords in the target files, migrate the repo package.json to "type":"module" and so on leading to a cascade of changes for a single mock. In this particular context, lots of other tooling assumes commonjs making this approach impossible.

What options do I have for mocking a module loaded with require() when using vitest. I really don't want to go back to Jest for this one feature.

[sheremet-va]

Vitest doesn't intercept require, so it is not possible to mock a module that was loaded with require

[cefn]

Thanks, Vladimir. I'm aware that the vi.mock support in Vitest doesn't intercept require.

My question is whether there is any other mechanism, library or approach that's compatible with Vitest (not part of Vitest) and that intercepts require.

Perhaps there's a theoretical reason why this is impossible because of how Vitest runs, which I would be interested to hear. This would at least clarify what I need to do (switch back to using jest for anything authored in CommonJS that needs module mocking for tests).

[cefn]

By way of an example, there is https://www.npmjs.com/package/mock-require but that hasn't been updated in 4 years, perhaps because CommonJS is an outdated standard? Hence wondering if there's a standard choice of strategy that people adopt that avoids any obvious pitfalls. Perhaps that older module is still fine as it doesn't need updates.

[djMax]

"outdated standard" made me LOL. It is no more outdated than "Javascript" is outdated.

[jiovanmichel]

Use vi.spyOn

BeforeEach / BeforeAll
vi.spyOn(class, 'method').mockReturnValue('mock value');

AfterEach / AfterAll
vi.restoreAllMocks();

[cefn]

Adopting mock-require in the test suite was an effective workaround.

[sm3sher]

Thank you four your quick reply. I get a ReferenceError since Module from 'module' needs to be imported before vi.hoisted.
Is there a way to execute selected imports before vi.hoisted?

[sheremet-va]

You can import modules inside vi.hoisted. Don't forget to await it

[sm3sher]

Thanks, works with dynamic imports and vi.hoisted. Very neat! 😬

[binodov]

What exactly was the solution? How do we lever the above function in a vitest test?

[tim-trewartha]

Thanks for this helpful discussion - I found mock-require does the job but I'd like to avoid it if possible. I'm not too sure how to achieve the same with vi.hoisted. My issue is that a node-module imported in a shared (transpiled) package is imported using require, and thus I am unable to intercept using Vitest.

[haayhappen]

Can somebody post some code snipped with a working mock-require implementation? That would be very helpful 👍

[sm3sher]

I have this scenario to mock:

const {ClassToMock} = require('@toBeMocked');

And am mocking it successfully like that at the top of my test class:

vi.hoisted(
    () =>
        void mock('@toBeMocked', {
            ClassToMock: class ClassToMock {
                getSomething = () => yourReturnValue;
            },
        })
);

async function mock(mockedUri, stub) {
    const {Module} = await import('module');

    Module._load_original = Module._load;
    Module._load = (uri, parent) => {
        if (uri === mockedUri) return stub;
        return Module._load_original(uri, parent);
    };
}

If you have exported functions to mock your stub would look different but other than that this works pretty well.