jest --watch hangs silently if moduleNameMapper cannot locate module #4883

ashtonsix · 2017-11-13T15:57:06Z

Bug

jest --watch was getting stuck at Determining test suites to run... and stopped doing anything.

I started debugging ResolveDependencies.resolver.getMockModule inside the jest-resolve package and noticed nothing was getting logged after it was called with a dependency path that failed to map. I fixed the issue by creating the missing files - but tracking down this bug took much longer than it should & it'd have been great to see a helpful error (issues others encountered related to watchman turned out to be red herrings).

  return compact(
      dependencies.map((dependency, i) => {
        console.log(52, i)
        if (this._resolver.isCoreModule(dependency)) {
          return null
        }
        console.log(53, i)
        try {
          return this._resolver.resolveModule(file, dependency, options)
        } catch (e) {}
        console.log(54, file, dependency)
        const mock = this._resolver.getMockModule(file, dependency) || null
        // NEVER LOGGED!! (for files that don't map)
        console.log(55, mock)
        return mock
      })
    )

Expected behavior

I should have seen this error when running jest --watch:

Configuration error:

Could not locate module meteor/raix:eventemitter (mapped as /home/ashton/code/beyond/packages/beyond/private/mocks/meteor/raix_eventemitter)

Please check:

"moduleNameMapper": {
  "/^meteor\/([\w-]+):([\w-]+)$/": "/home/ashton/code/beyond/packages/beyond/private/mocks/meteor/$1_$2"
},
"resolver": undefined

Config + details

Jest 21.0.2
Node 8.5.0
NPM 4.6.1
Ubuntu 16.04

Issue not encountered at all when using --watchAll

My colleagues are using Ubuntu 17.10 & MacOS Sierra but they didn't encounter this issue (or see any related issues).

I think the tests which relied on unmocked meteor libraries were skipped (explaining the apparent lack of errors in some circumstances).

The text was updated successfully, but these errors were encountered:

cpojer · 2017-11-13T16:33:35Z

Do you mind trying this with jest@test to see if this is better now?

ashtonsix · 2017-11-13T16:44:36Z

My directory structure is like

.git/
packages/
  beyond/
    server/
    client/
    package.json
    ...etc

When running jest --watch inside /packages/beyond with jest@test I now get the following error (we have slightly different jest configs for some packages & this made adopting the multi-project stuff / running at top-level more intimidating):

--watch is not supported without git/hg, please use --watchAll

jtulk · 2017-11-22T18:45:35Z

Similar issue: I have the problem where Jest gets stuck determining test suites to run all the time. I think typically import/export declaration mutations from sloppy Git merges are at fault, which would make this consistent with a dependency that failed to resolve. What's the easiest way to debug this since without a hard failure I don't get any indication of 'where' the fail occurs?

Update

This happens sometimes without anything being broken at all. The tests will all pass, but then running with --watch will hang indefinitely. Adding a useless commit (changing whitespace or something) will be enough to get things moving again in watch mode.

ashtonsix · 2017-11-22T19:00:08Z

@jtulk Could you try going to node_modules/jest-resolve/build/index.js, and adding console.error(error) before every line that says throw error?

jtulk · 2017-11-22T20:09:19Z

@ashtonsix Sweet - that works perfectly. Thank you!

anilanar · 2018-01-24T15:23:19Z

Here you go:

jest-haste-map: duplicate manual mock found:
  Module name: index
  Duplicate Mock path: /Users/thatsme/development/src-js/module/Viewport/__mocks__/index.js
This warning is caused by two manual mock files with the same file name.
Jest will use the mock file found in: 
/Users/thatsme/development/src-js/module/Viewport/__mocks__/index.js
 Please delete one of the following two files: 
 /Users/thatsme/development/src-js/@hotelsearch/app-store-search-util/src/__mocks__/index.js
/Users/thatsme/development/src-js/module/Viewport/__mocks__/index.js


