Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We鈥檒l occasionally send you account related emails.

Already on GitHub? Sign in to your account

Syntax error when running Jest with coverage and watch (example repo included) #6859

Closed
garyking opened this issue Aug 16, 2018 · 11 comments 路 Fixed by #7611
Closed

Syntax error when running Jest with coverage and watch (example repo included) #6859

garyking opened this issue Aug 16, 2018 · 11 comments 路 Fixed by #7611

Comments

@garyking
Copy link

garyking commented Aug 16, 2018

馃悰 Bug Report

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)

To Reproduce

Steps to reproduce the behavior:

  1. Clone this repo.
  2. Create a new branch from 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.
  3. Run yarn test-w. You will get the same error.

I assume the cause is because:

  1. coverage is enabled. It has to be via Jest config collectCoverage: true, and not CLI --coverage.
  2. 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.
  3. This is actually a pretty common scenario, at least for me, so I get this error a lot.

Expected behavior

The error should not happen.

Link to repl or repo (highly encouraged)

The repo is linked to in step 1 of "Reproduce" section above.

Run npx envinfo --preset jest

Paste 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.

@markhu
Copy link

markhu commented Sep 8, 2018

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

@ctsstc
Copy link

ctsstc commented Nov 8, 2018

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 :[

https://github.com/facebook/jest/blob/fbd66d3562ba30b910fc2779f0acd69a7f3ca083/packages/jest-cli/src/runJest.js#L150

@adrianmcli
Copy link

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.

@rodgobbi
Copy link

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"
  ],
}

@MarcoScabbiolo
Copy link
Contributor

MarcoScabbiolo commented Jan 12, 2019

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.

@SimenB
Copy link
Member

SimenB commented Jan 12, 2019

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.

@davalapar
Copy link

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)

@stipsan
Copy link
Contributor

stipsan commented Jan 14, 2019

@SimenB sure I'll take a look 馃槃

@nillo
Copy link

nillo commented Jan 24, 2019

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!

@scripter-co
Copy link

scripter-co commented Feb 1, 2019

ignore the files for now

"coveragePathIgnorePatterns": [
  "/node_modules/",
  "package.json"
]

@github-actions
Copy link

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.

@github-actions github-actions bot locked as resolved and limited conversation to collaborators May 12, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

Successfully merging a pull request may close this issue.