Sourcemaps do not debug correctly in chrome. (T7210)

[babel-bot]

Issue originally made by @joshuap256

Bug information

• Babel version: 6.7.2
• Node version: 4.2.4
• npm version: 2.14.2

Options

Just --source-maps using babel-cli.

Input code

debugger;

[1,2,3,4,5]
    .map(n => n * 100)
    .forEach(n => console.log(n));

var foo = {
    func: () => {}
};

var bar = foo.func({
    baz: () => {
        var qux = Math.round(0);
    }
});

[1,2,3,4,5]
    .map(n => n * 100)
    .forEach(n => console.log(n));

Description

edit: Please check tebari's comment for a demo repo that reproduces the issue.

This is a simplified example that demonstrates messed up break points while using Chrome v48.0.2564.116. If you transpile this code using babel-cli:

./node_modules/.bin/babel src/demo.js -o dist/bundle.js --source-maps

Then in Chrome it won't let you set a break point on line 3. However line 17 is fine.

If you use the raw js file without transpiling, Chrome can add a break point on line 3. Also I found that Babel 6.4.4 generates sourcemaps that work correctly in Chrome.
{F49466}

[babel-bot]

Comment originally made by @tebari

This repository reproduces the issue, without involving webpack, and also demonstrates the breakpoint working when transpiling with babel 6.4.4.

https://github.com/tebari/babel-t7210-example

[babel-bot]

Comment originally made by @loganfsmyth

If you're subscribing to this and you're unable to place a breakpoint in other places that aren't arrays like in this example, it'd be great to get more reproduction cases for this.

[babel-bot]

Comment originally made by @tebari

I was playing around with the sample, and found that if I run this

//Demo file -- babel current
debugger;

[1,2,3,4,5]
    .map(n => n * 100)
    .forEach(n => console.log(n));

var foo = {
    func: () => {}
};

foo.func();

var bar = foo.func({
    baz: () => {
        var qux = Math.round(0);
    }
});

[1,2,3,4,5]
    .map(n => n * 100)
    .forEach(n => console.log(n));

I can't set a breakpoint in the foo.func(); line. But now I can set a breakpoint on the first array.

[babel-bot]

Comment originally made by Nino Porcino (nino.porcino)

opening a babel-generated sourcemap in Visual Studio and setting a breakpoint shows there is an 4-character offset (see the attached image).

The offset could explain why some lines are breakpointable and some others not. I hope this is an hint.

{F80363}

[hzoo]

Closing this issue as it's been inactive for several months. Please feel free to open a new issue or leave a comment asking to reopen this issue. Thanks! ✌️

If you just have an usage issue or want help, I would recommend checking out our slack community or StackOverflow.

[CharlieGreenman]

Is there any way we can re-open this? Running across an issue where breakpoints in chrome are off by one line.

[jridgewell]

#6008.

[CharlieGreenman]

I should mention that I think there is merit with having sourcemaps compiled using eval. There is a work around with webpack using eval. If there is a way we can figure out how to do that with babel-cli, that would solve issue for most: https://stackoverflow.com/questions/46669432/using-the-webpack-eval-devtool-option-with-babel-cli

Users can then migrate from babel over to webpack. Giving more space for this issue to be solved. Thank you.

[loganfsmyth]

@CharlieGreenman If something works with eval but not normal sourcemaps, then that's just a Webpack bug, because either way Babel is generating the exact same sourcemap.

[CharlieGreenman]

@loganfsmyth just to clarify. This is an issue using the babel cli --source-maps inline / --source-maps option. Suggestion was to borrow from solution that works with webpack, wherein sourcemaps are compiled using eval. Trying to apply that solution for babel cli without webpack.

[loganfsmyth]

@CharlieGreenman This issue is about Babel in general failing to create accurate sourcemaps in some cases. Whether a sourcemap is inlined with eval or put into a file is irrelevant, it is still the identical sourcemap content. The only reason Webpack has the eval mode is because it makes incremental compilation faster, it does not change the meaning of any sourcemap content.

[CharlieGreenman]

@loganfsmyth you are right. That being said, I have the following question. Would we be able to offer an eval option for the babel cli?