最近在开发一个低代码平台，次要用于经营搭建 H5 流动。这两头波及到第三方组件的开发，而第三方组件想要接入平台，须要通过咱们特定的打包工具来 build。构建之后的组件，会合并成单个的 js 文件，而且代码会被压缩会混同，这个时候如果须要调试，那就会极其苦楚。想要有一个好的调试环境，就要波及 SourceMap 的输入，而 Webpack 的 devtools 字段就是用于管制 SourceMap。
SourceMap 原理
在具体解释 devtools 配置之前，先看看 SourceMap 的原理。SourceMap 的次要作用就是用来还原代码，将曾经编译压缩的代码，还原成之前的代码。
下图右边代码为 Webpack 打包之前，左边为打包之后。
关上 chrome 引入 dist.js ，会发现浏览器会主动将压缩的代码进行了还原。
那这个 SourceMap 到底是怎么将左边的代码还原成右边的样子的呢。咱们先看一下 dist.js.map 的构造。
{ // 版本号 "version": 3, // 输入的文件名 "file": "dist.js", // 输入代码与源代码的映射关系 "mappings": "MAAA,IAAMA,EAAM,CACVC,KAAM,KACNC,OAAQ,KAGV,SAASC,IACPH,EAAIE,QAAU,EAGhB,SAASE,IACPJ,EAAIE,QAAU,EACdG,QAAQC,IAAIN,EAAIC,KAAM,OAGxBE,IACAC,IACAA,IACAD,K", // 原代码中的一些变量名 "names": [ "dog", "name", "weight", "eat", "call", "console", "log" ], // 源文件列表 // 咱们打包的时候常常是多个js文件合并成一个，所以源文件有多个 "sources": [ "webpack:///./src/index.ts" ], // 源文件内容的列表，与sources字段对应 "sourcesContent": [ "const dog = {\n name: '旺财',\n weight: 100\n}\n\nfunction eat() {\n dog.weight += 1\n}\n\nfunction call() {\n dog.weight -= 1\n console.log(dog.name, '汪汪汪')\n}\n\neat()\ncall()\ncall()\neat()" ],}其余字段应该都好了解，比拟难懂的就是 mappings 字段，看着就像是一堆乱码。这是一串应用 VLQ 进行编码的字符串，规定比较复杂。咱们能够间接在 github 找一个VLQ（https://github.com/Rich-Harris/vlq/blob/master/src/index.js）编码的库，对这串字符进行解码。
/** @type {Record<string, number>} */let char_to_integer = {};/** @type {Record<number, string>} */let integer_to_char = {};'ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789+/=' .split('') .forEach(function (char, i) { char_to_integer[char] = i; integer_to_char[i] = char; });/** @param {string} string */function decode(string) { /** @type {number[]} */ let result = []; let shift = 0; let value = 0; for (let i = 0; i < string.length; i += 1) { let integer = char_to_integer[string[i]]; if (integer === undefined) { throw new Error('Invalid character (' + string[i] + ')'); } const has_continuation_bit = integer & 32; integer &= 31; value += integer << shift; if (has_continuation_bit) { shift += 5; } else { const should_negate = value & 1; value >>>= 1; if (should_negate) { result.push(value === 0 ? -0x80000000 : -value); } else { result.push(value); } // reset value = shift = 0; } } return result;}mappings 字符串个别通过分号（;）和逗号（,）进行分隔。每个分号分隔的局部对应压缩后代码的每一行。因为下面打包的代码通过了压缩，只有一行代码，所以这个 mappings 中就没有分号。而通过逗号进行宰割的局部示意压缩后代码以后行的某一列与源代码的对应关系。
咱们试着通过下面的代码，对 mappings 的后面一部分进行解码。
'MAAA,IAAMA,EAAM,CACVC,KAAM'.split(',').forEach((str) => { console.log(decode(str))})解码后果如下：
[ 6, 0, 0, 0 ] // MAAA[ 4, 0, 0, 6, 0 ] // IAAMA[ 2, 0, 0, 6 ] // EAAM[ 1, 0, 1, -10, 1 ] // CACVC[ 5, 0, 0, 6 ] // KAAM每一串字符都对应五个数字，这个五个数字别离对应上面的含意：
- 第一位，示意这个地位压缩代码的第几列（与后面的数字累加获取）。
- 第二位，示意这个地位属于sources属性中的哪一个文件。
- 第三位，示意这个地位属于源码的第几行（与后面的数字累加获取）。
- 第四位，示意这个地位属于源码的第几列（与后面的数字累加获取）。
- 第五位，示意这个地位属于names属性中的哪一个变量。
那么 MAAA: [ 6, 0, 0, 0 ]: 对应的意思就是，压缩后代码的第1行的第7列（PS. 计数都是从0开始，所以数字6对应的应该是第7列，前面的数字同理），对应sources中的第1个文件的第1行的第1列。看代码能看出，就是示意压缩后的这个 var 申明，对应源码的 const。
在看看 IAAMA: [ 4, 0, 0, 6, 0 ]，示意压缩代码的第11列（这里的4，示意从后面已计算的列向后再数4列，也就是第11列），对应源码第1行的第7列（这里同理，也是向后数6列），且对应 names 属性的第1个变量名，也就是 "dog"。这里对代码进行了混同，所以有个 names 字段专门用来记录压缩之前的变量名。
简略翻译一下后面的解码后果：
[ 6, 0, 0, 0 ] // 压缩代码的第7列，对应源码第1行的第1列[ 4, 0, 0, 6, 0 ] // 压缩代码的第11列，对应源码第1行的第7列，对应names第1个变量（"dog"）[ 2, 0, 0, 6 ] // 压缩代码的第13列，对应源码第1行的第13列[ 1, 0, 1, -10, 1 ] // 压缩代码的第14列，对应源码第2行的第3列，对应names第2个变量（"name"）[ 5, 0, 0, 6 ] // 压缩代码的第19列，对应源码第2行的第9列能够看到这外面呈现了一个正数，这里是因为对应关系从源码的第1行，跳到了第2行，新的一行列数应该从后面开始计算，而列数是依照后面的后果累加的，所以这里要进行列数的回退，所以呈现了一个正数，将列数进行回退。
下面是代码通过压缩解决的状况，如果咱们只通过webpack进行打包解决，不进行压缩，生成的 mappings 如下：
能够看到，dist.js 后面5行代码都是 webpack 生成的 runtime，与源代码无关，所以 mappings 后面有五个分号（;），示意前 5 行与源码没有对应关系，前面的 AAAA,IAAMA,GAAG,GAAG; 才是 dist.js 第六行与源码的对应关系。
devtools 配置项
在理解了 SourceMap 的原理后，在看看 devtools 的配置项。如果看 Webpack 的官网文档，会发现 devtools 的配置项是一个有十几行的表格，有点唬人，仔细观察会发现，devtools 配置以 "source-map" 为根底，而后加上各种前缀。
格局如下：
[inline-|hidden-|eval-][nosources-][cheap-[module-]]source-map不同的配置会生成不同的产物，在 webpack 的 github 仓库中，有一个专门的demo用于展现不同参数打包后的产物：https://github.com/webpack/webpack/tree/main/examples/source-map。
source-map
先看最根底的配置（devtools: "source-map"），就是独自生成一个 .map 文件，而后在打包代码的最初一行加上一个正文，写明生成 SourceMap 的门路，不便浏览器读取。
//# sourceMappingURL=SourceMap文件门路inline-source-map
看名字很容易了解，在后面加上 inline- 属于内联的 SourceMap，就是将 SourceMap 的内容进行 base64 本义，间接放到打包代码的最初一行。
//# sourceMappingURL=data:application/json;charset=utf-8;.......eval/eval-source-map
eval-source-map 会将对应模块的代码都放到 eval() 中执行，如果加上了 //# sourceURL=xxx ，浏览器会主动将 eval 中的代码主动放到 sources 中。
通过 eval 生成代码的益处，改变了某个模块，只须要对某个模块的代码从新 eval 就能够，能够晋升二次编译的效率。官网文档也有阐明，eval 的 rebuild 的效率根本是最高的。
cheap-source-map/cheap-module-source-map
// source-map"mappings": ";;;;;AAAA,IAAMA,GAGL,GAAG;EACFC,IAAI,EAAE,IADJ;EAEFC,MAAM,EAAE;AAFN,CAHJ;;AAQA,SAASC,GAAT,CAAaD,MAAb,EAA6B;EAC3BF,GAAG,CAACE,MAAJ,IAAcA,MAAd;AACD;;AAED,SAASE,IAAT,GAAgB;EACdJ,GAAG,CAACE,MAAJ,IAAc,CAAd;EACAG,OAAO,CAACC,GAAR,CAAYN,GAAG,CAACC,IAAhB,EAAsB,KAAtB;AACD;;AAEDE,GAAG,CAAC,EAAD,CAAH;AACAC,IAAI;AACJA,IAAI;AACJD,GAAG,CAAC,CAAD,CAAH,C"// cheap-source-map"mappings": ";;;;;AAAA;AACA;AACA;AACA;AACA;AACA;AACA;AACA;AACA;AACA;AACA;AACA;AACA;AACA;AACA;AACA;AACA;AACA"下面是通过 source-map 和 cheap-source-map 生成的 mappings 的区别，能够看到 cheap-source-map 生成的 mappings 精简了很多。因为 cheap-source-map 去掉了列信息，能够大幅提高 souremap 生成的效率。
在 webpack 打包的过程中，代码会通过许多 loader 解决，而 loader 解决的过程中，对应的代码映射关系可能会发生变化，而 cheap-module-source-map 的作用就是打包后的代码是与最开始的代码进行对应的，而不是通过 loader 解决的代码。
咱们先写一段 typescript 代码，如下：
const dog: { name: string, weight: number} = { name: '旺财', weight: 100}function eat(weight: number) { dog.weight += weight}function call() { dog.weight -= 1 console.log(`${dog.name}: 汪汪汪`)}eat(10)call()call()eat(5)先看看间接应用 cheap-source-map 还原出的代码：
在看看 cheap-module-source-map 进行还原出的代码：
hidden-source-map
与 source-map 配置一样，会独自生成一个 .map 文件，只是打包代码的最初没有与之关联的正文，个别生产公布的时候，将 .map 文件上传到报错平台（例如：sentry）。另外，如果配置了多个 loader，能够思考在上线时，将 devtools 配置成 hidden-cheap-module-source-map。
小结
下面介绍了各种配置输入代码的个性，每一种都是能排列组合的。比方，在开发环境，为了尽可能的看到未通过 loader 转化的原代码，能够配置成 cheap-module-source-map。如果须要进一步晋升编译速度，就能够配置成 eval-cheap-module-source-map。而在公布上线的时候，就能够将配置调整成 hidden-cheap-module-source-map。
本文由mdnice多平台公布