Lots of issues debugging es7 babel node apps with async / await.

When I am debugging my app in many cases it works but in other cases, especially inside of async methods, I am getting tons of cases where the breakpoint jumps around from the top of the method to some lines, instead of stepping over the async method. Also sometimes my breakpoints won't even get hit, or if they do, it break at the top of the async method, rather then the line I set. However, if I put a "debugger" line in my code, it always seems to hit and stop right on that line fine.

I am also seeing a bunch of cases where a variable that is clearly defined (and works fine in code) but when I mouse over it I receive "ReferenceError: object is not defined". Watch window doesn't work, variable doesn't show up in Variables window (some do). 

I am using the mocha run option with 

--compilers js:babel-core/register

method to transpile, with the following .babelrc file:

"presets": ["env", "es2017"],
"plugins": ["syntax-async-functions","transform-regenerator", "transform-object-rest-spread"],
"sourceMaps": "both"

Am I doing something wrong? Why can't I use the debugger like I can everywhere else? I am using IntelliJ 2016.3.5.


Async functions debugging with Node.js is not yet supported - see https://youtrack.jetbrains.com/issue/WEB-19876.

Note that V8 engine itself doesn't include async/await implementation (https://github.com/nodejs/promises/issues/4)


Right, but isn't intellij capable of using source maps from babel for debugging? Why does placing a "debugger" line always work? Why do some variables show in the debugger but not others? Debugging also works sometimes... Wouldn't it just either work or not at all? Why so inconsistent?


>but isn't intellij capable of using source maps from babel for debugging?


sure, and it does use it. But sourcemaps produced by Babel are not always accurate - see https://github.com/mozilla/source-map/issues/221, https://github.com/babel/babel/issues/2515

>Why does placing a "debugger" line always work? 

`debugger` support is implemented differently - it's a core functionality, this statement is parsed by VM itself (unlike breakpoints that are set by clients in files that are not run by VM before the code is executed, etc.)

>Wouldn't it just either work or not at all?

works if the correct line number is returned, doesn't work otherwise


BTW, I can't make Mocha async tests running at all when using your .babelrc + `--compilers js:babel-core/register` - always getting `ReferenceError: regeneratorRuntime is not defined`. Any hints? I'm using the most recent versions of all required modules


Too bad - my async code is amazingly beautiful, concise and a pleasure to develop... but debugging with these issues can sometimes be a massive pain.

Here is my npm run line:

cross-env NODE_ENV=test mocha --compilers js:babel-core/register --require babel-polyfill api/**/tests/*.js


"dependencies": {
"cross-env": "^3.1.4",
"debug": "~2.2.0",
"es6-promisify": "^5.0.0",
"forever": "^0.15.2",
"inert": "^4.1.0",
"log4js": "^0.6.38",
"morgan": "~1.7.0",
"update": "^0.7.4",
"validator": "^3.40.0",
"vision": "^4.1.1",
"web-request": "^1.0.7"
"devDependencies": {
"babel-cli": "^6.22.2",
"babel-core": "^6.22.1",
"babel-plugin-transform-object-rest-spread": "^6.23.0",
"babel-preset-env": "^1.1.8",
"babel-preset-es2015": "^6.22.0",
"babel-preset-es2017": "^6.22.0",
"babel-promisify": "^1.0.0",
"babel-register": "^6.22.0",
"better-npm-run": "0.0.14",
"chai": "^3.5.0",
"chai-http": "^3.0.0",
"mocha": "^3.2.0",
"npm-run-all": "^4.0.1",
"should": "^6.0.3",
"sinon": "^1.17.7",
"supertest": "^0.15.0"

"presets": ["env", "es2017"],
"plugins": ["syntax-async-functions","transform-regenerator", "transform-object-rest-spread"],
"sourceMaps": "both"

`--require babel-polyfill` did it, thank you!


+1 please add this feature


Any update on this? When will it be supported, really makes debugging a huge pain:(



I've been developing js apps for another year since I made this post, been buying intellij for years and wow, I cannot believe this is still an issue. I am consistently unable to inspect certain variables, hit certain break points, and many of the time it doesn't even properly break on the line that has the breakpoint. It is impossible to step over a line with an await and it is just nightmarish to get into any complex code that has an await and debug. When is this going to be fixed!?!?!? There's gotta be a lot more js async/await node developers out there by now!


WebStorm does provide async/await support when debugging with Node.js 8.5+ (https://youtrack.jetbrains.com/issue/WEB-19876#focus=streamItem-27-2692614-0-0).

But babel issues are still there, so breakpoints in async functions don't work reliably - see https://github.com/Microsoft/vscode/issues/45345, for example


I understand it doesn't support but it's been out long enough now and is an extremely important feature to use when devloping. What is taking so long to support?


I don't understand what feature you are talking about. Babel produces bad sourcemaps for async functions, and, as sourcemaps is the only way to map files in VM to the original source files, there is not much we can do to fix the issue


our team has discussed migrating to another IDE just because of the issues with debugging babel node processes.

right now we are using inspect with chrome debugger to have a slightly better debugging env.

we are facing issues with async / await, multiple node processes (e.g while using webpack api) etc.


Please sign in to leave a comment.