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
I noticed this behavior when implementing this PR for c8: bcoe/c8#158
When we supply coverage there is often a default range coverage that covers the whole file. For some files, I seem to get a sort of undefined behavior when remapping columns.
Now, in a normal covered file this seems to mostly not matter because the subsequent coverage ranges will get processed and the coverage report recovers.
However, in our --all case where we fake a single coverage block with the full range, we end up having a situation where lines in the file get filtered out and we can never assign count 0 to them. This causes the fake entries in our report to have 100 line coverage.
I ended up getting an approach to --all working similar to yours, but not fully tested with your work yet, that populates the v8 object with the fake function (empty-report).
I noticed this behavior when implementing this PR for c8: bcoe/c8#158
When we supply coverage there is often a default range coverage that covers the whole file. For some files, I seem to get a sort of undefined behavior when remapping columns.
For example for this compiled typescript fixture: https://github.com/bcoe/c8/blob/2a21d8d9e3d89478da866e8f8663e3cbd1fd8321/test/fixtures/all/ts-source-maps/loaded.js
We get an initial coverage block that looks like this:
When the first range 0-460 is fed down through into
source-map
'sSourceMapConsumer
for the mappings come back asnull
. That code lives here: https://github.com/mozilla/source-map/blob/master/lib/source-map-consumer.js#L494The result here in
v8-to-istanbul
's code is that an empty object is returned here: https://github.com/istanbuljs/v8-to-istanbul/blob/master/lib/v8-to-istanbul.js#L153 and our destructured variables are all undefined. This causesrelativeToOffset
to returneof
because line is nowNaN
.Now, in a normal covered file this seems to mostly not matter because the subsequent coverage ranges will get processed and the coverage report recovers.
However, in our
--all
case where we fake a single coverage block with the full range, we end up having a situation where lines in the file get filtered out and we can never assign count 0 to them. This causes the fake entries in our report to have 100 line coverage.On my end the simplest fix was to wrap these lines: https://github.com/istanbuljs/v8-to-istanbul/blob/master/lib/v8-to-istanbul.js#L161 in an if check for undefineds which defaults to the originally supplied values.
I would issue that as a PR but I have to wait until monday to get legal clearance (womp womp).
Anyway - I wanted to give you a heads up.
The text was updated successfully, but these errors were encountered: