Open jaydenseric opened 1 week ago
I'm not sure, but maybe inspiration can be taken from https://github.com/istanbuljs/v8-to-istanbul/pull/244 .
Why is coverage exempt from respecting how --enable-source-maps works for other Node.js features?
That seems like a bug to me. @MoLow do we need to check the flag here?
Seems like a bug to me as well. not sure where is the correct place to fix
Version
v22.8.0
Platform
Subsystem
No response
What steps will reproduce the bug?
With this TypeScript source code in
src/a.mts
(where the import is from doesn't matter):Compiling that to
dist/a.mjs
:With source map
dist/a.mjs.map
:Then in
test.mjs
:Run:
How often does it reproduce? Is there a required condition?
Every time.
What is the expected behavior? Why is that the expected behavior?
100% code coverage reported for the module
src/a.mts
.What do you see instead?
Notice the false missing line coverage reported in the terminal output:
Additional information
If you comment out the
import type {} from "node:assert";
and rebuild, a second run for functionally the same runtime code now correctly reports no missing coverage:If you don't create source maps when compiling TypeScript modules containing
import type
, the Node.js test runner correctly reports no missing coverage. So the problem is around how Node.js is interpreting the source maps. Only runtime code should determine code coverage; not source code like TypeScriptimport type
that is eliminated in the build.Something else that is strange, is that the Node.js CLI flag
--enable-source-maps
doesn't seem to have an effect on how the Node.js test runner reports coverage; even without the flag it will always take into account the source maps information. Why is coverage exempt from respecting how--enable-source-maps
works for other Node.js features?