Code coverage reports on transpiled JavaScript, instead of TypeScript source

[gerardolima]

Support plan

• is this issue currently blocking your project? (yes/no): no
• is this issue affecting a production system? (yes/no): yes

Context

• node version: v14.15.4
• module version with issue: "@hapi/lab": "^24.1.1"
• last module version without issue: unknown
• environment (e.g. node, browser, native): node
• used with (e.g. hapi application, another framework, standalone, ...): not relevant
• any other relevant information: Project is developed in TypeScript

What are you trying to achieve or the steps to reproduce?

On HTML code coverage report, code is shown in JavaScript, instead of TypeScript. Also, code introduced by the TypeScript compiler (i.e __importStar, __setModuleDefaul) is marked as not covered.

$ lab --coverage --reporter html --output ./out/coverage.html --coverage-path src --coverage-all \
   --coverage-pattern '^(?!.*\\.spec\\.ts)(?:.*\\.ts)$'

  // package.json
  // ...
  "devDependencies": {
    "@hapi/code": "^8.0.2",
    "@hapi/lab": "^24.1.1",
    "lab-transform-typescript": "^3.0.1",
    "typescript": "^4.2.3",
    // ...
  }

// .labrc.js
module.exports = {
	flat: false,
	paths: ['./src'],
	pattern: '\.spec',
	transform: 'node_modules/lab-transform-typescript',
	sourcemaps: true,
	assert: '@hapi/code',
	colors: true,
	coverage: false,
	globals: '__core-js_shared__,core,global-symbol-property',
	reporter: 'console',
	shuffle: true,
	timeout: 4000,
	verbose: true,
}

What was the result you got?

What result did you expect?

I expected to see the original source, in TypeScript, with the appropriate status about code coverage.

[devinivy]

I suspect this is a duplicate of #952, which also has a workaround you may find useful. I agree it's not ideal behavior, but I don't have a sense for how extensive of a fix would be needed.

[gerardolima]

thank you for the great work @devinivy! is it expected for this to be tackled, someday?

[kanongil]

Presently lab only supports js code, and you need to transform any typescript before it can be checked. Unfortunately, this conversion can inject hidden (and possibly untestable) lines of code.

It can also convert what is a single statement into multiple statements. Eg. variable ?? 'default' is 2 statements with a ES2019 target, thus requiring an extra test for coverage.

I'm not sure we will be able to solve the later issue, but the first has some potential remedies. Eg. I created my own version of lab-transform-typescript to mitigate the injected header code coverage issue, but it it very hacky and currently messes up line numbers:
https://github.com/kanongil/hls-playlist-reader/blob/main/build/transform-typescript.js

[kanongil]

Another code level coverage problem is "enums", which creates code that cannot be covered.

https://www.typescriptlang.org/play?target=7#code/PTAEAEGcAsHsHcCiBbAlgFwFAFMB2BXZURAogb01FAEEAaTAX00wBtt1QBDUAXmNIB01ANyt2oXJ2TYA8gDNqvfoQDanALrDQIUACJquoA

In Enum || (Enum = {}), the first Enum can only be undefined, and it is not realistic to test it against any other value.