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:
- Quick rebuilds
- Features and quality
- 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:
- Confidentiality of source code - we don’t want to share our entire original source code with the world via a source map
- No unnecessary downloading for users, impacting loading performance
- 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.
