fix(coverage): exclude injected functions without mapping #7192
Conversation
| @@ -349,6 +350,29 @@ export class V8CoverageProvider extends BaseCoverageProvider<ResolvedCoverageOpt | |||
| // If file was executed by vite-node we'll need to add its wrapper | |||
| const wrapperLength = sources.isExecuted ? WRAPPER_LENGTH : 0 | |||
|
|
|||
| // filter out functions without mappings, | |||
There was a problem hiding this comment.
All code that is not present on source maps should already be excluded from final coverage report. Bundlers tend to inject plenty of helpers, generators and polyfills that are not present on source maps - these should be automatically be excluded.
There was a problem hiding this comment.
All code that is not present on source maps should already be excluded from final coverage report.
Was it the case even before having this patch #5457? I agree that should be the expected behavior of v8-to-istanbul in any cases, but there's still an edge case even after the patch when the injected code's line overlaps with original code as in the reproduction #7130 (comment):
// source
console.log("x");
// generated ("prepended" doesn't get excluded from coverage)
function prepended(){};console.log("x");
function appended(){};Also it turned out this is also the case for istanbul provider too as seen in the new snapshot test/coverage-test/test/injected-functions.test.ts, which is not fixed in this PR and haven't investigated yet.
This looks to me a bug, which is fixable either Vitest side or v8-to-istanbul eventually. I'm wondering how you see this issue in general. We want to land ssr transform fix vitejs/vite#18983, which can cause this edge case more often, so I would like to know your opinions on whether it's fine to land or wait until we get a better understanding of the issue.
There was a problem hiding this comment.
I did some manual testing with this and see now why this work-around is required. To me this looks like a bug in v8-to-istanbul. Ideally we should file a bug report there with minimal repro and PR later on. Or even better, not use v8-to-istanbul at all and roll our own V8 coverage processing.
The #5457 is only about line coverage and does not affect function coverage at all. The v8-to-istanbul has some special handing for line coverage that is not done for function coverage.
I see that VITE_EXPORTS_LINE_PATTERN is now conflicting when using Vite version from the PR. Can we remove that and be backwards compatible?
There was a problem hiding this comment.
Right, I think it's worth reporting on istanbul side and it would also help isolating the issue properly. istanbul-lib-source-maps probably has a similar issue with functions overlapped in a single line (one with source map and other without), so I'll try the repro for that too.
I see that
VITE_EXPORTS_LINE_PATTERNis now conflicting when using Vite version from the PR. Can we remove that and be backwards compatible?
What do you mean by conflicting? In current Vitest, VITE_EXPORTS_LINE_PATTERN seems to have no effect on coverage as I tested in #7132. Also the issue #7130, which is fixed by this PR, happens on user land plugin doing a similar injection and not only caused by new SSR transform.
There was a problem hiding this comment.
What do you mean by conflicting?
When using "vite": "https://pkg.pr.new/vite@18983" with this PR, I get:
Statements : 100% ( 2/2 )
Branches : 100% ( 0/0 )
Functions : 100% ( 0/0 )
Lines : 100% ( 2/2 )
And when removing the VITE_EXPORTS_LINE_PATTERN in the same setup, I get correct results:
Statements : 100% ( 3/3 )
Branches : 100% ( 1/1 )
Functions : 100% ( 1/1 )
Lines : 100% ( 3/3 )
There was a problem hiding this comment.
Oh, that's not what I expected and I haven't actually tested it 😅 I need to debug this thing again. Thanks for checking 👍
There was a problem hiding this comment.
Ah, okay, I remembered this one. Currently it's dropping an entire Object.defineProperty(__vite_ssr_exports__ line which includes original function sum, so this PR alone doesn't fix vitejs/vite#18983.
I'm not sure what's the good way to proceed. From what I understand, VITE_EXPORTS_LINE_PATTERN is not necessary, so we can apply #7132 anytime. What kind of compatibility check needed there?
There was a problem hiding this comment.
From what I understand,
VITE_EXPORTS_LINE_PATTERNis not necessary
Before this PR it used to be necessary. See here how end of line 4 is included in sourcemaps: https://evanw.github.io/source-map-visualization/#NTY5AGZ1bmN0aW.... That's from main branch. When I remove the VITE_EXPORTS_LINE_PATTERN in main, the function count incorrectly raises to 2.
What kind of compatibility check needed there?
So for vite@18983 we need to remove VITE_EXPORTS_LINE_PATTERN like shown in #7192 (comment).
And once VITE_EXPORTS_LINE_PATTERN is removed, we need to make sure older Vite versions like 5 still keep working as expected.
There was a problem hiding this comment.
Hmm, I just noticed #7132 first commit passed CI, then 2nd one failed. Sorry, I didn't even look at that. That's another thing unexpected.
✅ Deploy Preview for vitest-dev ready!Built without sensitive environment variables
To edit notification comments on pull requests, go to your Netlify site configuration. |
Description
This PR filters v8 functions coverage on Vitest side. The idea sounds similar to istanbuljs/v8-to-istanbul#244, but this seems necessary to properly exclude coverage of injected functions at the same line as the original code as seen in the reproduction.
todo
Please don't delete this checklist! Before submitting the PR, please make sure you do the following:
pnpm-lock.yamlunless you introduce a new test example.Tests
pnpm test:ci.Documentation
pnpm run docscommand.Changesets
feat:,fix:,perf:,docs:, orchore:.