Use better-suited devtool option for sourcemaps

[WickyNilliams]

I recently hit an issue where this value was showing up as undefined when debugging in browser's dev tools, in cases like this:

const foo = {
  greeting: "hello",
  audiences: ["world", "mars", "wales"],

  bar() {
    return this.audiences.map(audience => {
      return `${this.greeting} ${audience}`; // `this` is `undefined` when inspecting
    });
  }
};

Note, this is only when debugging and inspecting the value (e.g. mouseover), the actual code is fine when running.

After some research I realised this was due to the choice to sourcemap generated by webpack. You currently have it set to "cheap-module-source-map", which the webpack docs say is "not ideal for development nor production".

The webpack docs recommend either "eval", "eval-source-map", "cheap-eval-source-map", or "cheap-module-eval-source-map"for dev. "eval-source-map" fixed the issue I described above.

Is it worth changing to a setting recommended by webpack, or is there some specific reason for using "cheap-module-source-map" that is not obvious to me?

[gaearon]

As far as I remember our option is the only one that reliably worked in Chrome with breakpoints. Others either ignore breakpoints on start, or put them in wrong places. (Maybe this got fixed by now.)

"eval-source-map"fixed the issue I described above.

Can you explain how this is possible? this doesn't work because Babel probably transpiled it to _this or something like it. How can changing sourcemap setting affect this?

[miraage]

Not sure about breakpoints, but I have always been using eval-source-map in development mode for fancy sourcemaps.

[WickyNilliams]

Right now, breakpoints seem to be working fine for me in chrome with eval-source-map. I'll report back at the end of the day after using it for a few hours.

Source maps support mapping of variable/symbol names. I assume only the more comprehensive sourcemap generation options do this, whereas the more lightweight options do not. See https://bugs.chromium.org/p/chromium/issues/detail?id=327092

In any case, the current choice is not recommended so it's probably worth changing to one that is recommended, even if it is not eval-source-map

[gaearon]

In any case, the current choice is not recommended so it's probably worth changing to one that is recommended, even if it is not eval-source-map

I just want to make it clear that we didn't pick the current one randomly. We picked it after weeks of complaints and research as to which option works most reliably, and reporting bugs upstream. Maybe it's not "recommended" but there were good reasons why it was chosen. At the time the "recommended" ones were problematic, and I don't know if the webpack documentation authors were aware of these problems or not (and whether they are now). So it's worth doing a very extensive check with the test cases one can find in different past issues, both here and in webpack repo.

[gaearon]

(There is also an issue of compilation speed in larger projects. Especially hot reloading. The chosen option can make a difference between 200ms and 2 seconds.)

[WickyNilliams]

I did ask initially if there is some reason for choosing it that's not obvious. So thanks for the insight on that :) And I absolutely agree that it's a change that shouldn't be made on a whim, or without extensive research.

Regarding compilation speed, webpack docs say that cheap-module-source-map is "medium" speed to build, but "pretty slow" for rebuilds. Whereas eval-source-map is "slow" to build but "pretty fast" to rebuild (on that front, cheap-module-eval-source-map is listed as being speedier than both, but same quality as the current cheap-module-source-map). Though it's not clear if the listed rebuild speeds are relative to build speed, or whether they're some absolute measure. It may be that eval-source-map is not so bad after initial startup cost, since rebuild speed is probably the most important important metric?

[gaearon]

No idea, sorry 😄

If you feel like doing this research again, you are most welcome!

[jasonLaster]

We recently landed support for mapping scopes and variables in Firefox DevTools. The feature requires column-based mappings, which are needed for accurately mapping identifiers between original and generated code.

Webpack has a couple of source map options that work well (source-map, eval-source-map , inline-source-map). Basically it can't be cheap (read line-based) and it has to include the original source docs.

Would you be open to switching from a cheap-module-source-map to one of the other options in development?

Before

After

[WickyNilliams]

Awesome! Thanks @jasonLaster