Debug compiled ES6 nodejs app in WebStorm

Question

I want to debug a node app that runs from babel compiled ES6 files. I have my ES6 source in an src folder and the babel ES5 equivalent in a build folder.

Project root
|
| build
| > ES5 Compiled files
|
| src
| > ES6 Source files

My goal: Place breakpoints directly in my ES6 source.

I have generated proper source maps and I made a node debug configuration that runs the ES5 main file with project root set as working directory. I can break when I set breakpoints in ES5 compiled files, and it automatically shows my ES6 source.

However I'd like to place breakpoints directly in the ES6 source.

Is that even possible?

-

> 2015-10-11 edit <

Source mapping works now great with @mockaroodev's config when I use an absolute sourceRoot!

However the debugging is still broken: stepping over a line sometimes brings me at unexpected places. Seems that when the line implies a non-internal (not native) require in some way, the debugger will break at the end of the required content. Which is terribly annoying!

I'm using the Webstorm 10.0.4 on linux and upgraded both babel and sourcemaps to the lastest versions.

Does anybody also meet this issue?

Deductive

Officially a feature of WS10 - Tracing languages compiled to JavaScript jetbrains.com/webstorm/whatsnew/#spyjs - though I haven't been able to get this to fully work myself #RTFM; presumably to be able to highlight the execution path a breakpoint will have to be set somewhere in the first instance. – Malm

spy-js: advanced search and source map support blog.jetbrains.com/webstorm/2015/02/webstorm-10-eap - I'm running tests from an ES5 test suite, so not quite as straightforward as this by the looks (not sure where the trace tab is accessible from otherwise also). – Malm

Thank you very much for the info! However I'm still unable to break while using spy. Seems like it's not running in debug mode. Is there a specific conf to setup for spy-js node debugging? – Deductive

FYI I have been able to step through ES6 code with mocha-traceur plugin installed, it didn't behave exactly as I expected though and I didn't have time to follow it up. github.com/domenic/mocha-traceur – Malm

Thank you for the link! However I'm not using traceur but Babel with source maps. – Deductive

There is a karma babel preprocessor github.com/addyosmani/es6-tools#karma-plugins - jonathan-petitcolas.com/2015/03/09/… – Malm

@blint were you able to make this work? – Wicket

@KunalKapadia I partially just did by upgrading Webstorm to latest version as well as gulp-babel and gulp-sourcemaps and making sourceRoot absolute. Partially because stepping over lines doesn't work as expected, see my comment below for more details – Deductive

how do you setup the webstorm debugger? I'm still confused on how to get it to debug babel. Do you use babel-node binary instead of node? Do you only debug code in generated ./dist folder? – Pale

well, not it should just work, isn't it? – Oceania

Answer 1

As of WebStorm 2016.2 EAP, you don't need any source mapping, or even file watchers. Simply configure your "node" executable to be babel-node, and you can debug to your heart's content, even scripts containing async/await.

Tyeshatyg

Answer 2

@mockaroodev solution will work only if you have a flat hierarchy in source. If you have sources in different subpaths, an absolute path (from the domain root) pointing to the source file root is recommended for sourceRoot option.

Updated gulp babel task:

var gulp = require('gulp'),
    sourcemaps = require('gulp-sourcemaps'),
    babel = require('gulp-babel'),
    gutil = require('gulp-util'),
    path = require('path');

// Compile ES6 to ES5
gulp.task("babel", function () {
    return gulp.src('**/*.js')
        .pipe(sourcemaps.init())
        .pipe(babel())
        .on('error', gutil.log)
        .pipe(sourcemaps.write('.', {
            includeContent: false,
            sourceRoot: function(file) {
                return path.relative(file.path, __dirname);
            }
        }))
        .pipe(gulp.dest('dist'));
});

Wicket

this causes some crazyness when your gulp tasks are in a ./tasks folder. I had to do this: var from = file.path; var to = path.resolve(__dirname+'/../server'); var dest = path.relative(from, to) + '/../server'; return dest; – Pale

Just replacing __dirname with '../' + _dirname didn't work ? – Wicket

I posted about it here: #33820576 – Pale

Answer 3

There was an issue concerning this in Jetbrains' ticket system. I think this issue is resolved. Also see the corresponding GitHub issue in the Babel repo.

There is an example setup on Jetbrains' blog, basically setting up babel flags such us --source-maps.

Mazonson

I just tried making sourcemaps directly from latest babel instead of gulp-babel but the situation doesn't get better. Anyway thanks a lot for these links! – Deductive

Answer 4

Yes, it is possible to put breakpoints in your ES6 code using WebStorm. In order for breakpoints to work you need to generate source maps. I use gulp-babel and gulp-sourcemaps to compile es6 with the following gulp task:

var gulp = require('gulp');
var sourcemaps = require('gulp-sourcemaps');
var babel = require('gulp-babel');
var gutil = require('gulp-util');

gulp.src(['src/**/*.es6'])
    .pipe(sourcemaps.init())
    .pipe(babel())
    .on('error', gutil.log)
    .pipe(sourcemaps.write('.', {
        includeContent: false,
        sourceRoot: '../src'
    }))
    .pipe(gulp.dest('lib'))

Note that the extra includeContent and sourceRoot options to sourcemaps.write are critical. By default gulp-sourcemaps adds an erroneous sourceRoot: source to each js.map file. These extra options correct this problem.

Quesenberry

I went away from my work for some time and gave up on this debugging so apologies for this delayed reaction - but I'm back to this! Source mapping works with your config (with an absolute source root) so thanks for this :D However the debugger seems a bit messed up when I step over lines: I can now run to a breakpoint (very slow) but stepping over a line that imply some require makes me break at the end of the required content, which is hugely boring. Any advice for this? – Deductive

Answer 5

adding --inspect flag in the "Node parameters" in the node configuration section solved the issue for me. (additionally to the setting babel-node as node interpreter.

Fathometer