优化 Webpack 打包效果

[xiaoiver]

最近参考了一些文章和 Nuxt 等成熟方案，发现在 Lavas 使用 Webpack 构建的过程中，可能存在以下优化点：

在减少构建时间方面：

1. UglifyPlugin 提供 parallel 选项并行压缩 JS 代码。Nuxt 中也开启了这一选项。
2. happypack 可以使某些 loader 并行执行，例如 babel-loader，能减少转译源码时间。
3. Webpack 提供的 DLLPlugin，某些不常修改的第三方库，不需要每次重新编译。只需要第一次编译，可以缩短后续构建时间。autodll-webpack-plugin 提供了更加简便的配置方法。

减少打包大小，提升执行速度：
ModuleConcatenationPlugin 可以：

预编译所有模块到一个闭包中，提升你的代码在浏览器中的执行速度。

另外，在 #38 中提到的打包方案的问题，现有的方案可能会存在问题：

默认情况下，模块的 id 是这个模块在模块数组中的索引。OccurenceOrderPlugin 会将引用次数多的模块放在前面，在每次编译时模块的顺序都是一致的...如果你修改代码时新增或删除了一些模块，这将会影响到所有模块的 id。

使用 HashedModuleIdsPlugin 可以保证模块的 id 的稳定，从而保证 vendor.js 的 hash 不受到业务代码的影响。Nuxt 中在生产环境也使用了这个插件，而在开发环境使用了另一个 NamedModulesPlugin。这一点和 Webpack 文档中关于这两个插件的使用建议一致。

我会尝试一下以上方案，观察构建性能提升情况。

参考：

• 提升 Webpack 构建性能
• Webpack 打包方案

[xiaoiver]

测试均在 Lavas 多 entry 模版下进行，同时引入 Vuetify 部分组件。

1. 在开启 UglifyPlugin parallel 选项后，构建时间从 19778ms 减少到 17794ms，缩短了 2s 左右。
2. 使用了 Happypack 对处理 JS 文件的 babel-loader 进行并行处理（线程池中 4 个线程）后，构建时间并没有减少，毕竟多线程通信也有开销。
3. 开启 ModuleConcatenationPlugin 后，生成 chunk 文件没有明显减少，倒是 index.js.map 文件减少了7k。比较 vue.js 可以发现生成的闭包从 140 个减少到了 138 个，可见插件是发挥作用了，虽然不明显，可能是测试项目比较简单，但是应该也没有副作用，可以在生产环境放心开启。