jest-haste-map: @providesModule naming collision:
  Duplicate module name: @trivago/<%= name %>
  Paths: /Users/thatsme/development/src-js/@trivago/generator-node-package/src/templates/package.json collides with /Users/thatsme/development/src-js/@trivago/generator-node-package/app/templates/package.json

This warning is caused by a @providesModule declaration with the same name across two different files.
jest-haste-map: @providesModule naming collision:
  Duplicate module name: @trivago/accommodation-map
  Paths: /Users/thatsme/development/src-js/lib/accounts/accommodation-map/package.json collides with /Users/thatsme/development/src-js/@trivago/accommodation-map/package.json

This warning is caused by a @providesModule declaration with the same name across two different files.
{ Error: Cannot find module 'trv-harmony' from '/Users/thatsme/development/src-js/@accounts/app'
    at resolveSync (/Users/thatsme/development/node_modules/jest-resolve/build/default_resolver.js:82:15)
    at defaultResolver (/Users/thatsme/development/node_modules/jest-resolve/build/default_resolver.js:54:374)
    at Function.findNodeModule (/Users/thatsme/development/node_modules/jest-resolve/build/index.js:98:14)
    at resolveNodeModule (/Users/thatsme/development/node_modules/jest-resolve/build/index.js:154:23)
    at Resolver.resolveModule (/Users/thatsme/development/node_modules/jest-resolve/build/index.js:166:16)
    at dependencies.map.dependency (/Users/thatsme/development/node_modules/jest-resolve-dependencies/build/index.js:58:31)
    at Array.map (<anonymous>)
    at DependencyResolver.resolve (/Users/thatsme/development/node_modules/jest-resolve-dependencies/build/index.js:53:18)
    at modules._hasteFS.getAllFiles.map.file (/Users/thatsme/development/node_modules/jest-resolve-dependencies/build/index.js:114:26)
    at Array.map (<anonymous>) code: 'MODULE_NOT_FOUND' }

Well, we have a large codebase with a very complicated jest config. The module/dependency resolver is touching files that are not covered by any test files at all (why is it trying to resolve dependencies for /Users/thatsme/development/src-js/@accounts/app?). I think it is going through all JS files in the project directory?

lebreRafael · 2018-01-24T16:29:42Z

I'm having a similar problem with moduleNameMapper.
I work with some alias in webpack, so I need to add them in moduleNameMapper to run my tests.

"moduleNameMapper": { "^react-native$": "react-native-web", "^shared(.*)$": "<rootDir>/src/shared$1" },

When I did that, jest apparently starts to look at all files under <rootDir> looking for any import that uses the alias shared. My problem is that I have a folder with old code at <rootDir> that use some files under shared alias that no more exists, so the test never runs.

Obs: I can be sure that shared in moduleNameMapper is the reason due to the console.log() cited above.

phouri · 2018-01-25T08:53:31Z

I'm having the same issue, with the moduleNameMapper jest --watch hangs.
Removing the moduleNameMapper it works (well, runs the tests and fails kind of work ;) ).

Adding the console.error in the jest-resolve didn't show anything.

My project structure is like this:

root/
    .git
    package.json
   client/
       package.json (jest here)
   server/
       package.json (jest here)

Update:

Realised I was running global jest command - so my changes had no effect.
When running the correct one, shows that moduleNamerResolver is throwing tons of errors - it works correctly not in watch mode though.

Update#2:

Seems like the problem comes from this:

Could not locate module @/components/icons/rating-${this.symbol} (mapped as .../client/src/components/icons/rating-${this.symbol})

Update 3: ;)
Solved with a stub:
"^@/.*/rating-(.*)$": "<rootDir>/test/stub.js" since this file is not needed for tests.

But in a real dynamic import scenario, how can this be solved?

lebreRafael · 2018-01-26T13:37:42Z

Today I added one more line in moduleNameMapper and my problem is gone.
I did somes tests and seems that the line in moduleNameMapper that is the problem (the line containing the alias used in some place to point to a non existing file) can't be the last one.

