序
近来遇项目打包之事，撰文记之。以期分享，皆有所获。
前提
前提有两点，需要得到你的认同：
-
【后台管理系统】框架和 UI 组件库最强组合为 vue-element-admin + Element UI！(●'◡'●)
-
webpack4 最核心的特性是 【splitChunks】，splitChunks 最核心的配置是 cacheGroups！
基于这个两个前提，我们再进行下一步。
分析工具
webpack 打包分析有它就够了：webpack-bundle-analyzer
- 安装
npm install --save-dev webpack-bundle-analyzer
- 配置：因为 vue-element-admin 基于 vueCli4，所以在 vue.config.js chainWebpack 中设置
config.plugin('BundleAnalyzerPlugin').use(BundleAnalyzerPlugin).tap(() => [
{
rel: 'BundleAnalyzerPlugin',
analyzerMode: 'server', // 'server': 启动端口服务；'static': 生成 report.html；'disabled': 配合 generateStatsFile 使用；
generateStatsFile: false, // 是否生成stats.json文件
analyzerHost: '127.0.0.1',
analyzerPort: '8877',
reportFilename: 'report.html',
defaultSizes: 'parsed',
openAnalyzer: false,
statsFilename: 'stats.json',
statsOptions: null,
excludeAssets: null
}
其中 analyzerMode 的设置比较重要。
- 运行：
npm run dev 或 npm run build
- 访问：
http://127.0.0.1:8877
现状问题
看一下咱们的打包分析图：
得出如上图的分包并不难，vue-element-admin 自带这些配置。
config.optimization.splitChunks({
chunks: 'all',
cacheGroups: {
libs: {
name: 'chunk-libs',
test: /[\\/]node_modules[\\/]/,
priority: 10,
chunks: 'initial' // only package third parties that are initially dependent
},
elementUI: {
name: 'chunk-elementUI', // split elementUI into a single package
priority: 20, // the weight needs to be larger than libs and app or it will be packaged into libs or app
test: /[\\/]node_modules[\\/]_?element-ui(.*)/ // in order to adapt to cnpm
},
commons: {
name: 'chunk-commons',
test: resolve('src/components'), // can customize your rules
minChunks: 3, // minimum common number
priority: 5,
reuseExistingChunk: true
}
}
})
如果你暂时还看不懂这些配置项，先别急，后面会一一陈述。
你只用先知道：它拆了初始化加载的第三方包、拆了 Element UI 库、拆了 src/components。
一切似乎好像还不错，但是我们并不满足。
实际上，咱们跑一下 npm run build:test 也会报警告。
那么还有哪些点可以继续优化？结合以上分析图和 test warning，很明显，我们需要思考：
- Echarts 的体积大小不能忽视，如何处理它？是首页加载还是异步加载？要按需引入吗？
- vue.js 等库还能不能再拆？
- 首页 Entrypoints 所依赖的包还能不能再优化？
- 包的体积应控制在什么范围？包太大，加载会太慢！包太小，会消耗 HTTP 请求连接！更多：合并 HTTP 请求是否真的有意义？
- 更多......
淦！打包什么的，多打几遍就完事了。十遍不行就一百遍，一百遍不行就一千遍，一千遍不行就......
优化的结果
淦完后得出如下打包分析图：
本瓜成功的将打包大小从 3.1MB 变成了 2.36MB，文件数从 68个 打包到了 43个 ！！！，既实现了拆包（拆公共库），也实现了并包（合并极小的包）。
虽然这不会是最终的结果，但本瓜可以先下一个结论：
配置 cacheGroups，权衡拆包与并包二者，便是 webpack 分包的究极奥义！
以下是 cacheGroups 配置：
config.optimization.splitChunks({
chunks: 'all',
cacheGroups: {
vue: {
name: 'chunk-vuejs',
test: /[\\/]node_modules[\\/]_?vue(.*)/,
priority: 20
},
elementUI: {
name: 'chunk-elementUI', // split elementUI into a single package
priority: 30, // the weight needs to be larger than libs and app or it will be packaged into libs or app
test: /[\\/]node_modules[\\/]_?element-ui(.*)/ // in order to adapt to cnpm
},
commons: { // split async commons chunk
name: 'chunk-async-commons',
minChunks: 2,
priority: 40,
chunks: 'async'
},
echarts: { // split echarts libs
name: 'chunk-echarts',
test: /[\\/]node_modules[\\/]_?echarts(.*)/,
priority: 50,
chunks: 'async'
},
zrender: { // split zrender libs
name: 'chunk-zrender',
test: /[\\/]node_modules[\\/]_?zrender(.*)/,
priority: 55,
chunks: 'async'
},
'manage-sendMsg': { // resolve src
name: 'chunk-manage-sendMsg',
test: resolve('src/views/manage/sendMsg'),
priority: 80,
chunks: 'async'
},
'manage-packageLink': { // resolve src
name: 'chunk-manage-packageLink',
test: resolve('src/views/manage/packageLink'),
priority: 80,
chunks: 'async'
}，
......
})
其实咱单独从配置上去做优化，可操作的空间并不大。我们还应该从打包分析结果去回看我们的代码细节，调整业务代码来优化打包结果，或许是最直接有效的优化思路之一。包括：如何整合或解耦业务？如何做组件化？组件怎么引？插件怎么引？引多少？......每个点都能再操作操作！
- 尤其注意
| CommonJs(require) | ES6(import) |
|---|---|
| 输出的是一个值的拷贝 | 输出的是值的引用 |
| 运行时加载 | 编译时输出接口 |
cacheGroups
下面我们再具体看看 cacheGroups 最关键的配置：
【重要】
-
name chunk 的文件名
-
test 过滤 modules，默认为所有的 modules，可匹配模块路径或 chunk 名字，当匹配到某个 chunk 的名字时，这个 chunk 里面引入的所有 module 都会选中；
-
priority 权重，数字越大表示优先级越高。一个 module 可能会满足多个 cacheGroups 的正则匹配，到底将哪个缓存组应用于这个 module，取决于优先级；
-
chunks（非常非常非常重要） 有三个值：all、async、initial。
这里是一段示例代码，来看看设置不同的 chunks，它们有什么样的打包区别：
//app.js
import "my-statis-module";
if(some_condition_is_true){
import ("my-dynamic-module")
}
console.log("My app is running")
asyn : (default)
会生成两个打包文件：
- bundle.js (包含 app.js + my-statis-module)
- chunk.js (只包含 my-dynamic-module)
initial :
会生成三个打包文件：
- app.js (只包含 app.js)
- bundle.js (只包含 my-static-module)
- chunk.js (只包含 my-dynamic-module)
all :
会生成两个打包文件：
- app.js (只包含 app.js)
- bundle.js (包含 my-static-module + my-dynamic-module)
设置 "all" 大小将最小，区别使用这三者，是核心中的核心。
【了解】
-
minSize 表示被拆分出的 bundle 在拆分之前的体积的最小数值，只有 >= minSize 的 bundle 会被拆分出来；
-
maxSize
表示被拆分出的 bundle 在拆分之前的体积的最大数值，默认值为 0，表示 bundle 在拆分前的体积没有上限；maxSize 如果为非 0 值时，不能小于 minSize；
-
minChunks 表示在分割前，可被多少个chunk分享的最小值
-
reuseExistingChunk 表示是否使用已有的 chunk，true 则表示如果当前的 chunk 包含的模块已经被抽取出去了，那么将不会重新生成新的，即几个 chunk 复用被拆分出去的一个 module；
意外收获
代码层面：这样写，user.png 会被单独打成一个包。打包出来 148B ，属实没必要！
<img v-show="imageUrl" :src="imageUrl" class="sort-img">
<img v-show="!imageUrl" src="~@/assets/user.png" class="sort-img">
如果改成这样，则不会再被单独打包了。
<img :src="imageUrl?imageUrl:'~@/assets/user.png'" class="sort-img">
回看其它代码，本瓜发现所有在条件判断里面引入的文件都会被单独打包。然而它们其中有些是可以调整写法的，真没必要将几 KB 的文件单独打包成一个几 B 的包文件。
从打包的结果去检验代码，也是一种不错的优化手段！
策略小结
基于本次分包，本瓜简单梳理一下策略：
- 公共的库是一定要尽量拆的。
- 公共的库尽量做到按需加载，这也是优化首屏加载需要注意的。
- 分包不能太细，0KB 至 10 KB 的包是极小的包，应当考虑合并。10 KB 至 100 KB 的包是小包，比较合适；100 KB 至 200 KB 的包只能是比较核心重要的包，需要重点关注，大于 200KB 的包就需要考虑拆包了。当然，也不排除一些特殊情况。
| 包大小 | 策略 |
|---|---|
| 0 KB 至 10 KB | 合并包 |
| 10 KB 至 100 KB | 大小合适 |
| 100 KB 至 200 KB | 核心包，重点关注 |
| 大于 200 KB | 考虑拆包 |
| 特殊情况 | 特殊处理 |
本次就先到这，打包无止境，愿这个世上没有打包攻城狮。
关注公众号【掘金安东尼】，你的三连，我的动力！！！
