Debugging With Chrome With Es6

I am trying to use Ecmascript 2015 for my project and I am finding it hard to add breakpoints at specific places (places I thought was logical to have a breakpoint). I have #enabl

Solution 1:

The problem is with source code (via source maps) to real code mapping. While the source is concise and dense, the generated code is typically longer and the mapping between the two isn't (and probably cannot be) done in a way which will guarantee a 1:1 relationship between the two.

So when you try to place a breakpoint in a single line statement such as (foo) => bar, the actual executed code is at least a few lines long and I assume (and don't really know!) that devtools tries to place the real breakpoint simply on the first line of the real, running code. - Which in turn fails for expressions.

It is an inherent disadvantage of generated code and applies to all compile-to-js languages with source maps. Unfortunately, I'm not aware of a good workaround. As a last resort in these cases I just turn off source maps in the browser and step through the real, generated code.

Hope that helps :/

Solution 2:

Have you followed all the instructions here?

https://developer.chrome.com/devtools/docs/javascript-debugging#source-maps

Also, if you have enable harmony flag set, you won't need to use babeljs to transpile, Chrome will understand ES6/2015 or at least the subset it supports... so maybe turn off babeljs and avoid sourcemaps all together?

Solution 3:

Normally I would solely blame sourcemaps, but from what you are showing here I am drawing a conclusion from comparing debug in chrome to the javascript debugger statement. I believe they do not work that differently.

So we know that you cannot place a debugger statement within a functions parameters area.

This is happening alot in your recorded example.

.then(debugger)

If you want to be able to break there you must add more code.

.then((whatever) => { 
 // We need an existing empty line here.return whatever
})

Also turning off source maps is a good idea too, and then just step through the code line by line.

I notice that you want to pause near or in promise flow. Remember this warning that pausing async code in complex apps can cause race conditions and furthermore lots of unexpected behavior.

Solution 4:

It seems to be an error on Chrome.

It's fixed on Canary: https://bugs.chromium.org/p/chromium/issues/detail?id=611328#c21

There's a big discussion going on in github if it doesn't solve your problem. https://github.com/webpack/webpack/issues/2145