一个普通的写网页的人如何过渡到ES6 (三) - Sourcemap

Sourcemap 这个单词也时不时出现在我们眼里,今天就来学习它。其实有时候学习一些概念并不是很刻意地去学习,而是遇到了问题,发现了这里有个解决方案,就把它给学了。

那么,Sourcemap 解决了什么呢?

问题背景

上一节中,我们已经基本学会怎么把 es6 的代码转化为 es5,那假设我在 b.js 中,刻意制造一些错误。

let words = "cat";
let error = "i am a " + message; // 未定义的变量
export {words};

接着记得使用 browserify a.js -o a_bundle.js -t [babelify --presets[env]] 编译一下代码。

补充一下,我使用的浏览器是 chrome 浏览器。

尝试打开页面之后会发现浏览器报错了:

很明显,浏览器找到了你使用了未定义变量 message 的错误。

但是我们会发现一个问题:浏览器定位错误的时候,定位的是打包后的那个 a_bundle.js 。可以看到上图中定位到了这个文件的第 25 行,在日常的开发中我们很经常看了行号就回去修改 bug 了。然而,我们开发的时候并不是使用这个 a_bundle.js 进行开发,所以这个定位对于我们没有什么用呀。

Q:这个例子中直接回去改 b.js 不就完了= =?
A:在日常的开发中,脚本文件一多,一不小心在哪里敲多了个符号,然后全部脚本都被拼接到 bundle.js 里面,一旦浏览器报错,定位的行号却只是 bundle.js 的行号而不是具体到哪一个脚本的行号,导致不知道如何修改自己的代码错误。在例子中只是刻意制造一种出错的情况。

Sourcemap

Sourcemap 是一种文件,我们直接翻译过来就叫做来源地图,顾名思义就是一张 帮你找到当前代码在被处理之前所在的位置状态的一张地图

先别纠结这句话这么久,我们直接看看怎么生成这张东西再回过头来理解。

生成的方式很简单,在我们上面使用过的编译命令后面加多一个 -d 参数就可以了:

browserify a.js -o a_bundle.js -t [babelify --presets[env]] -d

这样子的话,会把这个所谓的 Sourcemap 直接输出在 a_bundle.js 文件里面。

偷偷地在编辑器打开 a_bundle.js 你会发现最后多了一行很长很长很长很长很长很长很长很长很长很长的代码:

这最后一行代码其实就是我们口中所说的 Sourcemap
然后我们再打开页面,发现浏览器给出的代码错误的定位变了:

发现了没有!它帮我们定位到了 b.js 之上了!

虽然会在 谷歌浏览器来源(Source)面板 上看到 b.js ,但是对于网页本身加载而言,是不会去加载这个 b.js 的。因为我们所有的代码都被压缩到了 a_bundle.js 里面了呀!

之所以会看到 b.js 全靠 谷歌浏览器 的功劳,它能够识别你的 Sourcemap 文件并加载相应的本地文件给你看,全为你的偷懒,啊不,是方便而考虑。

所以,Sourcemap 真是一个好东西!帮你找到 源代码 中的代码错误正确位置!

还有,还有

Sourcemap 在本例中是通过 browserify 生成的,可以理解为它都是使用工具生成的。

它不仅仅应用于 es6es5 的场合,还适用于各种凡是对代码进行编译预处理的场合。

比如说大家接触 jQuery 这么久一定知道它还提供了压缩版的脚本 jquery.min.js

压缩后的代码杂乱无章,基本上不是给人看的。

那如果有一天,你也有压缩脚本的需求,你可能会找到某个 例如叫做 yasuo 的工具= =,那么这个工具它应该会提供一些参数,在压缩的过程中同时也生成 Sourcemap 给你用于调试错误。

阮一峰老师就写过一篇关于 Sourcemap 的文章,“刚好” 就是引用了 jquery 来讲,虽然后面可能偏向于原理性,不妨大家也吸收一下?

当然,还有好多好多情况也会使用到 Sourcemap,以后有需求我们再跟进吧。

  JavaScript ES6