来聊聊SourceMap

前言

我们项目的代码在经过编译打包后&＃xff0c;会将开发时多个文件的代码合并到同一份文件中&＃xff0c;而且还会经过各种压缩&＃xff0c;合并&＃xff0c;代码丑化等等操作&＃xff0c;转换完最终生成的代码才会用于线上环境&＃xff0c;所以我们线上实际运行的代码跟我们开发时的代码是有非常大的不同&＃xff0c;如果此时出现了bug&＃xff0c;那么我们只能定位到转换后代码的位置&＃xff0c;但此时的代码已经面目全非了

转换后的代码类似下面这样

虽然这种代码对计算机非常友好&＃xff0c;但是我们debug将会变得很困难&＃xff0c;这时候就需要sourcemap了

什么是SourceMap

简单来说&＃xff0c;Sourcemap 就是一个信息文件&＃xff0c;它里面存储着代码转换前后的对应位置信息&＃xff0c;也就是转换压缩后的代码所对应的转换前的源代码位置&＃xff0c;是源代码和生产代码的映射&＃xff0c; Sourcemap 解决了在打包过程中&＃xff0c;代码经过压缩&＃xff0c;去空格以及 babel 编译转化后&＃xff0c;由于代码之间差异性过大&＃xff0c;debug 困难的问题

大家的项目在开发完进行build后&＃xff0c;在打包文件夹里除了有js&＃xff0c;css&＃xff0c;图片等资源&＃xff0c;一定还见过 .js.map文件&＃xff0c;这种就是sourcemap文件

点开一个打包后的js文件&＃xff0c;拉到最后一行&＃xff0c;可以看到 //# sourceMappingURL&＃61;main.js.map

有了这行&＃xff0c;就可以启用sourcemap&＃xff0c;这个sourceMappingURL就是标记了该文件的sourcemap的地址&＃xff0c;这个sourcemap文件可以放在本地&＃xff0c;也可以放在网络上

再点开一个 .js.map 文件看看&＃xff0c;有一堆类似乱码的东西&＃xff0c;后面看一个简单一点的

SourceMap的生成

生成的方法有很多&＃xff0c;而且有很多前端的工具都支持&＃xff0c;如webpack&＃xff0c;uglifyjs&＃xff0c;gulp等&＃xff0c;这里就不详细讲述了&＃xff0c;对怎么生成sourcemap感兴趣可以看这个文章

https://code.tutsplus.com/tutorials/source-maps-101--net-29173

SourceMap的属性

我们看一个简单一点的代码

const value &＃61; 123;
console.log(value);

用webpack打包后的代码

console.log(123);
//# sourceMappingURL&＃61;bundle.js.map

生成的sourcemap文件

