主要是用在 开发环境 中,线上环境是关闭的
引出 source map
当 webpack 打包源代码时,可能会很难追踪到 error(错误) 和 warning(警告) 在源代码中的原始位置。
因为我们的代码通常运行在浏览器上,是通过打包压缩的bundle.js代码,即真实跑在浏览器上的代码,和我们编写的源代码其实是有差异的:比如ES6的代码可能被转换成ES5;比如TS被转换成JS;比如代码进行丑化压缩后,会将之前命名的变量进行修改;比如对应的代码行号、列号在经过编译后肯定会不一致等。 当代码报错需要调试代码时是非常不方便的
例如,如果将三个源文件(a.js, b.js 和 c.js)打包到一个 bundle(bundle.js)中,而其中一个源文件包含一个错误,那么堆栈跟踪就会直接指向到 bundle.js。(见第二张图)
你可能需要准确地知道错误来自于哪个源文件,所以这种提示这通常不会提供太多帮助。
为了更容易地追踪 error 和 warning,JavaScript 提供了 source maps 功能,可以将编译后的代码映射回原始源代码。如果一个错误来自于 b.js,source map 就会明确的告诉你。
在print.js文件中生成一个错误,如下图所示。之后运行 npm run build。
图 未使用source map
图 使用了source map,定位到具体的文件和行号
Q:那么如何调试这种转换后不一致的代码呢?
答案就是source-map。
source-map是从已转换的代码,映射到原始的源文件(source-map文件)。从而使得浏览器可以重构原始源,并在调试器中显示重建的原始源。
bundle.map.source-map文件 浏览器会根据注释自动加载该source-map文件(前提是浏览器得支持source-map)
如何使用source-map
第一步:根据源文件,生成source-map文件。在webpack.config.js中,配置devtool,然后webpack在npm run build打包后,就会生成source-map文件;
2)在转换后的bundle.js中,在该文件的最后一行添加一个注释:即该文件指向sourcemap文件。(注释的格式是固定的)
//# sourceMappingURL = bundle.js.map
浏览器在读取打包后的文件时,当它读取到最后一行注释的时候,就会根据该注释自动查找对应的source-map文件并在浏览器中加载该文件; 浏览器会根据bundle.js和bundle.map.source-map这两个文件还原出源代码 映射 便于调试 当你代码中有问题的时候,报错信息就指向源代码中的具体位置了
那么如何查看浏览器是否支持source-map呢
分析source-map文件
source-map迄今已经历3次版本迭代。第一版的source-map文件体积是原始文件的10倍;第二版减少了约50%;第三版又减少了50%。
所以,目前一个133kb的文件,最终生成的source-map文件大小大概在300kb左右。
虽然目前生成的source-map文件还是有点大,消耗性能。 但是在不同的环境中,我们有不同的最佳实践:比如 在development环境下,我们用哪种source-map比较好; 在production环境下,我们又用哪种source-map比较好
Q:目前的source-map文件是怎么样的呢
- version:当前使用的版本,也就是最新的第三版;
- sources:源文件(我们现在的bundle.js文件都是由哪些文件加载出来的)
- names:转换之前的变量和属性名称(因为我目前使用的是development模式,所以不需要保留转换前的名称);
- mappings(核心):source-map用来和源文件映射的信息(比如位置信息等)、一串base64 VLQ(veriable-length quantity可变长度值)编码;
- file:打包后的文件(浏览器加载的文件);
- sourceContent:转换前的具体代码信息(和sources是对应的关系);
- sourceRoot:所有的sources相对的根目录
生成source-map
devtool选项控制是否生成,以及如何生成source map
如何在使用webpack打包的时候,生成对应的source-map呢?webpack为我们提供了非常多的选项(目前是26个),来处理source-map。官网查询地址https://webpack.docschina.org/configuration/devtool/
选择不同的值,生成的source-map会稍微有差异,打包的过程也会有性能的差异,可以根据不同的情况进行选择。
下面几个值不会生成source-map:
- false:不使用source-map,也就是没有任何和source-map相关的内容;
- none:production模式下的默认值(什么都不写),不生成source-map;
- eval:development模式下的默认值,不生成source-map,但是它会在eval执行的代码中,添加 //# sourceURL=,它会被浏览器在执行时解析,并且在调试面板中生成对应的一些文件目录,方便我们调试代码。
eval("const sum = (a, b) => a + b\r\nconst mul = (a, b) => a * b\r\n\r\nmodule.exports = {\r\n sum,\r\n mul\r\n}\n\n//# sourceURL=webpack://webpack5/./src/js/content.js?");
我们会发现最后一行有/# sourceURL=webpack://webpack5/./src/js/content.js?,浏览器能通过它生成对应的一些文件目录,方便我们调试代码。
source-map的值(即devtool的值)
生成一个独立的source-map文件,并且在bundle文件中有一个注释,指向source-map文件。
bundle.js文件中有如下的注释://# sourceMappingURL=bundle.js.map
1)eval-source-map
eval-source-map会生成sourcemap,但是source-map是以DataUrl添加到eval函数的后面。
2)inline-source-map
inline-source-map会生成sourcemap,但是source-map是以DataUrl添加到bundle文件的后面。
3)cheap-source-map
cheap-source-map会生成sourcemap,但是会更加高效一些(cheap低开销),因为它没有生成列映射(Column Mapping),在开发中,我们只需要行信息通常就可以定位到错误了。
4)cheap-module-source-map
cheap-module-source-map会生成sourcemap,类似于cheap-source-map,但是对源自loader的sourcemap处理会更好。
这里有一个很模糊的概念:对源自loader的sourcemap处理会更好,官方也没有给出很好的解释,其实是如果loader对我们的源码进行了特殊的处理,比如babel。当代码被loader处理后,使用cheap-module-source-map处理效果更好。
即你原先的源代码如果通过loader转换的话,用cheap-module-source-map处理效果会更好
5)hidden-source-map
hidden-source-map会生成sourcemap,但是不会对source-map文件进行引用,相当于删除了打包文件中对sourcemap的引用注释。
// 被删除掉的
//# sourceMappingURL=bundle.js.map
6)nosrouces-source-map
nosources-source-map会生成sourcemap,但是生成的sourcemap只有错误信息的提示,不会生成源代码文件。点击错误提示,无法查看源码。
7)多个值的组合
事实上,webpack提供给我们的26个值,是可以进行多组合的。
组合的规则如下:
- inline-|hidden-|eval:三个值时三选一
- nosources:可选值
- cheap:可选值,并且可以跟随module的值
[inline-|hidden-|eval-][nosources-][cheap-[module-]]source-map
8)每个阶段的最佳实践
- 开发阶段:推荐使用 source-map 或者 cheap-module-source-map,这分别是vue和react使用的值,可以获取调试信息,方便快速开发;
- 测试阶段:推荐使用 source-map 或者cheap-module-source-map,测试阶段我们也希望在浏览器下看到正确的错误提示;
- 发布阶段:false、缺省值(不写)。