Chaoszhu'Blog

Appearance

webpack构建优化 ​

配置部分 ​

1、及时升级Node.js或webpack稳定版本，webpack4构建速度较webpack3提升了40%。(插件及其他内部模块升级)

2、在不必要的模块上不要使用loader,例如exclude:node_modules(或者include: path.resolve(__dirname, '../src'))

3、合理配置plugin，例如在dev环境下就没必要配置一些压缩代码的插件

4、合理配置resolve中的extensions【自动寻找扩展名】

5、控制包文件大小, 尽量使用ES module按需引入变量，做到Tree-Shaking最优化

进阶部分 ​

6、使用DllPlugin不再打包库文件(自带) ​

思路：把固定的库代码生成映射文件，通过配置webpack在项目中引入库文件时 不再去node_modules寻找和打包，而是直接使用已经打包好的库文件，这样就不用每次都打包库文件。

实现 ​

(1)、新增webpack配置文件(webpack.dll.js)，配置好生成库代码和映射文件的参数。webpack.dll.js

(2)、在webpack.base.js中使用add-asset-html-webpack-plugin将打包好的库文件引入到index.html中

js
new addAssetHtmlWebpackPlugin({
    filepath: path.resolve(__dirname, '../dll/dllPack.dll.js')
})

(3)、在webpack.base.js中使用webpack.DllPlugin声明配置文件，这样webpack打包就不会到node_modules中去打包库文件了。

js
new webpack.DllReferencePlugin({
    manifest: path.resolve(__dirname, '../dll/dllPack.manifest.json')
})

进一步提升编译速度(多进程) ​

就要知道瓶颈在哪？通过测试，发现有两个阶段较慢

1、babel 等 loaders 解析阶段.

2、 js 压缩阶段。loader 解析稍后会讨论，而 js 压缩是发布编译的最后阶段，通常webpack需要卡好一会，这是因为压缩 JS 需要先将代码解析成 AST 语法树，然后需要根据复杂的规则去分析和处理 AST，最后将 AST 还原成 JS，这个过程涉及到大量计算，因此比较耗时.

7、开启多进程打包 ​

7.1 happyPack可以开启多进程加速loader的解析阶段 ​

注意：项目越大效果越明显，项目较小可能反而会降低速度(进程开销)，所以这个插件应该按需使用。 ​

7.2 webpack-parallel-uglify-plugin可以开启多进程加速代码的压缩阶段【效果显著】 ​

支持配置是否删除注释、console语句的功能

js

new ParallelUglifyPlugin({
    uglifyJS: {
        output: {
            comments: true,//是否保留代码中的注释，默认为保留
        },
        warnings: true,//是否在UglifyJS删除没有用到的代码时输出警告信息，默认为false
        compress: {
            drop_console: true,//是否删除代码中所有的console语句，默认为false
        }
        },
        cacheDir: path.resolve(__dirname, '../.catch'),//用作缓存的可选绝对路径。如果未提供，则不使用缓存。
        sourceMap: false,//可选布尔值。是否为压缩后的代码生成对应的Source Map(浏览器可以在调试代码时定位到源码位置了),这会减慢编译速度。默认为false
})