使用 vue-cli 构建项目中的 Webpack优化
webpack 升级 3.x
根据官方的 release 声明，webpack 3.x 的一个显著特性是 Scope Hoisting。之前 webpack 构建时会把每个模块单独的放到一个闭包函数中，这会增加 javascript 的执行时间。 3.x 之后，webpack 则会将有联系的模块，放到一个大的闭包函数里面去，这样可以减少构建出来的文件大小和 javascript 的执行时间。要让 Scope Hoisting 起作用，只需要添加下面的插件：
module.exports = {
plugins: [
new webpack.optimize.ModuleConcatenationPlugin()
]
};
这条优化主要是针对 javascript 执行效率的，自己在项目中使用时，对于构建的时间并没有显著提升。
减小文件搜索范围
这一点的优化可以让 webpack 不必自己遍历去搜索模块，而可以通过我们定义的路径，快速定位模块。配置代码如下：
resolve: {
//...
// modules选项配置，指定node_modules文件夹所在的位置
//节省webpack去查找的时间
modules: [resolve('node_modules')],
alias: {
// vue-cli自带生成，'vue$' 表示严格匹配 'vue' 这个字段
'vue$': 'vue/dist/vue.esm.js',
'@': resolve('src'), // vue-cli自带生成
'api': resolve('src/api')
//... 其他配置
}
}
resolve.modules是用来配置模块库（通常是 node_modules）所在的位置。默认的配置会采用向上递归搜索的方式去寻找，为了减少搜索范围，可以直接写明 node_modules 的全路径。
而alias是指配置别名。通过编写alias，既能让webpack查找文件定位更快，在开发的时候，也能少些很多相对路径的../..，在引入模块的时候也会很方便。
运行时构建
Vue官网的安装指南里面有这么一段话
当使用 vue-loader 或 vueify 的时候，*.vue 文件内部的模板会在构建时预编译成 JavaScript。你在最终打好的包里实际上是不需要编译器的，因为只是用运行时构建即可。
因为运行时构建相比完整版缩减了 30% 的体积，你应该尽可能使用这个版本。
但是在 vue-cli 构建出来的项目配置中，我们发现它还是使用了完整版构建。那把它改正运行时构建会怎么样呢？
resolve: {
//...
alias: {
/* vue-cli自带生成，'vue$' 表示严格匹配 'vue' 这个字段 */
// 'vue$': 'vue/dist/vue.esm.js', /* 自带生成完整版 */
'vue$': 'vue/dist/vue.runtime.esm.js', /* 改为运行时 */
//...
}
}
npm run dev 之后会发现报了这么一个错
vue 报错
我们明明使用了 vue-loader，按照官网的描述，为什么还会提示需要 vue 包含编译器的版本呢？原因在于我们实例化 vue 的时候，还是使用了需要编译器的写法，在入口文件 main.js 最下面，找到实例化 vue 的代码
/* vue-cli 自动生成 */
new Vue({
el: '#app',
router,
store,
template: '<App/>',
components: { App }
})
为了能使用运行时构建，我们需要把代码改成不需要编译器的形式
/* 修改之后 */
new Vue({
el: '#app',
router,
store,
// template: '<App/>', /* 如果 Vue 选项中包含渲染函数，该模板将被忽略 */
// components: { App },
render: h => h(App), // 使用render方式引入组件
})
修改之后，运行没有问题。通过这种修改方式，在项目里就可以用更小的 vue 文件进行构建了。
happypack
webpack 的构建是单进程的。采用 happypack 可以改为多进程构建，从而提高构建速度。但是我在项目中使用了之后，构建速度并没有网上描述的提升那么明显。
首先安装：npm install happypack --save-dev
然后修改 webpack 配置文件：
const os = require('os');
const HappyPack = require('happypack');
const happThreadPool = HappyPack.ThreadPool({size: os.cpus().length}); // 采用多进程，进程数由CPU核数决定
//...
module.exports = {
plugins: [
// ...
new HappyPack({
id: 'js',
cache: true,
loaders: ['babel-loader?cacheDirectory=true'], // ?cacheDirectory=true 开启babel-loader的缓存
threadPool: happThreadPool
})
],
module: {
rules: [
{
// vue-loader 似乎有兼容性问题，故没有使用
test: /\.vue$/,
loader: 'vue-loader',
options: vueLoaderConfig ,
},
{
test: /\.js$/,
loader: ['happypack/loader?id=js'], // 将loader换成happypack
include: [resolve('src')],
},
]
}
}
DllPlugin和DllReferencePlugin
在日常工作中，每当修改了业务代码之后，一些第三方的，体积比较大的模块也会被重新打包，极大的浪费了时间。这时我们就可以使用 DLL 预先把一些第三方模块提前打包，以后修改业务代码再构建时就不会构建这些模块了。所以，DLL 的作用，简单的说是把之前一步完成的构建分成了两步：
- 将一些第三方的模块抽离出来（比如 vue、echarts、axios等），预先构建一遍
- 构建其他模块和业务代码
因为第三方的模块变动并不会频繁，在第一步构建之后的 bundle 就可以长期的放在项目里，后续的构建时只需要进行第二步，这样会节省大量的构建时间。
在 build 文件夹里建立一个 webpack.dll.conf.js，我们将一些常用的依赖打包成dll。
var path = require("path");
var webpack = require("webpack");
module.exports = {
// dll 包含模块的名字
entry: {
vendor: ['vue/dist/vue.runtime.esm.js', 'lodash', 'vuex', 'axios', 'vue-router', 'element-ui']
},
output: {
path: path.join(__dirname, './static/js'),
filename: '[name].dll.js',
// 给DllPlugin中的name使用，需要和 webpack.DllPlugin 中的 name 字段保持一致
library: '[name]_library'
},
plugins: [
new webpack.DllPlugin({
path: path.join(__dirname, '.', '[name]-manifest.json'),
// 和上面的 library 保持一致
name: '[name]_library',
context: __dirname
}),
]
};
在 package.json 中加入：
"scripts": {
"dll": "webpack --config ./build/webpack.dll.config.js"
},
运行 npm run dll 之后，会在 static/js 文件夹下生成 vender.dll.js，会在 build 文件夹下生成 vender-manifest.json。这个 vender-manifest.json 会被 webpack.base.config.js 中加入的新插件 DllReferencePlugin 使用，以便于业务代码能正确地访问到构建好的第三方模块的。
在 webpack.base.config.js 中，添加 DllReferencePlugin：
module.exports = {
//... 其他配置
plugins: [
// ... 其他插件
new webpack.DllReferencePlugin({
context: __dirname,
manifest: require('./vendor-mainfest.json') // 指向之前生成的 vendor-mainfest.json
})
]
}
最后，在项目输出的index.html里，最先引入这个js：
<body>
<div id="app"></div>
<script src="./static/js/vendor.dll.js"></script>
<script src="/dist/build.js"></script>
</body>
这样只要第三方模块不变，我们之后的上线构建都不用运行 npm run dll了。只构建业务代码和一些体积比较小的包，构建速度是非常快的。
devtools
// vue-cli 默认配置
devtool: config.build.productionSourceMap ? '#source-map' : false,
devtools 决定了 source-map 的生成方式。source-map的作用这里不深入展开，有兴趣可以参考阮一峰老师的�这篇文章。下图是 webpack 官网给出的 devtools 几种配置选项：
devtool配置项
vue-cli 在生产环境默认采用的模式是 source-map，可以发现，这种模式不管对于 build 还是 rebuild，都会�增加时间。可以根据项目需求更改配置。我在生产环境使用的是eval模式，因为我觉得生产环境为了减少请求和混淆代码可以不用加上source-map，毕竟很少在生产环境进行debug。开发环境我采用 cheap-module-eval-source-map 模式。这样针对生产环境再进行构建，会发现时间也是大幅度减少了。
