source maps are not working when debugging with chrome

[yanivefraim]

• Version: 6.3.1 +
• Platform: OSX

I am debugging my mocha tests using native node debugger, using the following command:

/usr/local/bin/node --debug-brk --inspect=9444 --expose_debug_as=v8debug /Users/yanivef/Documents/projects/node-debug-example/node_modules/mocha/bin/_mocha --require babel-register --timeout 0 --ui bdd test/**/*.spec.js

Debugger works great, but I cannot make source maps to work.

I created a small simple example here.

Just clone + npm i + npm run test-debug. You'll see that when opening the address from command line (chrome-devtools://devtools....) you can debug but source maps are not working:

I tried adding project to workspace / adding source maps manually with no luck. Am I doing something wrong here? Is there an issue here?

[jasnell]

Yep, this is a known limitation and it's not something that we can actually fix at this time. The issue is that the chrome debugger needs to know how to fetch the original source but the inspector code has no way of providing it yet.

[matthewoates]

@jasnell How so? The sourcemap in this example is inlined. Isn't the data from the sourcemap sufficient? Sourcemaps in the browser can show the original source without having access to the actual files.

[matthewoates]

poke @jasnell

[knownasilya]

Ping

[MylesBorins]

/cc @nodejs/v8-inspector

[samuelcastro]

Any solution here guys? @jasnell @matthewoates

[jasnell]

hmm... I thought I had responded to this earlier today. Perhaps it got lost somewhere and will show up on wikileaks someday... in any case, there's no solution at this time. Source maps are not supported when using the chrome inspector with node because there is no mechanism by which to locate and load those source maps. We would need some one to figure out how to make it work and open a PR.

[jasnell]

Source maps aren't supported at the current time because there's no
mechanism for loading them. It's something that has been discussed from
time to time but there's been no resolution yet

On Friday, October 21, 2016, Samuel Castro [email protected] wrote:

Any solution here guys? @jasnell https://github.com/jasnell
@matthewoates https://github.com/matthewoates

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#8369 (comment), or mute
the thread
https://github.com/notifications/unsubscribe-auth/AAa2eeQkUcpdzhyIVLU8GVxoyQY7tk1vks5q2Q8vgaJpZM4JytlQ
.

[EricMCornelius]

@jasnell - can you give some technical background/pointers on what's going on here? I'll happily try to help out if I can get a bit of direction.

Isn't this just stock Chrome DevTools UI integrating with node's debugging protocol exposed via v8-inspector? Chrome's DevTools support sourcemap loading already for frontend work, and the context menu option to "Add Source Map" exists when you right-click on the code pane. It seems non-functional though.

Unfortunately, a ton of people are using Babel/Typescript transpilation for node, and lack of sourcemaps leaves --inspect functionality severely hampered.

@pavelfeldman indicated in a couple places that they should work:
#6792 (comment)
#6725 (comment)

[noinkling]

I'm chipping in because I've been a bit confused by this, and see no reason it shouldn't work given what's presented in Chrome.

• Node version: 7.0
• Platform: Windows 10
• Chrome version: 54 stable

I'm using babel-node in development which outputs inline source maps by default, I assume it's pretty much the same with babel-register. In my case I simply run something like babel-node --inspect src/server/index.js. In Chrome, in the sources panel, the path in the file tree and in the tab title point to the original source file, and it says it detects a source map, but I get displayed the transpiled version of the code (which I believe is served from memory with babel-node).

When I click "more" this is the message:

but there are no other versions of the same file in the file tree or when I press Ctrl + P.

If Chrome can both detect an inline source map and knows the path to my source, shouldn't this be able to work?

Debugging seems to work pretty much fine otherwise, other than a bug with the console sometimes not working correctly.

As an aside: I know it's probably not comparable, but I recently gave VS Code a go using the new Node debugger (referred to as node2) which uses the v8 inspector protocol, and source maps work fine there for the same use case (after setting "sourceMaps": true in launch.json).

[roblourens]

If you guys are opening the inspect link in Chrome, then I think they won't work because a webpage has no way of accessing the disk, right? Typically chrome devtools is run in a host that provides access to the disk and other things. Probably would work from the chrome://inspect page though.

[matthewoates]

@robertchiras see my first comment. You don't need to access the filesystem for source maps to work.

