This bug is likely the same as #6258.
In some cases, when I run jest --coverage --watch, I get the following error:
Running coverage on untested files...Failed to collect coverage from /Users/gary/Downloads/Unsorted/test/jest-bug/package.json
ERROR: Unexpected token, expected ; (2:8)
STACK: SyntaxError: Unexpected token, expected ; (2:8)
Steps to reproduce the behavior:
master. Reset HEAD to the commit before HEAD ("add package.json and yarn.lock"), but keep the changes, and unstage them. So now you have a.test.js uncommitted, and package.json has "name": "test" uncommitted.yarn test-w. You will get the same error.I assume the cause is because:
coverage is enabled. It has to be via Jest config collectCoverage: true, and not CLI --coverage.watch is enabled (and it possibly also occurs with watch-all), so only uncommitted changes are watched. In order to reproduce this bug, there needs to be changes to a test file, and changes in a non-JS file, like .eslintrc.json or package.json. The error should not happen.
The repo is linked to in step 1 of "Reproduce" section above.
npx envinfo --preset jestPaste the results here:
System:
OS: macOS High Sierra 10.13.5
CPU: x64 Intel(R) Core(TM) i7-3615QM CPU @ 2.30GHz
Binaries:
Node: 8.11.2 - /usr/local/bin/node
Yarn: 1.9.4 - /usr/local/bin/yarn
npm: 6.4.0 - /usr/local/bin/npm
npmPackages:
jest: ^23.5.0 => 23.5.0
The bug does not exist in 22.4.4. The bug exists in 23.0.0.
Unfortunately, I can't downgrade to Jest 22 for now, since that version has the jsdom errors instead.
One minor difference in my observations: I was able to repro with CLI --coverage switch.
$ jq .jest package.json | grep -i coverage
"collectCoverage": false,
"collectCoverageFrom": [
"coverageDirectory": "./coverage/",
$ npx envinfo --preset jest
System:
OS: macOS High Sierra 10.13.6
CPU: x64 Intel(R) Core(TM) i7-6820HQ CPU @ 2.70GHz
Binaries:
Node: 10.9.0 - /usr/local/bin/node
Yarn: 1.9.4 - /usr/local/bin/yarn
npm: 6.2.0 - /usr/local/bin/npm
npmPackages:
@types/jest: ^23.3.1 => 23.3.1
jest: 23.5.0 => 23.5.0
I hate to bump, but this is still happening w/o any traction behind it 3 months later.
It seems when I do Press w to show more. and then a for all the error doesn't show up that run. I noticed the watcher does run when my json file saves (tsconfig.json) but now I'm not seeing the problem after running the "all" option.
I'm seeing that if I manually set the collectCoverageFrom then I stop getting this. It's important to note that you must restart the watcher for the new jest.config changes to take effect. The documentation says it defaults to undefined but I'm not sure if that means everything, or a default? If it does default it shouldn't do json files it seems.
Maybe it's finagling its way through changedFilesPromise. I unfortunately do not have the time to take the deep dig into this :[
Just wanted to say that I still have this problem as well. It's not critical in our pipeline so I've just ignored the problem for now, but this should really get fixed.
My team was having this problem too, even without the watch mode or trying to use collectCoverage: true. My teammate discovered this solution:
Put into the jest config
"jest": {
...
"coveragePathIgnorePatterns": [
"/node_modules/",
"testconfig.js",
... (any file that doesn't need coverage check but is targeted by the coverage report)
"package.json",
"package-lock.json"
],
}
I think this bug should be marked as confirmed, I've added a skipped (until fixed) regression e2e test in my fork.
It looks like the coverage is being reported on every changed file (even .json files) instead of only the files being tested.
Thank you! Dug into it, and this comes from #5601, specifically https://github.com/facebook/jest/blob/94c40a5dc5df86b8f27e403bde7fff1e33c74e16/packages/jest-cli/src/SearchSource.js#L171-L179
That collectCoverageFrom contains all the untracked files in the repo. I think this filter is supposed to clear out the files that shouldn't be instrumented, doesn't seems like it does in this case: https://github.com/facebook/jest/blob/94c40a5dc5df86b8f27e403bde7fff1e33c74e16/packages/jest-cli/src/runJest.js#L166-L187
Normally https://github.com/facebook/jest/blob/94c40a5dc5df86b8f27e403bde7fff1e33c74e16/packages/jest-cli/src/generateEmptyCoverage.js#L34 would clear it out, but since collectCoverageFrom is set, it doesn't. That's the reason @rodgobbi's workaround works, then Runtime.shouldInstrument correctly filters it out
@stipsan could you take a look? 鉂わ笍 A failing test was added to #7611.
solved this by putting my files in /src/ folder and adding "--collectCoverageFrom=src/*/.js" so the coverage report won't touch package.json (which likely causes the error in my case)
@SimenB sure I'll take a look 馃槃
For me the solution was adding the /build folder to the coveragePathIgnorePatterns
"coveragePathIgnorePatterns": [
"/node_modules/",
"/build/"
];
because it tries to process the whole file, before making a report 馃ぃ
in my case that was about 205900 lines.
cheers!
ignore the files for now
```json
"coveragePathIgnorePatterns": [
"/node_modules/",
"package.json"
]
Most helpful comment
My team was having this problem too, even without the
watchmode or trying to usecollectCoverage: true. My teammate discovered this solution:Put into the jest config