从Tree Shaking来走进Babel插件开发者的世界

2021-11-15 14:09:47 浏览数 (1)

引言

如果对Babel基础知识和插件开发不是很了解的同学，可以查看这篇文章「前端基建」带你在Babel的世界中畅游补充下Babel的基础知识哦~

作为前端开发者，无论是作为业务还是学习我相信大家都有一个属于自己的组件库。

这里，我们就从Tree Shaking的角度出发来谈谈如何为我们自己的组件库提供按需加载方式。

何谓Tree Shaking

简单聊聊什么是Tree Shaking

其实Tree Shaking的概念已经耳熟能详了，所谓的“摇树”就是说将我们代码中的没有用到的代码进行摇晃掉，从而减少包的体积。

我们来看一个简单的例子:

代码语言：javascript复制
// index.js 入口文件
import { funcHao } from './math'

funcHao()
复制代码
代码语言：javascript复制
// math.js
const funcWang = () => {
  const obj = {};
  return obj;
};

const funcHao = () => {
  console.log('hao');
};

export { funcWang, funcHao };


export {
  funcWang,
  funcHao
}
复制代码
代码语言：javascript复制
// webpack.config.js
const { resolve } = require('path');

module.exports = {
  mode: 'production',
  entry: resolve(__dirname, './src/index.js'),
  module: {
    rules: [
      {
        test: /.js$/,
        use: [
          {
            loader: 'babel-loader',
            options: {
              presets: ['@babel/preset-env'],
            },
          },
        ],
      },
    ],
  },
  output: {
    filename: '[name].js',
  },
};

复制代码

这里我们使用webpack新建了一个只有两个文件的项目。

  • src/index.js: 入口文件，导入math.js中的funcHao方法。
  • src/math.js: 导出两个方法funcHao和funcWang两个方法。

tip: 这里我们配置babel的原因不单单是为了转译箭头函数，稍微我在后边会讲述为什么这里为配置了一个babel-preset-env。

让我们运行webpack命令打包我们的代码:

代码语言：javascript复制
// dist/main.js
(()=>{"use strict";console.log("hao")})();
复制代码

我们会发现打包后的代码仅存在console.log("hao")，而funcWang这个函数的内容并没有被打包进入。

其实简单来说这就是所谓的Tree Shaking: 基于 ES Module 规范的 Dead Code Elimination 技术，它会在运行过程中静态分析模块之间的导入导出，确定 ESM 模块中哪些导出值未曾其它模块使用，并将其删除，以此实现打包产物的优化。

简单来说就是删除项目中没有使用到的代码从而达到优化代码的效果。

Tree Shaking工作原理

需要额外注意的是:

  • Tree Shaking是基于ESM模块基础进行处理的。

至于为什么Tree Shaking需要ESM模块才能使用呢? 让我们来一起看一看这个问题。

简单来说一段js代码的执行过程，需要经历以下三个步骤:

  • V8通过源码进行词法分析，语法分析生成AST和执行上下文。
  • 根据AST生成计算机可执行的字节码。
  • 执行生成的字节码。

在JS的执行过程中，ES Module**在第一步时就可以确认对应的依赖关系(编译阶段)**,并不需要执行就可以确认模块的导入、导出。

ES Module在js编译阶段就可以确定模块之间的依赖关系(import)以及模块的导出(export)，所以我们并不需要代码执行就可以根据ESM确定模块之间的规则从而实现Tree Shaking，我们称之为静态分析特性。

同理，对比commonjs模块，它依赖于代码的执行，需要在第三阶段执行完成代码之后才能确认模块的依赖关系。

自然也就不支持Tree Shaking。

关于ES Module中的动态引入dynamic import，因为它同样是动态需要js执行后才能确认的模块关系。自然也就无法支持Tree Shaking。

为什么我要配置babel-preset-env

上文讲到过我刻意配置了@babel/preset-env处理我们的代码，了解过它的同学可能会清楚。

@babel/preset-env是存在一个modules的配置参数，它的默认值是**auto**。

modules配置的含义是,在preset-env转译时中启用 ES 模块语法到另一种模块类型的转换。

也许你会在很多教程或者网站上看到，由于Tree Shaking必须基于Es Module模块。

所以如果我们项目中使用到babel-preset-env时需要将它的modules配置为false:相当于告诉babel，"嘿，Babel请保留我代码中的ESM模块规范"。