[jkrems]

IIRC the problem is that Devtools wants to resolve all URLs (including data:) relative / in the context of the debug target's origin, not the origin of the Devtools page. This requires active support on the side of the debug target, tied into the network stack (which is not part of V8 and thus not (yet) instrumented in node). Obviously that doesn't make as much sense when debugging a server-side app locally. It becomes more important when debugging remotely or when origin policies come into play.

So my best guess is that the place to fix it would be the devtools frontend, potentially adding a special case there for data urls..?

[jkrems]

Possible duplicate on the devtools side: https://bugs.chromium.org/p/chromium/issues/detail?id=664801&q=component%3APlatform%3EDevTools%20node&colspec=ID%20Owner%20Summary%20Modified%20Stars

[joshunger]

This appears to be fixed in Node 7.2.1 and Canary. Can anyone else confirm?

[zfedoran]

@joshunger Node 7.2.1 and Canary did not resolve the issue for me.

A workaround is to host the source map file...

Example:
Run python -m SimpleHTTPServer,
Then manually add //# sourceMappingURL=http://localhost:8000/main.js.map
to the bottom of your source file.

[RanjithNair]

@joshunger This is working for me now with Node 7.2.1 & Canary (Version 57.0.2962.0 (Official Build) canary (64-bit) )

[miksansegundo]

Confirmed 😄 It's working here with Node 7.3.0 and Canay Version 57.0.2963.0

[zfedoran]

I may have been on an older version of Canary when I tried this earlier. I can confirm that this does work for me as well with Version 57.0.2967.0 (Official Build) canary (64-bit) and Node 7.3.0.

[joshunger]

Looks like Firefox's https://github.com/devtools-html/debugger.html/ works with Node 6 if you want to compare debuggers.

[RanjithNair]

Is there anyway to open up the chrome debug link automatically rather than copying and pasting everytime?

[jkrems]

@RanjithNair Latest chrome exposes it directly in the devtools as an experiment, generally you can have "chrome://inspect" open and a link you can click will just pop up.

[pavelfeldman]

@eugeneo , @s3ththompson: when do we remove auto-attach from behind experiments in Chrome?

[philippefutureboy]

I can confirm that it is currently working on my side with the following setup:

• OS: MacOS Sierra 10.12.6
• npm: 5.5.1
• node: 8.5.0
• babel-cli: ^6.26.0
• Transpiled from: ES2015
• No inlining

Steps to reproduce:

1. Have a script babel <src folder> -d <dist folder> -s && node --inspect --inspect-brk <dist folder>/index.js in your package.json
2. Run said script
3. Open Chrome at about://inspect and click on your device (node) process.
4. In the Chrome Devtools, ⌘+P and click on the file you want to see. You should see the original file.

Confirmed not working with npm 3.10.10 & node 6.11.3

[philippefutureboy]

@kevinsimper have you attempted to map the ports of your docker container to the localhost?

[kevinsimper]

@philippefutureboy

the npm script should look something like this

"start": "node --inspect=0.0.0.0:9229 bootstrap.js",

[philippefutureboy]

I spoke too soon, the source map only works for the entry file (index.js), but not for any other files linked by the index file :(

Any other file is simply not imported.

[davidlivingrooms]

Platform: win10
Tested browsers:

Chrome Canary Version 64.0.3250.0 (Official Build) canary (64-bit)
Chrome Version Version 62.0.3202.75 (Official Build) (64-bit)
Node version: v8.8.1 and 8.4.1

Sourcemaps don't work for me either for a simple typescript project. I had a coworker install the same project on his mac and the source maps work just fine...

[kevinsimper]

The issue on chromium has been closed with the following comment:

Status: WontFix: This needs to be implemented on the node side (e.g. Node needs to provide source maps to devtools)

https://bugs.chromium.org/p/chromium/issues/detail?id=664801&q=component%3APlatform%3EDevTools%20node&colspec=ID%20Owner%20Summary%20Modified%20Stars

[bnoordhuis]

How though? I remember when I last looked at this passing a source map URL with v8::ScriptOptions did absolutely nothing and I didn't (and don't) see a way to specify one through the inspector protocol. Only //# sourceMappingURL comments in the source worked.

cc @eugeneo

[philippefutureboy]

Nifty update from my side! ✨ ✨ ✨

• Google Chrome: 64.0.3269.0 (Official Build) canary (64-bit) revision 41ecce8b3fefc4d967b1ea183ffb3c67bc0f3ac2-refs/heads/master@{#516552}
• OS: MacOS High Sierra 10.13.1
• JavaScript: V8 6.4.299
• npm: 5.5.1
• node: 8.9.1
• babel-cli: ^6.26.0
• Transpiled from: ES2017
• Inlining

It works 😱

[eyalella]

Thanks to @fauverism pointing to this stack overflow link the problem was easily solved for me.
All you need to do is turn on Enable JavaScript Sourcemaps in Chrome's dev tools settings and it works like a charm 🎉
I used devtool: "source-map" BTW...

[magano]

From some tests performed on source-maps I could state that currently they work on MacOS and Linux on Chrome both systems.

Unfortunately on Windows Systems (Windows 10) I can't get it to work.
I tested for Google Chrome Official and Canary Builds and on both cases the app was unable to load the source maps.

On top of that I tried loading the source-maps from the filesystem and from a Simple HTTP server with no success.

MacOS

• Google Chrome: 64.0.3282.186 (Official Build) (64-bit)
• OS: MacOS High Sierra 10.13.2
• node: 6.13.0 && 8.9.4

Linux

• Google Chrome: 64.0.3282.186 (Official Build) (64-bit)
• OS: Ubuntu 17.10
• node: 6.13.0 && 8.9.4

Windows

• Google Chrome: 64.0.3282.167 (Official Build) && 66.0.3350.0 (Canary Build)
• OS: Windows 10
• node: 6.13.0 && 8.9.4

Anyone can confirm or check this?

[anied]

Just a time saver for anyone who might have been in the same boat as me-- the Node.js V8 --inspector Manager (NiM) seems to introduce this issue when it otherwise wouldn't be present-- I spent about an hour banging my head before disabling the Chrome plugin and discovering that everything worked fine when opening from chrome://inspect.

[blaskovicz]

@anied thank you so much. I spent hours reading github posts, tweaking the settings of gulp-typescript and gulp-sourcemaps, etc. Also worth noting is that because I was using cluster, I had to add port N+1, so localhost:9230, to debug my worker process.

X-Ref: https://stackoverflow.com/a/51327814/626810

[Trott]

Seems to be working on macOS and Linux, but not on Windows. However, for Windows, there's an issue at #10838. So I'm going to close this. However, if I'm wrong to do that, leave a comment. Just doing some tidying around the issue tracker....

[reverofevil]

@Trott Closing the bug because it's being partially blocked by another bug doesn't really make sense for me.

The blocking bug could be easily fixed by recoding Windows-style file paths to Unix-style (required API is generously provided by Node's library), but it is not fixed as to enforce enough rage in users to go into Chromium's bugtracker and sign upstream bug there. I don't really think this is a community-friendly behavior. We already have an example of node-gyp with upstream bugs in gyp, that haven't been fixed for 6 years, and most likely never won't.

[Trott]

Closing the bug because it's being partially blocked by another bug doesn't really make sense for me.

FWIW, I closed it because I'm under the impression that the remaining issue is actually caused by that bug, not because a fix is partially blocked by that bug.

[reverofevil]

Yes, the issue is that Chrome mixed up paths and URLs, but in the end only the fact that source maps are not working is important. Even though it's theoretically correct to fix it in the browser, it's impractical to wait for it, because it won't.

[bnoordhuis]

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

[f1am3d]

It still not working sometimes.
However, source maps working perfectly in latest Firefox.

[june07]

Just a time saver for anyone who might have been in the same boat as me-- the Node.js V8 --inspector Manager (NiM) seems to introduce this issue when it otherwise wouldn't be present-- I spent about an hour banging my head before disabling the Chrome plugin and discovering that everything worked fine when opening from chrome://inspect.

While using chrome://inspect may have worked for you in this instance, more often using NiM is preferred as it provides greater flexibility and I'd be careful in claiming causality. If you more clearly understood what the tool NiM was doing you'd understand that the root cause is the DevTools version you are running and not inherently NiM.

https://blog.june07.com/nim-custom-devtools-url/