临近春节，公司很多同事都提前回家过年，剩余人员根据禅道去修改bug，当bug修正完毕以后，我们需要重新打包给运维，上测试服给测试同事提测，但是由于项目本体比较庞大，所以打包时间太过漫长（二十五分钟以上:sob:），所以有了打包优化的想法（其实想法早就有了，但是因为平时工作计划比较充实，所以一直没有去完成这个工作），这次正好有时间，所以去重新考虑了这个问题！
webpack是react项目标配的打包工具，和NPM搭配起来使用管理模块实在非常方便。
webapck 把所有的静态资源都看做是一个 module，通过 webpack，将这些 module 组成到一个 bundle 中去，从而实现在页面上引入一个 bundle.js，来实现所有静态资源的加载。
话不多说，直接开始正文吧
先给大家看一下项目的目录结构：
就是正常的项目结构，简单说一下吧：
build文件夹包含的是一些打包配置的一下东西
config文件夹是项目的基础配置
dist是打包之后的文件
node_modules是项目的依赖包
src文件夹里面是项目的源码
static文件夹里面放的是一些项目使用的静态资源
index.html是项目的首页
package.json文件是项目的配置json
yarn.lock是使用yarn锁定项目用的依赖
优化思路
项目打包时间长，原因无外乎就是项目整体比较庞大、依赖复杂、组件之前拆分不够合理。
对于这三个问题呢，我们可以针对下面这几个方面去做一下处理：
对项目进行路由屏蔽，只打包自己需要打包的部分（我司就是好几个项目合并在了一起，至于原因则是 需求类似，所以放在一起比较省事 -_-||| 开发过程中是省了不少事，但是现在一样要还的！！！！）
依赖关系复杂，这里说的是项目中的依赖模块比较多，像我们现在这个项目，光算依赖包的话就有40+，另外一个重要原因就是组件之间存在相同引用的依赖。解决思路是把项目中重用的依赖抽离出来进行单独打包。
组件在写的过程中，需要考虑好这个组件的使用方向，以及实现功能，不能混为一谈。
实际操作
有了整体的思路，那么开搞就可以啦 去webpack文档去看了一下有一个DllPlugin，这个插件就是帮助我们解决问题的关键，下面是我webpack.dll.config的代码：
var path = require("path"); var webpack = require("webpack"); function resolve (dir) { return path.join(__dirname, '..', dir) } module.exports = { // 你想要打包的模块的数组 entry: { vendor: ['vue', 'lodash', 'vuex', 'axios', 'vue-router', 'iview', 'element-ui', 'echarts','xlsx','jquery','vue-fullcalendar','vue-cookie','handsontable'] }, output: { path: path.join(__dirname, '../dist/vendor-dll-js'), // 打包后文件输出的位置 filename: '[name].dll.js', library: '[name]_library' // vendor.dll.js中暴露出的全局变量名。 // 主要是给DllPlugin中的name使用， // 故这里需要和webpack.DllPlugin中的`name: '[name]_library',`保持一致。 }, resolve: { extensions: ['.js', '.vue', '.json'], alias: { 'vue$': 'vue/dist/vue.esm.js', '@': resolve('src'), } }, plugins: [ new webpack.DllPlugin({ path: path.join(__dirname, '.', '[name]-manifest.json'), name: '[name]_library', context: __dirname }), // 压缩打包的文件，与该文章主线无关 new webpack.optimize.UglifyJsPlugin({ compress: { warnings: false } }) ] };
我们需要将项目中具有重用性的包抽离出来，放在vendor数组里面，然后在下面output里面定义一下打包输出的文件路径，然后在resolve里面配置解析参数，最后定义使用的DllPlugin插件，UglifyJsPlugin是压缩js的插件
Dllplugin里的path，会输出一个vendor-manifest.json，这是用来做关联id的，打包的时候不会打包进去，所以不用放到static里 然后运行一下 webpack -p --progress --config build/webpack.dll.conf.js
成功以后，static下会有dll.vendor.js，根目录下会有vendor.manifest.json 各自打开看一下，就会看到依赖库的源码和匹配id
ok，到这里，抽离依赖库的事情就完成了，那么接下来问题就是怎么引用呢，怎么在dev和build跑呢？
这里补了一点dll和commonsChunk概念上的区别，commonsChunk之所以慢和大，是因为每次run的时候，都会去做一次打包，而实际上我们不会一直去更新我们引用的依赖库，所以dll的做法就等于是，事先先打包好依赖库，然后只对每次都修改的js做打包。
继续上面的步骤，我们需要根据生成的json文件去修改webpack.base.config文件：
const manifest = require('../vendor-manifest.json') ...... plugins: [ new webpack.DllReferencePlugin({ manifest }) ]
然后打开index.html，在底部加上 <script src="https://www.jb51.net/article/static/dll.vendor.js"></script> ；
执行一下 npm run build ,一起正常的话，表示你的操作是正确的。
升级处理