UPDATE

Sorry, I was wrong! The reason that my test is running fine is that no tests are running because I didin't change any files covered by tests.

AlexTwine · 2018-02-09T17:39:06Z

Having same problems when specifying items under moduleNameMapper. e.g.

"moduleNameMapper": {
      "^components/(.*)": "<rootDir>/src/components/$1"
}

thymikee · 2018-02-16T14:57:46Z

It's hard to test it without a downloadable repro. Can you provide one?

dgsmith2 · 2018-02-19T16:29:53Z

FWIW, I was encountering this as well. I expanded the console logging to be:

console.log(updatedName, {
              basedir: dirname,
              browser: this._options.browser,
              extensions,
              moduleDirectory,
              paths,
              resolver,
              rootDir: this._options.rootDir }, error);

In doing this I noticed that basedir referred to a path that pertained to a coverage folder that was created by karma (I'm in the process of migrating to jest). I deleted coverage and jest --watch worked. At least in my case, it appears jest was consuming karma's coverage folder and some bit of content in it led to a module resolution attempt. This does not occur if I have multiple coverage directories created by jest.

alloy · 2018-02-20T13:35:16Z

@ashtonsix Thanks, your suggestion helped me pinpoint the issue (in my case I had to add some submodules to modulePathIgnorePatterns) 👍

@thymikee With these steps multiple people could repro, but 1 person wasn’t, so there’s something additionally different in their env. There’s a good chance you’d be able to repro it, though, so if you checkout our repo at artsy/emission@5038138, then perform these steps:

yarn install
yarn jest --watch works fine.
Checkout submodules git submodule update --init
yarn jest --watch hangs on “Determining test suites to run...”
Hot-patch jest as per @ashtonsix’s suggestion.

Run yarn jest --watch again and see an error like:

Error: Configuration error:

Could not locate module lib/loaders/legacy/gravity (mapped as /Users/eloy/Code/Artsy/emission/src/lib/loaders/legacy/gravity)

Please check:

"moduleNameMapper": {
  "/^lib\/(.*)/": "/Users/eloy/Code/Artsy/emission/src/lib/$1"
},
"resolver": undefined]

Add "modulePathIgnorePatterns": ["<rootDir>/externals"] to jest config in package.json.
Run yarn jest --watch again and notice it works fine now.

thymikee · 2018-02-20T14:15:37Z

Thanks @alloy, I'll have a look

thymikee · 2018-02-20T16:34:14Z

I can definitely repro that, still no idea what's the case :D

danielkcz · 2018-04-04T11:10:06Z

I am encountering a similar issue. Running jest --watchAll or jest --watch fileNamePattern works fine. Apparently, the issue is more likely about detecting files that have been changed since the last commit. When running --watchAll and later changing to only run tests related to changed files by hitting o key, it gets stuck the same way.

I am using moduleNameMapper as well, but it doesn't sound right it would be an issue when watching changed files only.

I tried suggestion #4883 (comment) and a bunch of errors that mapped module is not found pops out indeed. However, once again, it does work when watching in the other mode then 'changed only'. How is there such a huge difference?

troywatt · 2018-04-18T15:41:49Z

FWIW, I followed the suggested comment #4883 as well to log resolver errors to the console. I noticed in the logs the test runner was loading some legacy modules in my project that I thought I had deleted during a refactor that were trying to import other modules that had actually been deleted.

This was causing a "Module not found" error. Deleting any old files that were attempting to import non-existing files fixed the issue for me.

Update:

I should add that I am also using moduleNameMapper and that the module it was failing on was being referenced with an alias.

justin-calleja · 2018-06-22T19:22:54Z

@ashtonsix thanks! I was able to get enough context with the console log.

It was picking up code in a vscode plugin under the .history directory. Code I was working on in a different branch and which didn't exist in the current one.

It only seems to look in .history when using --watch. I could not configure jest to ignore .history when using watch - but deleting .history did the trick.

P.S. I tried using the following to configure jest with no luck:

