Quick guide to webpack source map options

The webpack devtool configuration option controls source map generation. It has many options, and there are a few things to consider when choosing which one to use in different scenarios. This quick guide introduces the feature/performance differences between each one, and what to consider when choosing.

Development

The goals here are:

  1. Quick rebuilds
  2. Features and quality
  3. Quick initial builds

Which one you choose will depend on the features/quality you want, and performance - taking into account codebase size. My comments on performance are only based on the ratings given in the table from the documentation.

The following are in increasing order of quality, or decreasing order of performance.

none

(Omit the devtool option). No source map. You can view the as-downloaded bundle, in one big file.

This isn’t a reasonable choice here, but it’s where we start.

eval

Modules (files) are now separated, named, and organised as per application directory structure.

“Super fast”.

cheap-eval-source-map

Loading code generated by Webpack is now removed. You see the output of your loaders/transpilers.

“Pretty fast” builds, “fast” rebuilds.

cheap-module-eval-source-map

You see your original source. It uses the source maps output by your loaders.

“Medium” builds, “fast” rebuilds.

eval-source-map

Adds column-level mappings, so you can set inline breakpoints, and step debug at statement-level.

“Slow” builds, “pretty fast” rebuilds. The best quality.

Production

The goals here are:

  1. Confidentiality of source code - we don’t want to share our entire original source code with the world via a source map
  2. No unnecessary downloading for users, impacting loading performance
  3. Useful error stack traces - errors reported to us (by users, or a reporting service) should be of use to us in diagnosing problems

(none)

As seen above for Development, is also an option here. Error stack traces are useless.

source-map

Full source map to original source, as a separate file. A reference comment at the end of the bundle tells browser developer tools where to load it from, which is done as soon as they are opened.

This source map shouldn’t be made publically accessible. Configure your server to restrict access to it, or deploy it somewhere internal. In the latter case, adapt the reference comment by using the SourceMapDevToolPlugin directly instead of the devtool option, and setting its append option.

You could upload it to a JavaScript error reporting service, so it can show you mapped stack traces for errors that your application uploads there.

hidden-source-map

As source-map, but without the reference comment in the bundle.

Use this if you want the source map, but don’t want browser developer tools to load it automatically. You can still load it manually.

Also use this if you’re not going to deploy the source map at all.

nosources-source-map

As source-map, but without the actual source code - so only the module names, paths, and line numbers. This allows useful error stack traces to be generated by the browser, albeit without method names - but you can look those up against original source using the line numbers.

Using this would allow you to receive useful stack traces copy-pasted by users from the console (or an error detail dialog). The downside is that it exposes your module names and directory structure.

Other options

The documentation also lists a few other options as not ideal for development nor production, but needed for some 3rd party tools.

Also remember

As well as setting the devtool option, you’ll need to configure your loaders to produce source maps, and your minifier to be source map friendly.

Fully-working sourcemaps rely on a fairly long chain of tools being compatible, so all combinations of versions and configuration options may not work.

MORE BY ROBAT

blog comments powered by Disqus