基于 Webpack 提升构建速度和保证构建质量详解

￡神魔★判官ぃ 2023-01-19 09:56 1阅读 0赞

点击上方 前端Q，关注公众号

回复加群，加入前端Q技术交流群

当前市面上大部分前端应用都是基于webpack进行构建，而随着应用日益庞大，webpack应用就会出现构建速度慢，构建结果体积大等一系列问题。

> 作者：百命
> 
> https://juejin.cn/post/6844904033434468359

### 1.webpack应用治理应该从哪个方向入手？ ###

随着应用的不断迭代，webpack应用最常见的两个问题就是：

1.  构建速度慢
2.  构建体积大

有一个很简单的划分方式，就是以构建（build）为分界线，分成前向治理和后向治理：

*  前向治理：提升构建速度
 *  后向治理：保证构建结果质量

我们的治理方向，就是围绕前向治理和后向治理。

![fe91585da51fb7b65df36d766e9bbaf4.png][]

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

### 2.前向治理包含哪些内容？ ###

前向治理的核心概念，就是一个字 `快` ，目的就是提升构建速度，市面上大部分webpack优化文章都是这一类提升构建速度的文章，所以这里就简单介绍一些不错的实践

#### 2.1 利用SMP采集webpack数据指标 ####

![613655b3e8646d820ed669610821bf73.png][]

数据先行，通过speed-measure-webpack-plugin\[1\]采集性能指标，可以得到webpack在整个编译过程中在loader、plugin上花费的时间，基于该数据可以专项的进行优化和治理。

#### 2.2 开启缓存 ####

如果通过SMP分析得知在loader编译过程耗时较多，那么可以在核心loader，例如babel-loader中添加缓存。

{
      loader: 'babel-loader',
        options: {
          cacheDirectory: true
        }
    }
    复制代码

#### 2.3 开启happyPack多线程编译 ####

如果通过SMP分析得知在loader编译过程耗时较多，还可以通过使用happyPack\[2\]，开启多线程编译，提升开发效率。

#### 2.4 使用dll技术 ####

dll可以简单理解成提前打包，例如lodash、echarts等大型npm包，可以通过dll将其提前打包好，这样在业务开发过程中就不用再重复去打包了，可以大幅缩减打包时间。

#### 2.5 升级到webpack5 ####

webpack5利用 `持久缓存` 来提高构建性能，或许升级webpack后，前述的各种优化，都将成为历史。

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

### 3. 后向治理包含哪些内容？ ###

后向治理主要保证构建结果的质量

#### 3.1可视化分析构建结果 ####

![608189dcf2ba739edbdab539497fafe7.png][]

很常见的就是webpack-bundle-analyzeer\[3\]，提供打包结果的可视化展示，如上图给予的决策帮助是：

1.  是否需要按需加载
2.  是否需要提取公共代码
3.  是否需要制定cacheGroup的策略

#### 3.2 清理deadcode ####

业务开发过程中，随着业务迭代，经常有些文件、模块及代码被废弃，这些废弃代码随着时间推移，将逐渐变为历史包袱，所以针对构建后结果，我们要做的就是清理其中的deadcode。

前面webpack-bundle-analyzeer虽然是最常用的插件，但依旧有一些缺陷：

##### 3.2.1. 体积超小的deadcode模块引用，无法被准确识别 #####

![d1b8fa8a8f66eb61f80cebdd83e06172.png][]

例如上图：

*  lodash体积大一下子就能被发现，就会意识到重复引用或者是未使用
 *  但deadcode模块c体积很小，即便被chunk1、chunk2都引用了，也不一定能立刻发现，很容易被带到线上
 *  而且这种deadcode也无法通过splitchunk来进行优化，因为splitchunk根据引用次数提取公共代码，无法分辨是否是废弃代码，所以对模块c.js这种的deadcode就无力了

##### 3.2.2. tree-sharking只保留有用的代码，但deadcode还在那里 #####

tree-sharking大家都了解，摇掉不需要的代码，做为最终的输出结果，但反过来说，这些废弃代码依旧在本地真实不虚的存在着。

所以如何能准确的清理掉deadcode呢？这就需要通过webpack的 `统计信息(stats)` 来进行更细节的分析

#### 3.3 统计信息(stats) ####

stats\[4\]是通过 webpack 编译源文件时，生成的包含有关于模块的统计数据的 JSON 文件，这些统计数据不仅可以帮助开发者来分析应用的依赖图表，还可以优化编译的速度。

webpack --profile --json > compilation-stats.json
    复制代码

通过上述全局命令即可输出统计信息,例如：

