TypeError: Cannot read property 'locations' of undefined #322
Comments
|
It looks like karma-coverage depends on the deprecated istanbul module. I suspect this is why it is generating coverage files that are incompatible with nyc (lacking fields required by the HTML report). See karma-runner/karma-coverage#375 for the ticket about migrating away from the |
|
hello @coreyfarrell , I also meet this error in my project, is there any update for this issue? I'm writing Typescript codes, and only run these codes on Node.js environment. I'm using I'm running my tests using And this is my nyc config:
|
Frequently users run `nyc --all` in a way that causes source files to be transpiled for actual testing but not transpiled for `--all`. This produces incompatible coverage data and inconsistantly wrong reporting. The work around here is to drop coverage produced by `--all` for any file where we have coverage produced by actual test runs. This ensures that we prefer code that was transpiled in the way which tests actually ran. Fixes #123, #224, #260, #322, #413
|
I have the same issue, but it is non consistent.... |
|
Same issue here after merging cypress coverage with jest coverage using nyc. All of them use the same versions of the istanbul libraries. The separate reports look fine. |
|
@D0rmouse this issue is about karma. I don't know how cypress coverage works or even what module enables it, but I have seen a number of recent reports about issues with cypress. In any case please open a new bug including all required information. For those who originally posted this issue |
|
I'd rather say this issue is about this error message. I got it through another route, as did @zhaochy1990 with Mocha. My dependencies: I use "babel-plugin-istanbul@6.0.0" to instrument my code that is tested by Cypress, which is also used by Jest. |
|
I just got code coverage up and am having this same issue on half my application files. |
|
I was able to reproduce this on a little demo project I've been playing around this when using v8toistanbul to convert v8 coverage reports and merge them into a coverage map. What appears to be happening is that merging doesn't merge the branch/statement/functionMap's together, but it does merge the hit counts, and "annotating" expects those hit counts to have the same number of branches/statements/functions as the other FileCoverage object it's merging in. In my case, it doesn't. On one such file I've got in my project that's demonstrating this problem, the first This results in the final merged It's worth noting that as long as later Here's the relevant code in my project: And here are the pre-merge I suspect the people above that reported this are encountering this same bug. |
|
A quick skim through the issues for this project shows lots of bugs related to this. It seems like that merge function needs to get smarter. |
|
Same, it happens to me when I follow this guide which shows how to merge coverage from Jest and Cypress |
|
We are experiencing the same. Our situation is the following; The files are generated using the babel-loader in combination with webpack. The tests are initiated by cypress. The trouble occurs in a monorepo, with multiple libraries and applications. The focus is on the e2e tests and do units tests for the missing parts. So unit tests in a library do not always cover all the files, but are still mentioned in the generated I currently narrowed it down to two *.json files with coverage referencing a single file in which the error occurs. In the first In 'TypeError: Cannot read property 'locations' of undefined' The two jsons are located in a folder I also tried using the merge command first: So this looks very similair to istanbuljs/nyc#1302 |
|
@JustinChristensen just released your changes, thank you for the contribution 👏 @bennycode, @petermanders89, etc., does this help your situation at all? |
|
@bcoe Unfortunatly this caused a new error for me: This is probably caused by the following example. I have got two One: Two: |
|
I'll look at this later on tonight. This looks like one of the invariants I
mentioned I was worried about holding about the shape of these objects.
…On Thu, Sep 23, 2021, 10:36 AM petermanders89 ***@***.***> wrote:
@bcoe <https://github.com/bcoe> Unfortunatly this caused a new error for
me:
Cannot destructure property 'start' of 'undefined' as it is undefined.
This is probably caused by the following example. I have got two *.json
files. Note that this is a striped so not all the coverage is shown. The
first file does not show any coverage. Probably imported/compiled, but not
used at all. The one the file is used and it has coverage. Mapping them
together could probably indicate that start is undefined in the 0 object.
Before the update it was working, but with the location errors. Now it
doesnt work at all anymore.
One:
"/grid.ts": {
"path": "/grid.ts",
"statementMap": {},
"fnMap": {},
"branchMap": {},
"s": {},
"f": {},
"b": {}
},
Two:
{
"/grid.ts":{
"path":"/grid.ts",
"statementMap":{
"0":{
"start":{
"line":59,
"column":4
},
"end":{
"line":59,
"column":41
}
},
"1":{
"start":{
"line":63,
"column":4
},
"end":{
"line":63,
"column":35
}
}
},
"fnMap":{
"0":{
"name":"(anonymous_0)",
"decl":{
"start":{
"line":58,
"column":2
},
"end":{
"line":58,
"column":3
}
},
"loc":{
"start":{
"line":58,
"column":27
},
"end":{
"line":60,
"column":3
}
},
"line":58
}
},
"branchMap":{
"0":{
"loc":{
"start":{
"line":73,
"column":4
},
"end":{
"line":75,
"column":5
}
},
"type":"if",
"locations":[
{
"start":{
"line":73,
"column":4
},
"end":{
"line":75,
"column":5
}
},
{
"start":{
"line":73,
"column":4
},
"end":{
"line":75,
"column":5
}
}
],
"line":73
}
},
"s":{
"0":710,
"1":408,
"2":408,
"3":408,
"4":408,
"5":408,
"6":408,
"7":408,
"8":408
},
"f":{
"0":710,
"1":408,
"2":2688,
"3":1764,
"4":1764
},
"b":{
"0":[
380,
28
],
"1":[
58,
1136
],
"2":[
88,
1048
],
"3":[
30,
58
]
},
"_coverageSchema":"1a1c01bbd47fc00a2c39e90264f33305004495a9",
"hash":"ff6e72e6654cd65218b6f03b003f3b5946223bbc"
}
}
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#322 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAJ6NHH75VPHCUMK6IRUICTUDNCOLANCNFSM4G4DJZPA>
.
Triage notifications on the go with GitHub Mobile for iOS
<https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675>
or Android
<https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.
|
|
This particular error you're running into is that you've got hit counters in I'm not sure how you'd even get into that state, but I don't believe it has anything to do with merging two |
|
At least, that's invariant I believe is expected to hold. That is, that there will always be a corresponding entry in a "xMap" for every hit counter in "x". |
|
My improvement makes it so two |
|
Oh, @petermanders89, you said those examples are from JSON files. If those were the output of some process that was using the previous |
|
@JustinChristensen The situation this occured for me is the following. We've got a monorepo with multiple apps and libraries. All libraries and apps are tested with The output without So in the first ouptut the file has coverage (the app output), but in the second one it has none (the lib output). Both are correct in my situtation. So the files are generated seperatly, not using any merge before. I am not completely aware if the I am not completely aware on how the library works. Generating code-coverage based on the individual |
|
The empty JSON file you showed is perfectly valid and not a concern at all. The above rambling I was doing was referring to the fact that, for example, in your second file And this is why you're seeing the error. My merge logic iterates through the hit counters in You shouldn't even be in this state coming into the merge. |
|
So the bug you're running into is pre-merge. I.e., not something my fix would have anything to do with. |
|
@docwhite, @craig-dae, @bennycode would you be able to verify whether @JustinChristensen's fix addresses the issue for you? |
|
@JustinChristensen Oh no, both are valid. But I stripped down the file. I didnt want to output a 500 line file here. If I run coverage seperatly on each file, the output is valid (html, or summary), but when merging it throws the error. |
|
@petermanders89 The example you showed isn't valid. |
|
Downgrading to 3.0.0 fixes it |
|
@etaoins @bcoe The reason this behavior wasn't happening pre 3.0.1 is because the old version of merge was making the assumption that the entries in So my new merge algorithm errors here because it's expecting |
getting this error when trying to view the html report for some files: istanbuljs/istanbuljs#322
|
@bcoe I took a quick peek at this, and I that'll be all I'll have time for, but I think it has to do with Jest and other libraries' use of Istanbuls instrumentation faculties. Jest gets it's I see that Hopefully that helps. |
|
@etaoins would you be able to provide a repository with a minimum reproduction of the issue you're seeing? I believe I have a fix. |
|
@bennycode there's a chance you wandered on from this issue, as it's been a couple years. But, @JustinChristensen's fixes, along with a couple follow on fixes appear to have addressed your original issue:
|
|
I haven't minimised the repo but I can confirm it works again with |
|
@bcoe, three years later I updated the dependencies and verified the fix! Thank you for getting it done. Better late than never. 😊 |
@bennycode there's a chance I'm a little over committed on open source, will do my best to hav a slightly quicker turn over for future bugs 😝 Thanks @JustinChristensen for dusting this off and getting the fix most of the way there. |
|
No problem :)
…On Mon, Oct 18, 2021, 8:44 AM Benjamin E. Coe ***@***.***> wrote:
Better late than never.
@bennycode <https://github.com/bennycode> there's a chance I'm a little
over committed on open source, will do my best to hav a slightly quicker
turn over for future bugs 😝
Thanks @JustinChristensen <https://github.com/JustinChristensen> for
dusting this off and getting the fix most of the way there.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#322 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAJ6NHB36ACSXH7F7QLGABLUHQQETANCNFSM4G4DJZPA>
.
Triage notifications on the go with GitHub Mobile for iOS
<https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675>
or Android
<https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.
|
|
Same issue here, when use
My minimal reproduce part is interface foo {
bar: Buffer
}Within Two ways both work. import type {Buffer} from 'buffer'
interface foo {
bar: Buffer
}
But I guess |
Both these packages have gone up a version and provide new tooling (specifically v8-to-istanbul) that is critical for code coverage remapping. This also adds the istanbul-lib-coverage package explicitly as a recent bug (istanbuljs/istanbuljs#322) causes the reports to return with "Cannot find locations of undefined". It is fixed when using version 3.0.2. Bug: 1337530 Test: ./update_npm_deps Change-Id: I6a10ec492707545e6b3ee90db4598997562eae3f Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3761783 Commit-Queue: Ben Reich <benreich@chromium.org> Reviewed-by: Tibor Goldschwendt <tiborg@chromium.org> Cr-Commit-Position: refs/heads/main@{#1024532}
Both these packages have gone up a version and provide new tooling (specifically v8-to-istanbul) that is critical for code coverage remapping. This also adds the istanbul-lib-coverage package explicitly as a recent bug (istanbuljs/istanbuljs#322) causes the reports to return with "Cannot find locations of undefined". It is fixed when using version 3.0.2. Bug: 1337530 Test: ./update_npm_deps Change-Id: I6a10ec492707545e6b3ee90db4598997562eae3f Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3761783 Commit-Queue: Ben Reich <benreich@chromium.org> Reviewed-by: Tibor Goldschwendt <tiborg@chromium.org> Cr-Commit-Position: refs/heads/main@{#1024532} NOKEYCHECK=True GitOrigin-RevId: f434ed5f6727d647dd8a2aa82970a15e6f40b18b
Frequently users run `nyc --all` in a way that causes source files to be transpiled for actual testing but not transpiled for `--all`. This produces incompatible coverage data and inconsistantly wrong reporting. The work around here is to drop coverage produced by `--all` for any file where we have coverage produced by actual test runs. This ensures that we prefer code that was transpiled in the way which tests actually ran. Fixes istanbuljs#123, istanbuljs#224, istanbuljs#260, istanbuljs#322, istanbuljs#413
I created a coverage report using the
nyc karma startcommand. It generated a HTML report but when I click on a class in that report I see the following error:Scenario can be replayed with the following repository:
The text was updated successfully, but these errors were encountered: