Inconsistent nyc baseline coverage results with pre-instrumented code

[AndrewFinlay]

Link to bug demonstration repository

nyc_bad_baseline

Expected Behavior

Baseline coverage generated from raw source should match that generated from instrumented source.

Observed Behavior

The coverage report is different, with missing files and differences in statistics.
The missing files seem to be affected by the presence of whitespace and comments.

Troubleshooting steps

• [y] still occurring when I put cache: false in my nyc config

Environment Information

  System:
    OS: macOS High Sierra 10.13.6
    CPU: (4) x64 Intel(R) Core(TM) i5-7600 CPU @ 3.50GHz
    Memory: 564.82 MB / 32.00 GB
    Shell: 3.2.57 - /bin/bash
  Binaries:
    Node: 8.16.0 - ~/.nvm/versions/node/v8.16.0/bin/node
    Yarn: 1.7.0 - /usr/local/bin/yarn
    npm: 6.4.1 - ~/.nvm/versions/node/v8.16.0/bin/npm
 ...snip

[AndrewFinlay]

See earlier discussion in #1202

[coreyfarrell]

I believe this is caused by #1191. If I delete the inputSourceMap key from each file in the instrumented coverage I get the expected results. This is a blocker for final release of nyc 15, I will have to investigate. Thanks for the great reproduction.

I'm unsure how this caused the issue. The intended result of #1191 was that if you ran tsc on src input and lib output, nyc would add the source-map for those transformations to the coverage data, thus allowing the master process to perform remapping of the lib files which were executed to produce coverage for the src files. Weird thing is this remapping was always happening and #1191 shouldn't have changed the source maps used nor the how they are processed.

It's also possible this issue isn't caused by #1191 and in fact the issue is that --all on pre-instrumented sources just needs some more work (nyc 14 wouldn't find baseline coverage from pre-instrumented sources). In either case we can't have nyc loading --all coverage for these files if it's going to mess it up.