jest: jest --watch hangs silently if moduleNameMapper cannot locate module

@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?

I can definitely repro that, still no idea what’s the case 😄

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?

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

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

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 😃

Did you delete the test coverage folder?

This should be fixed by https://github.com/facebook/jest/pull/6407. Please let me know otherwise

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?

@ashtonsix Sweet - that works perfectly. Thank you!

I’ve raised an issue with the mongodb-memory-server repo: https://github.com/nodkz/mongodb-memory-server/issues/204 Thanks for your hard work everyone.

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”,

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?

@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/"],

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.