jest: [bug] duplicate manual mock found in separate directories

This seems to work for me. in jest.config.js:

module.exports = {
  // ...
  modulePathIgnorePatterns: ["<rootDir>/.*/__mocks__"]
};

I’m not sure of the the scope or impact of this change, because I have a small project.

3 years and 10 months

modulePathIgnorePatterns: ["<rootDir>/.*/__mocks__"]

This solution works although it made my top level mocks for node modules fail. So I changed it to not ignore my root mock folder with: "modulePathIgnorePatterns": ["<rootDir>/src/react/.*/__mocks__"],. Still it’s quite weird that mocks are not just unique based on the full path from the root. It’s pretty common to have: users/helper.js & posts/helper.js. The warning does take quite some space, and I don’t want to completely hide actual warnings.

Any updates on how to fix this problem? This turns out to be really painful if you follow a structure like this:

project/
├── models
│   ├── index.js
│   ├── __mocks__/
│   │   ├── index.js/
├── challenges
│   ├── index.js
│   ├── __mocks__/
│   │   ├── index.js/

Right now I have to manually mock a module in the test if I’m using two with a ‘conflicting’ name even though they actually don’t have conflicting names since the path should be considered.

Cheers, Dominik

Any update on this?

Yes this does suck indeed. The manual mocking system is really not good and I’m happy to accept PRs that will improve the situation, assuming we can make sure we don’t break all of FB (but I can take care of that 😃 )

+1

3 years and 10 months

And one of the messages 3 years ago was “I might find some time tomorrow to cook up a patch, but no promises though”… 😛

@masoudcs I think this got rid of the warning:

package.json

"jest": {
  /* other settings ... */
  "modulePathIgnorePatterns": ["<rootDir>/node_modules/react-native/Libraries/Core/__mocks__"]
}

Add the “duplicate” folders in the modulePathIgnorePatterns array and the warning will be gone

Here’s the offending code:

https://github.com/facebook/jest/blob/cd8976ec50dbed79cfe07f275052cdd80d466e73/packages/jest-haste-map/src/index.js#L98

But it looks like the behavior might be explicitly wanted as there is a test confirming it:

https://github.com/facebook/jest/blob/8de90b320c87a0a36d68f6bd8177620a985df269/packages/jest-haste-map/src/__tests__/__snapshots__/index-test.js.snap#L15

Which was added in:

https://github.com/facebook/jest/commit/cfade282fbbe2737b6dd2cee1cf3da3ee8624512

I wonder why we are using basename rather than the whole path as the key?

/cc @flarnie

A little workaround for me is to mock the modules with require

jest.mock('models/index', () => require('models/index/_mocks_/index'));

I renamed the __mocks__ folder name to _mocks_ so that jest does not catch the files.

One day when this will work I will rename _mocks_ to __mocks__ and remove the require part from jest.mock

This means that basenames for modules need to be globally unique in a project when using manual mocks. For my use case, it means I can’t do something like:

import { MyWhatever } from 'models/MyWhatever/schema';
import { MyOtherWhatever } from 'models/MyOtherWhatever/schema';

and use manual mocks at the same time. Jest will currently see them both as mocking schema and complain.

Though the workaround is trivial (s/schema/MyWhateverSchema/), it feels like a bug to rename and restructure non-test code to make jest happy 🐞 .

This issue is super frustrating, but I think I’ve found a nice workaround that results in a cleaner naming convention.

In package.json

{
  "jest": {
    "setupFiles": [
      "<rootDir>/test.mocks.ts"
    ]
  }
}

/* test.mocks.ts */

// modules mocked before every test
// use `jest.unmock(...)` to undo for any single test case
const mockedModules = [
    "./path/to/module1/index.ts",
    "./path/to/module2/index.ts",
];

mockedModules.forEach((path) => {
    const mockPath = path.replace(/\.ts$/g, ".mock.ts");
    jest.mock(path, () => require(mockPath));
});

This will allow you to mock anything.ts by creating a sibling anything.mock.ts and adding the path to the original in the top-level test.mocks’s mockedModules array.

We have found that in spite of the warnings, our actual tests succeed and thus the individual manual index mocks are actually being used. What then does the warnings mean?

So what is the current status of PR? Is there any proper solution or just some hacks?

Guys any update?

