Hey @modernserf I ran into the same issue and adding the following to my Jest config helped:

  "haste": {
    "providesModuleNodeModules": [".*"]
  }

It would be really nice to have this supported properly. For me neither the workaround nor any other suggestion made it working. 🙄

What I’m trying to do:

having directory tree

+ monorepo root
| + apps
  | - app1
  | - app2
  | + node_modules
    | + a-package
       | - package.json
       | - index.js
       | - a-test-for-index.test.js
     

a-package.json

{
  ...
  scripts: {
    test: "jest"
  },
  "dependencies": {
    ....
  },
  "devDependencies": {
    "jest": "^24.7.1",
     ....
   }
}

running jest

what I do simply:

$ cd monorepo-root/apps/node_modules/a-package
$ npm run test

results

No tests found, exiting with code 1

results using the workaround

set as part of a-package/package.json jest config

...
  "devDependencies": {
    "jest": "^24.7.1",
     ...
  },
  "jest": {
    "haste": {
      "providesModuleNodeModules": [".*"]
    }
  }
...

… a lot of jest-haste-map warnings …

jest-haste-map: Haste module naming collision: source-map The following files share their name; please adjust your hasteImpl:

• <rootDir>/node_modules/snapdragon/node_modules/source-map/package.json
• <rootDir>/node_modules/source-map/package.json

No tests found, exiting with code 1

results using the workaround & testPathIgnorePatterns

ie I have the following jest config within a-package/package.json:

...
  "devDependencies": {
    "jest": "^24.7.1",
     ....
  },
  "jest": {
    "testPathIgnorePatterns": ["<rootDir>/(node_modules)/"],
    "haste": {
      "providesModuleNodeModules": [".*"]
    }
  }
...

Still without any luck. This time the test has been found and properly loaded however:

FAIL a-test-for-index.test.js ● Test suite failed to run

The name source-map was looked up in the Haste module map. It cannot be resolved, because there exists several different files, or packages, that provide a module for that particular name and platform. The platform is generic (no extension). You must delete or blacklist files until there remains only one of these:

  * `...{full path removed privacy concerns}.../node_modules/@babel/core/node_modules/source-map/package.json` (package)
  * `...{full path removed privacy concerns}.../node_modules/@babel/generator/node_modules/source-map/package.json` (package)
  * `...{full path removed privacy concerns}.../node_modules/snapdragon/node_modules/source-map/package.json` (package)
 * `...{full path removed privacy concerns}.../node_modules/source-map/package.json` (package)

 at ModuleMap._assertNoDuplicates (node_modules/jest-haste-map/build/ModuleMap.js:280:11)

Test Suites: 1 failed, 1 total

---

I’m reporting all the above just to add more context/info on the problem and its possible cause. I have a ton of dependencies within a-package.json (obviously omitted) and seems jest-haste-map gets confused 😃

why

I’m sharing common modules across apps within a monorepo and I cant use symlinks to do the job (thus Lerna isnt an option). The native nodejs require/resolve process works just fine for directory trees as described above, thus I’m able to require/import common modules into apps without ‘magic’ tricks.

All fine until the point which I needed some tests for the common modules of mine which of course are placed within the common modules rendering them under node_modules path which seems is causing problems.

what I think I need

Jest to be able to run as it runs normally - excluding ./node_modules subdirectory relative to the current working directory and be able to do that when the path of the current working directory contains ‘node_modules’ in it 😃

---

update: please excuse me if the above doesnt makes sense or isnt helpful / related to the current github issue

To work around it now, I made a wrapper file:

const Runtime = require('jest-runtime');

const origCreateHasteMap = Runtime.createHasteMap;

Runtime.createHasteMap = function(...args) {
  const ret = origCreateHasteMap.call(this, ...args);
  ret._options.retainAllFiles = true;
  return ret;
};

module.exports = require('jest/bin/jest');

And I run that file instead of the main Jest executable. I’d much rather have a config option if the maintainers are amenable to a pull request…

P.S. I also configured my testPathIgnorePatterns like this:

  "jest": {
    "testPathIgnorePatterns": [
      "<rootDir>/node_modules"
    ]
  }

Not working on 26.0.1, even with mentioned workarounds. It seems that haste field is deprecated now and thus Jest refuses to run tests correctly.

Is there any plans to fix this? It is very strange that Jest ignores tests when the package is places inside node_modules. I think it would be better to check if the test is placed inside the local node_modules rather than just checking if the path includes it.

This issue prevents some decoupling that proves useful when building integration tests that can be shared across multiple of my node services.

The approach I took was to write my integration tests in a new project, and npm install it into each service that would use it, placing the jest installation along with the relevant tests into each respective node_modules folder. Sadly jest refuses to locate any of the tests since node_modules would always exist in the directory path of its parent directory.

Adding all of these items to my jest.config.js apears to be working for me:

module.exports = {
  haste: {
    providesModuleNodeModules: ['.*']
  },
  testPathIgnorePatterns: ['<rootDir>/node_modules/'],
  transformIgnorePatterns: ['<rootDir>/node_modules/'],
  modulePathIgnorePatterns: ['<rootDir>/node_modules/']
};

I believe this is because haste ignores files in all node_modules directories, so files in src/node_modules don’t even make it to where testPathIgnorePatterns is used

xandris solution works fine, but I would like to know, if this is a bug and this suppose to work in near future or these tests are excluded by design.

@kuka-radovan I stopped using that style of monorepo and now recommend npm 7 or yarn workspaces to do inter-module linking rather than relying on the node_modules resolution quirk. As far as Jest is concerned, maybe it shouldn’t make assumptions about node_modules directories. There could be a default heuristic, and Jest could allow the user to override it, but I don’t think it’s worth the effort given the alternatives. 🤷‍♀️

I have the problem too.

We have a package core, which is used by 6 other packages as a framework. core has its own jest tests, but each packageX (where X is from 1 to 6) also has its own tests. We want to yarn add --dev each package to our core package, and run all pacakgeX tests in our core CI. So, we could be sure, we didnt break any backward compatibility for any of packageX.

Not sure how “standard” that approach is, but packageX tests are located in node_modules (of course).

@cpojer did you look at the example repo? I’m using

  "testPathIgnorePatterns": [
    "<rootDir>/(build|config|node_modules)/"
  ]

and its still ignoring src/node_modules.