最近负责做一个比较大型的前端编辑器项目，里面涉及很多前端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开发工具就可以使用与打断点了

参考目录