jest --watch fails to determine files to run tests against if there are changes since last commit

[blackholegalaxy]

Do you want to request a feature or report a bug?

Bug

What is the current behavior?

We have an angular project using jest. Jest uses git to determine file changes and run tests against these files.

Clean project

If the project is "clean" with no change since last commit, then running jest --watch starts properly. Then we can use it normally, it detects changes properly and run expected tests suits.

Dirty project

if the projects has changes on certain files since last commit and we try to run jest --watch then Jest struggles to start and stay forever on the Determining test suites to run... state. Any change after that doesn't change the stuck jest state.

If we revert our changes (nothing to be commited) then retry to launch jest --watch works. So it seems it's a real problem with git changes detection by Jest.

Environment

This behavior is always encountered on windows. And sometimes on mac OS.

What is the expected behavior?

Being able to run jest --watch even if there are modified files since last commit. If the changes files are not detected properly we expect to be able to even load jest and being able to pattern filter on the files we want.

Please provide your exact Jest configuration

module.exports = {
  setupTestFrameworkScriptFile: "<rootDir>/src/setupJest.ts",
  globals: {
    'ts-jest': {
      'tsConfigFile': 'src/tsconfig.spec.json'
    },
    '__TRANSFORM_HTML__': true
  },
  transform: {
    '^.+\\.(ts|js|html)$': '<rootDir>/node_modules/jest-preset-angular/preprocessor.js',
  },
  testMatch: [
    "**/__tests__/**/*.+(ts|js)?(x)",
    "**/+(*.)+(spec).+(ts|js)?(x)"
  ],
  moduleFileExtensions: [
    'ts',
    'js',
    'html'
  ],
  moduleNameMapper: {
    "assets/(.*)": "<rootDir>/src/assets/$1"
  },
  transformIgnorePatterns: [
    'node_modules/(?!@ngrx)'
  ],
  coverageReporters: ['html', 'text-summary', 'text']
};

Run npx envinfo --preset jest in your project directory and paste the
results here

System:
    OS: Windows 10
    CPU: x64 Intel(R) Core(TM) i7-6700K CPU @ 4.00GHz
  Binaries:
    Yarn: 1.6.0 - C:\Program Files (x86)\Yarn\bin\yarn.CMD
    npm: 5.8.0 - C:\Program Files\nodejs\npm.CM

  System:
    OS: macOS High Sierra 10.13.4
    CPU: x64 Intel(R) Core(TM) i7-6700HQ CPU @ 2.60GHz
  Binaries:
    Node: 8.11.1 - /usr/local/bin/node
    Yarn: 1.6.0 - /usr/local/bin/yarn
    npm: 5.6.0 - /usr/local/bin/npm
  npmPackages:
    @types/jest: 22.2.3 => 22.2.3
    jest: 22.4.3 => 22.4.3

[SimenB]

I've never encountered this... Are you able to set up a reproduction for it?

[blackholegalaxy]

basically, how can I show a reproduction of that? Any git project using this config and jest --watch has the problem to me.

[eugene-sea]

I'm having the same issue. It is interesting jest --watch starts to work if I remove custom moduleNameMapper from jest.config.js:

moduleNameMapper: {
    "@app/(.*)": "<rootDir>/src/app/$1",
    "@sdk/(.*)": "<rootDir>/src/sdk/$1",
    "@mocks/(.*)": "<rootDir>/src/mocks/$1"
}

I need it.

[blackholegalaxy]

I also need moduleNameMapper.

@SimenB Here is a recording of the problem:

For your information:

• running without clearCache doesn't solve the problem
• running with watchAll works

So it's certainly a git change detection problem within jest. As you can see VSCode detects the change in control versioning panel, also is my command line (master switching to red).

[SimenB]

I'm unable to reproduce, so if you can put together a minimal repo showing the error (if only just on your amchine), that'd be great!

[eugene-sea]

@SimenB, I have added tracing to jest and was able to find root cause of the issue in my case. Please, see image below. There was an error inside jest-resolve-dependencies and it was "eaten" without any reporting causing jest to stuck.

The problem was related to coverage folder (produced by karma), it contained some garbage but jest was trying to work with it contents. I have added the following to jest.config.js and jest now works OK:

modulePathIgnorePatterns: ['<rootDir>/coverage/'],

jest-resolve-dependencies error handling can be improved to not hide such errors.
Thank you for your work on such great tool anyway.

[SimenB]

Great that you were able to find a fix! Are you able to set up a reproduction though, so we at least can fix the swallowed error?

[eugene-sea]

To fix swallowed error I would suggest to throw error inside this.resolve(file, options) from image above and ensure it is correctly reported.

[SimenB]

I agree, but we don't swallow it on purpose. A reproduction would help us narrow down where the error is and fix it

[aryzing]

Having a similar issue that might be related: I've deleted the entire moduleNameMapper section, and yet, tests continue to pass! Should not happen since I'm using custom module names that clearly do not exist in my node_modules. I suspect it must be a caching issue, since when I boot up a brand new docker instance, the tests fail as expected when the moduleNameMapper section is not present, yet on my local machine they continue to pass.

[evpozdniakov]

Had similar issue. Added try-catch (as @eugene-sea suggested) and found few files referenced to non-existing dependencies, e.g.

// adminCleanup.js (some legacy entry file, excluded from entry points in webpack.config.js)
import finalize from 'vks/vks-base'; // vks-base.js was renamed
...

I tried to add these files into watchPathIgnorePatterns, but it did not help. Had no choice but rework the code.

[SimenB]

I think this was fixed in #6407 available in 23.4.0. Happy to reopen if that's not the case

[dereklin]

I am use 23.4.2 and it's not fixed.

[SimenB]

Did you try jest --clearCache? or --noCache

[dereklin]

My previous report about fixing it is wrong. I thought i was fixed, but then I can do --watch one more time, the same problem happened.

Then I did --clearCache, but it didn't fix the problem. when I did --noCache, I get:

> jest "--noCache"

● Unrecognized CLI Parameter:

  Unrecognized option "noCache".

  CLI Options Documentation:
  https://jestjs.io/docs/en/cli.html

Still looking for a solution...

[dereklin]

Oh. Should have read each comment here carefully. The issue is with the coverage folder. Apparently the coverage was referring to some old code that was deleted, and jest is still trying to find it. Deleting the coverage folder fixes the issue for me.

[ghost]

@dereklin this was exactly it, thanks for posting the fix.

[distante]

It would be really great if the error showed where was the wrong file found. I had no idea my old coverage folder was the problem.

[github-actions]

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.