Test coverage shows untransformed output

[garthk]

I'm not yet sure whether this is a bug in lab-transform-typescript or lab itself. As originally raised in hapijs/lab#614:

lab -T test/lib/transform-tsc.js test -v -S -c -r html -o cov.html produces a coverage file with:

• Correct test results
• Correct pre-transform filenames, e.g. index.ts in the navigation bar and code coverage report headers
• Correct coverage information, e.g. reporting "condition always false"
• The post-transform file contents, not the expected pre-transform file contents

lab -T test/lib/transform-tsc.js test -v -S with a failing test produces correct line numbers for pre-transformed code.

[testica]

My input is something likes:

lab src/test --sourcemaps --transform node_modules/lab-transform-typescript --reporter console --threshold 100 --assert code --coverage --verbose

And I got ouput likes:

src/api/zones/index.ts missing coverage from file(s):
	null on line(s): , , , , , , , , , , ,

@garthk Do you know the reason ?

[garthk]

I'm afraid not, and I'm no longer working with TypeScript and Lab on a daily basis.

[stevendesu]

I just looked into this issue since I was having it, myself, and it's a but in @hapijs/lab, not in lab-transform-typescript. Here's the gist of what's going on:

• If a file has source maps, HapiJS maps every line in the transformed file that wasn't covered by tests to a line in the source file
• The TypeScript compiler is adding certain boilerplate code to the transformed file (e.g. a polyfill for "await")
• Some of these polyfills aren't being covered by tests (maybe you don't have a test for Promise rejection)
• Because this code was added by the compiler, it doesn't map to any of your original source code. Hence, the line without coverage maps back to "null" on line "null"

If time permits (it probably won't) I would like to submit a PR to HapiJS to improve their code coverage tool. In the mean time, I found a workaround: update your tsconfig.json file and set the target to "es2017". This will use native generators, the native await keyword, and other ES6 features that TypeScript was otherwise polyfilling.

Doing so does mean your code will require NodeJS 10 or later, so if that's an issue then you'll have to live with lying code coverage errors.