从 Tree Shaking 来走进 Babel 插件开发者的世界
共 8891字,需浏览 18分钟
·
2021-11-17 22:28
点击上方 前端瓶子君,关注公众号
回复算法,加入前端编程面试算法每日一题群
引言
如果对Babel基础知识和插件开发不是很了解的同学,可以查看这篇文章「前端基建」带你在Babel的世界中畅游[2]补充下
Babel
的基础知识哦~
作为前端开发者,无论是作为业务还是学习我相信大家都有一个属于自己的组件库。
这里,我们就从Tree Shaking
的角度出发来谈谈如何为我们自己的组件库提供按需加载方式。
何谓Tree Shaking
简单聊聊什么是Tree Shaking
其实Tree Shaking
的概念已经耳熟能详了,所谓的“摇树”就是说将我们代码中的没有用到的代码进行摇晃掉,从而减少包的体积。
我们来看一个简单的例子:
// index.js 入口文件
import { funcHao } from './math'
funcHao()
复制代码
// math.js
const funcWang = () => {
const obj = {};
return obj;
};
const funcHao = () => {
console.log('hao');
};
export { funcWang, funcHao };
export {
funcWang,
funcHao
}
复制代码
// 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
命令打包我们的代码:
// 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`[3]数据来确定是否import()
应转换ES 模块和模块功能(例如)。
关于如何理解这段话,比如: 如果我们使用Babel-Loader
调用Babel
,那么modules
将设置为False
,因为WebPack
支持es
模块。
关于
auto
参数更加详细的信息,你可以在这次commit[4]中看到。
其实这里我配置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
为例子:
import { cloneDeep } from 'lodash'
// ... 业务代码
复制代码
当你这样使用lodash
时,由于打包出来的lodash
并不是基于esm
模块规范的。所以我们无法达到Tree Shaking
的效果。
import cloneDeep from 'lodash/cloneDeep'
// ... 业务代码
复制代码
此时,由于lodash
中的cloneDeep
方法存在的位置是一个独立的文件--lodash/cloneDeep
文件。
当我们这样引入时,相当于仅仅引入了一个js
文件而已。就可以显著的减少引入的体积从而删除无用的代码。
当然现阶段
lodash
已经提供了es
标准的库,这里我们只是用它来举例从而让大家更好的理解而已。
Babel
插件实现Tree Shaking
的原理
其实上边针对于lodash
的例子已经非常接近于插件所要实现的功能了。
在使用import
引入特定的库方法时(非默认),我们分析对应的import
语句从而改写对应的import
语句:引入对应的方法指向对应的独立文件就可以Tree Shaking
的效果了。
当然也许有同学会好奇,我直接这样可以吗:
import cloneDeep from 'lodash/cloneDeep'
import join from 'lodash/join'
import findLast from 'lodash/findLast'
// ....
复制代码
Emm...这样的确可以实现效果,不过嘛。作为一个合格的前端工程师怎么能写出这样冗余的代码呢。
import { cloneDeep,join,findLast } from 'lodash'
复制代码
相比之下,这样岂不是更清爽嘛😂。
实现Babel插件
需要使用到的Babel
包
文章中顶部链接已经贴出了一份详尽的Babel
配置指南和基础插件开发者指南了。这里我就简单提一下关于插件开发中使用到的babel
相关的tool package
:
@babel/core
: 核心babel
转译包,这里主要使用到它的transform
方法。babel/types
:babel
工具包,这里使用它来生成对应的AST
节点和调用对应检查节点API
。babel/handbook
:babel
插件开发者手册,这里[5]涵盖了babel
插件对应的流程和API
。
开发插件
讲了那么多原理,让我们在真正来到Coding
阶段吧!
// index.js
const core = require('@babel/core');
const babelPluginImport = require('./babel-plugin-import');
const sourceCode = `
import { Button, Alert } from 'hy-store';
`;
const parseCode = core.transform(sourceCode, {
plugins: [
babelPluginImport({
libraryName: 'hy-store',
}),
],
});
console.log(sourceCode, '输入的Code');
console.log(parseCode.code, '输出的结果');
复制代码
index.js
中我们首先建立一个测试文件。用来测试我们的插件。这里调用了我们写好的插件,并且输入了源代码import { Button, Alert } from 'hy-store';
。
我们希望的打印结果是:
同时我们的插件需要接受一个参数为libraryName
的参数。这个参数用来告诉我们的插件:仅针对于这个libraryName
的导入语句进行处理。
在搭建好基础的测试插件代码后,让我们来进入插件内部的逻辑:
Babel插件本质上就是一个对象中包含一个visitor
属性,从而针对visitor
属性上的key
进行深度遍历生成的AST
,匹配到对应visitor
上的key
时触发对应的方法从而进行对AST
节点的增删改查实现生成新的AST
->生成新的code
。
当然你也可以导出一个函数,函数返回这个对象。
让我们先来进行基础的插件结构开发:
const core = require('@babel/core');
const t = require('@babel/types');
function babelPluginImport(options) {
const { libraryName = 'hy-store' } = options;
return {
// babel插件就是基于`visitor`观察者模式
visitor: {
// do something
},
};
}
module.exports = babelPluginImport;
复制代码
接下下让我们打开--Astexplorer[6],输入我们的输入代码和输出代码:
我们首先来看看输入(需要分析)代码:
注意 1
位置我们选择编译器为@babel/parser
。同时我们在左侧输入我们的 source Code
。右侧就会动态生成对应的 AST
。
同样的操作让我们再来输入targetCode
(分析后生成的代码)来看一看吧:
看到这里的同学,我希望你停一停往下看,自己稍微对比下这两棵树的差距。在脑海中思考如果将source
中的Tree转化为target
中的Tree,需要怎么处理。
让我们稍微来捋一捋:
首先当我们碰到
ImportDeclaration
语句时,需要判断它的source
是否来自于我们的libararyName
这个库。当匹配引入我们的对应库时,我们还需要遍历当前
ImportDeclaration
节点中的specifiers
中是否包含默认导出ImportDefaultSpecifier
。当上述两个条件都满足时,进入我们之后的逻辑处理。
引入( import
)的是我们传入匹配的libraryName
。引入语句中不包含 import xx from libraryName
(默认导出语句)。我们需要遍历左侧
ImportDeclaration
中的specifiers
,将specifiers
中每一个导出语句修改成为对应独立文件路径的默认导出语句。
简单来说,一个Tree Shaking Babel Pluign
需要经历的就是上述四个步骤。
const t = require('@babel/types');
function babelPluginImport(options) {
const { libraryName = 'hy-store' } = options;
return {
visitor: {
// 匹配ImportDeclaration时进入
ImportDeclaration(nodePath) {
// checked Validity
if (checkedDefaultImport(nodePath) || checkedLibraryName(nodePath)) {
return;
}
const node = nodePath.node;
// 获取声明说明符
const { specifiers } = node;
// 遍历对应的声明符
const importDeclarations = specifiers.map((specifier, index) => {
// 获得原本导入的模块
const moduleName = specifier.imported.name;
// 获得导入时的重新命名
const localIdentifier = specifier.local;
return generateImportStatement(moduleName, localIdentifier);
});
if (importDeclarations.length === 1) {
// 如果仅仅只有一个语句时
nodePath.replaceWith(importDeclarations[0]);
} else {
// 多个声明替换
nodePath.replaceWithMultiple(importDeclarations);
}
},
},
};
// 检查导入是否是固定匹配库
function checkedLibraryName(nodePath) {
const { node } = nodePath;
return node.source.value !== libraryName;
}
// 检查语句是否存在默认导入
function checkedDefaultImport(nodePath) {
const { node } = nodePath;
const { specifiers } = node;
return specifiers.some((specifier) =>
t.isImportDefaultSpecifier(specifier)
);
}
// 生成导出语句 将每一个引入更换为一个新的单独路径默认导出的语句
function generateImportStatement(moduleName, localIdentifier) {
return t.importDeclaration(
[t.ImportDefaultSpecifier(localIdentifier)],
t.StringLiteral(`${libraryName}/${moduleName}`)
);
}
}
module.exports = babelPluginImport;
复制代码
至此,我们一个最基础的Tree Shaking Babel plugin
已经实现了。
你可以发现它仅仅只有60
行代码,但是麻雀虽小五脏俱全。针对于一个Babel
插件的开发流程以及核心思路我相信大家在熟练掌握了这个插件的开发思想后,针对于其他类似需求完全可以做到游刃有余。
接下来让我们运行一下我们最开始的代码:
大功告成!!
针对于这个Babel Plugin
其实还很很多可以优化的feature
。
比如
组件库中的
css/scss/less
等样式支持Tree Shaking
引入。组件库中路径支持动态参数传入。
...
这些细节我会在之后的commit
中进行依次完善,有兴趣的同学到可以在[这里看到它的代码地址]。(github.com/19Qingfeng/…[7])
写在结尾
至此,我们针对于Tree Shaking
结合Babel Plguin
的讲述到这里就完成了。
文章中的Plugin
的例子只是我个人觉得比较实用的一个易用简单讲解的🌰,更多的我还是希望的是大家在业务/工具中碰到一些棘手的问题时,不要忘记我们还可以从定制Babel Plugin
的角度去尝试思考解决问题的不同方式。
在之后的代码仓库[8]中我会扩展更多的Babel Learn Feature
去总结分享给每一个奋斗在前端路上的同学。
如果大家有什么疑问也可以在评论区互相交流,我会第一时间进行回复😂~
我的博客即将同步至腾讯云+社区,邀请大家一同入驻:cloud.tencent.com/developer/s…[9]
关于本文
来源:19组清风
https://juejin.cn/post/7028584587227824158