Debugging with babel-register + NodeJs does not work

[mattflix]

• VSCode Version: 1.0.0
• OS Version: Mac OS 10.11.3

Setup Steps:

1. Download and expand NodeJsWithBabelDebuggingExample.ZIP
   into a local folder.
2. Open the Terminal and point it to the folder from Step 1.
3. Run npm install (to install the Babel dependencies).
4. Run npm start (to demonstrate that the project is working Node program) which should produce a few lines of output and no errors.

Steps to Reproduce (on Mac OS):

1. In VS Code, open the folder created in the steps above.
2. Press F5 to start debugging the program.
3. Observe the debugger break at line 1 of ./index.js, which is a comment. (This is the first sign of trouble.)
4. Repeatedly press F10 (to step) and observe the debugger break on various other lines of ./index.js that have nothing to do with the code being executed.

Apparently, the inline source map generated by Babel is either being missed, ignored, or misinterpreted. It is also possible that the source map may be faulty, but seeing as a similar setup using other tools (such as Chrome Dev Tools) results in accurate debugging (and only when the source map is supplied) suggests that this is not the case.

Btw, VS Code gives zero feedback (as far as I can see) as to whether a source map was found and/or is being used, making it almost impossible to diagnose this type of trouble.

A few questions:

1. Have a done something wrong in this setup? Is there something wrong or missing in my launch.json or package.json (where the Babel settings are)?
2. Are there some diagnostics that I can enable in VS Code to help determine what is going wrong?
3. Should I even expect to be able to successfully perform source-level debugging of dynamically-transpiled code with VS Code like this, or not? (Other tools can do it, so I will be disappointed if this is not a supported use-case for VS Code.)

The VS Code web pages (https://code.visualstudio.com/docs/editor/debugging) certainly make this sound like I should reasonably expect debugging to work:

Source maps can be generated with two kinds of inlining:

• Inlined source maps: the generated JavaScript file contains the source map as a data URI at the end (instead of referencing the source map through a file URI).
• Inlined source: the source map contains the original source (instead of referencing the source through a path).

VS Code supports both the inlined source maps and the inlined source.

As far as I know, setting { "sourceMaps": "inline" } in the Babel configuration (which this project does via package.json) adheres to the first case ("inlined source maps") which the above quote from the VS Code web pages seems to suggest is supported.

Thanks.

[bpasero]

@isidorn @weinand fyi

[weinand]

@mattflix VS Code does support inlined source maps but it does not yet support dynamically generated source maps at all. We are working on this feature already (and it was planned that the April release would already include some experimental support for dynamically generated source maps).

The babel-register setup is especially tricky because it maps the original source *.js to *.js.source and the generated JavaScript to the original source. This is not a big problem in a debug-only tool like node-inspector which gets all its files through node.js. But in VS Code it is much more difficult because we have to map the files seen by node.js back to the workspace files that VS Code sees. And VS Code does not know what babel-register is actually doing.

[mattflix]

@weinand Thanks for the reply. Good to know that the feature is being worked on.

Fwiw, Chrome DevTools with a workspace configured (where it can read/write from the local file system, turning into a more or less full editor/debugger) manages to work well with the source maps produced by dynamic Babel transpilation.. so it can't be that tricky. :) It creates the illusion that you are debugging and editing only the original source files. It even subtly shades the lines in the code editor that have been mapped by the source map (which is as example of providing feedback about whether or not source maps have been used).

[weinand]

@mattflix VS Code's node debugging is limited by the v8 debugger protocol, it cannot (yet) use the Remote Debugging Protocol. On the other hand the VS Code debugger supports many more languages/runtimes than the Chrome DevTools. One consequence of this is that the VS Code debugger doesn't know anything about source maps. Providing source map feedback in the UI requires more abstractions and protocol enhancements which we will add over time.

BTW, how do you debug node.js with the Chrome DevTools?

[mattflix]

@weinand Thanks for the reply. I don't debug Node.js per se in the regular Chome DevTools, but I can debug projects that take advantage of dynamic Babel transpilation via SystemJS there. The source maps are provided inline (by Babel) and Chrome consumes them. Used in conjunction with a DevTools workspace, to point to my local files, the debugging experience is very good. Plus, I find that it is one of the fastest (most responsive) Javascript debugging environments out there.

In any case, the source map issues are a bit orthogonal to the "pure Node" debugging case but, to answer your question, I can simulate Node-style module resolution using SystemJS by "pre-resolving" all my module locations and writing them to a configuration for SystemJS (a bit like how JSPM works) such that all my requires and imports work as they would running under Node.exe. Of course, I can't use Node-only APIs this way (fs, http), but I am usually debugging "pure" Javascript code, rather than anything Node-specific.