webpack的devtool和source maps的作用

来源：网络文章列表 2019-07-09 8

我们在打包中，将开发环境中源代码经过压缩，去空格，babel编译转化，最终可以得到适用于生产环境的项目代码，这样处理后的项目代码和源代码之间差异性很大，会造成无法debug的问题。举例来说，如果压缩等处理过的生产环境中的代码出现bug，调试的时候只能定位到压缩处理后的代码的位置，无法定位到开发环境中的源代码。

Webpack打包生成的.map后缀文件，使得我们的开发调试更加方便，它能帮助我们链接到断点对应的源代码的位置进行调试（//# souceURL），而devtool就是用来指定source-maps的配置方式的。

一、什么是Sourcemap?

我们在打包中，将开发环境中源代码经过压缩，去空格，babel编译转化，最终可以得到适用于生产环境的项目代码，这样处理后的项目代码和源代码之间差异性很大，会造成无法debug的问题。

举例来说，如果压缩等处理过的生产环境中的代码出现bug，调试的时候只能定位到压缩处理后的代码的位置，无法定位到开发环境中的源代码。

sourcemap就是为了解决上述代码定位的问题，简单理解，就是构建了处理前的代码和处理后的代码之间的桥梁。主要是方便开发人员的错误定位。这里的处理操作包括：

I）压缩，减小体积

II）将多个文件合并成同一个文件

III）其他语言编译成javascript，比如TypeScript和CoffeeScript等

官网里的sourcemap种类

二、 Webpack中的Sourcemap

webpack在打包中同样支持Sourcemap，并且提供了十几种的组合。我们以官网给出的为例：

I）eval ：每一个模块都执行eval()过程，并且会追加//@ sourceURL

II）eval-source-map：每一个模块在执行eval()过程之后，并且会为每一个模块生成sourcemap文件，生成的sourcemap文件通过DataURL的方式添加

III）cheap-eval-source-map：跟eval-source-map相同，唯一不同的就是增加了”cheap”，”cheap”是指忽略了行信息。这个属性同时也不会生成不同loader模块之间的sourcemap。

VI）cheap-module-eval-source-map：与cheap-eval-source-map相同，但是包含了不同loader模块之间的sourcemap

官网给出的例子容易让人看懵，因为官网的devtool类型都是以组合形式给出的，实际上webpack中的sourcemap的基本类型包括：eval，cheap,moudule，inline,source-map。其他的类型都是根据这5个基本类型组合而来。我们来具体分析一下这5个基本类型

（1）eval

eval会将每一个module模块，执行eval，执行后不会生成sourcemap文件，仅仅是在每一个模块后，增加sourceURL来关联模块处理前后的对应关系。举例来说：

webpackJsonp([1],[  
function(module,exports,__webpack_require__){    
eval(
      ...      
//# sourceURL=webpack:///./src/js/index.js?'
    )
  },  
function(module,exports,__webpack_require__){    
eval(
      ...      
//# sourceURL=webpack:///./src/static/css/app.less?./~/.npminstall/css-loader/0.23.1/css-loader!./~/.npminstall/postcss-loader/1.1.1/postcss-loader!./~/.npminstall/less-loader/2.2.3/less-loader'
    )
  },  
function(module,exports,__webpack_require__){   
 eval(
      ...      
 //# sourceURL=webpack:///./src/tmpl/appTemplate.tpl?"
    )
  },
...])

上述是一个指定devtool：eval的压缩后的代码，我们发现压缩后的代码的每一个模块后面都增加了一端包含sourceURL的注释，sourceURL的值是压缩前的代码，这样就通过sourceURL关联了压缩前后的代码，并没有为每一个模块生成相应的sourcemap。

因为不需要生成模块的sourcemap，因此打包的速度很快。

（2）soure-map
source-map会为每一个打包后的模块生成独立的soucemap文件，举例来说：

webpackJsonp([1],[  
function(e,t,i){...},  
function(e,t,i){...},  
function(e,t,i){...},  
function(e,t,i){...},
  ...
])//# sourceMappingURL=index.js.map

打包后的模块在模块后面会对应引用一个.map文件，同时在打包好的目录下会针对每一个模块生成相应的.map文件，在上例中会生成一个index.js.map文件，这个文件是一个典型的sourcemap文件，形式如下：

{  
"version":3,  
"sources":[
    "webpack:///js/index.js","webpack:///./src/js/index.js",    
    "webpack:///./~/.npminstall/css-loader/0.23.1/css-loader/lib/css-base.js",
    ...
],  
"names":["webpackJsonp","module","exports"...], 
"mappings":"AAAAA,cAAc,IAER,SAASC...",  
"file":"js/index.js",  
"sourcesContent":[...],  
"sourceRoot":""
}

（3）inline

与source-map不同，增加inline属性后，不会生成独立的.map文件，而是将.map文件以dataURL的形式插入。如下所示：

