webpack前台编译优化

放开公司其余单页应用的项目不说，在我们快速迭代的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缓存的插件，注释掉就好了，
erm0l0v/webpack-md5-hash/issues/5
这里都是说这个插件不好的地方，推荐看下可替代方案

还有少量问题忘记了，应该是比较好处理的

随后听说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/    }, 

这样再运行项目的时候就不会报错了。

0.4分钟是什么概念？也就是动动手指刷新一下浏览器的时间吧。到此，第一批工程算是完事了，其实还能更细节的去优化webpack，未完待续...

小ps:
刚开始的时候不知道怎样入手去优化，就安装了一个项目分析的插件webpack-bundle-analyzer,具体的安装和使用不赘述，可以看webpack打包体积优化，详细分布查看插件 webpack-bundle-analyzer,
就是每次我们运行项目的时候会出现一个本地服务器去分析哪些资源占用了比例比较大等

后来发现这个对于一个SPA的项目会非常实用，哪个js占用的资源大了，即可以对其进行解决，对于我们的项目来说用处不大，仅供参考。