//   testPathIgnorePatterns: ["<rootDir>/node_modules/", "<rootDir>/.history/"],
//   "coveragePathIgnorePatterns": ["<rootDir>/node_modules/", "<rootDir>/.history/"],
  "coveragePathIgnorePatterns": ["/node_modules/", "/.history/"],

swcisel · 2018-06-27T17:02:00Z

@justin-calleja I'm having the same issue. Have you figured out how to configure jest to correct it? I'd like to avoid moving my .history out of my project directory if possible.

justin-calleja · 2018-06-27T21:09:59Z

@swcisel nope sorry. I deleted my .history. I don't really use it. It wasn't worth playing around with jest to get it to ignore .history. AFAIC, this is a bug in jest's watch mode - I don't see why I should configure it to ignore hidden directories - why would I put tests in hidden directories!?

thymikee · 2018-07-16T08:52:18Z

This should be fixed by #6407. Please let me know otherwise

KagamiChan · 2018-08-03T07:50:17Z

It is great that I could know why my --watch hangs, but I'm curious why my mapped module could not be located under watch mode but work well under watchAll mode. Could someone give me a hint?

I'm sorry it's off topic

dereklin · 2018-08-09T00:30:05Z

Same question as @KagamiChan. I have deleted a module physically. If I try to search for that module, it's not in my source code. Does --watch remember the the old mappings? Is there a way to clean up any cache it might have?

Kepro · 2018-08-17T14:14:08Z

same issue here...
$ node scripts/test.js --env=jsdom --watchAll --notify
working well
$ node scripts/test.js --env=jsdom --coverage --notify
working well

$ node scripts/test.js --env=jsdom --notify
FAIL

Configuration error:

Could not locate module @/types/i18next mapped as:
/Projects/web-gui/src/types/i18next.

Please check your configuration for these entries:
{
"moduleNameMapper": {
"/^@/(.*)/": "/Projects/web-gui/src/$1"
},
"resolver": null
}

I tested it with the latest JEST 23.5.0

@thymikee any workaround or how can I help to fix this issue?

jktravis · 2018-11-05T19:02:37Z

I've just encountered the problem. Only happens in watch mode, but watchAll works fine. It complains about a module that has been removed. Running grep -irl <moduleName> <scriptsDir> shows no results. I also tried running with --no-cache with no luck.

Version info:
"jest": "^23.6.0",
"ts-jest": "^22.4.6",

dereklin · 2018-11-05T20:05:45Z

Did you delete the test coverage folder?

jktravis · 2018-11-05T20:14:46Z

Huh. I was messing with another problem earlier and was just nuking lock files, node_modules and my build folder, and never went back to check this particular problem. But I bet that was it.

okonet · 2018-11-14T14:34:34Z

I've identified this to be a configuration issue. We didn't have rootDir so Jest was looking from the root directory and was picking up /build directory. Removing directory solved it, but the proper solution is to specify rootDir option and point it to src/ directory of your project.

mikew · 2018-12-26T23:31:48Z

I'm seeing this with create-react-app, where rootDir is correctly set. Could also have something to do with the fact that we're using TypeScript, and the file jest is complaining about is a .d.ts file.

grantcarthew · 2019-05-17T12:06:42Z

I'm having this issue now.

Here is the error after injecting some console.error statements:

