Sourcemap is not enabled in development?

[kasperpeulen]

It seems like sourcemap is not enabled in development, is there some reason for that?

My normal workflow, is that if I see an error in the chrome console, I look up the file and line number of the error in my editor. But at this moment, the line numbers are not correct, because it doesn't use source mapping.

This leads to another question, why is ES6 transpiled to ES5 in development? Shouldn't it transpile to ES6 now that chrome, edge, safari and firefox all support more ES6 than babel itself support?

I think ES6 to ES5 transpiling is something only needed for production.

[mxstbr]

It seems like sourcemap is not enabled in development, is there some reason for that?

I don't think there is one except it was an oversight, that should definitely be added!

This leads to another question, why is ES6 transpiled to ES5 in development? Shouldn't it transpile to ES6 now that chrome, edge, safari and firefox all support more ES6 than babel itself support?

I've never heard of this being done before to be honest, but I think we want to support everybody with create-react-app, even developers that still use IE, so I don't think that'll change!

[gaearon]

We want to support any browsers currently supported by React (that includes >= IE 9).
As for sourcemaps, unfortunately there is a reason: #109 (comment).

I wonder if this could be fixed on Webpack (or Chrome?) side in any way.
cc @TheLarkInn

[ChrisCinelli]

What about using cheap-module-eval-source-map?

[gaearon]

Same problem as I described in #109 (comment).

[taion]

This was a (bizarre) bug fixed in Chrome 53.

We handle this with

config = merge(config, {
  devtool: 'cheap-module-source-map',

  // TODO: Workaround for Chrome < 53. Remove once Chrome 53 hits stable.
  output: {
    devtoolModuleFilenameTemplate: '[absolute-resource-path]',
  },
});

per something cited on some webpack issue somewhere.

eval sourcemaps don't work with breakpoints on startup in general. The "inline" sourcemap would work too, and would obviate the need for the dumb devtoolModuleFilenameTemplate thing, but it imposes a significant penalty on page load time for large apps (from 6s to 30s in our case, which was unacceptable even for development)

[taion]

IMO the best balanced approach is to use cheap-module-source-map as above, stick in an override for devtoolModuleFilenameTemplate, and remove it once Chrome 53 hits the stable channel.

[gaearon]

This is super interesting, thank you for the info. We'll give it a try.

[gaearon]

I looked it again. cheap-module-source-map works great with breakpoints, thanks for the tip.

There is however another (IMO rather big) usability problem: https://bugs.chromium.org/p/chromium/issues/detail?id=327092

I understand this is not Webpack’s issue, but not being able to inspect or reference some variables / import in console is very frustrating and completely non-obvious to the beginners.

Canary shipped support for variable mappings but I don’t think Webpack or Babel support this sourcemap spec (I’m not even sure which spec Chrome is supporting.)

So I’m not comfortable enabling sourcemaps in development until Babel and Webpack output them in a way that at least Canary can map the variable names correctly.

[taion]

I don't think the tradeoff is clearly in favor of "avoid unexpected variable names", BTW – the flip side is that the code you see in the debugger is not the code that you wrote, which also is confusing and strange.

As a caveat, I think "variable bindings like this and imports are a bit messed up" is less bad than "the code you see in the debugger is not the code you wrote, and the variable bindings are still messed up but transparently so" – especially because as transpiled, semantically imports cannot be represented as "normal" variables anyway.

[taion]

Like specifically, at least as long as imports are transpiled with Babel and are not actually supported, something like:

import Foo from './Foo';

needs to be something like FooModule.default rather than just Foo, and it's not just a matter of mapping the variable name.