-
Notifications
You must be signed in to change notification settings - Fork 91
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
100% line coverage when 50% at most with ESM #34
Comments
@danieldiekmeier you've hit the nail on the head, the problem is that we're not taking into account the wrapper that's injected before executing ESM code. A similar problem to the first issue pointed out here: would love help digging into this; for starters we could allow he header length to be configured in c8 ... this feels like a fragile long-term solution though, and I was unable to find common ground in the Node.js internal modules (the prefix injected into the code seems to vary). |
Maybe sourcemaps could help? I'm not too familiar with how istanbul/nyc do it, but I think they can work backwards from sourcemaps to show the coverage of your original source code? |
If sourcemaps are the answer I can provide inline sourcemaps or if some other c8 specific metadata is needed I can do that too. |
Quick question: is this a bug in the V8 implementation or in userland? |
@matthewmueller is your issue also ESM related? in this case it's a little bit of both:
|
Ah, I hadn't realized this issue was ESM-specific, but that's still a very interesting summary of the current state of affairs. Thanks! |
I updated the minimal reproduction repo for this issue with the last version of c8 and esm, but still no luck. |
@jdalton, @GMartigny, and company, with recent work in Node.js, related to source-maps, as of Node 13, we can now support source-maps that are added during in-memory transpilation, see: I would love to add a similar test for ESM, and close this ticket. |
Grabbing this will try to tackle |
Did you have any luck with this? |
I'm using esm and I've tried switch to |
@StreetStrider @JohnHardy we would still need to do a bit of work to make ESM and c8 source map support work together appropriately I believe. |
In Node.js v13.2.0+ ES-modules is available without the |
Apologies, I have been working on other issues :( |
Any update on this? I wouldn't press so hard, but this bug effectively renders c8 useless. Code coverage for ESM modules at this point is bit completely broken. The metrics are effectively useless given how off the numbers are that its reporting for ESM modules. More and more projects are moving to ESM, especially given that it's been available since Node 12, and Node 20 is expected to be released in a month. Any traction on this at all would be superb! 🤞 |
@danieldiekmeier Given that this is still an issue even with native ES Modules, has discussion, history, and watchers, and its still open, I don't see how it would be useful to create multiple issues when this one already exists. However, if you're not experiencing issues with it, I would recommend you Unsubscribe from the topic so that you're not bothered by future notifications 🙂 |
Are there any updates to this? |
## Description - removes c8 dependency & config - uses the --experimental-test-coverage cli switch to get coverage - updates `./tools/dot-with-summary.reporter.js` reporter to emit coverage information - updates the ci workflow to emit information from that report instead of the markdown derived from the codecov run (on node 20 only for now as there it's stable). ## Motivation and Context In our setup c8 doesn't provide any real coverage information anymore (see below - note the number of lines, functions and branches). Root cause probably lies [how node handles ESM/ how v8-to-istanbul can process that](bcoe/c8#34). As nodejs now also has a --experimental-test-coverage built in we migrate this to that. > --experimental-test-coverage isn't perfect either b.t.w. In node 20 it's stable, but on node 22 (at least in our set up) it tends to report different results on each run with unchanged source code. <details> <summary>recent c8 output on virtual-code-owners main branch</summary> ```shell $ npm test > virtual-code-owners@8.0.5 test > c8 tsx --test-reporter ./tools/dot-with-summary.reporter.js --test src/*.test.ts src/**/*.test.ts ..................................................... 53 passing (1.159 ms) =============================== Coverage summary =============================== Statements : 100% ( 11/11 ) Branches : 100% ( 0/0 ) Functions : 100% ( 0/0 ) Lines : 100% ( 11/11 ) ================================================================================ ``` </details> ## How Has This Been Tested? - [x] green ci - [x] manually (the script in tools should probably be put in a separate repo and get its own set of unit tests c.s., but for fixing the issue at hand a bit out of scope. ## Screenshots ``` ..................................................... 53 passing (1.199 ms) =============================== Coverage summary =============================== Branches : 100 % (205/205) Functions : 100 % (123/123) Lines : 100 % (1.533/1.533) ================================================================================ ``` With uncovered lines/ functions (b.t.w. same, unchanged codebase as above ..., but using node 22, after a run or two) ```shell ..................................................... 53 passing (1.216 ms) =============================== Coverage summary =============================== Branches : 100 % (184/184) Functions : 98,31 % (116/118) NOK Lines : 99,74 % (1.529/1.533) ================================================================================ Uncovered lines: /Users/sander/prg/js/virtual-code-owners/src/labeler-yml/generate.ts:102,103,104 /Users/sander/prg/js/virtual-code-owners/src/virtual-code-owners/anomalies.ts:40 Uncovered functions: /Users/sander/prg/js/virtual-code-owners/src/virtual-code-owners/anomalies.ts:40,40 ``` ## Types of changes <!--- What types of changes does your code introduce? Put an `x` in all the boxes that apply: --> - [ ] Bug fix (non-breaking change which fixes an issue) - [ ] Documentation only change - [ ] Refactor (non-breaking change which fixes an issue without changing functionality) - [ ] New feature (non-breaking change which adds functionality) - [ ] Breaking change (fix or feature that would cause existing functionality to change) - [x] Chore (thing that needs doing in e.g. coding infrastructure)
## Description - removes c8 dependency & config - uses the --experimental-test-coverage cli switch to get coverage - updates `./tools/dot-with-summary.reporter.js` reporter to emit coverage information - updates the ci workflow to emit information from that report instead of the markdown derived from the codecov run (on node 20 only for now as there it's stable). ## Motivation and Context In our setup c8 doesn't provide any real coverage information anymore (see below - note the number of lines, functions and branches). Root cause probably lies [how node handles ESM/ how v8-to-istanbul can process that](bcoe/c8#34). As nodejs now also has a --experimental-test-coverage built in we migrate this to that. > --experimental-test-coverage isn't perfect either b.t.w. In node 20 it's stable, but on node 22 (at least in our set up) it tends to report different results on each run with unchanged source code. <details> <summary>recent c8 output on virtual-code-owners main branch</summary> ```shell $ npm test > virtual-code-owners@8.0.5 test > c8 tsx --test-reporter ./tools/dot-with-summary.reporter.js --test src/*.test.ts src/**/*.test.ts ..................................................... 53 passing (1.159 ms) =============================== Coverage summary =============================== Statements : 100% ( 11/11 ) Branches : 100% ( 0/0 ) Functions : 100% ( 0/0 ) Lines : 100% ( 11/11 ) ================================================================================ ``` </details> ## How Has This Been Tested? - [x] green ci - [x] manually (the script in tools should probably be put in a separate repo and get its own set of unit tests c.s., but for fixing the issue at hand a bit out of scope. ## Screenshots ``` ..................................................... 53 passing (1.199 ms) =============================== Coverage summary =============================== Branches : 100 % (205/205) Functions : 100 % (123/123) Lines : 100 % (1.533/1.533) ================================================================================ ``` With uncovered lines/ functions (b.t.w. same, unchanged codebase as above ..., but using node 22, after a run or two) ```shell ..................................................... 53 passing (1.216 ms) =============================== Coverage summary =============================== Branches : 100 % (184/184) Functions : 98,31 % (116/118) NOK Lines : 99,74 % (1.529/1.533) ================================================================================ Uncovered lines: /Users/sander/prg/js/virtual-code-owners/src/labeler-yml/generate.ts:102,103,104 /Users/sander/prg/js/virtual-code-owners/src/virtual-code-owners/anomalies.ts:40 Uncovered functions: /Users/sander/prg/js/virtual-code-owners/src/virtual-code-owners/anomalies.ts:40,40 ``` ## Types of changes <!--- What types of changes does your code introduce? Put an `x` in all the boxes that apply: --> - [ ] Bug fix (non-breaking change which fixes an issue) - [ ] Documentation only change - [ ] Refactor (non-breaking change which fixes an issue without changing functionality) - [ ] New feature (non-breaking change which adds functionality) - [ ] Breaking change (fix or feature that would cause existing functionality to change) - [x] Chore (thing that needs doing in e.g. coding infrastructure)
## Description - removes c8 dependency & config - uses the --experimental-test-coverage cli switch to get coverage - updates `./tools/dot-with-summary.reporter.js` reporter to emit coverage information - updates the ci workflow to emit information from that report instead of the markdown derived from the codecov run (on node 20 only for now as there it's stable). ## Motivation and Context In our setup c8 doesn't provide any real coverage information anymore (see below - note the number of lines, functions and branches). Root cause probably lies [how node handles ESM/ how v8-to-istanbul can process that](bcoe/c8#34). As nodejs now also has a --experimental-test-coverage built in we migrate this to that. > --experimental-test-coverage isn't perfect either b.t.w. In node 20 it's stable, but on node 22 (at least in our set up) it tends to report different results on each run with unchanged source code. <details> <summary>recent c8 output on virtual-code-owners main branch</summary> ```shell $ npm test > virtual-code-owners@8.0.5 test > c8 tsx --test-reporter ./tools/dot-with-summary.reporter.js --test src/*.test.ts src/**/*.test.ts ..................................................... 53 passing (1.159 ms) =============================== Coverage summary =============================== Statements : 100% ( 11/11 ) Branches : 100% ( 0/0 ) Functions : 100% ( 0/0 ) Lines : 100% ( 11/11 ) ================================================================================ ``` </details> ## How Has This Been Tested? - [x] green ci - [x] manually (the script in tools should probably be put in a separate repo and get its own set of unit tests c.s., but for fixing the issue at hand a bit out of scope. ## Screenshots ``` ..................................................... 53 passing (1.199 ms) =============================== Coverage summary =============================== Branches : 100 % (205/205) Functions : 100 % (123/123) Lines : 100 % (1.533/1.533) ================================================================================ ``` With uncovered lines/ functions (b.t.w. same, unchanged codebase as above ..., but using node 22, after a run or two) ```shell ..................................................... 53 passing (1.216 ms) =============================== Coverage summary =============================== Branches : 100 % (184/184) Functions : 98,31 % (116/118) NOK Lines : 99,74 % (1.529/1.533) ================================================================================ Uncovered lines: /Users/sander/prg/js/virtual-code-owners/src/labeler-yml/generate.ts:102,103,104 /Users/sander/prg/js/virtual-code-owners/src/virtual-code-owners/anomalies.ts:40 Uncovered functions: /Users/sander/prg/js/virtual-code-owners/src/virtual-code-owners/anomalies.ts:40,40 ``` ## Types of changes <!--- What types of changes does your code introduce? Put an `x` in all the boxes that apply: --> - [ ] Bug fix (non-breaking change which fixes an issue) - [ ] Documentation only change - [ ] Refactor (non-breaking change which fixes an issue without changing functionality) - [ ] New feature (non-breaking change which adds functionality) - [ ] Breaking change (fix or feature that would cause existing functionality to change) - [x] Chore (thing that needs doing in e.g. coding infrastructure)
From what I can tell both c8 and Nyc are broken if the source under test makes use of ESM. Is that correct? Is there any form of coverage collection that works when using ESM? |
@nwoolls I've been using nyc + ts-mocha and it reports proper numbers for my project. |
@StreetStrider thanks very much for that info & direction. I pushed further down that path and got it working. The issue I had run into with that direction ended up being with Chai (chaijs/chai#1568). |
@nwoolls I had something similar. I think this is due to chai v5 ESM migration. I decided to stick with v4, maybe for an extended time. Chai CJS has been serving me for years without problems, so why should I push to the new version when v4 does the job. Besides, it is a testing infrastructure, so no risks or vulnerabilities for the user. |
@StreetStrider that's the direction I took as well 👍🏻. |
I'm filing at the request of @bcoe. The bug may actually be in v8-to-istanbul.
To repro
npm i -g c8 esm nyc
Then create a file
foo.js
:and run
c8 node foo.js
which will report:now change the line
const { log } = console
toimport { log } from "console"
and run
c8 node -r esm foo.js
which will report:If I run
nyc node -r esm foo.js
instead it will report:and with
report --reporter=html
isThe text was updated successfully, but these errors were encountered: