认识sourcemap

我们的代码通常运行在浏览器上时，是通过打包压缩的：

1. 也就是真实跑在浏览器上的代码，和我们编写的代码其实是有差异的；
2. 比如ES6的代码可能被转换成ES5；
3. 比如对应的代码行号、列号在经过编译后肯定会不一致；
4. 比如代码进行丑化压缩时，会将编码名称等修改；
5. 比如我们使用了TypeScript等方式编写的代码，最终转换成JavaScript；
6. 但是，当代码报错需要调试时（debug），调试转换后的代码是很困难的。
7. 如何可以调试这种转换后不一致的代码呢？答案就是source-map
8. source-map是从已转换的代码，映射到原始的源文件；
9. 使浏览器可以重构原始源并在调试器中显示重建的原始源；

如何使用sourcemap

如何可以使用source-map呢？两个步骤：

1. 第一步：根据源文件，生成source-map文件，webpack在打包时，可以通过配置生成source-map；
2. 第二步：在转换后的代码，最后添加一个注释，它指向sourcemap； //# sourceMappingURL=common.bundle.js.map
3. 浏览器会根据我们的注释，查找响应的source-map，并且根据source-map还原我们的代码，方便进行调试。
4. 在Chrome中，我们可以按照如下的方式打开source-map：

分析sourcemap

1. 最初source-map生成的文件带下是原始文件的10倍，第二版减少了约50%，第三版又减少了50%，所以目前一个133kb的文件，最终的source-map的大小大概在300kb。
2. 目前的source-map长什么样子呢？
3. version：当前使用的版本，也就是最新的第三版；
4. sources：从哪些文件转换过来的source-map和打包的代码（最初始的文件）；
5. names：转换前的变量和属性名称（因为我目前使用的是development模式，所以不需要保留转换前的名称）
6. mappings：source-map用来和源文件映射的信息（比如位置信息等），一串base64 VLQ（veriablelength quantity可变长度值）编码；
7. file：打包后的文件（浏览器加载的文件）；
8. sourceContent：转换前的具体代码信息（和sources是对应的关系）；
9. sourceRoot：所有的sources相对的根目录；

sourcemap文件

生成sourcemap

1. 如何在使用webpack打包的时候，生成对应的source-map呢？
2. webpack为我们提供了非常多的选项（目前是26个），来处理source-map
3. https://webpack.docschina.org/configuration/devtool/
4. 选择不同的值，生成的source-map会稍微有差异，打包的过程也会有性能的差异，可以根据不同的情况进行选择；
5. 下面几个值不会生成source-map
6. false：不使用source-map，也就是没有任何和source-map相关的内容。
7. none：production模式下的默认值，不生成source-map。
8. eval：development模式下的默认值，不生成source-map
9. 但是它会在eval执行的代码中，添加 //# sourceURL=；它会被浏览器在执行时解析，并且在调试面板中生成对应的一些文件目录，方便我们调试代码；

eval的效果

source-map值

source-map 比 eval信息更加的全，不仅仅展示出错误的源文件，而且把源文件的目录都给展示出来，这样方便用户查看项目结构。

eval-source-map值

inline-source-map值

cheap-source-map

1. 会生成sourcemap，但是会更加高效一些（cheap低开销），因为它没有生成列映射（Column Mapping）
2. 因为在开发中，我们只需要行信息通常就可以定位到错误了
3. 只管业务代码，不管第三方代码

cheap-module-source-map值

1. 会生成sourcemap，类似于cheap-source-map，但是对源自loader的sourcemap处理会更好。
2. 这里有一个很模糊的概念：对源自loader的sourcemap处理会更好，官方也没有给出很好的解释，其实是如果loader对我们的源码进行了特殊的处理，比如babel；

cheap-source-map和cheap-module-source-map

hidden-source-map值

1. 会生成sourcemap，但是不会对source-map文件进行引用；
2. 相当于删除了打包文件中对sourcemap的引用注释；
3. 
4. 如果我们手动添加进来，那么sourcemap就会生效了

nosources-source-map值

1. 会生成sourcemap，但是生成的sourcemap只有错误信息的提示，不会生成源代码文件；
2. 错误提示
3. 点击错误提示，无法查看源码：

多个值的组合

1. 事实上，webpack提供给我们的26个值，是可以进行多组合的。
2. 组合的规则如下：
3. inline-|hidden-|eval：三个值时三选一；
4. nosources：可选值；
5. cheap可选值，并且可以跟随module的值；
6. [inline-|hidden-|eval-][nosources-][cheap-[module-]]source-map
7. 那么在开发中，最佳的实践是什么呢？
8. 开发阶段：推荐使用 source-map或者cheap-module-source-map，这分别是vue和react使用的值，可以获取调试信息，方便快速开发；
9. 测试阶段：推荐使用 source-map或者cheap-module-source-map，测试阶段我们也希望在浏览器下看到正确的错误提示；
10. 发布阶段：false、缺省值（其实就是不写）

Hash、ContentHash、ChunkHash区别

cdn服务器

webpack代码分离

多入口起点：

Entry Dependencies(入口依赖)：

加粗样式：

SplitChunks自定义配置：

webpack 打包分析

打包时间分析

1. 影响 npm run build 打包时间：node版本，电脑性能。

2. 默认情况下，打包完成展示，打包的总时间，并没有告诉我，每个插件使用所消耗的时间

3. 希望看到每个loader，每个plugin消耗的打包时间，可以借助一个插件：speed-measure-webpack-plugin，该插件有webpack版本兼容问题

4. npm install speed-measure-webpack-plugin

5. 有部分插件不支持，可能不支持，需要给注释一下

打包文件大小分析

方法一：官方提供的

  "scripts": {
    "stats": "webpack --config ./config/webpack.common.js --env production --profile --json=stats.json"
  },
1
2
3

--profile --json=stats.json 加了这个 生成stats.json文件，把该文件上传到
https://webpack.github.io/analyse/网站上，可以看到可视化分析

方法二：插件提供的

1. npm install webpack-bundle-analyzer -D
2. const { BundleAnalyzerPLugin } = require(" webpack-bundle-analyzer")
3. new BundleAnalyzerPlugin( )
4. npm run build 自动打开网页 127.0.0.1:8888