-
Notifications
You must be signed in to change notification settings - Fork 29.9k
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
vscode node debugger parses inline sourcemap incorrectly #35978
Comments
|
I didn't know that was valid. |
Oh, rad! Yep, it's allowed 😋 For more info see: thlorenz/convert-source-map#59 (comment) |
@roblourens Moving to March since you are not here ... |
I'm going INSANE with this one. Any movement? |
Is this format commonly used? I think the right fix will be to take a dependency on that |
Some more side information here: The issue is the inlined source maps aren't being encoded properly. Here is the issue present in getMapForGeneratedPath, and what I see is that the mapPath has HTML entities used which throws everything off. Going up the stack trace... It's present in onScriptParsed in chromeDebugAdapter.js... |
Still not sure why this issue popped up... I updated a fair amount of dependencies and this happened. Does this have to do with a recent typescript update? Does anyone know of workarounds to this? |
Ohhh it might have been updating @std/esm! If anyone is having this issue downgrading that will probably help things. |
confirming that downgrading to esm@3.0.18 reversed this issue. |
@jdalton would you happen to know the latest non-breaking version of esm that won't re-trigger this issue? |
The encoding is valid, I just haven't gotten to supporting it since it doesn't seem to be very common. |
The error is really obscure though, it might be worth putting in a note regarding this in the error output. |
The only recent change I've done to source maps is to ensure they use a file url instead of a file path (because on Windows the file path is not a valid url and caused load fails in the Node inspector). It would be great not to have to base64 encode since that's processing and these source maps are generated at runtime. The encoding is just "//# sourceMappingURL=data:application/json;charset=utf-8," +
encodeURI(createSourceMap(filename, content)) so decoding is decodeURI(sourceMappungURL.slice(36)) Update: I'll prep a PR to patch getInlineSourceMapContents() with support for utf-8 encoded urls. |
That would be fantastic, thanks. |
@Pokute beat you to it but I'll get this into tomorrow's Insiders build. |
Rock, thank you! |
I just ran into this issue using VSCode 1.25.1. Just checking… should this fix have been released yet? |
@remcohaszing its in insiders build, not released to the public yet |
Steps to Reproduce:
package.json
with the following content:index.js
with the following content:npm install
Reproduces without extensions: Yes
It seems vscode debugger always assumes the inline sourcemap data URI is in base64 encoding (even if the
;base64
extension is not included in the data URI scheme).This will lead to data decoding error.
The text was updated successfully, but these errors were encountered: