Repository navigation
Support statement coverage #54530
Description
Activity
I see at least two issues with doing this:
- This will hurt performance of coverage, particularly on large projects.
- We would be parsing the code with a different parser than the one V8 uses. This should almost always be fine, but could have some issues particularly when new syntax is introduced.
Of course there is some code complexity to doing this too. While I agree that statement coverage would be nice to have, I haven't seen any users of the test runner asking for it either. My understanding (which @MoLow seemed to confirm) is that C8 does not report this metric from V8 coverage. If they aren't doing it, I don't see a great reason for us to do it either.
Reacted by Moshe Atlow and Ari PerkkiöThe latest version of C8 can do this with
--experimental-monocartc8 --experimental-monocart --reporter=v8 --reporter=console-details node foo.js
As an alternative, we can also use the custom test reporter
node --test-reporter=node-monocart-coverage --test tests
Indeed, it is extremely complicated and hurt performance.
There is a benchmark for reference, TypeScript is currently usingc8 --experimental-monocartto generate coverage reports.- The TypeScript source code have almost 17M
- It takes almost 19 seconds to generate the coverage reports using the default GitHub Action environment (test job)
Check TypeScript coverage job in CI
See microsoft/TypeScript#58850Reacted by Colin Ihrig and Aviv KellerIf this was implemented directly in V8, whole JS/Node ecosystem could benefit from this. Adding AST based coverage analysis is not ideal for performance.
There has been no activity on this feature request for 5 months. To help maintain relevant open issues, please add the never-stale
Issues and PRs exempt from automated stale handling. label or close this issue if it should be closed. If not, the issue will be automatically closed 6 months after the last non-automated comment.
For more information on how the project manages feature requests, please consult the feature request management document.This is pretty important since basically every other coverage tool in the ecosystem has this 4th metric. Perhaps it would make more sense to see if someone can contribute it to v8 directly? That way all of the valid downsides listed in #54530 (comment) wouldn't apply.
Reacted by Pietro MarchiniThe compromise is that the Node test runner can export all the native V8 coverage data, as well as the source code and sourcemap, in custom reports
test:coverageevent. This should be relatively easy and allow third-party tools to extend.const { Transform } = require('node:stream'); const customReporter = new Transform({ writableObjectMode: true, transform(event, encoding, callback) { switch (event.type) { // ... case 'test:coverage': { const { rawV8CoverageData, sourcesAndSourcemaps } = event.data; break; } } }, }); module.exports = customReporter;
Reacted by Aviv KellerThere has been no activity on this feature request for 5 months. To help maintain relevant open issues, please add the never-stale
Issues and PRs exempt from automated stale handling. label or close this issue if it should be closed. If not, the issue will be automatically closed 6 months after the last non-automated comment.
For more information on how the project manages feature requests, please consult the feature request management document.There has been no activity on this feature request and it is being closed. If you feel closing this issue is not the right thing to do, please leave a comment.
For more information on how the project manages feature requests, please consult the feature request management document.
A year later after my comment in #54530 (comment):
For Vitest we went ahead and created a library for doing the AST analysis based V8 coverage conversion. For 2-3 years we tried to avoid this but due to V8's limitations (like statement coverage) we needed more accurate approach. Compared to the 3rd party library mentioned in #54530 (comment), this one is ~96% smaller and focuses only on the coverage convertion.
Reacted by Pietro MarchiniHey @AriPerkkio , thank you very much for the follow-up and for the suggestion! I'll take a look asap 😁
- added a commit that references this issue
on Mar 19, 2026
I think the Node.js coverage reporter should include support for reporting statement coverage.
My idea is to parse the source code into an Abstract Syntax Tree (AST) using
acorn-walk, and then use theStatementcallback to extract statements. They could then be converted toCoverageStatements, (similarly to how thegetLinesfunction works with lines toCoverageLines).These statements could then be mapped to ranges in the same way that lines are handled in
mapRangeToLines.I saw a (extremely complicated) way of doing this in https://github.com/cenfun/monocart-coverage-reports/, so it appears to be possible.