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:
{
"functionName": "",
"ranges": [
{
"startOffset": 0,
"endOffset": 460,
"count": 1
}
],
"isBlockCoverage": true
}
When the first range 0-460 is fed down through into source-map's SourceMapConsumer for the mappings come back as null. That code lives here: https://github.com/mozilla/source-map/blob/master/lib/source-map-consumer.js#L494
The 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 causes relativeToOffset to return eof because line is now NaN.
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.
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'sSourceMapConsumerfor 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 causesrelativeToOffsetto returneofbecause 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
--allcase 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.