放开公司其他单页应用的项目不说，在我们快速迭代的app中，内嵌了很多h5页面，这些页面在不同的业务线中，也没有任何联系，所以每个页面都是一个单独的入口， 时间长了，每个页面都难免引入一些公共的第三类库等等，所以随着页面越来越多，项目编译和打包都非常慢，即使更改了一个标点符号，都要等待7分钟的编译时间，7分钟什么概念，这么说吧我下楼买个饮料才5分钟。
后来，分析了一下套路，大概因为我们的webpack版本过低吧，还是2开头的，现在早就更新到4了，也就是说别人都汽车了，我们还在骑自行车狂奔，所以第一步更新webpack，并且解决相关插件编译报错，第二部让webpack搭配HappyPack实现编译编译更加快速
1、更新webpack（yarn add webpack -s -d）
2、英文webpack4使用了webpack-cli，所以需要安装webpack-cli（yarn add webpack-cli -s -d）
这里可能有错误，因为后期运行项目的时候总是提示webpack-cli没有安装，因为后期运行了很多命令，不确定哪里是修改了哪里，所以建议全局安装一遍webpack和webpack-cli还有更新node版本
3、有错改错，安装了以上发现很多插件都不能用了，所以那个插件错了，就把那个插件重新装下。
4、几个印象比较深的错误
原因：webpack.optimize.CommonsChunkPlugin在webpack4里早已寿终正寝，取而代之的是optimization，所以这里要根据项目需求进行更改。
原因：这个错误找了很久，可以说是气到我摔电脑，github上也是人云亦云，最后在男神的帮助下，发现了webpack-md5-hash的问题，这个是一个hash缓存的插件，注释掉就好了，
https://github.com/erm0l0v/webpack-md5-hash/issues/5
这里都是说这个插件不好的地方，推荐看下可替代方案
还有一个这个警告，不影响编译，查了很久发现是因为html-webpack-plugin这个版本的问题，所以暂时不追究了。
还有一些问题不记得了，应该是比较好解决的
这些前期工作做好了以后，发现webpack4是可以正常跑起来了，编译时间也有了质的飞跃，从7分钟变为一分钟
随后听说webpack4搭配HappyPack会编译的更快，于是安装happypack npm i -D happypack
然后：
const HappyPack = require('happypack');
{
test: /\.js$/,
loader: 'happypack/loader?id=happyBabel',
exclude: /node_modules/,
options: {
presets: [
'es2015', 'stage-0'
],
plugins: ['transform-runtime']
}
},
new HappyPack({
// 用id来标识 happypack处理那里类文件
id: 'happyBabel',
// 如何处理 用法和loader 的配置一样
loaders: [{
loader: 'babel-loader'
}],
// 允许 HappyPack 输出日志
verbose:true
}),
其中会遇到一个错误
[AssertionError [ERR_ASSERTION]]:HappyPack: plugin for the loader '1' could not be found! Did you forget to add it to the plugin list?
{
test: /\.js$/,
loader: 'happypack/loader?id=happyBabel',
exclude: /node_modules/
},
这样再运行项目的时候就不会报错了。
到此为止再次运行项目的编译时间是
20几秒是什么概念？也就是动动手指刷新一下浏览器的时间吧。到此，第一批工程算是完事了，其实还能更细节的去优化webpack，未完待续...
小ps:
刚开始的时候不知道怎么入手去优化，就安装了一个项目分析的插件webpack-bundle-analyzer,具体的安装和使用不赘述，可以看webpack打包体积优化，详细分布查看插件 webpack-bundle-analyzer,
就是每次我们运行项目的时候会出现一个本地服务器去分析哪些资源占用了比例比较大等
后来发现这个对于一个SPA的项目会非常实用，哪个js占用的资源大了，就可以对其进行处理，对于我们的项目来说用处不大，仅供参考。
