-
-
Notifications
You must be signed in to change notification settings - Fork 1.2k
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
TypeError: Cannot read properties of undefined (reading 'endCol') #6297
Comments
What's this line? It's importing something that doesn't exist. Removing it makes the coverage work. |
@AriPerkkio It's importing the package itself. It's equivalent to importing |
I don't think this is regression. Has this ever worked?
{
"scriptId": "468",
"url": "file:///Users/x/vitest/test/coverage-test/fixtures/src/cjs-package/basic.js",
"functions": [
{
"functionName": "",
"ranges": [
{
"startOffset": 0,
"endOffset": 1031, // <-- Notice that this doesn't match file's actual content -> It's executed by vite-node that adds wrapper code around it.
"count": 1
}
],
"isBlockCoverage": true
}
]
}
{
"scriptId": "469",
"url": "file:///Users/x/vitest/test/coverage-test/fixtures/src/cjs-package/basic.js",
"functions": [
{
"functionName": "",
"ranges": [
{
"startOffset": 0,
"endOffset": 95, // <-- Notice, no vite-node's wrapper used. Only the file itself was executed
"count": 1
}
],
"isBlockCoverage": true
}
]
} I'm not sure if this can be fixed properly at all. Maybe we should finally just make the decision to completely ignore files that were not loaded via Vite. You can fix this in your codebase by not relying on CommonJS when you are using Vite/Vitest. |
Also note that V8 coverage includes all files that Node executed so we don't really control that part. |
I think we could add a try-catch around here with warning logging when this kind of issues happen. It would then not fail whole report generation. vitest/packages/coverage-v8/src/provider.ts Line 546 in 5d54203
|
I was basing this on your comment in the PR for the issue where you said:
Perhaps its semi-related but not quite the same issue / not a regression. I still find it a bit strange that adding the comment fixes the issue of the import. On this note:
We're working on migrating to ESM and away from CJS currently. We just finished migrating to Vitest from a slew of other test runners (mocha, tap, tape, jest, etc) and our next step is starting to convert to ESM. We were hoping that we would be able to get all our coverage working through the v8 provider before moving to that step though.
I do think this would be a good idea as it would be helpful for people in similar cases. |
It may seem that it works, but it's still causing incorrect coverage results. When 'use strict';async (__vite_ssr_import__,__vite_ssr_dynamic_import__,__vite_ssr_exports__,__vite_ssr_exportAll__,__vite_ssr_import_meta__,require,exports,module,__filename,__dirname)=>{{"use strict";
module.exports = {
debug: 0,
info: 1,
warn: 2,
error: 3,
fatal: 4,
};
//# sourceMappingSource=vite-node
//# sourceMappingURL=data:application/json;charset=utf-8;base64,...
}} And when "use strict";
module.exports = {
debug: 0,
info: 1,
warn: 2,
error: 3,
fatal: 4,
}; Now when we get coverage results for this, they look like shown in #6297 (comment). In order to properly remap the coverage results back to source code, we need to apply offset in the beginning to get rid of the When the wrapper code is incorrectly assumed to be in the V8 coverage result, we simply read out-of-bounds of the original source file. When you add new comment (or any other code) there, it luckily adds enough characters so that this out-of-bounds read doesn't happen. But it's still incorrectly mapped so results are off. I did some testing whether we could actually detect from the V8 results whether |
Ah, that makes a lot more sense! Thank you for the explanation! I agree that proceeding with the warning and not blocking coverage would be the best route |
Just confirmed that the fix worked by testing |
Describe the bug
Appears to be a regression of a previous bug: #5639
Related PR for previous bug: #5642
When running coverage using
@vitest/coverage-v8
, with CJS files, it fails to properly report coverage.As noted in the previous issue, adding a comment above the export makes the coverage work.
Reproduction
Reproduction on GitHub because StackBlitz doesn't support
@vitest/coverage-v8
.Minimal Reproduction: https://github.com/stramel/vitest-v8-coverage-repro/tree/main
Steps:
npm run cover
Expected Result: Coverage should finish correctly without error
Actual Result: Coverage doesn't finish and results in the error
TypeError: Cannot read properties of undefined (reading 'endCol')
If you change
src/basic.js
to thisthen run
npm run cover
it will work as expected.System Info
Used Package Manager
npm
Validations
The text was updated successfully, but these errors were encountered: