source maps are not working when debugging with chrome
Closed this issue ยท 71 comments
- 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.jsDebugger 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?
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.
@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.
poke @jasnell
Ping
/cc @nodejs/v8-inspector
Any solution here guys? @jasnell @matthewoates
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.
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 notifications@github.com 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
.
@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)
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).
+1
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.
@robertchiras see my first comment. You don't need to access the filesystem for source maps to work.
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..?
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
This appears to be fixed in Node 7.2.1 and Canary. Can anyone else confirm?
@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.
@joshunger This is working for me now with Node 7.2.1 & Canary (Version 57.0.2962.0 (Official Build) canary (64-bit) )
Confirmed ๐ It's working here with Node 7.3.0 and Canay Version 57.0.2963.0
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.
Looks like Firefox's https://github.com/devtools-html/debugger.html/ works with Node 6 if you want to compare debuggers.
Is there anyway to open up the chrome debug link automatically rather than copying and pasting everytime?
@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.
@eugeneo , @s3ththompson: when do we remove auto-attach from behind experiments in Chrome?
@RanjithNair view this #9185 issue, I write a proxy to workaround the uuid problem
Based on @joshunger's idea. The following works for me:
- Launch chrome with:
/Applications/Google\ Chrome.app/Contents/MacOS/Google\ Chrome --remote-debugging-port=9222 --no-first-run --user-data-dir=/tmp/chrome-dev-profile - Visit the debug URL from
node --inspect --debug-brkcommand. For example:chrome-devtools://devtools/bundled/inspector.html?experiments=true&v8only=true&ws=127.0.0.1:9229/32b58564-d201-4d3b-9174-272cee84146f
@RanjithNair checkout this module: https://github.com/jaridmargolin/inspect-process
Its basically a convenience wrapper around --inspect option. Works great for me so far.
Node Version: v7.7.1
Platform: Win 10
Chrome: 58.0.3029.6
node --debug-brk --inspect
Source maps are not working in Developer Tools node source panel
Platform: win7
Tested browsers:
- Chrome Canary Version 59.0.3049.0 (Official Build) canary (64-bit)
- Chrome Version 59.0.3047.4 (Official Build) dev (64-bit)
Node version: v7.7.4
Inlined sourceMaps still don't work
Finally debugging es6/babel source maps is working correctly with me:
Platform: Ubuntu 16.10
Chrome: Version 57.0.2987.98 (64-bit)
Node: v7.7.1
The only way I was able to debug remote typescript on node 7.7.4 was to inline maps and source files with:
"inlineSourceMap": true,
"inlineSources": true
in tsconfig.json so it looks like:
{
"compilerOptions": {
"module": "commonjs",
"target": "es6",
"sourceMap": true,
"alwaysStrict": true,
"inlineSourceMap": true,
"inlineSources": true
},
"exclude": [
"node_modules"
]
}
Otherwise Chrome and WbStorm 2017.1 don't even show .ts files.
@sffetlio Well, with that settings on the tsc2.2.1 I got this:
error TS5053: Option 'sourceMap' cannot be specified with option 'inlineSourceMap'Anyway it's not so critical to debug w/o sourcemaps but with them it would be much more better.
Yes, I just checked, I got this too when running tsc. I'm using WebStorm and it doesn't complain.
Still, debugging works for me without "sourceMap": true,.
I tried to repro the issue from the original comment and it looks like it is working (e.g. DevTools status bar shows that the file is source mapped, breakpoints seem to be working):
@eugeneo What the platform and nodejs working with and tool that generates these sourcemaps?
I used the original repro from this issue (i.e. the top post).
@hinell I was using repro from to very first comment by @yanivefraim
@eugeneo, if you would, please specify node.js version and OS.
I have tried example from first comment and it doesn't work. My specs:
node.js : 7.7.1,
win 10 x64,
Chrome version 58.0.3029.41 beta,
Chrome Canary version 59.0.3062.0
Upd.
Have checked it with Ubuntu 16.4, latest Chrome Dev and node 7.7.1 - it works, and seems i've got the difference. It's strange, because i ran node.js and chrome with admin rights on Windows.
Chrome Dev 59.0.3053.3
@eugeneo, yes, source-maps are embedded. Also i've tried latest 8.0.0. nightly build of Node.js on Windows, and it does not gave any positive result.
Chromium Version 58.0.3029.110 (64-bit)
Node.js v8.1.2
OS: Linux arch 4.10.3-1-ARCH
Inline source map still doesn't work.
Anyone figured out why debugging with inline sourcemaps works for someone, and doesn't works for another?
May be different compiler options? Or something?
The missing sourcemaps problem occures only on my windows system (with latest nodejs version 8.2.1). On my Ubuntu system + on a friends mac system everything works fine. (Chrome Version on all systems: Version 60.0.3112.90).
โฎ(โฏ_โฐ)โญ
Work on mac๏ผNode 7.9.0 Chrome 59
Don't work on windows Node 7.9.0, Chrome 60
But, I run Node on mac. then forward port to windows, The Chrome on windows works!
I can tell the problem occures on windows's Node
โฎ(โฏ_โฐ)โญ @bnoordhuis How can I do to pass the bug? Such as modify configure?
The problem still persist when debugging nodejs apps with both embedded and standalone source maps.
Browser: Chrome Version 60.0.3112.90 (Official Build) (64-bit)
Node: v8.2.1
Platform: Windows 10 x64 Pro
Source maps are generated by TypeScript compiler.
โฎ(โฏ_โฐ)โญ
@hinell you can refer to #10838 (comment)
I found a temp workaround
@j3l11234 Well, that's pretty interesting solution. I'll test it soon and report back later.
I am running node.js inside a Docker container and therefore paths are not correct compared to what chrome thinks.
@j3l11234 workaround works, however it looks weird! ๐
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:
- Have a script
babel <src folder> -d <dist folder> -s && node --inspect --inspect-brk <dist folder>/index.jsin your package.json - Run said script
- Open Chrome at
about://inspectand click on your device (node) process. - In the Chrome Devtools,
โ+Pand 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
@kevinsimper have you attempted to map the ports of your docker container to the localhost?
the npm script should look something like this
"start": "node --inspect=0.0.0.0:9229 bootstrap.js",
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.
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...
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)
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
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 ๐ฑ
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...
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?
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.
@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.
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....
@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.
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.
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.
It's been fixed in devtools (diff) so I'm going to go ahead and close this out.
It still not working sometimes.
However, source maps working perfectly in latest Firefox.
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.