Allow mocking `require.resolve`

[nicolo-ribaudo]

🚀 Feature Proposal

The require.resolve function is re-created for every file: this is needed so that it starts resolving from the correct location.

However, this makes it impossible to mock it: require.resolve = jest.fn() doesn't work.
I propose adding an API similar to jest.mock specifically for require.resolve's behavior.

Motivation

We have different tests in @babel/core that test plugins/presets aliasing (ref). For example, we test that when someone uses @babel/env in their config Babel tries to resolve @babel/preset-env.

We currently rely on "fake" node_modules folders, however:

1. We don't want to test node's resolution algorithm, we should only test what we are asking node to resolve.
2. Using real FS just to check plugins/presets aliasing makes our tests slower.
3. This approach doesn't work with Yarn PnP, because it changes the resolution behavior (and it shouldn't affect our tests).

Example

Maybe something like this?

jest.mockResolution("@babel/env", __dirname + "/fake/@babel/preset-env");

// test

jest.unmockResolution("@babel/env");

Pitch

Mocks are already handled by the Jest core platform 😁

[SimenB]

Oooh, I like it! It would essentially be jest.mock but only instead of providing the inline implementation, you provide the path it should resolve to? Would allow people to easily reuse mock modules without putting a file in __mocks__/ directories as well.

Not a huge fan of needing to replicate all of .mock, doMock, unmock and dontMock though... Would overloading be confusing to people? So if a function is provided it's a inline mock, if it's a string, it's the resolution that's mocked? I generally hate overloaded APIs, but in this case I think it might make sense?

[nicolo-ribaudo]

Somehow I didn't realize that my proposal could be directly related to jest.mock 😂 I think that your proposed overload makes sense, and might even be more intuitive than having to use a parallel API.

Do you think that require.resolve should check if the mocked path exists? I'd say no, but then we would need something to mock a file as non-existing.

[SimenB]

We have jest.mock('thing', factory, {virtual: true}) if you don't want the thing you're mocking to exist. I think that should work with require.resolve as well, no?

/cc @jeysal @thymikee @cpojer thoughts on this one?

[nicolo-ribaudo]

Oh, I didn't know about virtual.

If no one from the team has concerns with this feature request, I could start working on an implementation next week.

[cpojer]

I think virtual mocks should cover your use case. Let's try that first before adding more APIs to Jest. I do not think that mocking require.resolve is desirable, there are too many ways to shoot yourself in the foot :D

[nicolo-ribaudo]

Since Babel internally directly calls require.resolve, I don't see how virtual mocks could cover my use case 🤔

[cpojer]

You should be able to create virtual mocks to ensure that require.resolve doesn't throw. If it throws, you know Babel did something unexpected.

You can also require the module after calling require.resolve and then verify that the mock module function was called etc.

[nicolo-ribaudo]

It doesn't seem to work:

describe.only("virtual mocks", function() {
  it("finds preset", () => {
    try {
      const preset = () => ({});

      // also tested with "../../../node_modules/babel-preset-test-1234"
      jest.doMock("babel-preset-test-1234", () => preset, { virtual: true });

      expect(() =>
        babel.transformSync("code;", {
          presets: ["babel-preset-test-1234"],
          configFile: false,
        }),
      ).not.toThrow();
    } finally {
      jest.dontMock("babel-preset-test-1234");
    }
  });
});

reports

  ● virtual mocks › finds preset

    expect(received).not.toThrow()

    Error name:    "Error"
    Error message: "Cannot resolve module 'babel-preset-test-1234' from paths ['/home/nicolo/Documenti/dev/babel/babel'] from /home/nicolo/Documenti/dev/babel/babel/packages/babel-core/lib/config/files/plugins.js"

          89 | 
          90 |   try {
        > 91 |     return require.resolve(standardizedName, {
             |                    ^
          92 |       paths: [dirname]
          93 |     });
          94 |   } catch (e) {

          at Runtime._requireResolve (node_modules/jest-runtime/build/index.js:892:13)
          at resolveStandardizedName (packages/babel-core/lib/config/files/plugins.js:91:20)
          at resolvePreset (packages/babel-core/lib/config/files/plugins.js:48:10)
          at loadPreset (packages/babel-core/lib/config/files/plugins.js:67:20)
          at createDescriptor (packages/babel-core/lib/config/config-descriptors.js:154:9)
          at packages/babel-core/lib/config/config-descriptors.js:109:50
              at Array.map (<anonymous>)
          at createDescriptors (packages/babel-core/lib/config/config-descriptors.js:109:29)
          at createPresetDescriptors (packages/babel-core/lib/config/config-descriptors.js:101:10)

      14 |           configFile: false,
      15 |         }),
    > 16 |       ).not.toThrow();
         |             ^
      17 |     } finally {
      18 |       jest.dontMock("babel-preset-test-1234");
      19 |     }

      at Object.<anonymous> (packages/babel-core/test/resolution.js:16:13)

Test Suites: 1 failed, 1 total
Tests:       1 failed, 40 skipped, 41 total
Snapshots:   0 total
Time:        0.634s

It doesn't work because the jest replacement for require checks for mocks, but the replacement for require.resolve doesn't.

Also, I don't know what require.resolve would be currently expected to return with mocks, because it must return a string which we aren't providing to jest.mock.

[cpojer]

Thanks for trying it out and checking. That's a good observation that I missed. Now the question is: should require.resolve consider mocks and give a fake temporary file-path or should we allow mocking require.resolve?

[nicolo-ribaudo]

If require.resolve("foo") returned something like "/tmp/jest-virtual-mocks/node_modules/foo" if an only if foo is a mocked module, then it would probably cover our use case. However, Jest should make calls to require("/tmp/jest-virtual-mocks/node_modules/foo") return the mocked implementation otherwise require(require.resolve("foo")) won't work.

I still think that explicitly specifying to Jest what to return when require.resolveing a mocked module would be better. Maybe something like this?

jest.mock("foo", () => {}, { virtual: true, resolve: "/tmp/node_modules/foo" });

Also, I realized that my original proposal doesn't cover a use case we would need in half of our resolution-related tests: checking that the correct error message is thrown when require.resolveing a module that doesn't exist (ref). This currently already works, but it checks every folder up to the root of the real FS because it uses the "real" algorithm.

It probably would need a separate option, which makes a mock throw whenever require or require.resolve are called:

jest.mock("foo", () => {}, { virtual: true, missing: true });

[cpojer]

I'm a bit hesitant of adding new APIs to Jest because you are running into a very limited use case that not many people are encountering. I think I would prefer simply making it so you can overwrite require.resolve, then you can do whatever you like with it.

[SimenB]

What I like about expanding jests API is that you can have reusable mocks (possibly distributed through npm) without __mocks__ directory. Also, it's weird that jest.mock affects require but not require.resolve.

[nicolo-ribaudo]

I'm a bit hesitant of adding new APIs to Jest because you are running into a very limited use case that not many people are encountering.

I agree with this sentiment. However, I don't think that mine is a limited use case:

• https://stackoverflow.com/questions/47907454/mocking-and-testing-require-resolve-calls-in-jest
• https://stackoverflow.com/questions/60107539/jest-mock-require-resolve-calls
• https://blog.zfanw.com/how-to-mock-require-resolve-under-jest/ (not in english)
• Currently GitHub search gives more results for require.resolve than for jest.mock

However, I didn't find anyone else asking how to mark a mocked module as not existing. Let's keep the discussion focused only on the original proposal.
Also, it could probably be worked around with @SimenB's original proposal (#9543 (comment)).

What I like about expanding jests API is that you can have reusable mocks (possibly distributed through npm) without __mocks__ directory.

This is something I personally don't need, but I definitely see how it would be useful for the rest of the community!

Also, it's weird that jest.mock affects require but not require.resolve.

💯 The require and require.resolve node APIs are designed to be symmetrical (I think that require itself uses require.resolve internally). Currently, this simmetry is broken when using jest.mock.

[SimenB]

I'm down with adding a resolve option next to virtual. I think almost all of the code changes needed in jest-runtime will be the exact same regardless of where the signal comes from (a separate option, string as factory or an entirely new API, or something else we haven't thought of), and the bulk of the work will remain the same no matter what API we land on.

One challenge with overloading is that babel-plugin-jest does some checking on the type provided. You're probably the most qualified person around to make the changes to the Babel plugin, though 😛
https://github.com/facebook/jest/blob/47b8aaec0a6bb80b96f7641d68c76587d86abe23/packages/babel-plugin-jest-hoist/src/index.ts#L97-L102
Should probably be noted though that we might need to validate resolve in a similar way, since hoisting will make it so that e.g. jest.mock('./thing', () => {}, {resolve: findSomeUrl()}) can behave differently. Right now we force you to have everything in scope of the mock factory, be a global or be named mock*Something*. Something like it probably makes sense for whatever we end up adding to allow mocking require.resolve as well