详解多页应用 Webpack4 配置优化与踩坑记录

前言

最近新起了一个多页项目，之前都未使用 webpack4，于是准备上手实践一下。这篇文章主要就是一些配置介绍，对于正准备使用 webpack4 的同学，可以做一些参考。

webpack4 相比之前的 2 与 3，改变很大。最主要的一点是很多配置已经内置，使得 webpack 能“开箱即用”。当然这个开箱即用不可能满足所有情况，但是很多以往的配置，其实可以不用了。比如在之前，压缩混淆代码，需要增加uglify插件，作用域提升(scope hosting)需要增加ModuleConcatenationPlugin。而在 webpack4 中，只需要设置 mode 为 production即可。当然，如果再强行增加这些插件也不会报错。

所以我建议，如果大家想迁移到 webpack4，还是从 0 开始做加法，参考历史，重新做一个配置。而不是从历史的配置里删删减减，再升级为 webpack4。这样 webpack4 的配置会显得更精简。

打包优化

打包优化主要就是多页应用构建时，对所有页面加载的依赖进行合理打包。这个目前业界都已经有了很多实践，包括 webpack4，也有很多文章介绍。我再补充几个不容易注意的小细节。有些点我不详细介绍，不熟悉 webpack 配置的同学可能会不明白，可以搜索对应关键词，网上肯定有非常详细的文章介绍。

首先，构建多页应用，往往会抽离如下几个 chunk 包：

然后我们会给打出的 chunk 包名，注入 contentHash，以实现最大缓存效果。在我们分 chunk 的过程中，最关键的一个思想就是，每次迭代发布，尽量减少 chunk hash 值的改变。这个在业界也有很多非常多的实践，比如这篇文章：https://github.com/pigcan/blog/issues/9

不过在 webpack4 中，我们不用再增加这么多插件啦，一个 optimization 配置完全就能搞定。

我先贴上我的 webpack 的 optimization 配置，然后我再对其做一些介绍，加深大家印象

const commonOptions = { chunks: 'all', reuseExistingChunk: true}export default { namedChunks: true, moduleIds: 'hashed', runtimeChunk: {  name: 'manifest' }, splitChunks: {  maxInitialRequests: 5,  cacheGroups: {   polyfill: {    test: /[///]node_modules[///](core-js|raf|@babel|babel)[///]/,    name: 'polyfill',    priority: 2,    ...commonOptions   },   dll: {    test: /[///]node_modules[///](react|react-dom)[///]/,    name: 'dll',    priority: 1,    ...commonOptions   },   commons: {    name: 'commons',    minChunks: Math.ceil(pages.length / 3), // 至少被1/3页面的引入才打入common包    ...commonOptions   }  } }}