Yes, mocks are “global” as well. This is a terrible design that we have to live with, unfortunately. At FB we have 4000+ mock files in the wrong location (and often there isn’t even a proper location). It is likely we will fix this early next half, so this should improve in Jest. I’m happy to support PRs that improve the behavior in Jest for open source – if we can retain the old behavior for Jest at FB for now.

To ask the stupid question… Would using the whole path instead of just the filename not solve this?

Hey everyone, sorry for the delay, I’m pretty backed up with a ton of stuff right now.

I think I’m fine if you guys decide to do whatever breaking change in Jest that is necessary to improve this system. Manual mocking is really messed up and doesn’t work well. One thing we kind of want to do is limit the scope of “haste modules” (internal FB module system) using a config option, like "haste_modules": ['path/a', 'path/b']" and then only look at haste modules in those folders, including this weird mocking behavior. If anybody wants to make this change, that would be amazing.

One thing to be figured out then, is this: If all manual mocks are local, like __mocks__/a.js maps to a.js, what do we do with node_module mocks? For this there are a couple of ways:

• Introduce a new __node_modules_mocks__ folder but that is ugly.
• The top level __mocks__ folder as seen from rootDir (project root) could act as a global folder.

So to summarize:

• Let’s fix manual mocks in Jest!
• Let’s namespace haste modules and limit them to certain folders/regex whatever.
• Make sure that the current mocking behavior still works for FB, even if that means we have to whitelist certain folders to make haste work (it would just look like ["<rootDir>"] for us for now, I guess)
• Figure out how to still be able to mock node modules.

What do you think?

Is there no workaround (without changing your implementation). index exports are really useful and being able to mock them throughout…

A flag to turn off the warning would be good enough for us. Or its outright removal. There’s no added value from this warning. Having two identically named files is impossible on a standard file system. My concern is that if we keep investing in manual mocks we’re going to get flooded by these warnings. They make the DX poor and make our project look clunky and broken.

+1

+1, is there a way to fix this?

When this bug will be fixed? I have __mocks__ folders mocking the same module differently in different folders that conflict with each other. The first one that is resolved when test run is executed is used for all mocking fo that module.

+1 very frustrating to see these warnings. Can’t wait for a fix.

Cool. I might find some time tomorrow to cook up a patch, but no promises though 😅

I think the issue I’m having is related:

if I have a jest.mock(‘src/utils/history’), it also incorrectly mocks the ‘history’ node_module.

https://github.com/cwmoo740/jest-manual-mocks-node-modules

Valid

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.

"modulePathIgnorePatterns": ["<rootDir>/src/react/.*/__mocks__"],.

Still it’s quite weird that mocks are not just unique based on the full path from the root.

this is what worked for me 😃

@karomancer I’ve submitted PR #6037 which will allow you to use a configuration to remove the warnings. As of yet, it hasn’t been merged; I’m waiting for a response from the contributors.

Firstly: Thanks for all the awesome work. Secondly: This is really, quite frustrating. I find myself forced to use jest.mock in the test file when the mocked file shares a name with any other file in the entire codebase that also gets mocked. The hoisting disallows the actual mock to be imported too, so it forces you to duplicate the mock in any two tests that require that file to be mocked, adding to the fragility of the test suite. Are we looking at addressing this? Does FB use this stuff? If yes, then how? 😞

We cannot break the current behavior as we rely on it extremely heavily at Facebook.

What about just a config option to change the behavior of getMockName?

Not too familiar with the internals of jest, but it looks like that is the simplest solution to fix the issue without breaking jest for FB.

This is going to be more complicated than I originally thought. To me, manual mocks should replace the file they’re closest too, ie. something like this:

{ 'aws-sdk': '/Users/project/__mocks__/aws-sdk.js',
  'slack': '/Users/project/__mocks__/slack.js',
  '/Users/project/db/index': '/Users/project/db/__mocks__/index.js',
  '/Users/project/slack/index': '/Users/projects/slack/__mocks__/index.js' }

require('aws-sdk') should resolve to the /Users/project/__mocks__/aws-sdk.js this is a mock for a node_module.

require('./db') (or any path to db) should resolve to: /Users/project/db/__mocks__/index.js.

My understanding of the way to setup jest manual mocks (and there should probably be more documentation if something like the above is used) was that they should be as close to the file being mocked as possible within a __mocks__ directory.

