【Webpack 性能优化系列(2) - source-map】

ゝ一世哀愁。 2022-09-09 06:55 242阅读 0赞

**webpack系列文章：**

*  [【Webpack 性能优化系列(9) - 多进程打包】极大的提升项目打包构建速度！！！][Webpack _9_ -]
 *  [【Webpack 性能优化系列(8) - PWA】使用渐进式网络应用程序为我们的项目添加离线体验][Webpack _8_ - PWA]
 *  [【Webpack 性能优化系列(7) - 懒加载和预加载】][Webpack _7_ -]
 *  [【Webpack 性能优化系列(6) - code splitting 】通过代码分割来获取更小的 bundle，优化资源加载][Webpack _6_ - code splitting _ bundle]
 *  [【Webpack 性能优化系列(5) - tree shaking 】去除未引用代码，减少代码体积！！！][Webpack _5_ - tree shaking]
 *  [【Webpack 性能优化系列(4) - 缓存 】详解如何做bable缓存和文件资源缓存][Webpack _4_ - _ _bable]
 *  [【Webpack 性能优化系列(3) - oneOf】][Webpack _3_ - oneOf]
 *  [【Webpack 性能优化系列(1) - HMR 热模块替换】][Webpack _1_ - HMR]
 *  [【Webpack 生产环境配置】近两万字长文总结学习如何提取css为单独文件、css的压缩和兼容性处理，如何压缩html和js、如何做js语法检查eslint和js兼容性处理babel！！！][Webpack _css_css_html_js_js_eslint_js_babel]
 *  [【Webpack 开发环境配置】万字长文总结学习如何打包样式资源、html资源、图片资源和其他资源？devServer是什么，如何配置？][Webpack _html_devServer]
 *  [【Webpack 简介及五个核心概念】][Webpack]

# source-map #

**本文讲一下开发环境下如何调试代码，解决开发环境下调试代码问题，这个技术叫`source-map`**

**`source-map`: 一种 提供源代码到构建后代码映射 技术 （如果构建后代码出错了，通过映射可以追踪源代码错误）**

在webpack中启动`source-map`只需要在配置中添加：`devtool: 'source-map'`  
![在这里插入图片描述][watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBA5ZyG5ZyGMDE_size_20_color_FFFFFF_t_70_g_se_x_16]  
**启动`source-map`后，打包运行就可以在build目录下看到`built.js.map`，这个文件就是`source-map`文件，它提供了源代码和构建后代码的映射关系**  
![在这里插入图片描述][ed0a46ed767748ed9015d2c79c3b7ff5.png]  
![在这里插入图片描述][watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBA5ZyG5ZyGMDE_size_20_color_FFFFFF_t_70_g_se_x_16 1]  
上面的写法是`source-map`最基本的写法

**`devtool`的模式写法可以总结为：`[inline-|hidden-|eval-][nosources-][cheap-[module-]]source-map`**

具体就是有以下几种模式：

**1.source-map：外部**

错误代码准确信息 和 源代码的错误位置

**2.inline-source-map：内联**

只生成一个内联source-map

错误代码准确信息 和 源代码的错误位置

**3.hidden-source-map：外部**

错误代码错误原因，但是没有错误位置

不能追踪源代码错误，只能提示到构建后代码的错误位置

**4.eval-source-map：内联**

每一个文件都生成对应的source-map，都在eval

错误代码准确信息 和 源代码的错误位置

**5.nosources-source-map：外部**

错误代码准确信息, 但是没有任何源代码信息

**6.cheap-source-map：外部**

错误代码准确信息 和 源代码的错误位置

只能精确的行

**7.cheap-module-source-map：外部**

错误代码准确信息 和 源代码的错误位置

module会将loader的source map加入

--------------------

上述这些模式，其中一些值适用于开发环境，一些适用于生产环境。对于开发环境，通常希望更快速的 source map，需要添加到 bundle 中以增加体积为代价，但是对于生产环境，则希望更精准的 source map，需要从 bundle 中分离并独立存在。

我们看一下效果：

