webpack treeshking的三个要点

场景介绍

最近做一个需求的时候，想引入lodash来简化一些逻辑处理，我只用到了get、isArray等几个函数，但打包出的bundle却增加了69kb。说明webpack处理时把lodash整个都给打包进去了。

使用webpack-bundle-analyzer分析bundle的结果：

image

webpack从2.0开始加入了treeshking的功能，但是这里明显没有触发treesking。经过查阅文档和实践，解决了这个问题。

先看下成果：

image

treeshking的原理

webpack的treeshking是基于 es module的静态分析，能够在编译期间就确定哪些模块用到了哪些模块没用到，并且配合解构赋值还能确定哪些export用到了，哪些export没用到。然后对用到的部分和没用到的部分进行标记，在压缩阶段就可以删除标记出的没有用到的部分，从而达到treeshking的目的。

触发treeshking的三个要点

根据treeshking的原理，想要触发treesking需要满足3个条件：

1. 使用es module的模块规范、使用解构赋值

treeshking建立在es module静态分析的基础之上，所以代码必须使用esm的规范。业务代码一般都会使用esm，但是引入的第三方依赖就不一定了。比如lodash就是commonjs规范的，直接使用lodash是不会触发treeshking的，解决方案就是使用lodash的esm版本lodash-es。

package.json中的main字段是node package的入口，但是是commonjs规范的。想要使用treeshking的功能必须使用esm的入口，所以rollup（最早的treeshking实现）提出了module字段的提案，在这里配置es module的入口，这种约定虽然还没有成为规范，但已经被很多包所实现了。比如vue的package.json:

image

也有的包是esm规范的和commonsjs规范的分成了两个包，比如lodash和lodash-es。

总之，业务代码和第三方依赖都需要使用esm的规范。

然后引入的方式需要使用解构赋值的方式，

import { get } from 'lodash';

这种写法才可以在编译期间就能确定用到了哪些export，而

import _ from 'lodash';

这种写法无法在编译期间确定用到了哪部分，所以也无法进行treeshking。关于这点我做过测试，有兴趣的同学也可以试下。（分别使用两种引入方式，使用webpack-bundle-analyzer 分析打包出的bundle中lodash这个模块的大小）

2. 开启 optimization.usedExports

编译时可以分析出解构写法引入的esm模块，哪些export用到了，哪些模块没有用到。然后就需要分别进行标记，开启标记的配置项就是 optimization.usedExports 。

标记类似这样：

/* harmony export (immutable) */ __webpack_exports__["xxx"] = xxxx;

/* unused harmony export xxx */

unused harmony export标记的部分就是需要删掉的。

3. 使用压缩的插件

在编译期间对不同模块标记之后，在压缩时就可以删掉没用到的部分，任何一个压缩的plugin都可以做到这个。

其实上面的2、3两步，也就是开启optimization.usedExports和使用压缩的插件，在webpack4的mode设置为production时，已经默认开启了，所以开发者只需要关心业务代码和第三方包的模块规范是不是es module，以及有没有使用解构赋值的引入方式。

treeshking的其他注意事项

1. 有副作用的模块不能被treeshking

treeshking只是建立在某个es module的某一些export有没有被用到的基础上的，但是有一些代码会有副作用，比如在window上挂一个变量、写本地文件等，这种代码虽然没有export一些内容，但也是不能被treeshking掉的。对于这些文件需要过滤掉，配置的方式就是在package.json中添加sideEffects字段，因为webpack的模块包括图片、字体文件、css文件等，这些模块都是需要配置的。

2. treeshking只能做到export级别

如果一些模块导出了一个对象，用到这个模块的地方只使用了某几个方法，其余的方式是不能被treeshking的。原因也是因为编译期间的静态分析只能对es module的相关语法做分析，是不会真正去执行代码的。

所以为了更好的配合treeshking，能够写成分散的export的就不要封装成对象，这样能够配置treeshking打包成最小的bundle。

总结

treeshking是减小打包的bundle size很重要的一个手段，但触发treeshking是有条件的，首先需要代码是es module规范的并且使用解构赋值的方式引入，第二要开始optimization.usedExports来标记使用和未使用的模块，第三是使用压缩的插件进行删除未使用代码。 webpack4的mode设置为production之后，我们只需要关心第一点就好了。

treeshking是有限制的，副作用的代码不能treeshking，只能对export进行treeshking。

了解了treeshking的原理和触发条件，以及treeshking的限制，我们才能针对性的优化代码来达到最小的bundle size。当然达到最优可能还需要结合code spliting等其他方式。