Malformed "url" parameter in "Debugger.scriptParsed" event

[segrey]

• Version: 7.4.0
• Platform: Windows 10

Debugger.scriptParsed events contain malformed "url" parameter values, like:

{
  "method": "Debugger.scriptParsed",
  "params": {
    "scriptId": "58",
    "url": "C:\\Users\\Sergey.Simonchik\\simple-example\\foo.js",
    "startLine": 0,
    "startColumn": 0,
    "endLine": 3,
    "endColumn": 3,
    "executionContextId": 1,
    "hash": "6A46C633B7646A730A332EE66076717AE7A6D0F1",
    "isLiveEdit": false,
    "sourceMapURL": "",
    "hasSourceURL": false
  }
}

Here "url" is set to "C:\\Users\\Sergey.Simonchik\\simple-example\\foo.js" which is an invalid URL.

According to https://chromium.googlesource.com/v8/v8/+/master/src/inspector/js_protocol.json, "url" parameter of "scriptParsed" event is defined as

{ "name": "url", "type": "string", "description": "URL or name of the script parsed (if any)." }

Probably, the expected value should be "file://C:\\Users\\Sergey.Simonchik\\simple-example\\foo.js"

[mscdex]

/cc @nodejs/v8-inspector

[joshgav]

/cc @roblourens

[lacmuch]

Our problem is a little similar at #10672 . I can't map files in chrome workspace.

[Trott]

Should this remain open?

[bnoordhuis]

It's a legitimate bug: the inspector uses the script name as the URL, but it's a file path in node.js.

Although it can be overridden by inserting a //# sourceURL=... comment in the script source (and node.js could even do that automatically), it's probably better solved by making it programmatically overridable through the inspector's C++ API.

edit: pre-existing bug report: https://bugs.chromium.org/p/chromium/issues/detail?id=679144

[TimothyGu]

The Dev Tools frontend has already implemented a workaround: https://cs.chromium.org/chromium/src/third_party/WebKit/Source/devtools/front_end/sdk/DebuggerModel.js?l=485&rcl=0a99285795ade2dd281995dee72fdb9e80d3fd6d

It's just a matter of getting that into V8.

[bnoordhuis]

sourceURL.startsWith('/')

That won't work for Windows file paths.

[j3l11234]

╮(╯_╰)╭
I found a temp workaround.

//bootstrap.js
const fs = require('fs');
const vm = require('vm');

var mainCode = fs.readFileSync(__dirname + '/' + 'main.js');
vm.runInThisContext(module.constructor.wrap(mainCode), 'file://app/main.js')(exports, require, module, __filename, __dirname, process, global, Buffer);

node --inspect bootstrap.js

Then I use inline sourcemap in main.js
I works on my windows Chrome!

[hinell]

@j3l11234 Tried your solution with no lack.
Also there are a few links referencing .ts files that emerged after that.
If I'm trying to edit it the pane is rendered blank.

I have tested it with various paths in the 'File:/// ...path' but nothing changed..

[j3l11234]

╮(╯_╰)╭
@hinell
I use webpack，use devtool: 'inline-cheap-module-source-map',
Maybe you should use inline sourcemap

[kevinsimper]

@j3l11234 this is definitely a "that one little that worked" 😱 👍

[j3l11234]

╮(╯_╰)╭
@kellygerber I think is the bug of node，
I try it for Chrome opening local html, The path uri is normal, so Chrome Devtools can parse the sourceMap.
But in node, the path uri is malformed, so So Chrome Devtools cant parse the sourceMap.

[j3l11234]

╮(╯_╰)╭
@bnoordhuis @kevinsimper
I submit a issue to chrome
https://bugs.chromium.org/p/chromium/issues/detail?id=789569
It is bug of chrome devtools.

[roblourens]

When I run node with --experimental-modules, I see that it returns paths as file URLs in the url field. Does anyone know whether that will always be the case in the future? Intentional change?

[demurgos]

Should be fixed in Node 10.12.

[bnoordhuis]

It's been fixed in devtools (diff) so I'm going to go ahead and close this out.