Manual mocks are defined by writing a module in a mocks/ subdirectory immediately adjacent to the module. (https://facebook.github.io/jest/docs/manual-mocks.html)

Given that, the above behavior makes the most sense to me.

Thoughts?

here’s what I came up with 💩

// jest.setup.js

jest.mock('src/my/cool/Scope', () => require('src/my/cool/Scope/__mocks__/Scope.index'))

Heh, I’ve left many such comments myself.

Alternatively, it would be nice if we could force Jest to throw an error when this issue comes up, rather than just warning. Warnings are easily ignored; on my project, I’d prefer that an error be thrown, so the dev who introduced it has to deal with it.

Our directory structure looks the same as @dkundel 's referenced here https://github.com/facebook/jest/issues/2070#issuecomment-301332202 with models and components in their own namespaces with index.js being the default export.

Would prefer to not silence warnings or throw all mocks into a flat directory. Some of our mocks are deeply nested, and the workaround suggested would likely look like jest.mock('pages/index/components/Component', () => require('pages/index/components/Component/_mocks_/index')); in our structure.

Any word?

cc @voideanvalue this may be something you’ll have to think about (namespace manual mocks as part of the new haste implementation).

what about two new config options:

• fullPathMockResolution (defaulted to false to keep existing behavior) coupled with:
• namedMockDirectories: if fullPathMockResolution is enabled, any directories within that array will be resolved with the existing behavior. For the FB use case, this would just be [<rootDir>] like you mention above.

This lets devs opt into the full path resolution so it doesn’t require changes by existing jest installs and also enables the existing behavior for specific directories if they want that.

I think these are some larger changes on the way to get this resolved but I think we need both the singular globalMocks option (could be a string or array of strings) and the hasteModules option which would be an array of paths of haste modules. Most of this code lives in jest-haste-map and jest-resolve. I’m not 100% sure what the right solution will look like yet.

From: Max Sysoev notifications@github.com Sent: Friday, December 9, 2016 8:18:44 AM To: facebook/jest Cc: Christoph Pojer; Mention Subject: Re: [facebook/jest] [bug] duplicate manual mock found in separate directories (#2070)

I can work on PR this sunday, I’m kinda free

@cpojerhttps://github.com/cpojer just to recap - create globalMocks config entry with default value of <rootDir>/mocks. This option regulates use of node-haste within jest by specifying path? Or it will be array of paths?

You are receiving this because you were mentioned. Reply to this email directly, view it on GitHubhttps://github.com/facebook/jest/issues/2070#issuecomment-265958606, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AAA0KAMFc34iKqBDLHZzgaGHqyc3WkAzks5rGQ7kgaJpZM4Kt2DW.

Let’s keep this focused on changing how haste works (whitelist/blacklist rather than on by default). I do think I’d prefer to maintain that <rootDir>/__mocks__ should be the default for node module mocks. We could make this a configuration option as well: “globalMocks” that defaults to <rootDir>/__mocks__. Is anybody willing to work on this?

I fully agree with "haste_modules".

We personally don’t use automocking that much, so I can’t say what’s better, my wild guess is that the "autoMockingPaths" var could be useful and elastic enough. On the contrary I find "automock": "app" too stiff (jest already disabled automocking by default).

The __node_modules_mocks__ could be an option, I agree that rareness compensate for ugliness (in my particular case, we rarely mock node_modules, and when we have to do it, we use jest.mock(...)). The only caveat is: what happens when you have a nested node_modules folder (e.g. src/node_modules), do you have to mock its modules from the global __node_modules_mocks__, a nested version of it, or normally with __mocks__ co-located?

In order:

• Let’s fix manual mocks in Jest!

HURRAY 😄 🎉

• Let’s namespace haste modules and limit them to certain folders/regex whatever.
• Make sure that the current mocking behavior still works for FB, even if that means we have to whitelist certain folders to make haste work (it would just look like [“<rootDir>”] for us for now, I guess)

I’m not sure I understand the needs with haste. What you mean is to give the possibility to say “those modules are haste modules”? If we have four modules: /path_1/a, /path_1/b, /path_2/a, /path_2/c, and the setting is

"haste_modules:" ["/path_1/a", "/path_2/c"]

only /path_1/a and /path_1/b are restricted to exist only in /path_1, so /path_2/c is valid, and /path_2/a raises an error/warning.

I’d say, targets could easily be specific files and entire directories, even with single/double *.

• Figure out how to still be able to mock node modules.

I’d maintain the current behavior:

If the module you are mocking is a node module (eg: fs), the mock should be placed in the same parent directory as the node_modules folder.