webpack优化实践(遇到很奇葩的问题)

1、先上打包前后的优化效果图

2、优化背景

webpack 的构建过程太花时间
webpack 打包的结果体积太大
作者的项目是webpack 2的老项目（项目已上线很久，不太敢突然的升级webpack版本，以防有意想不到的问题）

3、优化操作

1. 用include或exclude来避免不必要的转义

module: {
    rules: [{
        test: /\.js$/,
        use: {
             loader: 'babel-loader',
        },
        // 规避了对庞大的 node_modules 文件夹或者 bower_components 文件夹的处理
        exclude: /(node_modules|bower_components)/,
        include: resolve('source')
    }]
}

2. 开启缓存将转译结果缓存至文件系统

module: {
    rules: [{
        test: /\.js$/,
        use: {
            // 开启缓存
            loader: 'babel-loader?cacheDirectory=true'
        },
        exclude: /(node_modules|bower_components)/,
        include: resolve('source')
    }]
}

3. DllPlugin/DLLReferencePlugin优化处理

处理第三方库有多种方式，externals、CommonsChunkPlugin、splitChunks、DllPlugin/DLLReferencePlugin 。我们先说说各种的优劣势

3.1 externals

防止将某些 import 的包(package)打包到 bundle 中，而是在运行时(runtime)再去从外部获取这些扩展依赖(external dependencies)。

<script src="https://unpkg.com/element-ui@2.0.8/lib/index.js"></script>

module.exports= {
    externals: {
        ElementUi: 'ELEMENT' // 主要element-ui保留出来的全局变量是ELEMENT
    }
}

import ElementUi from 'ElementUi';

优点：操作比较简单，支持多种设置方式，也可以自定义行为。
缺点：操作不是很灵活，需要设置多步，并且会出现意想不到的情况。下面我会介绍到。

3.2 CommonsChunkPlugin

通过将公共模块拆出来，最终合成的文件能够在最开始的时候加载一次，便存到缓存中供后续使用。这个带来速度上的提升，因为浏览器会迅速将公共的代码从缓存中取出来，而不是每次访问一个新页面时，再去加载一个更大的文件。（但是新的webpack中已经被移除，使用的是SplitChunksPlugin）

new webpack.optimize.CommonsChunlPlugin({
      name: string, // or
      names: string[],
      // 这是 common chunk 的名称。已经存在的 chunk 可以通过传入一个已存在的 chunk 名称而被选择。
      // 如果一个字符串数组被传入，这相当于插件针对每个 chunk 名被多次调用
      // 如果该选项被忽略，同时 `options.async` 或者 `options.children` 被设置，所有的 chunk 都会被使用，
      // 否则 `options.filename` 会用于作为 chunk 名。
      // When using `options.async` to create common chunks from other async chunks you must specify an entry-point
      // chunk name here instead of omitting the `option.name`.
    
      filename: string,
      // common chunk 的文件名模板。可以包含与 `output.filename` 相同的占位符。
      // 如果被忽略，原本的文件名不会被修改(通常是 `output.filename` 或者 `output.chunkFilename`)。
      // This option is not permitted if you're using `options.async` as well, see below for more details.
    
      minChunks: number|Infinity|function(module, count) -> boolean,
      // 在传入  公共chunk(commons chunk) 之前所需要包含的最少数量的 chunks 。
      // 数量必须大于等于2，或者少于等于 chunks的数量
      // 传入 `Infinity` 会马上生成 公共chunk，但里面没有模块。
      // 你可以传入一个 `function` ，以添加定制的逻辑（默认是 chunk 的数量）
    
      chunks: string[],
      // 通过 chunk name 去选择 chunks 的来源。chunk 必须是  公共chunk 的子模块。
      // 如果被忽略，所有的，所有的 入口chunk (entry chunk) 都会被选择。
    
      children: boolean,
      // 如果设置为 `true`，所有公共 chunk 的子模块都会被选择
    
      deepChildren: boolean,
      // 如果设置为 `true`，所有公共 chunk 的后代模块都会被选择
    
      async: boolean|string,
      // 如果设置为 `true`，一个异步的  公共chunk 会作为 `options.name` 的子模块，和 `options.chunks` 的兄弟模块被创建。
      // 它会与 `options.chunks` 并行被加载。
      // Instead of using `option.filename`, it is possible to change the name of the output file by providing
      // the desired string here instead of `true`.
    
      minSize: number,
      // 在 公共chunk 被创建立之前，所有 公共模块 (common module) 的最少大小。
});

优点：最终合成的文件能够在最开始的时候加载一次，便存到缓存中供后续使用。这个带来速度上的提升。
缺点：每次构建时都会重新构建一次 vendor。