Error: Cannot find module 'jest-environment-/fm/fm-api/tests/setup/mongo-environment.js' from '/fm/fm-api'
    at resolveSync (/fm/fm-api/node_modules/jest-resolve/build/defaultResolver.js:119:15)
    at defaultResolver (/fm/fm-api/node_modules/jest-resolve/build/defaultResolver.js:71:10)
    at Function.findNodeModule (/fm/fm-api/node_modules/jest-resolve/build/index.js:112:14)
    at resolveWithPrefix (/fm/fm-api/node_modules/jest-config/build/utils.js:158:39)
    at getTestEnvironment (/fm/fm-api/node_modules/jest-config/build/utils.js:204:3)
    at normalize (/fm/fm-api/node_modules/jest-config/build/normalize.js:569:59)
    at readConfig (/fm/fm-api/node_modules/jest-config/build/index.js:163:46)
    at readConfigs (/fm/fm-api/node_modules/jest-config/build/index.js:372:26)
    at /fm/fm-api/node_modules/@jest/core/build/cli/index.js:155:58
    at Generator.next (<anonymous>) {
  code: 'MODULE_NOT_FOUND'
}
Error: Cannot find module 'jest-sequencer-@jest/test-sequencer' from '/fm/fm-api'
    at resolveSync (/fm/fm-api/node_modules/jest-resolve/build/defaultResolver.js:119:15)
    at defaultResolver (/fm/fm-api/node_modules/jest-resolve/build/defaultResolver.js:71:10)
    at Function.findNodeModule (/fm/fm-api/node_modules/jest-resolve/build/index.js:112:14)
    at resolveWithPrefix (/fm/fm-api/node_modules/jest-config/build/utils.js:158:39)
    at getSequencer (/fm/fm-api/node_modules/jest-config/build/utils.js:262:3)
    at normalize (/fm/fm-api/node_modules/jest-config/build/normalize.js:1012:54)
    at readConfig (/fm/fm-api/node_modules/jest-config/build/index.js:163:46)
    at readConfigs (/fm/fm-api/node_modules/jest-config/build/index.js:372:26)
    at /fm/fm-api/node_modules/@jest/core/build/cli/index.js:155:58
    at Generator.next (<anonymous>) {
  code: 'MODULE_NOT_FOUND'
}

It looks like Jest is replacing parts of the module names with other modules or paths.

Any ideas?

uname -a

Linux dev 4.19.0-5-amd64 #1 SMP Debian 4.19.37-2 (2019-05-14) x86_64 GNU/Linux

thymikee · 2019-05-17T12:27:04Z

@grantcarthew if you can create a repo with a minimal repro we can download, feel free to create a new issue

grantcarthew · 2019-07-24T00:06:53Z

Hi @thymikee, it is a private project so I can't really upload it to a public repository.

This is still an issue and is becoming more so.

At home I run a desktop with Debian Unstable. This was the first machine I saw the issue. I just upgraded my dev virtual machine on my laptop to Debian Buster. It now has the same issue. It looks like it is an issue with Buster and my setup.

Buster was released on the 4th July, so it is only new.

grantcarthew · 2019-07-24T00:10:25Z

I tried removing the --watch parameter and now it writes Determining test suites to run... then just returns to the console prompt.

grantcarthew · 2019-07-24T03:13:50Z

I've found the cause.
In my global setup the call to await mongod.start() is not returning.
I'm using https://github.com/nodkz/mongodb-memory-server

grantcarthew · 2019-07-24T04:46:03Z

I've raised an issue with the mongodb-memory-server repo: typegoose/mongodb-memory-server#204
Thanks for your hard work everyone.

geyuqiu · 2019-09-13T08:32:24Z

for me the error message reveals itself after I moved a .ts file to another directory.
However run jest without watch mode runs successfully.
But I could not understand how this error message is helpful ? Because --watch is not working after renamed a directory and the according import command?
@ashtonsix

@dereklin deleting the test coverage folder worked for me thx :)

hasparus · 2020-10-05T15:17:36Z

Could you try going to node_modules/jest-resolve/build/index.js, and adding console.error(error) before every line that says throw error?

Okay, I just added console.error and found a ModuleNotFoundError, but I wanted to ask:
Why does Jest hang instead of crashing? Swallowing errors doesn't seem like a good idea IMHO.

Liboul · 2020-11-27T11:41:44Z

For me, jest started hanging after moving converting the option testResultsProcessor to the option reporters.
Reverting this change fixed the issue...

github-actions · 2021-05-11T01:29:20Z

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.
Please note this issue tracker is not a help forum. We recommend using StackOverflow or our discord channel for questions.