webpackJsonp([1],[  
function(e,t,i){...},  
function(e,t,i){...},  
function(e,t,i){...},  
function(e,t,i){...},
  ...
])
//# sourceMappingURL=data:application/json;charset=utf-8;base64,eyJ2ZXJzaW9...

打包好模块后，在sourceMappingURL中直接将.map文件中的内容以DataURL的方式引入。

（4）cheap

cheap属性在打包后同样会为每一个模块生成.map文件，但是与source-map的区别在于cheap生成的.map文件会忽略原始代码中的列信息。

devtool: 'eval-source-map'

"mappings": "AAAAA,QAAQC,GAAR,CAAY,aAAZ",
devtool: 'cheap-source-map'

"mappings": "AAAA",

对比增加cheap和没有cheap情况下，打包后输出的.map文件，在文件中
使用了VLQ编码，有”逗号”表示包含了列信息，显然增加cheap属性后，.map文件中不包含列信息。

此外增加cheap后也不会有loader模块之间对应的sourcemap，什么是模块之间的sourcemap呢？

因为webpack最终会将所有的非js资源，通过loader的形式转变成js资源。比如jsx语言的操作分为：

jsx——（loader）——js——（压缩等处理）——压缩后的js

如果没有loader之间的sourcemap，那么在debug的时候定义到上图中的压缩前的js处，而不能追踪到jsx中。

（5）module：包含了loader模块之间的sourcemap

这样差不多就理清了webpack中所有的sourcemap类型。

三、在不同的环境中如何选择sourcemap的类型

在了解了webpack中所有的sourcemap基本类型后，我们来分析，如何针对开发环境和生产环境，选择合理的sourcemap属性。

（1）首先在源代码的列信息是没有意义的，只要有行信息就能完整的建立打包前后代码之间的依赖关系。因此不管是开发环境还是生产环境，我们都会选择增加cheap基本类型来忽略模块打包前后的列信息关联。

（2）其次，不管在生产环境还是开发环境，我们都需要定位debug到最最原始的资源，比如定位错误到jsx，coffeeScript的原始代码处，而不是编译成js的代码处，因此，不能忽略module属性。

（3）再次我们希望通过生成.map文件的形式，因此要增加source-map属性

对于开发环境

eval 每个模块都使用 eval() 执行，并且都有 //@ sourceURL。此选项会相当快地构建。主要缺点是，由于会映射到转换后的代码，而不是映射到原始代码，所以不能正确的显示行数。
inline-source-map - SourceMap 转换为 DataUrl 后添加到 bundle 中。
eval-source-map - 每个模块使用 eval() 执行，并且 SourceMap 转换为 DataUrl 后添加到 eval() 中。初始化 SourceMap 时比较慢，但是会在重构建时提供很快的速度，并且生成实际的文件。行数能够正确映射，因为会映射到原始代码中。
cheap-module-eval-source-map - 就像 eval-source-map，每个模块使用 eval() 执行，并且 SourceMap 转换为 DataUrl 后添加到 eval() 中。"低开销"是因为它没有生成列映射(column map)，只是映射行数。

对于生产环境

source-map - 生成完整的 SourceMap，输出为独立文件。由于在 bundle 中添加了引用注释，所以开发工具知道在哪里去找到 SourceMap。
hidden-source-map - 和 source-map 相同，但是没有在 bundle 中添加引用注释。如果你只想要 SourceMap 映射错误报告中的错误堆栈跟踪信息，但不希望将 SourceMap 暴露给浏览器开发工具。
cheap-source-map - 不带列映射(column-map)的 SourceMap，忽略加载的 Source Map。
cheap-module-source-map - 不带列映射(column-map)的 SourceMap，将加载的 Source Map 简化为每行单独映射。
nosources-source-map - 创建一个没有 sourcesContent 的 SourceMap。它可以用来映射客户端（译者注：指浏览器）上的堆栈跟踪，而不会暴露所有的源码。

总结：

在开发环境中我们使用：cheap-module-eval-source-map

在生产环境中我们使用：cheap-module-source-map。

这里需要补充说明的是，eval-source-map组合使用是指将.map以DataURL的形式引入到打包好的模块中，类似于inline属性的效果，我们在生产中，使用eval-source-map会使打包后的文件太大，因此在生产环境中不会使用eval-source-map。但是因为eval的rebuild速度快，因此我们可以在本地环境中增加eval属性。

然而vue-cli脚手架搭建的工程，开发环境使用的是eval-source-map，生产环境用的是source-map。不管怎么说的，其实用起来感觉都差不多。但是，直接将sourceMap放入打包后的文件，会明显增大文件的大小，不利于静态文件的快速加载；而外联.map时，.map文件只会在F12开启时进行下载（sourceMap主要服务于调试），故推荐使用外联.map的形式。