webpack实战——打包优化【下】

2020-10-27 本文已影响0人流眸Tel

前言

这是webpack打包优化【下】篇。前几篇针对性能要求高的项目从加快打包速度、减小资源体积方面入手，提出了一些优化政策，然后测试都可起到一定优化效果。本篇描述死代码的检测与去除。

tree shaking

1 死代码检测去除

首先抛出问题，什么是死代码？

工程中没有被引用过的模块，这部分代码将永远无法被执行，称为“死代码”。

那知道了什么是死代码，如何检测去除呢？

在前面我们介绍过，ES6 module 依赖关系的构建是在代码编译时而非运行时。基于这项特性webpack提供了tree shaking功能。这个功能便可以在打包过程中帮助我们检测没有被引用的模块，然后对这部分代码进行标记，并在资源压缩时将它们从最终的bundle中去掉。

例：

// index.js
import { foo } from './util';
foo();

// util.js
export function foo() {
    console.log('this is foo');
}
export function bar() { // 没有被任何其他模块引用，因此属于死代码
    console.log('this is bar');
}

那么在webpack打包时就会对bar()添加一个标记，在正常本地开发环境下它依然会存在，但是在生产环境压缩资源那一环节则会被移除掉。

tree shaking有时可以使得bundle资源体积显著减小，但需要一些前提条件。

2 ES6 Module

tree shaking 只对ES6 Module生效。 有时候我们发现算只引用了某个库中的一个接口，却把整个库都加载了进来，使得bundle体积并没有什么变化，可能原因是该库是用CommonJS导出的，而不是ES6 Module。当然，为了更好地向下兼容，自然是使用CommonJS形式是库依然很多。而排开第三方库，在我们自己书写模块或者库时，可以尽可能的选择ES6 Module形式导出，这样tree shaking的效率会更高。

3 使用webpack进行依赖关系构建

一般我们都会在工程中使用到babel-loader，如果我们有使用到，那么一定要通过禁止它的模块依赖解析。原因是如果我们使用babel-loader来做依赖解析，那么webpack接收到的一般都是转化过的CommonJS形式的模块，那就无法对其进行tree shaking。

禁用babel-loader模块依赖解析配置如下：

// webpack.config.js
module.exports = {
    ...
    module: {
        ryles: [
            {
                test: /\.js$/,
                exclude: /node_modules/,
                use: [
                    {
                        loader: 'babel-loader',
                        options: {
                            presets: [
                                // 在这里加上modules: false
                                [@babel/preset-env, { modules: false }]
                            ]
                        }
                    }
                ]
            }
        ]
    }
}

4. 使用压缩工具去除死代码

tree shaking本身只是为死代码添加上标记，而真正意义上去除死代码则是通过压缩工具来进行的，而此工具之前介绍过：terser-webpack-plugin。在此不再赘述。

小结

通过【上】【中】【下】三篇描述，介绍的一些打包优化的方案均可以对项目有不同程度的优化，无论是打包速度还是减小资源体积，都有涉及。然而我们更需要清楚地了解到每一种优化策略都有其使用场景，并不是任何一个点放在一切项目中都有效。

当然，我们更需要不断培养自己的能力，当发现性能问题时，根据现有情况自己多加思考，分析出原因，然后对症下药。

下一篇介绍更多的JavaScript打包工具。