You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Platform: Microsoft Windows 10 Home / 10.0.19045 Build 19045
via MINGW64_NT-10.0-19045 User-PC 3.4.6.x86_64 2023-05-18 20:39 UTC x86_64 Msys
TypeError [ERR_INVALID_URL_SCHEME]: The URL must be of scheme file
at new NodeError (node:internal/errors:399:5)
at fileURLToPath (node:internal/url:1225:11)
at Report._normalizeSourceMapCache (C:\keymanapp\keyman\node_modules\c8\lib\report.js:314:29)
at Report._getMergedProcessCov (C:\keymanapp\keyman\node_modules\c8\lib\report.js:183:51)
at Report.getCoverageMapFromAllCoverageFiles (C:\keymanapp\keyman\node_modules\c8\lib\report.js:92:31)
at Report.run (C:\keymanapp\keyman\node_modules\c8\lib\report.js:72:31)
at exports.outputReport (C:\keymanapp\keyman\node_modules\c8\lib\commands\report.js:39:16)
at C:\keymanapp\keyman\node_modules\c8\bin\c8.js:39:15
at ChildProcess.<anonymous> (C:\keymanapp\keyman\node_modules\foreground-child\index.js:88:20)
at ChildProcess.emit (node:events:513:28)
Context: I have a project that embeds a Worker's code within its source. When live, the project constructs a data URL (on Node) or a Blob (in the DOM) for use to initialize that Worker. We're able to use this setup to run integration tests with the worker headlessly on Node. However, when running those automated tests under c8, the error above occurs.
Noting the method mentioned in the stack log above...
That said, I'm not well-versed enough in c8 architecture to know if this would cause undesired collateral effects.
If nothing else, it does cause VS Code to near-instantly hang when loading a temp-file with the resulting base64 JSON-object key, likely because of the difficulty of parsing it in the middle of lots of other JSON. I don't want the 'file' in my reports... but I imagine it would cause the report table to practically explode if not handled properly in some manner.
As the report stat calculation itself doesn't fall over, it may be wise to add a mapping structure (when necessary) for data URLs. Perhaps... give them a nice short-hand version in the report and the JSON keys, but maintain the longer-form for cache comparisons... and to provide enough identifying information about which data URL is being reported if it actually shows up in the report?
Also interesting:
the error does not occur when running under VS Code's "JavaScript Debug Terminal" (for Node.js-based debugging).
It appears that the file's coverage data somehow isn't generated / passed to c8 when run this way for some reason?
adding a post-test-suite timeout to all test suites does not work around the error.
The text was updated successfully, but these errors were encountered:
Context: I have a project that embeds a Worker's code within its source. When live, the project constructs a data URL (on Node) or a Blob (in the DOM) for use to initialize that Worker. We're able to use this setup to run integration tests with the worker headlessly on Node. However, when running those automated tests under c8, the error above occurs.
Noting the method mentioned in the stack log above...
c8/lib/report.js
Lines 389 to 395 in f8ee1ff
I have confirmed that the following prevents a c8 crash:
That said, I'm not well-versed enough in c8 architecture to know if this would cause undesired collateral effects.
If nothing else, it does cause VS Code to near-instantly hang when loading a temp-file with the resulting base64 JSON-object key, likely because of the difficulty of parsing it in the middle of lots of other JSON. I don't want the 'file' in my reports... but I imagine it would cause the report table to practically explode if not handled properly in some manner.
As the report stat calculation itself doesn't fall over, it may be wise to add a mapping structure (when necessary) for data URLs. Perhaps... give them a nice short-hand version in the report and the JSON keys, but maintain the longer-form for cache comparisons... and to provide enough identifying information about which data URL is being reported if it actually shows up in the report?
Also interesting:
The text was updated successfully, but these errors were encountered: