关于sourcemap解析问题的解释与优化建议

© Young 2017-02-06 15:43
Welcome to My GitHub

相关背景

由于需要根据上报的发布环境的错误信息结合sourcemap得到源代码的信息,所以需要生成sourcemap并记录下来。

目前使用如下库支持;

另外还需要更改发布脚本;

原因解释

由上图可知,打包发布脚本执行完成之后,一个js文件是会对应两个sourcemap文件的。

webpack可以生成sourcemap文件,gulp-sourcemaps也可以生成sourcemap文件;而且gulp-sourcemaps可以当源代码发生变化之后同时改变对应的sourcemap文件;但是gulp-sourcemaps支持的插件中并不包含webpack。

Plugins with gulp sourcemaps support

因此webpack对源代码做的改动必须由webpack自己处理相关sourcemap信息,通过uglify压缩再对代码进行变动时,需要gulp-sourcemaps进行后续处理。

至于为什么webpack有压缩功能依然采用单独压缩是因为webpack的压缩只能全量压缩,消耗时间太长。

gulp-sourcemaps进行后续处理也可以采取不同的方式,如果已经存在sourcemap信息了,初始化时可以指定文件形式的sourcemap信息,但是gulp的dest不是同步方式,在一个流任务中不能保证进行后续操作时,前边操作生成的文件已经完成,所以只能当成没有额外sourcemap信息的方式处理。

得到最终sourcemap信息后,解析后得到的位置信息并不是真正源代码的位置,而是webpack处理之后代码的位置,此时还需要再解析一次才能得到真正源代码的位置。

所以这里不光要保存最终sourcemap信息,还需要保存webpack得到的过渡的sourcemap信息,因此就会出现一个js文件对应两个sourcemap文件的情况。

画图概括如下;

优化方案

一个js对应两个sourcemap弊端在于不管是解析sourcemap还是生成sourcemap,工作量都是单个sourcemap的两倍,效率较低。

由上诉解释可知,如果把任务拆分成两个,一个任务只包含webpack打包处理;另一个任务则包含gulp-sourcemaps等其它后续工作,那么则可以保证gulp-sourcemaps处理时肯定存在对应的sourcemap额外文件,上边的问题也就不存在了。

需要注意的是拆分成两个任务之后,第二个任务没办法直接使用第一个任务的输入流,只能重新选取文件,会有些不再被使用的文件存在错误,需要注意排查。

该方案没被采纳的原因在于团队合作中其他人员对前端上报不了解,打包报错后不知道如何解决,可能会带来沟通上的麻烦。

发表评论

电子邮件地址不会被公开。 必填项已用*标注