eddyerburgh mentioned this issue Jan 17, 2018

Cannot resolve module when using --watch flag vuejs/vue-jest#46

Closed

thymikee added the Needs More Info 🤷‍♂️ label Feb 16, 2018

thymikee removed the Needs More Info 🤷‍♂️ label Feb 20, 2018

tpai mentioned this issue Jun 20, 2018

Jest watch hangs on "Determining Tests Suites to Run..." tpai/tpai.github.io#47

Open

Oliboy50 mentioned this issue Jul 3, 2018

behaviour of test:unit --watch changed? vuejs/vue-cli#1391

Closed

thymikee closed this as completed Jul 16, 2018

Szymon-dziewonski mentioned this issue Nov 4, 2020

"Could not locate module", but only in watch mode #9647

Closed

github-actions bot locked as resolved and limited conversation to collaborators May 11, 2021

jest --watch hangs silently if moduleNameMapper cannot locate module #4883

jest --watch hangs silently if moduleNameMapper cannot locate module #4883

Comments

ashtonsix commented Nov 13, 2017 • edited Loading

cpojer commented Nov 13, 2017

ashtonsix commented Nov 13, 2017 • edited Loading

jtulk commented Nov 22, 2017 • edited Loading

ashtonsix commented Nov 22, 2017 • edited Loading

jtulk commented Nov 22, 2017

anilanar commented Jan 24, 2018 • edited Loading

lebreRafael commented Jan 24, 2018 • edited Loading

phouri commented Jan 25, 2018 • edited Loading

lebreRafael commented Jan 26, 2018 • edited Loading

UPDATE

AlexTwine commented Feb 9, 2018

thymikee commented Feb 16, 2018

dgsmith2 commented Feb 19, 2018

alloy commented Feb 20, 2018

thymikee commented Feb 20, 2018

thymikee commented Feb 20, 2018

danielkcz commented Apr 4, 2018 • edited Loading

troywatt commented Apr 18, 2018 • edited Loading

justin-calleja commented Jun 22, 2018 • edited Loading

swcisel commented Jun 27, 2018

justin-calleja commented Jun 27, 2018

thymikee commented Jul 16, 2018

KagamiChan commented Aug 3, 2018 • edited Loading

dereklin commented Aug 9, 2018

Kepro commented Aug 17, 2018 • edited Loading

jktravis commented Nov 5, 2018

dereklin commented Nov 5, 2018

jktravis commented Nov 5, 2018

okonet commented Nov 14, 2018

mikew commented Dec 26, 2018

grantcarthew commented May 17, 2019

thymikee commented May 17, 2019

grantcarthew commented Jul 24, 2019

grantcarthew commented Jul 24, 2019

grantcarthew commented Jul 24, 2019 • edited Loading

grantcarthew commented Jul 24, 2019

geyuqiu commented Sep 13, 2019 • edited Loading

hasparus commented Oct 5, 2020

Liboul commented Nov 27, 2020

github-actions bot commented May 11, 2021

ashtonsix commented Nov 13, 2017 •

edited

Loading

ashtonsix commented Nov 13, 2017 •

edited

Loading

jtulk commented Nov 22, 2017 •

edited

Loading

ashtonsix commented Nov 22, 2017 •

edited

Loading

anilanar commented Jan 24, 2018 •

edited

Loading

lebreRafael commented Jan 24, 2018 •

edited

Loading

phouri commented Jan 25, 2018 •

edited

Loading

lebreRafael commented Jan 26, 2018 •

edited

Loading

danielkcz commented Apr 4, 2018 •

edited

Loading

troywatt commented Apr 18, 2018 •

edited

Loading

justin-calleja commented Jun 22, 2018 •

edited

Loading

KagamiChan commented Aug 3, 2018 •

edited

Loading

Kepro commented Aug 17, 2018 •

edited

Loading

grantcarthew commented Jul 24, 2019 •

edited

Loading

geyuqiu commented Sep 13, 2019 •

edited

Loading