Web前端开发中,对于生产环境的代码通常会进行压缩和混淆处理,以减小代码体积并提高源代码安全性。然而当生产环境有JS错误发生时,压缩和混淆的代码也让定位错误变得更困难。
我们先来看一个爱奇艺智能前端异常监控平台(鹰眼Hawkeye)检测到的错误日志:
图一 Hawkeye 收集的JS错误示例
可以看到,压缩后的错误行号和列号已经丢失,函数名也经过了变换,出错的真实文件名很难确定。如此,根据压缩代码的报错信息是很难定位错误的,但是,线上代码又必须压缩上传处理。
如何平衡?SourceMap正是解决这个矛盾的利器。本文将从Source Map的基本概念及其在前端异常监控中的运用、设计及实践等方面进行介绍。
01
Source Map介绍
Source Map是一种存储了源代码和编译后代码映射关系的信息文件,包含代码转换前后的位置信息。现在各种主流的打包工具都支持生成Source Map,例如: Uglify JS、Grunt、Gulp、Webpack等。生成Source Map一般在项目打包的编译阶段进行,打包工具先将源代码解析出AST(Abstract Syntax Tree),在生成编译后的代码时,即图二generate过程中,利用AST中节点的来源信息等生成Source Map。
图二 编译并生成Source Map
02
JS错误采集和利用Source Map解析错误
JS错误一般可以通过window.addEventListener监听error事件收集,框架错误一般利用框架暴露的钩子函数收集,比如Vue.config.errorHandler。收集到的错误中,从Error.prototype.stack可解析出错误堆栈信息。
获取到错误堆栈信息、Source Map文件内容后则可以通过Mozilla的source-map库进行错误定位。该库中的SourceMapConsumer 实例表示一个已解析的源映射的相关信息,我们可以通过为这个实例提供文件位置和文件内容来在生成的源中查询有关原始文件位置的信息。
目前,各大监控平台均有针对错误监控的Source Map的解析功能。例如开源监控平台Sentry支持Webpack插件和自身的CLI工具上传map文件后进行解析