Node.js 中 source map 使用问题总结

RosKwan 7年前
   <p style="text-align:center"><img src="https://simg.open-open.com/show/d44ddb7f884ac699b0538d8144bfec43.png"></p>    <h2>起源</h2>    <p>Node 应用功能越来越复杂,很多业务都开始尝试使用 TypeScript 来开发。在前端写的 JS 大部分是经过编译过程的,浏览器中通过 source map 的使用,可以很好的解决源码和编译运行时代码差异的问题。</p>    <p>那么在 Node 服务器环境应该如何使用 source map 呢?最近在重新搭建一个完全基于 ts 的 egg 应用,所有的相关流程看起来都挺美好的,唯一的缺陷是报错信息错误信息指向的是 js 文件。我觉得应该探索下如何让 Node 支持 source map 。</p>    <h2>原理</h2>    <p>对于 Node 而言,服务器 source map 最大的价值在于错误信息有正确的错误堆栈,所以只要我们能够实现自定义错误堆栈信息就可以了。</p>    <p>恰好 v8 引擎有提供一个私有的 ( Stack-Trace-API ), 这个提供了让开发者自定义错误 stack 信息的能力。具体来说,开发者可以实现 Error 对象的 prepareStackTrace 方法,如果 Error 对象上定义了这个方法,那么每次错误信息都会经过 Error.prepareStackTrace 处理后返回。</p>    <p>Error.prepareStackTrace 方法可以拿到两个参数,错误基本信息和结构化错误堆栈,第二个参数是一个数组,通过这个数组可以拿到错误文件以及位置信息。最后基于这些信息重新返回一个字符串,这样就可以覆盖 Error 对象的 stack 属性了。</p>    <p>基本代码结构如下:</p>    <pre>  <code class="language-javascript">function prepareStackTrace(error, stack) {    return error + stack.map(function(frame) {      return '\n    at ' + wrapCallSite(frame);;    }).join('');  }    Error.prepareStackTrace = prepareStackTrace;</code></pre>    <p>在 wrapCallSite 方法里面可以通过分析源码,找到 sourceMap 然后返回正确的位置信息。</p>    <p>原理很简单,已经有一个 npm 包 source-map-support 封装好了相关功能。</p>    <p>这看起来已经很完美了。source map 读取只在出现错误的时候才执行,所以 <strong>这个功能不会有性能问题,在生成环境也可以开启</strong> 。</p>    <h2>问题</h2>    <p>Stack Trace API 看起来很美好,但现实场景总是更加复杂。在引入 source-map-support 后,运行起来没什么问题,但在跑测试用例的时候,错误堆栈的位置信息完全不对,指向一个不存在的位置。</p>    <p>这个问题排查了很久,最终定位到在 wrapCallSite 方法中拿到的 frame 对象返回的行号就是错误的,而这个获取行号的方法是 native code ,这个几乎没法调试了。我想,难道是 Node 的问题?要调试到 Node 源码么?</p>    <p>折腾了很久没有什么效果,就在我打算放弃的时候,我换了一个假设,会不会是某个包依赖影响的?然后我尝试依次删除跑用例时 require 的包,终于发现是因为 egg-bin 默认引入的 power-assert 导致的。</p>    <p>问题定位到后,解决就容易了。但解决这个问题得先讲讲 power-assert 是如何实现的。</p>    <h3>power-assert 与 sourceMap</h3>    <p>power-assert 作为一个断言库,最大的特色在于错误信息的报告是非常友好的,一张图可以很清晰看到区别</p>    <p>实现这样炫酷的报告是需要做一些特殊的处理,把测试用例的代码进行一次转换,举个例子</p>    <pre>  <code class="language-javascript">it('foo', function foo() {    var a = 'foo';    var b = 'b';    assert(a === b);  });</code></pre>    <p>经过 espower-source 处理后,变成了这样</p>    <pre>  <code class="language-javascript">it('foo', function foo() {    var a = 'foo';    var b = 'b';      assert(expr(capture(capture(a, '/0/left') === capture(b, '/0/right'), '/0'), {        content: 'assert(a === b)',        filepath: 'bizLogger.test.ts',        line: 107    }));  })</code></pre>    <p>注:上面的代码不是真实运行的代码,经过一些删减</p>    <p>对于 assert(a === b) 这样一个表达式,会通过 capture 捕获每一个运算过程的位置和值,最终通过 expr 运算。这样经过转换后,代码运行逻辑不变,但是异常发生的时候可以返回 assert 表达式中每一步的返回值。</p>    <p>我所遇到的问题也就是因为 power-assert 对代码进行了转换,最终异常抛出时,真实 js 异常位置信息是转换后的位置,这个位置自然是无法正确定位到源码位置了。</p>    <p>但只运行 power-assert ,不引用 source-map-support 的时候,错误行号还是对的。这是因为 espower-source 返回重新编译后的源码后,还同时对源码文件的 sourceMap 进行了重新转换。所以大部分情况,我们是无法感知到源码有经过重新编译。</p>    <p>运行简单流程图如下</p>    <h3>解决问题</h3>    <p>回到最初的问题,跑用例的时候行号不对了。power-assert 的影响在于两点</p>    <ol>     <li>测试文件源码会被 power-assert 修改,增加一些信息收集代码</li>     <li>power-assert 同时有引入 source-map-support 来对错误堆栈进行重新定位</li>    </ol>    <p>当我在我自己的业务中也引入 source-map-support 来重新定位错误堆栈时,我所拿到的源码是被 power-assert 修改过的,所以这时候是无法重新定位到正确的 ts 位置了。</p>    <p>既然 power-assert 有引入 sourceMap ,那么是不是我关闭自己引入的 sourceMap 就可以了呢?理论上是应该如此的,但是因为 power-assert 对 sourceMap 文件不支持(inline source map 是支持的),所以只能定位到 js 源码,无法定位到 ts 源码。</p>    <p>问题确定了,就可以自己动手解决了,我发了一个 mr 让 espower-source 支持 sourceMap 文件,最新版的 power-assert 已经可以正确定位到 ts 源码位置了。</p>    <p>另外,还有一个问题,正常情况 source-map-support 同时引入两遍,只要引入的文件路径一直,也是不会有问题的。但 power-assert 使用的还是老版本 source-map-support ,而且老版定位位置信息还是不够准确,这个也很好解决, 升级依赖版本 既可以。</p>    <p>这两个问题解决后,在自己的业务用引入 source-map-support 也没有问题了,power-assert 返回的错误堆栈也可以正确的指向 sourceMap 位置了。</p>    <h2>总结</h2>    <p>基于 V8 的 Stack Trace API 的使用,浏览器的 sourceMap 能力也可以应用到 Node 服务器场景下,使用 npm 包 source-map-support 就可以了。</p>    <p>有时候可能会遇到一些奇怪的错误行号的问题,这可能是某个依赖包对 js 进行了转换,毕竟这在前端太常见了,动不动就重新编译 js 源码。</p>    <p> </p>    <p>来自:https://zhuanlan.zhihu.com/p/26267678</p>    <p> </p>