最近负责做一个比较大型的前端编辑器项目，里面涉及很多前端npm包相互引用，为了更好的调试，需包与包的引用之间能够通过devtool调试，但是为了使用调试功能，必须source-map功能正常使用。
理想很完美 现实很残酷，业务项目Webpack启用后，控制台爆Warning ‘Failed to parse source map from ’，下面就一探究竟。
分析warning之前，先简单了解source-map的背景与原理。
一、背景
随着浏览器的性能与兼容性越来越好，业务逻辑的前移也越多，很多业务逻辑与效果让js来承担，加之代码也分模块书写，源代码都需要转换与压缩后才能投入生产使用。
源代码压缩后的代码，已经与源代码相差甚远，如果线上有错，debug变的困难重重
为了解决这个问题，发明了source-map这个玩意
二、source-map
source-map文件是一个json数据，目前在版本3的格式如下。
{
"version": 3, // 文件版本，必须是个正整数
"file": "out.js", // 编译器生成后的文件
"sourceRoot": "", // 源文件相对路径，如果都在当前路径上，为空
"sources": [], // 源文件列表
"sourcesContent": [], // 源文件配置，当没有配置source的时候则使用这个
"names": [], // 变量列表
"mappings": "" // 映射表
}
mappings 数据结构
- 生成后的文件，每一行的映射片段都会以分号（；）分隔开来，所以第一个分号前的内容就是对应源代码的第一行，以此类推
- 第二层是位置对应，以逗号（，）表示，每个逗号对应转换后源码的一个位置，所以第一个逗号前的内容，就是对应该行源码的第一个位置，一次类推
- 第三层是位置转换，以VLQ编码表示，代表位置对应的转换前的源码位置
每个位置的映射，从左算起，有如下含义
- 第一位，表示这个位置在转换后的代码的第几列
- 第二位，表示这个位置属于sources属性中的哪一个文件
- 第三位，表示这个位置属于转换前代码的第几行
- 第四位，表示这个位置属于转换前代码的第几列
- 第五位，表示这个位置属于names属性中的哪一个变量
webpack配置
业务项目配置
{
devtool: "source-map"
}
但要加载npm里面的source-map文件，需要借助loader(source-map-loader)
配置项如下
module.exports = {
module: {
rules: [
{
test: /\.js$/,
enforce: "pre",
use: ["source-map-loader"],
},
],
},
};
配置完成后，借助chrome开发工具就可以使用与打断点了
参考目录