{
      "version": "1.4.13", // Version of webpack used for the compilation
      "hash": "11593e3b3ac85436984a", // Compilation specific hash
      "time": 2469, // Compilation time in milliseconds
      "filteredModules": 0, // A count of excluded modules when `exclude` is passed to the `toJson` method
      "assetsByChunkName": {
        // Chunk name to emitted asset(s) mapping
        "main": "web.js?h=11593e3b3ac85436984a",
        "named-chunk": "named-chunk.web.js",
        "other-chunk": [
          "other-chunk.js",
          "other-chunk.css"
        ]
      },
      "assets": [
        // A list of asset objects
      ],
      "chunks": [
        // A list of chunk objects
      ],
      "modules": [
        // A list of module objects
      ],
      "errors": [
        // A list of error strings
      ],
      "warnings": [
        // A list of warning strings
      ]
    }
    复制代码

*  modules：表示module的集合
 *   *  module：webpack依赖树中的真实模块
 *  chunks：表示chunk的集合
 *   *  chunk：包含entry入口、异步加载模块、代码分割（code spliting）后的代码块

通过对modules和chunks加以分析，就可以得到webpack完整的依赖关系，从而梳理出废弃文件及废弃代码，同时也可以根据业务形态进行定制。

#### 3.4 webpack-deadcode-plugin ####

前面提到分析stats.json，但因为是原始数据，数据量比较大，有一定处理和清洗成本，所以可以使用开源的webpack-deadcode-plugin\[5\]这个插件

![4392b1752e5a30467ab10878d717535e.png][]

通过webpack-deadcode-plugin，可以快速筛选出：

1.  未使用的文件
2.  未使用的已暴露变量

#### 3.5 结合eslint、tslint进行治理 ####

lint可以快速的扫描出未使用的变量，这能够极大的提升我们的deadcode清理效率。

1.  首先通过lint对未使用变量进行清理
2.  再通过webpack-deadcode-plugin再扫描出未使用文件和未使用的导出变量

顿时整个应用干干净净，舒舒服服！

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

### 参考 ###

#### 1. speed-measure-webpack-plugin\[6\] ####

#### 2. happyPack\[7\] ####

#### 3. webpack-bundle-analyzeer\[8\] ####

#### 4. stats\[9\] ####

#### 5. webpack-deadcode-plugin\[10\] ####

### 参考资料 ###

\[1\]

speed-measure-webpack-plugin: *https://github.com/stephencookdev/speed-measure-webpack-plugin*

\[2\]

happyPack: *https://github.com/amireh/happypack*

\[3\]

webpack-bundle-analyzeer: *https://github.com/webpack-contrib/webpack-bundle-analyzer*

\[4\]

stats: *https://webpack.js.org/api/stats/*

\[5\]

webpack-deadcode-plugin: *https://github.com/MQuy/webpack-deadcode-plugin*

\[6\]

speed-measure-webpack-plugin: *https://github.com/stephencookdev/speed-measure-webpack-plugin*

\[7\]

happyPack: *https://github.com/amireh/happypack*

\[8\]

webpack-bundle-analyzeer: *https://github.com/webpack-contrib/webpack-bundle-analyzer*

\[9\]

stats: *https://webpack.js.org/api/stats/*

\[10\]

webpack-deadcode-plugin: *https://github.com/MQuy/webpack-deadcode-plugin*

最后

![02af3215905af6cf29feae3ccd5c54b9.png][]

你好，我是winty，末流本科软件工程专业出身，目前就职于腾讯微信，掘金LV5作者。

技术上主导过服务端框架设计，是可视化搭建平台的核心开发，主导过基础库平台搭建/前端性能sdk开发等，接触过包括但不限于服务端、移动端、PC端、小程序等，目前主要专注于高级前端进阶方向的学习。

我偏爱理财，喜欢折腾技术；靠自己的努力已经在广州房车齐全，正在努力奋斗人生中的第一个千万。上方关注后可以加我私信，[点击蓝字查看我的奋斗之路。][Link 1]

[fe91585da51fb7b65df36d766e9bbaf4.png]: /images/20221021/833b7e5a0d304adaa7c98a78d3af563f.png
[613655b3e8646d820ed669610821bf73.png]: /images/20221021/1bc3e4b224a54ead9e6fc73db6c4379c.png
[608189dcf2ba739edbdab539497fafe7.png]: /images/20221021/04a46edd63094935a7fbd4ccdd5f3a27.png
[d1b8fa8a8f66eb61f80cebdd83e06172.png]: /images/20221021/9ddece01f3b44e0d8d53615d3bc6a173.png
[4392b1752e5a30467ab10878d717535e.png]: /images/20221021/397ffcb90007456ebe552e8f2bab363a.png
[02af3215905af6cf29feae3ccd5c54b9.png]: /images/20221021/3a2f11b14fcb45aa95d5b247b88e3d96.png
[Link 1]: http://mp.weixin.qq.com/s?__biz=MzI0MzIyMDM5Ng%3D%3D&chksm=f175f306c6027a1029967cde600630a5107fbbfdd125b64ba3f2c9d9b570b102162ab4c3b373&idx=1&mid=2649831877&scene=21&sn=9352cf4624308602c50a6fd10379d132#wechat_redirect