Error Cannot read property converageData of null

[jsoneaday]

🐛 Bug Report

When I attempt to run jest --coverage. I get the error above for paths to all my js files. For example as shown below. Having said that when I don't use the coverage flag and just run jest my test does run successfully. I took the react template from visual studio (it uses create-react-app v1) and upgraded jest to version 24.0.0 from 20.0.4. I suspect this has something to do with it.

Failed to collect coverage from C:\Source\ReportingSolution\DEV\Web\Acre.Web.ReportQuery\ClientApp\src\silos\administration\components\Portfolio\ShareClassFeeEditor.js
ERROR: Cannot read property 'coverageData' of null
STACK: TypeError: Cannot read property 'coverageData' of null
    at _default (C:\Source\ReportingSolution\DEV\Web\Acre.Web.ReportQuery\ClientApp\node_modules\jest\node_modules\jest-cli\build\generateEmptyCoverage.js:72:44)
    at Object.worker (C:\Source\ReportingSolution\DEV\Web\Acre.Web.ReportQuery\ClientApp\node_modules\jest\node_modules\jest-cli\build\reporters\coverage_worker.js:51:45)
    at execFunction (C:\Source\ReportingSolution\DEV\Web\Acre.Web.ReportQuery\ClientApp\node_modules\jest-worker\build\workers\processChild.js:165:17)
    at execHelper (C:\Source\ReportingSolution\DEV\Web\Acre.Web.ReportQuery\ClientApp\node_modules\jest-worker\build\workers\processChild.js:149:5)
    at execMethod (C:\Source\ReportingSolution\DEV\Web\Acre.Web.ReportQuery\ClientApp\node_modules\jest-worker\build\workers\processChild.js:153:5)
    at process.on.request (C:\Source\ReportingSolution\DEV\Web\Acre.Web.ReportQuery\ClientApp\node_modules\jest-worker\build\workers\processChild.js:72:7)
    at emitTwo (events.js:126:13)
    at process.emit (events.js:214:7)
    at emit (internal/child_process.js:772:12)
    at _combinedTickCallback (internal/process/next_tick.js:141:11)

To Reproduce

As indicated above

Expected behavior

Expecting a coverage of my code but got the errors indicated and this
----------|----------|----------|----------|----------|-------------------|
File | % Stmts | % Branch | % Funcs | % Lines | Uncovered Line #s |
----------|----------|----------|----------|----------|-------------------|
All files | 14.29 | 0 | 0 | 14.29 | |
index.js | 14.29 | 0 | 0 | 14.29 |... 25,26,27,29,35 |
----------|----------|----------|----------|----------|-------------------|
Test Suites: 1 passed, 1 total
Tests: 1 passed, 1 total
Snapshots: 0 total
Time: 15.854s
Ran all test suites.

Link to repl or repo (highly encouraged)

This would not be possible as it is company code.

Run npx envinfo --preset jest

npx: installed 1 in 10.561s
Path must be a string. Received undefined
npx: installed 1 in 3.611s
C:\Users\dchoi1\AppData\Roaming\npm-cache_npx\8628\node_modules\envinfo\dist\cli.js

System:
OS: Windows 10
CPU: (8) x64 Intel(R) Core(TM) i7-4790 CPU @ 3.60GHz
Binaries:
Node: 8.11.3 - C:\Program Files\nodejs\node.EXE
npm: 6.2.0 - C:\Program Files\nodejs\npm.CMD

[alcferreira]

It happens to me when I have /* istanbul ignore file */
It used to work fine on version 23.6.0

Looking at the changelog, this seems to be related to this change: #7388

[SimenB]

@alcferreira could you put together a reproduction? I'm unable to reproduce this

[alcferreira]

Hi @SimenB, yesterday I managed to workaround this by ignoring the desired file on collectCoverageFrom:

// jest.config.js
module.exports = {
  collectCoverageFrom: [
    'src/**/*.js',
    '!src/**/*.(story|fixtur(e|es)).js',
    '!src/fileToIgnore.js'
  ]
}

I was trying to reproduce it again today but it worked fine after reinstalling dependencies.

So it's all good here, thanks!

[thymikee]

So can we close it?

[jylertones]

I encountered this error today and was intent on reproducing it. But instead, I found the cause and fixed it for myself.

In short, I am using babel-jest. I upgraded jest to 24.0.0 but did not upgrade babel-jest. What I believe (educated guess here) happened is that the coverageData was generated for files run through babel-jest, but only if they were run through the test runner.

TLDR; upgrading both jest and babel-jest to 24.0.0 solved this problem.

[SimenB]

It should be valid to use babel-jest@23 with jest@24. Could you put together a reproduction?

[jylertones]

Here's a repo, with the repro:

https://github.com/jylertones/jest-coveragedata-null

[jeysal]

@mengdage looks like readInitialCoverage can return null. Do you have an idea what is going on?

[mariotsi]

Same issue for me, started to happen on Jest 24, with Jest 23.6.0 worked gine. I've both Jest@24 and babel-jest@24.
The file at which the error refers has /* istanbul ignore file */ on top

[bschlenk]

Here is a minimal repro which doesn't use babel at all: https://github.com/bschlenk/jest-coveragedata-null

Happens when a file has /* istanbul ignore file */, but is also matched by the collectCoverageFrom glob.

Ignoring the file with a negated pattern in collectCoverageFrom feels like a workaround, not a solution. I need to have an entry for each file I want to ignore. And if the files move around, I have to update collectCoverageFrom, whereas using /* istanbul ignore file */ I don't have to update anything.

[morungos]

@bschlenk I just came across this exact scenario and was about to wade in and report it. Literally /* istanbul ignore file */ is all you need to get this exact noisy trace. The error is logged, but the coverage reports all seem complete and miss out the expected files correctly. And yes, the workaround isn't really viable with a large repository, as you can't put all the patterns safely into the jest config.

And yes, @jeysal -- readInitialCoverage has at least three different conditions returning null, so it seems by design and that Jest should handle that situation. So even reading the code makes it clear there is a problem there. It feels like a judicious if (! extracted) return null; might do the trick in generateEmptyCoverage.js

[bschlenk]

Just curious, is this something that would have been caught by typescript's strict null checking? I love that you guys have already completed your migration to typescript!

[SimenB]

In theory yes, but the types aren't accurate enough. See https://github.com/DefinitelyTyped/DefinitelyTyped/blob/b8ad888a0c38884420262330c49be3357516bc66/types/istanbul-lib-instrument/index.d.ts#L61 - it can also return null as evidenced by this bug report

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