{version : 3,file :  bundle.js ,mappings :  AACAA,QAAQC,IADM ,sources : [webpack://studysourcemap/./test.js ],sourcesContent : [const value &＃61; 123;\nconsole.log(value); ],names : [console ,log ],sourceRoot :   
}

每个属性的含义如下

• version&＃xff1a;遵循的是哪一个sourcemap版本的规范&＃xff08;下面会浅提一下&＃xff09;

• sources&＃xff1a;转换前的源文件url数组&＃xff08;数组是因为存在多个文件合并的情况&＃xff09;

• names&＃xff1a;在mappings中引用的标识符数组&＃xff08;可以理解为转换前代码的所有变量名和属性名&＃xff09;

• sourceRoot&＃xff1a;源文件的根路径

• sourcesContent&＃xff1a;转换前源文件的原始内容&＃xff0c;也是一个数组

• mappings&＃xff1a;记录源码和编译后代码的位置信息的base64 VLQ 字符串&＃xff0c;是最重要的内容

• file&＃xff1a;生成的与该sourcemap文件关联的文件名&＃xff0c;也就是打包编译后的文件名

SourceMap的版本

关于sourcemap的版本

• 2009年&＃xff0c;google介绍他的一个编译器Cloure Compiler时&＃xff0c;也顺便推出了一个调试插件Closure Inspector&＃xff0c;可以方便调试编译后的代码&＃xff0c;这个就是 sourcemap 的雏形

• 2010年&＃xff0c;Closure Compiler Source Map 2.0中&＃xff0c;共同制定了一些标准&＃xff0c;已决定使用base64编码&＃xff0c;但是生成的map文件要比现在大很多

• 2011年&＃xff0c;第三代出炉&＃xff0c; Source Map Revision 3 Proposal&＃xff0c;也就是我们现在用的 sourcemap 的版本&＃xff0c;这也就是为什么我们上面map文件的 version&＃61;3 了&＃xff0c;这一版对算法进行了优化&＃xff0c;大大缩小了map文件的体积

第一版生成的map文件大概有转化后文件的10倍大&＃xff0c;第二版则将体积减少了20%&＃xff5e;30%&＃xff0c;第三版又在v2的基础上体积减少了一半

正是因为有了第三代 Source Map Revision 3 Proposal 这个标准&＃xff0c;不同的打包工具和浏览器才能使用sourcemap&＃xff0c;github上的一个根据这个标准生成sourcemap的库 https://github.com/mozilla/source-map

SourceMap的原理

这里主要关注mappings和names属性&＃xff0c;mappings属性是一个很长的字符串&＃xff0c;它分成三个部分

1. 分号(;)&＃xff0c;表示行对应&＃xff0c;生成的文件的每一行用分号(;)分隔&＃xff0c;一个分号代表转换后源码的一行

1. 逗号(,)&＃xff0c;位置对应&＃xff0c;每一段用逗号(,)分隔&＃xff0c;一个逗号对应转换后源码的一个位置

1. 英文字母&＃xff0c;每一段由1&＃xff0c;4或5块可变长度的字段组成&＃xff0c;记录原始代码的位置信息

举一个简单的例子&＃xff0c;假设有如下的mappings属性

mappings :  AACAA;QAAQC,IADM ,

有一个分号&＃xff0c;说明有两行代码&＃xff0c;分号前 AACAA 是第一行&＃xff0c;后面 QAAQC,IADM 是第二行

第二行有一个逗号&＃xff0c;说明这一行分为两段&＃xff0c;QAAQC 和 IADM

分号跟逗号大家应该都没什么疑问&＃xff0c;主要就是英文字母这一块的意义位置对应的原理

每一段最多有5个部分

• 第一部分&＃xff0c;表示这个位置在&＃xff08;转换后的代码&＃xff09;的第几列

• 第二部分&＃xff0c;表示这个位置属于sources属性中的哪一个文件

• 第三部分&＃xff0c;表示这个位置属于转换前代码的第几行

• 第四部分&＃xff0c;表示这个位置属于转换前代码的第几列

• 第五部分&＃xff0c;表示这个位置属于names属性中的哪一个变量

那么这五个部分是怎么来的&＃xff0c;我们一步一步来看

假设文件a.js有一行代码 I Love SourceMap&＃xff0c;最终打包后输出的文件为bundle.js&＃xff0c;内容为 Javascript is awesome&＃xff0c;如下

那么怎么表示映射关系

以 Love 为例&＃xff0c;它原始的位置为(0,2)&＃xff0c;输出后是awesome&＃xff0c;位置为(0,14)&＃xff0c;那么我们可以这样来映射

像这样写成一种固定的格式&＃xff0c;里面包含了原始位置和输出后的位置&＃xff0c;单词&＃xff0c;同时还有原始文件名&＃xff0c;因为可能把多个文件进行处理输出&＃xff0c;如果不写文件名&＃xff0c;就不知道输入位置来自哪个文件

我们可以优化一下&＃xff0c;把a.js和最后面的单词提出来各放到一个数组里&＃xff0c;用sources记录所有的原始文件名&＃xff0c;names记录原始文件中的所有单词&＃xff0c;然后用下标表示他们&＃xff0c;以Love为例&＃xff0c;就变成

很多时候&＃xff0c;我们输出的文件其实是只有一行的&＃xff0c;所以可以把输出文件的行号省略掉&＃xff0c;就变成

考虑到&＃xff0c;如果文件特别大的话&＃xff0c;那么行列的数值可能会特别大&＃xff0c;所以可以考虑用相对位置来代替绝对位置来表示&＃xff0c;只用绝对位置表示第一个单词的位置&＃xff0c;后面的都使用相对前一个单词的位置

所以我们现在可以得到这么一个初步的map文件

{names: [&＃39;I&＃39;, &＃39;Love&＃39;, &＃39;SourceMap&＃39;],sources: [&＃39;a.js&＃39;],mappings: [11&＃xff5c;0&＃xff5c;0&＃xff5c;0&＃xff5c;0, 3&＃xff5c;0&＃xff5c;0&＃xff5c;2&＃xff5c;1, -14&＃xff5c;0&＃xff5c;0&＃xff5c;5&＃xff5c;2]
}

但是mappings这里十分难看&＃xff0c;而且还需要用&＃xff5c;来分隔&＃xff0c;多占一个位置&＃xff0c;用 vlq 编码就可以解决分隔数字的问题&＃xff0c;他的核心思路是在连续的数字上做标记&＃xff0c;我们先来理解一下&＃xff0c;拿上面 mappings 属性的第一个为例&＃xff0c;去掉&＃xff5c;&＃xff0c;然后在连续的字符上加上一个标记

110000

从左往右开始读取&＃xff0c;数字1有标记&＃xff0c;说明还有连续&＃xff0c;再取下一个&＃xff0c;是1&＃xff0c;这个1没被标记&＃xff0c;第一个数结束&＃xff0c;所以第一个数是11

继续往下&＃xff0c;0没被标记&＃xff0c;说明是一个完整的数字&＃xff0c;第二个数就是0

依此类推。。。

最终就能得到11&＃xff0c;0&＃xff0c;0&＃xff0c;0&＃xff0c;0

而 vlq 利用6位二进制数进行存储&＃xff0c;其中第一位就表示是否连续的标识位&＃xff0c;最后一位表示正数还是负数&＃xff08;0正数&＃xff0c;1负数&＃xff09; &＃xff0c;中间只有4位&＃xff0c;因此一个单元表示的范围为[-15,15]&＃xff0c;如果超过了就要用连续标识位了

看几个例子来理解&＃xff0c;每一步的变化我都用不同颜色标记了

第三步&＃xff08;按...5554分割&＃xff09;&＃xff0c;最右边4位是因为他还需要额外多表示一位符号位&＃xff0c;其余的都可以用5位来表示数值

倒数第二步倒顺序&＃xff0c;是因为VLQ表示数据字节组的顺序是倒过来的

最终我们可以得到他们的 vlq 编码

然后再把它转成base64编码&＃xff0c;可以查下面这张表

就可以得到5和-19的base64 vlq编码了&＃xff0c;因为5的 vlq 编码数值是10&＃xff0c;所以查上表可得到K&＃xff0c;同理-19可以得到n和B&＃xff0c;最终能得到5和-19的 base64 vlq 编码分别是K和nB

这里有一个网站可以自己转换验证一下https://www.murzwin.com/base64vlq.html

然后我们回过头为我们最开始那个简单的js文件手动生成一下map文件来验证一下

const value &＃61; 123;
console.log(value);

打包后的代码

console.log(123);
//# sourceMappingURL&＃61;bundle.js.map

sources和names是可以先确定好的

{sources : [ a.js ],names : [ console ,  log ],
}

再得到 base64 vlq 编码

所以我们可以得到最终的map文件

{sources : [ a.js ],names : [  console ,  log ],mappings :  AACAA,QAAQC,IADM ,// ...其他的
}

反过来也能根据sourcemap文件推出原始的位置&＃xff0c;这里就不再演示了

SourceMap总结

• 映射转换过后的代码和源代码之间的关系

• 代码中引入 //# sourceMappingURL&＃61;xxx.js.map 启用

• source Map 解决了源代码和运行代码不一致所产生的问题

• 不只是js文件有&＃xff0c;css文件也有

• 核心原理是 base64 vlq 编码

感谢巨人

https://juejin.cn/post/7023537118454480904

https://juejin.cn/post/6963076475020902436

https://docs.google.com/document/d/1U1RGAehQwRypUTovF1KRlpiOFze0b-_2gc6fAH0KY0k/edit#heading&＃61;h.1ce2c87bpj24

https://www.ruanyifeng.com/blog/2013/01/Javascript_source_map.html

https://www.html5rocks.com/en/tutorials/developertools/sourcemaps/

http://www.qiutianaimeili.com/html/page/2019/05/89jrubx1soc.html

 - END -

关于奇舞团

奇舞团是 360 集团最大的大前端团队&＃xff0c;代表集团参与 W3C 和 ECMA 会员&＃xff08;TC39&＃xff09;工作。奇舞团非常重视人才培养&＃xff0c;有工程师、讲师、翻译官、业务接口人、团队 Leader 等多种发展方向供员工选择&＃xff0c;并辅以提供相应的技术力、专业力、通用力、领导力等培训课程。奇舞团以开放和求贤的心态欢迎各种优秀人才关注和加入奇舞团。