devtool: 'inline-source-map'

构建后没有`built.js.map`文件  
![在这里插入图片描述][ede0e7d2d6124b2b96fd3241b76f1310.png]  
但是会在built.js文件下面生成`base64`编码的`source-map`文件  
![在这里插入图片描述][watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBA5ZyG5ZyGMDE_size_20_color_FFFFFF_t_70_g_se_x_16 2]  
**这种方法是嵌到js中的，所以叫内联，像前面生成外部`built.js.map`文件的叫外联**

**内联 和 外部的区别：1. 外部生成了文件，内联没有 2. 内联构建速度更快**

# 应用场景 #

**前面讲了`source-map`的很多种配置方案，到底怎么用呢？**

**这里就需要考虑两种环境：开发环境和生产环境**

**开发环境：速度快，调试更友好**

**速度快(eval>inline>cheap>…)：**  
`eval-cheap-souce-map(首推)`  
`eval-source-map`

**调试更友好：**  
`souce-map(首推)`  
`cheap-module-souce-map`  
`cheap-souce-map`

**最终平衡速度和调试，开发环境推荐的方案：**  
`eval-source-map(调试最友好)`  
`eval-cheap-module-souce-map(性能更好)`

**如果我们使用vue或者react框架开发，都会有对应的脚手架，而脚手架的配置默认是：`eval-source-map`**

**生产环境：源代码要不要隐藏? 调试要不要更友好？**

**内联会让代码体积变大，所以在生产环境不用内联**

**需要隐藏源代码的方案：**  
`nosources-source-map(全部隐藏)`  
`hidden-source-map(只隐藏源代码，会提示构建后代码错误信息)`

**生产环境推荐方案：**  
`source-map(调试最友好)`  
`cheap-module-souce-map(性能更好)`

# 参考 #

*  https://www.bilibili.com/video/BV1e7411j7T5?p=14&spm\_id\_from=pageDriver
 *  https://webpack.docschina.org/configuration/devtool/

[Webpack _9_ -]: https://blog.csdn.net/weixin_45844049/article/details/120065367
[Webpack _8_ - PWA]: https://blog.csdn.net/weixin_45844049/article/details/120063411
[Webpack _7_ -]: https://blog.csdn.net/weixin_45844049/article/details/120048999
[Webpack _6_ - code splitting _ bundle]: https://blog.csdn.net/weixin_45844049/article/details/120044485
[Webpack _5_ - tree shaking]: https://blog.csdn.net/weixin_45844049/article/details/120043245
[Webpack _4_ - _ _bable]: https://blog.csdn.net/weixin_45844049/article/details/120022585
[Webpack _3_ - oneOf]: https://blog.csdn.net/weixin_45844049/article/details/120008581
[Webpack _1_ - HMR]: https://blog.csdn.net/weixin_45844049/article/details/119982759
[Webpack _css_css_html_js_js_eslint_js_babel]: https://blog.csdn.net/weixin_45844049/article/details/119828504
[Webpack _html_devServer]: https://blog.csdn.net/weixin_45844049/article/details/119718436
[Webpack]: https://blog.csdn.net/weixin_45844049/article/details/119452096
[watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBA5ZyG5ZyGMDE_size_20_color_FFFFFF_t_70_g_se_x_16]: /images/20220829/2200dfc59ff7493d8f64f9277975e344.png
[ed0a46ed767748ed9015d2c79c3b7ff5.png]: /images/20220829/e2b7758a518e4972bc17d379f46a2b90.png
[watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBA5ZyG5ZyGMDE_size_20_color_FFFFFF_t_70_g_se_x_16 1]: /images/20220829/a69d44a693db45b3ad095a2ca8075798.png
[ede0e7d2d6124b2b96fd3241b76f1310.png]: /images/20220829/9b151b6023fe4a2799ff2ee60560a5c3.png
[watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBA5ZyG5ZyGMDE_size_20_color_FFFFFF_t_70_g_se_x_16 2]: /images/20220829/da5a0700984e48fa91b6aa4e88d2fd8a.png