3.3 splitChunks

webpack4中支持了零配置的特性，同时对块打包也做了优化，CommonsChunkPlugin已经被移除了，现在是使用optimization.splitChunks代替。

// webpack.config.js
splitChunks: {
    chunks: "async",
    minSize: 30000,
    minChunks: 1,
    maxAsyncRequests: 5,
    maxInitialRequests: 3,
    automaticNameDelimiter: '~',
    name: true,
    cacheGroups: {
        vendors: {
            test: /[\\/]node_modules[\\/]/,
            priority: -10
        },
    	default: {
            minChunks: 2,
            priority: -20,
            reuseExistingChunk: true
        }
    }
}

优点：使用SplitChunksPlugin是Webpack 4的默认行为，可能你设置一下chunks: 'all'就足够了，打包速度更快了。
缺点：SplitChunksPlugin是Webpack 4的特性，Webpack 4之前不能操作，比如我当前优化项目，webpack 2。

3.4 DllPlugin/DLLReferencePlugin

DllPlugin:是基于 Windows 动态链接库（dll）的思想被创作出来的。这个插件会把第三方库单独打包到一个文件中，这个文件就是一个单纯的依赖库。这个依赖库不会跟着你的业务代码一起被重新打包，只有当依赖自身发生版本变化时才会重新打包。

DLLReferencePlugin:是基于 Windows 动态链接库（dll）的思想被创作出来的。这个插件会把第三方库单独打包到一个文件中，这个文件就是一个单纯的依赖库。这个依赖库不会跟着你的业务代码。

一起被重新打包，只有当依赖自身发生版本变化时才会重新打包。配置步骤如下：

新增一个配置文件webpack.dll.config.js

const path = require('path');
const webpack = require('webpack');
const CleanWebpackPlugin = require('clean-webpack-plugin');
module.exports = {
    entry: {
        // 依赖的库数组
        vendor: [
            'vue/dist/vue.esm.js',
            'axios',
            // 'element-ui',
            'vue-router',
            'vuex',
            'v-viewer',
            'vue-photo-preview',
            'mockjs'
        ]
    },
    output: {
        path: path.join(__dirname, 'htdocs/dist'),
        filename: '[name].js',
        library: '[name]_[hash]',
    },
    plugins: [
        new CleanWebpackPlugin(['htdocs/dist/vendor-manifest.json', 'htdocs/dist/vendor.js']),
        new webpack.DllPlugin({
            // DllPlugin的name属性需要和libary保持一致
            name: '[name]_[hash]',
            path: path.join(__dirname, 'htdocs/dist', '[name]-manifest.json'),
            // context需要和webpack.config.js保持一致
            context: __dirname,
        }),
    ],
}

配置package.json命令，npm run dll 这个命令就会生成两个文件，一个是vendor-manifest.json，一个是vendor.js。 vendor.js 不必解释，是我们第三方库打包的结果。这个多出来的 vendor-manifest.json，则用于描述每个第三方库对应的具体路径下。

/ package.json
"scripts": {
    "dll": "webpack -p --progress --config ./webpack.dll.config.js" 
    },

配置webpack.config.js

module.exports = {
    plugins: [
         new webpack.DllReferencePlugin({
            context: __dirname,
            // manifest就是我们第一步中打包出来的json文件
            manifest: require('./htdocs/dist/vendor-manifest.json'),
        })       
    ]
}

引入vendor.js，引入vendor.js有两种方式

第一种：直接在index.html。，这种方式简单粗暴，针对没有vendor.js没有hash值的，完全ok，但是如果你打包的vendor.js有hash，每次重新 npm run dll之后如果生成了新的hash，就要手动改这个路径了。
第二种：add-asset-html-webpack-plugin，该插件会将给定的JS或CSS文件添加到Webpack知道的文件中，并将其放入html-webpack-plugin注入到生成的html 的资产列表中。将插件添加到您的配置中。（但是需要注意的是此插件需要html-webpack-plugin@^2.10.0。在webpack 4+之后，需要先注册AddAssetHtmlPlugin后才使用内部使用的钩子，而先前版本的webpack对此并不关心。HtmlWebpackPluginhtml-webpack-plugin-before-html-generation。）

但是我在操作的时候遇到一个很奇葩的坑，element-ui被dllPlugins之后，el-table不生效，是的不生效，页面也么有报错，样式都还存在，但是就是页面展示不出来table。

我看到element-ui的issues上也有人遇到这样的情况，但是现在还没有一个解决方案，很难受。

如果不能dll elemenet-ui，打包出来的index文件，还是很大的，怎么办。

所以我想到了一个办法就是，利用externals来处理element-ui（操作步骤如上），index有80%的大小是element-ui打包之后占据的。但是externals来处理却发现了另外一个问题。index.js打包的文件是小了很多但是，有一个相应的js文件的大小反而变的很大，这样操作得不偿失。

网上有很多解决办法，但是都没有根治我这个问题，最后的解决方案是，单独的使用table，项目重写table。这样的方法也有一个弊端，就是当前只是发现了table不能正常使用，但是如果还有其他组件不行，也需要重写，这样的成本就很好了。所以，最后项目选择是不打包element-ui（无奈之举）。期待这个问题被解决。

4. happypack-将laoder转换为多线程

webpack 是单线程的，就算此刻存在多个任务，你也只能排队一个接一个地等待处理。这是 webpack 的缺点，好在我们的 CPU 是多核的，Happypack 会充分释放 CPU 在多核并发方面的优势，帮我们把任务分解给多个子进程去并发执行，大大提升打包效率。

HappyPack 的使用方法也非常简单，只需要我们把对 loader 的配置转移到 HappyPack 中去就好，我们可以手动告诉 HappyPack 我们需要多少个并发的进程：

const HappyPack = require("happypack");
// 手动创建进程池
const happyThreadPool = HappyPack.ThreadPool({ size: os.cpus().length });
module.exports = {
    plugins: [
        new HappyPack({
            // 这个HappyPack的“名字”就叫做happyBabel，和楼上的查询参数遥相呼应
            id: 'happyBabel',
            // 指定进程池
            threadPool: happyThreadPool,
            // 输出日志
            verbose: true,
            loaders: ['babel-loader?cacheDirectory']
        }),
    ]
};

5. webpack-parallel-uglify-plugin替换uglifyjs-webpack-plugin

这个插件可以帮助具有许多入口点的项目加速构建。随Webpack提供的uglifyjs插件在每个输出文件上按顺序运行。这个插件与每个可用CPU的一个线程并行运行uglify。这可能会导致显著减少构建时间，因为最小化是CPU密集型的。简单点来说就是顺序运行改为并行，所以大大提升了构建速度。

// const UglifyJsPlugin = require('uglifyjs-webpack-plugin'); 
const ParallelUglifyPlugin = require('webpack-parallel-uglify-plugin');
module.exports = {
    plugins: [
        new ParallelUglifyPlugin({
            cacheDir: 'cache_dir',//用作缓存的可选绝对路径。如果未提供，则不使用缓存。
            sourceMap: config.build.productionSourceMap, //可选布尔值。是否为压缩后的代码生成对应的Source Map(浏览器可以在调试代码时定位到源码位置了),这会减慢编译速度。默认为false
            uglifyJS: { 
               output: { 
                   comments: false,//是否保留代码中的注释，默认为保留 
               }, 
               warnings: true,//是否在UglifyJS删除没有用到的代码时输出警告信息，默认为false 
               compress: { 
                   drop_console: true,//是否删除代码中所有的console语句，默认为false 
                   collapse_vars: true,//是否内嵌虽然已经定义了，但是只用到一次的变量， 默认值false 
                   reduce_vars: true,//是否提取出现了多次但是没有定义成变量去引用的静态值，默认为false 
               } 
            },
        })
    ]
};

6. 路由按需加载

作者优化这个项目之前，开发人员也是分组打包，但是是一个路由打包一个js文件，导致最后的结果就是，生产了60+的js文件，在进行批量发布时，哪速度叫一个感人，作者进行了一个简单的操作优化，就是根据名称分组打包，最后打包下来只有10+的js，并且我发现，60+文件打包的大小比10+文件的总体大小要大一些。哈哈哈，无意间发现的。

7. 多使用函数式编程

这个优化其实就是一个日常需要注意的问题，但是能间接的提升webpack的打包效率、打包大小的优化。

为什么？因为在webpack 2开始，是集成了tree-shaking。在Vue的3.0版本，有一个重大的改变就是Vue采用了函数式编程。函数式更方便tree-shaking（删除无用的方法，例如：100个方法，只使用了1个方法，打包的时候的时候只打包一个方法，删除没有使用的方法），在Vue2.0暴露出去的是一个类，不利于tree-shaking。在Vue3.0中，使用函数式，全部暴露的是函数，使用哪个函数就是import哪个函数，更方便tree-shaking。减少了代码体积。在简单项目中Vue的打包体积可以降低到10KB左右。

所以我们在日常的操作中多使用函数式编程，来提升webpack的打包效率和打包大小。

4、遗留问题

element-ui被dllPlugins之后，el-table不生效。求大神解决。项目依赖版本如下：