没错，你配置为false的确没有任何问题，可是上边我们的配置没有进行任何配置，默认值为**auto**的时候同样进行了**Tree Shaking**。

你有想过这是为什么吗？ 日常工作中我相信大部分同学使用preset-env结合业务时也没有刻意配置modules:false吧。

其实根本原因就出现在它的默认参数auto中。

配置为auto,默认情况下，@babel/preset-env使用caller数据来确定是否import()应转换ES 模块和模块功能（例如）。

关于如何理解这段话，比如: 如果我们使用Babel-Loader调用Babel，那么modules将设置为False，因为WebPack支持es模块。

关于auto参数更加详细的信息，你可以在这次commit中看到。

其实这里我配置preset-env的原因就是想和大家讲述一下关于modules:auto的含义,我相信还是有不少朋友对于modules:auto之前仍然是一知半解的状态。

实现组件库Tree Shaking思路

在讲述了何谓Tree Shaking之后，让我们真正来动手基于Babel来实现一个Tree Shaking插件吧！

组件库Tree Shaking历程

首先，在老版本的**webpack**中是不支持将代码编译成为**Es module**模块的，所有就会导致一些组件库编译后的代码无法使用Tree Shaking进行处理。(因为它编译出来的代码压根就不是ES Module呀！)

所以老版本组件库中，比如element-ui中借用babel-plugin-component，老版本ant-design使用babel-plugin-import进行分析代码从而实现Tree Shaking的效果。

关于这两个插件其实是类似的效果，我们会在之后重点讲述这部分内容。

细心的朋友可能也发现了，在目前的antd和element-plus中官网中提到已经能够完全的支持Tree Shaking功能了。

没错！这正是因为它的的代码现在打包后会额外打出一份ES Module的模块规范代码，在结合package.json中的module字段，可以不借助于任何插件在ES Module模块下完美的进行Tree-Shaking。

既生瑜，何讲亮？

也许有的同学会问到了，既然现在很多构建工具都支持打包ES Module规范，如此我们将组件库直接打包为ES Module规范不就可以了吗？为什么费事费力写这么一个babel插件去使用。

首先，之所以选择写这样一个Tree Shaking插件更多的原因是想让大家通过这样一个插件"管中窥豹"。在了解了Tree Shaking和组件库的发展历程之后，在结合之前业内的实践去学习Babel插件的开发流程。我个人看来这个插件是最适合入门且思路清晰的。

其次，我们的组件库的确可以打包成为Es Module形式直接支持Tree Shaking，但是难免有一些我们在业务中使用到的库打包生成的文件并不是基于ES Module规范的。

此时，如果我们使用到的这些库。不同的方式存放于独立的文件之中的话，我们完全可以基于我们自己开发的Tree Shaking插件在引入时候进行语句分析从而实现Tree Shaking的功能。

比如我们以为lodash为例子:

代码语言：javascript复制
import { cloneDeep } from 'lodash'

// ... 业务代码
复制代码

当你这样使用lodash时，由于打包出来的lodash并不是基于esm模块规范的。所以我们无法达到Tree Shaking的效果。

代码语言：javascript复制
import cloneDeep from 'lodash/cloneDeep'

// ... 业务代码
复制代码

此时，由于lodash中的cloneDeep方法存在的位置是一个独立的文件--lodash/cloneDeep文件。

当我们这样引入时，相当于仅仅引入了一个js文件而已。就可以显著的减少引入的体积从而删除无用的代码。

当然现阶段lodash已经提供了es标准的库，这里我们只是用它来举例从而让大家更好的理解而已。

Babel插件实现Tree Shaking的原理

其实上边针对于lodash的例子已经非常接近于插件所要实现的功能了。

在使用import引入特定的库方法时(非默认)，我们分析对应的import语句从而改写对应的import语句：引入对应的方法指向对应的独立文件就可以**Tree Shaking**的效果了。

当然也许有同学会好奇，我直接这样可以吗:

代码语言：javascript复制
import cloneDeep from 'lodash/cloneDeep'
import join from 'lodash/join'
import findLast from 'lodash/findLast'
// ....

复制代码

Emm...这样的确可以实现效果，不过嘛。作为一个合格的前端工程师怎么能写出这样冗余的代码呢。

代码语言：javascript复制
import { cloneDeep,join,findLast } from 'lodash'
复制代码

相比之下，这样岂不是更清爽嘛

babel.js es 编程算法 打包 lodash

0 人点赞