You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The issue I'm seeing is that when you run jest with coverage and sharding, ts-jest causes jest to output consistent coverage-final.json files while swc/jest causes it to output inconsistent coverage-final.json files.
Jest when used with swc/jest should output the same data in the "statementMap" in the coverage-final.json file that's outputted for each shard so that nyc can merge the resulting coverage files.
Actual behavior
Notice how "statementMap" is different depending on the shard that produced the output. In shard 1 (the shard that actually got some coverage on the file in question), there are 4 lines of data in "statementMap"
instead of merging, we have two data items that refer to the same statement: "0" and "4"
Version
1.3.78
Additional context
I'm not sure if the column: null matters since ts-jest produces that in several other places in my complete coverage-final.json file, and coverage seems fine with it. The issue seems to arise when one shard produces a number for the column and the other shard produces a null.
The text was updated successfully, but these errors were encountered:
This is really not possible to debug, first there's no minimal repro at all, and secondly it involves so many toolchains at once - jest, babel (for jest coverage), sharding, nyc to merge and lastly swc per claims.
If you think swc is a culprit to play here it's likely coming from incorrect coverage mapping which should be provided as a minimal repro doesn't involve other tools.
This closed issue has been automatically locked because it had no new activity for a month. If you are running into a similar issue, please create a new issue with the steps to reproduce. Thank you.
Describe the bug
This is slightly different than #3854
The issue I'm seeing is that when you run jest with coverage and sharding, ts-jest causes jest to output consistent
coverage-final.json
files while swc/jest causes it to output inconsistentcoverage-final.json
files.swc/jest -> coverage-shard-1.json:
swc/jest -> coverage-shard-2.json:
swc/jest -> nyc merge -> coverage-final.json:
ts-jest -> coverage-shard-1.json:
ts-jest -> coverage-shard-2.json:
ts-jest -> nyc merge -> coverage-final.json:
Input code
Config
Playground link
No response
SWC Info output
Expected behavior
Jest when used with swc/jest should output the same data in the
"statementMap"
in thecoverage-final.json
file that's outputted for each shard so thatnyc
can merge the resulting coverage files.Actual behavior
Notice how
"statementMap"
is different depending on the shard that produced the output. In shard 1 (the shard that actually got some coverage on the file in question), there are 4 lines of data in"statementMap"
In shard 2, which produced zero coverage for the file in question, there is only 1 line of data in
"statementMap"
nyc
does not know how to merge these:instead of merging, we have two data items that refer to the same statement:
"0"
and"4"
Version
1.3.78
Additional context
I'm not sure if the
column: null
matters since ts-jest produces that in several other places in my complete coverage-final.json file, and coverage seems fine with it. The issue seems to arise when one shard produces a number for the column and the other shard produces a null.The text was updated successfully, but these errors were encountered: