Babel babel/plugin-transform-typeof-symbol 源码深潜让旧环境的 typeof 也能识别 “symbol”【免费下载链接】babel Babel is a compiler for writing next generation JavaScript.项目地址: https://gitcode.com/gh_mirrors/ba/babel本文以 Babel 单仓中的 packages/babel-plugin-transform-typeof-symbol 包为核心先完整交代该插件的定位与安装方式再逐行剖析 src/index.ts 中的转换逻辑与babel/helpers里_typeof辅助函数的双分支实现最后用仓库自带的测试 fixture 与回归测试展示插件在哪些情况下“必须转换”、哪些情况下“必须跳过”。读完本文你可以讲清为什么编译到 ES5 时代需要 typeof 帮助函数并能独立验证该插件的变换行为是否符合预期。一、插件要解决的问题旧环境中 typeof 对 Symbol 的盲区包的 README 对功能只有一句话概括见 README.mdThis transformer wraps all typeof expressions with a method that replicates native behaviour. (ie. returning “symbol” for symbols)本转换器会用一个方法包裹所有 typeof 表达式以复刻原生行为——即对 symbol 返回 “symbol”。问题的根源在于在原生支持 Symbol 的引擎里typeof sym返回symbol但在 ES5 时代的环境或只 polyfill 了Symbol构造器而没有引擎级支持的环境中同一个 symbol 值的typeof结果往往是object。packages/babel-helpers/src/helpers/typeof.ts 中的回退分支正是为此而写的_typeof function (obj) { return obj typeof Symbol function obj.constructor Symbol obj ! Symbol.prototype ? symbol : typeof obj; };它通过obj.constructor Symbol识别出 polyfill 出来的 symbol并排除Symbol.prototype本身原生的typeof Symbol.prototype是object见 test/fixtures/symbols/typeof/exec.js 中的断言expect(typeof Symbol.prototype).toBe(object)。该插件要做的事情就是把这些判断收敛到一个帮助函数里把源码中所有的typeof表达式统一替换为对该帮助函数的调用从而在目标环境缺失原生行为时得到与原生一致的symbol结果。二、安装与启用README 核心内容按照 README.md 给出的方式安装# npm npm install --save-dev babel/plugin-transform-typeof-symbol# yarn yarn add babel/plugin-transform-typeof-symbol --dev在 Babel 配置中通过插件短名启用。仓库测试 fixture 的 options.json 展示的就是这一最小配置{ plugins: [transform-typeof-symbol] }结合 package.json 可以看到该插件的适用前提以当前仓库为准版本 8.0.1peerDependencies要求babel/core: ^8.0.0插件本体只依赖babel/helper-plugin-utilsenginesnode ^22.18.0 || 24.11.0指仓库内开发/构建该插件所需的 Node 版本不是产物运行要求main指向./lib/index.jsexports中同时提供types: ./lib/index.d.ts。该插件没有提供任何用户可配置选项——从源码看下文第三节它的所有行为都是硬编码的启发式规则。三、源码剖析两个 visitor 构成全部变换逻辑packages/babel-plugin-transform-typeof-symbol/src/index.ts 全文仅 75 行结构如下export default declare(api { api.assertVersion(REQUIRED_VERSION(^7.0.0-0 || ^8.0.0)); return { name: transform-typeof-symbol, visitor: { Scope({ scope }) { /* 处理 Symbol 影子变量 */ }, UnaryExpression(path) { /* 处理 typeof 表达式 */ }, }, }; });插件通过declare(api ...)工厂声明并用api.assertVersion断言自身兼容^7.0.0-0 || ^8.0.0的 Babel 核心版本src/index.ts#L4-L5。真正的逻辑分布在两个 visitor 中。3.1 Scope visitor重命名对 Symbol 的局部遮蔽src/index.ts#L11-L17Scope({ scope }) { if (!scope.getBinding(Symbol)) { return; } scope.rename(Symbol); },如果当前作用域中存在名为Symbol的本地绑定插件会把该绑定重命名如Symbol→_Symbol防止用户变量遮蔽全局Symbol——因为帮助函数内部依赖obj.constructor Symbol这一判断一旦Symbol被局部变量顶掉整个识别逻辑就会失真。fixture shadow/input.js 展示了这一行为// 输入 var Symbol foo(); typeof s; foo(Symbol);// 输出 var _Symbol foo(); typeof s undefined ? undefined : babelHelpers.typeof(s); foo(_Symbol);可以看到Symbol被重命名为_Symbol同时typeof s也被包裹s是未声明的标识符见 3.2 节的 undefined 守卫。3.2 UnaryExpression visitor每个 typeof 的四步决策src/index.ts#L19-L72 是插件的主体对每个typeof一元表达式依次做如下判断第 1 步跳过不可能命中 symbol 的等值比较。当typeof处于二元表达式中、父节点是比较运算符时if ( path.parentPath.isBinaryExpression() t.EQUALITY_BINARY_OPERATORS.includes((parent as t.BinaryExpression).operator) ) { // optimise typeof foo string since we can determine that theyll never // need to handle symbols const opposite path.getOpposite()!; if ( opposite.isStringLiteral() opposite.node.value ! symbol opposite.node.value ! object ) { return; } }源码注释解释得很直白typeof foo string这类比较“永远不需要处理 symbol”因此直接跳过、保持原生typeof不动。注意右值被特意排除了symbol和object前者显然需要帮助函数才能命中后者则是从源码结构看的关键细节——在 ES5 环境里 polyfill symbol 的typeof恰好是object如果跳过typeof x object比较结果会与原生环境产生偏差所以必须转换。fixture arrow/input.js 正好演示了这种混合情况// 输入 const isPrimitive (value) (value null || (typeof value ! object typeof value ! function)); // 输出 const isPrimitive value value null || babelHelpers.typeof(value) ! object typeof value ! function;! object被转换为babelHelpers.typeof(value) ! object而! function保持原样。第 2 步跳过帮助函数自身内部的 typeof。插件会向上查找是否存在带有babel/helpers - typeof指令directive的函数声明src/index.ts#L41-L51若有则直接返回const isUnderHelper path.findParent(path { if (path.isFunctionDeclaration()) { return path.get(body.directives.0)?.node.value.value babel/helpers - typeof; } return false; }); if (isUnderHelper) return;这一检查保证即使babel/helpers生成的帮助函数代码再次经过 Babel 处理其内部的typeof Symbol function等表达式也不会被二次包裹避免了递归改写。仓库用 test/helper.spec.js 对此做了专门的回归验证见第五节。第 3 步对未声明标识符加 undefined 守卫。通过this.addHelper(typeof)注入帮助函数后插件检查typeof的操作数是否为“在全局中也没有绑定”的标识符src/index.ts#L58-L71const call t.callExpression(helper, [node.argument]); const arg path.get(argument); if (arg.isIdentifier() !path.scope.hasBinding(arg.node.name, true)) { const unary t.unaryExpression(typeof, t.cloneNode(node.argument)); path.replaceWith( t.conditionalExpression( t.binaryExpression(, unary, t.stringLiteral(undefined)), t.stringLiteral(undefined), call, ), ); } else { path.replaceWith(call); }之所以要加守卫是因为原生typeof undeclaredVar安全地返回undefined而babelHelpers.typeof(undeclaredVar)会抛出ReferenceError。因此对“可能根本不存在”的自由变量输出形如typeof o undefined ? undefined : babelHelpers.typeof(o)的三元表达式保留原生语义。源码中该分支还带有一句注释说明这个结构是为了与babel/helpers 7.8.3的向后兼容// This is needed for backward compatibility with babel/helpers 7.8.3.第 4 步其余情况直接包裹。当操作数不是“无绑定的标识符”例如成员表达式o.foo、对象字面量{}直接替换为babelHelpers.typeof(...)无需 undefined 守卫——因为o.foo在o存在时不会抛错、o不存在时的错误行为与原生一致{}更是必然可求值。四种输入形态的转换对照全部取自 test/fixtures/symbols 目录输入输出fixturetypeof ss已声明babelHelpers.typeof(s)typeoftypeof oo未声明typeof o undefined ? undefined : babelHelpers.typeof(o)typeoftypeof o.foobabelHelpers.typeof(babelHelpers.typeof(o.foo))嵌套同样逐层包裹typeoftypeof {}babelHelpers.typeof({})default-exporttypeof s string原样保留第 1 步优化typeoftypeof Reflect objecttypeof Reflect undefined ? undefined : babelHelpers.typeof(Reflect) object右值为object不可跳过builtin-global四、_typeof帮助函数一次探测终身缓存插件注入的调用最终落到babel/helpers导出的typeof帮助函数上实现在 packages/babel-helpers/src/helpers/typeof.tsexport default function _typeof(obj: unknown): | string | number | bigint | boolean | symbol | undefined | object | function { babel/helpers - typeof; // ← 即 3.2 节第 2 步识别的 directive if (typeof Symbol function typeof Symbol.iterator symbol) { _typeof function (obj: unknown) { return typeof obj; }; } else { _typeof function (obj: unknown) { return obj typeof Symbol function obj.constructor Symbol obj ! Symbol.prototype ? symbol : typeof obj; }; } return _typeof(obj); }实现上有两个值得注意的设计双分支探测typeof.ts#L16-L31首次调用时判断运行时是否具备“真 Symbol”typeof Symbol function typeof Symbol.iterator symbol。若具备则直接把函数体替换为一行return typeof obj——完全零开销地走原生路径若不具备则替换为 3.1 节描述过的构造器判定逻辑。自替换缓存探测结果通过重新赋值_typeof本身固化下来后续调用不再执行任何探测分支。这是典型的“self-caching”技巧把环境探测的成本限制在首次调用的一次之内。函数体首行的字符串字面量babel/helpers - typeof会成为 AST 中的 directive这正是插件在 3.2 节第 2 步中用来“认出帮助函数自身”的标记。五、测试如何验证这套行为该包的测试分为两层fixture 驱动测试。test/index.js 仅两行委托给babel/helper-plugin-test-runnerimport runner from babel/helper-plugin-test-runner; runner(import.meta.url);它会对 test/fixtures/symbols 下的每组 fixture 比对“实际输出”与output.*文件的期望输出并执行exec.js做运行时断言。六个 fixture 目录各司其职typeof核心场景覆盖已声明变量、未声明变量、嵌套typeof typeof x、 string跳过其 exec.js 在真实 Node 环境断言typeof s为symbol、typeof o为undefined、typeof Symbol.prototype为objectshadow验证Symbol局部遮蔽时的重命名arrow验证object不可跳过而function可跳过的差异non-typeof负例确保不含typeof的代码原样通过除格式化外输出不变builtin-global验证对Reflect这类内置全局的 undefined 守卫default-export验证模块顶层与typeof {}字面量场景。帮助函数回归测试。test/helper.spec.js 针对第 2 步的“不重复包裹”行为以 4 种组合babel/runtime/babel/runtime-corejs3× esm / cjs加载已发布的helpers/typeof模块源码分别用“带插件”与“不带插件”两种方式转译断言两者输出逐字节一致const withPlugin babel.transformFromAstSync(ast, src, { configFile: false, plugins: [transformTypeofSymbol], }); const withoutPlugin babel.transformFromAstSync(ast, src, { configFile: false }); expect(withPlugin.code).toBe(withoutPlugin.code);这条测试从消费侧保证了babel/runtime里打包好的typeof帮助函数即使再次进入 Babel 流水线也不会被破坏与 src/index.ts#L41-L51 的 directive 检测逻辑形成闭环。六、小结与适用前提babel/plugin-transform-typeof-symbol的价值可以用一句话概括以最小的运行时成本一个自缓存的帮助函数把“typeof 能否正确报出 symbol”这一环境差异从用户代码中剥离出去。实现上的三个关键取舍——跳过symbol/object之外的等值比较、对未声明标识符保留typeof语义的 undefined 守卫、以及对自身帮助函数的免重复包裹——都直接服务于“转换后的代码在任意环境下的可观察行为与原生一致”这一目标并分别由 test/fixtures/symbols 与 test/helper.spec.js 中的 fixture 和回归测试锁定。适用前提方面需要注意该插件服务于目标环境不具备原生 Symbol 语义或混用了 Symbol polyfill的场景从当前仓库的 package.json 看插件版本为 8.0.1、以babel/core ^8.0.0为 peer 依赖且不提供任何可配置选项。若目标环境已完整支持原生 Symboltypeof本身即可正确返回symbol无需引入本插件。【免费下载链接】babel Babel is a compiler for writing next generation JavaScript.项目地址: https://gitcode.com/gh_mirrors/ba/babel创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Babel @babel/plugin-transform-typeof-symbol 源码深潜：让旧环境的 typeof 也能识别 “symbol”
Babel babel/plugin-transform-typeof-symbol 源码深潜让旧环境的 typeof 也能识别 “symbol”【免费下载链接】babel Babel is a compiler for writing next generation JavaScript.项目地址: https://gitcode.com/gh_mirrors/ba/babel本文以 Babel 单仓中的 packages/babel-plugin-transform-typeof-symbol 包为核心先完整交代该插件的定位与安装方式再逐行剖析 src/index.ts 中的转换逻辑与babel/helpers里_typeof辅助函数的双分支实现最后用仓库自带的测试 fixture 与回归测试展示插件在哪些情况下“必须转换”、哪些情况下“必须跳过”。读完本文你可以讲清为什么编译到 ES5 时代需要 typeof 帮助函数并能独立验证该插件的变换行为是否符合预期。一、插件要解决的问题旧环境中 typeof 对 Symbol 的盲区包的 README 对功能只有一句话概括见 README.mdThis transformer wraps all typeof expressions with a method that replicates native behaviour. (ie. returning “symbol” for symbols)本转换器会用一个方法包裹所有 typeof 表达式以复刻原生行为——即对 symbol 返回 “symbol”。问题的根源在于在原生支持 Symbol 的引擎里typeof sym返回symbol但在 ES5 时代的环境或只 polyfill 了Symbol构造器而没有引擎级支持的环境中同一个 symbol 值的typeof结果往往是object。packages/babel-helpers/src/helpers/typeof.ts 中的回退分支正是为此而写的_typeof function (obj) { return obj typeof Symbol function obj.constructor Symbol obj ! Symbol.prototype ? symbol : typeof obj; };它通过obj.constructor Symbol识别出 polyfill 出来的 symbol并排除Symbol.prototype本身原生的typeof Symbol.prototype是object见 test/fixtures/symbols/typeof/exec.js 中的断言expect(typeof Symbol.prototype).toBe(object)。该插件要做的事情就是把这些判断收敛到一个帮助函数里把源码中所有的typeof表达式统一替换为对该帮助函数的调用从而在目标环境缺失原生行为时得到与原生一致的symbol结果。二、安装与启用README 核心内容按照 README.md 给出的方式安装# npm npm install --save-dev babel/plugin-transform-typeof-symbol# yarn yarn add babel/plugin-transform-typeof-symbol --dev在 Babel 配置中通过插件短名启用。仓库测试 fixture 的 options.json 展示的就是这一最小配置{ plugins: [transform-typeof-symbol] }结合 package.json 可以看到该插件的适用前提以当前仓库为准版本 8.0.1peerDependencies要求babel/core: ^8.0.0插件本体只依赖babel/helper-plugin-utilsenginesnode ^22.18.0 || 24.11.0指仓库内开发/构建该插件所需的 Node 版本不是产物运行要求main指向./lib/index.jsexports中同时提供types: ./lib/index.d.ts。该插件没有提供任何用户可配置选项——从源码看下文第三节它的所有行为都是硬编码的启发式规则。三、源码剖析两个 visitor 构成全部变换逻辑packages/babel-plugin-transform-typeof-symbol/src/index.ts 全文仅 75 行结构如下export default declare(api { api.assertVersion(REQUIRED_VERSION(^7.0.0-0 || ^8.0.0)); return { name: transform-typeof-symbol, visitor: { Scope({ scope }) { /* 处理 Symbol 影子变量 */ }, UnaryExpression(path) { /* 处理 typeof 表达式 */ }, }, }; });插件通过declare(api ...)工厂声明并用api.assertVersion断言自身兼容^7.0.0-0 || ^8.0.0的 Babel 核心版本src/index.ts#L4-L5。真正的逻辑分布在两个 visitor 中。3.1 Scope visitor重命名对 Symbol 的局部遮蔽src/index.ts#L11-L17Scope({ scope }) { if (!scope.getBinding(Symbol)) { return; } scope.rename(Symbol); },如果当前作用域中存在名为Symbol的本地绑定插件会把该绑定重命名如Symbol→_Symbol防止用户变量遮蔽全局Symbol——因为帮助函数内部依赖obj.constructor Symbol这一判断一旦Symbol被局部变量顶掉整个识别逻辑就会失真。fixture shadow/input.js 展示了这一行为// 输入 var Symbol foo(); typeof s; foo(Symbol);// 输出 var _Symbol foo(); typeof s undefined ? undefined : babelHelpers.typeof(s); foo(_Symbol);可以看到Symbol被重命名为_Symbol同时typeof s也被包裹s是未声明的标识符见 3.2 节的 undefined 守卫。3.2 UnaryExpression visitor每个 typeof 的四步决策src/index.ts#L19-L72 是插件的主体对每个typeof一元表达式依次做如下判断第 1 步跳过不可能命中 symbol 的等值比较。当typeof处于二元表达式中、父节点是比较运算符时if ( path.parentPath.isBinaryExpression() t.EQUALITY_BINARY_OPERATORS.includes((parent as t.BinaryExpression).operator) ) { // optimise typeof foo string since we can determine that theyll never // need to handle symbols const opposite path.getOpposite()!; if ( opposite.isStringLiteral() opposite.node.value ! symbol opposite.node.value ! object ) { return; } }源码注释解释得很直白typeof foo string这类比较“永远不需要处理 symbol”因此直接跳过、保持原生typeof不动。注意右值被特意排除了symbol和object前者显然需要帮助函数才能命中后者则是从源码结构看的关键细节——在 ES5 环境里 polyfill symbol 的typeof恰好是object如果跳过typeof x object比较结果会与原生环境产生偏差所以必须转换。fixture arrow/input.js 正好演示了这种混合情况// 输入 const isPrimitive (value) (value null || (typeof value ! object typeof value ! function)); // 输出 const isPrimitive value value null || babelHelpers.typeof(value) ! object typeof value ! function;! object被转换为babelHelpers.typeof(value) ! object而! function保持原样。第 2 步跳过帮助函数自身内部的 typeof。插件会向上查找是否存在带有babel/helpers - typeof指令directive的函数声明src/index.ts#L41-L51若有则直接返回const isUnderHelper path.findParent(path { if (path.isFunctionDeclaration()) { return path.get(body.directives.0)?.node.value.value babel/helpers - typeof; } return false; }); if (isUnderHelper) return;这一检查保证即使babel/helpers生成的帮助函数代码再次经过 Babel 处理其内部的typeof Symbol function等表达式也不会被二次包裹避免了递归改写。仓库用 test/helper.spec.js 对此做了专门的回归验证见第五节。第 3 步对未声明标识符加 undefined 守卫。通过this.addHelper(typeof)注入帮助函数后插件检查typeof的操作数是否为“在全局中也没有绑定”的标识符src/index.ts#L58-L71const call t.callExpression(helper, [node.argument]); const arg path.get(argument); if (arg.isIdentifier() !path.scope.hasBinding(arg.node.name, true)) { const unary t.unaryExpression(typeof, t.cloneNode(node.argument)); path.replaceWith( t.conditionalExpression( t.binaryExpression(, unary, t.stringLiteral(undefined)), t.stringLiteral(undefined), call, ), ); } else { path.replaceWith(call); }之所以要加守卫是因为原生typeof undeclaredVar安全地返回undefined而babelHelpers.typeof(undeclaredVar)会抛出ReferenceError。因此对“可能根本不存在”的自由变量输出形如typeof o undefined ? undefined : babelHelpers.typeof(o)的三元表达式保留原生语义。源码中该分支还带有一句注释说明这个结构是为了与babel/helpers 7.8.3的向后兼容// This is needed for backward compatibility with babel/helpers 7.8.3.第 4 步其余情况直接包裹。当操作数不是“无绑定的标识符”例如成员表达式o.foo、对象字面量{}直接替换为babelHelpers.typeof(...)无需 undefined 守卫——因为o.foo在o存在时不会抛错、o不存在时的错误行为与原生一致{}更是必然可求值。四种输入形态的转换对照全部取自 test/fixtures/symbols 目录输入输出fixturetypeof ss已声明babelHelpers.typeof(s)typeoftypeof oo未声明typeof o undefined ? undefined : babelHelpers.typeof(o)typeoftypeof o.foobabelHelpers.typeof(babelHelpers.typeof(o.foo))嵌套同样逐层包裹typeoftypeof {}babelHelpers.typeof({})default-exporttypeof s string原样保留第 1 步优化typeoftypeof Reflect objecttypeof Reflect undefined ? undefined : babelHelpers.typeof(Reflect) object右值为object不可跳过builtin-global四、_typeof帮助函数一次探测终身缓存插件注入的调用最终落到babel/helpers导出的typeof帮助函数上实现在 packages/babel-helpers/src/helpers/typeof.tsexport default function _typeof(obj: unknown): | string | number | bigint | boolean | symbol | undefined | object | function { babel/helpers - typeof; // ← 即 3.2 节第 2 步识别的 directive if (typeof Symbol function typeof Symbol.iterator symbol) { _typeof function (obj: unknown) { return typeof obj; }; } else { _typeof function (obj: unknown) { return obj typeof Symbol function obj.constructor Symbol obj ! Symbol.prototype ? symbol : typeof obj; }; } return _typeof(obj); }实现上有两个值得注意的设计双分支探测typeof.ts#L16-L31首次调用时判断运行时是否具备“真 Symbol”typeof Symbol function typeof Symbol.iterator symbol。若具备则直接把函数体替换为一行return typeof obj——完全零开销地走原生路径若不具备则替换为 3.1 节描述过的构造器判定逻辑。自替换缓存探测结果通过重新赋值_typeof本身固化下来后续调用不再执行任何探测分支。这是典型的“self-caching”技巧把环境探测的成本限制在首次调用的一次之内。函数体首行的字符串字面量babel/helpers - typeof会成为 AST 中的 directive这正是插件在 3.2 节第 2 步中用来“认出帮助函数自身”的标记。五、测试如何验证这套行为该包的测试分为两层fixture 驱动测试。test/index.js 仅两行委托给babel/helper-plugin-test-runnerimport runner from babel/helper-plugin-test-runner; runner(import.meta.url);它会对 test/fixtures/symbols 下的每组 fixture 比对“实际输出”与output.*文件的期望输出并执行exec.js做运行时断言。六个 fixture 目录各司其职typeof核心场景覆盖已声明变量、未声明变量、嵌套typeof typeof x、 string跳过其 exec.js 在真实 Node 环境断言typeof s为symbol、typeof o为undefined、typeof Symbol.prototype为objectshadow验证Symbol局部遮蔽时的重命名arrow验证object不可跳过而function可跳过的差异non-typeof负例确保不含typeof的代码原样通过除格式化外输出不变builtin-global验证对Reflect这类内置全局的 undefined 守卫default-export验证模块顶层与typeof {}字面量场景。帮助函数回归测试。test/helper.spec.js 针对第 2 步的“不重复包裹”行为以 4 种组合babel/runtime/babel/runtime-corejs3× esm / cjs加载已发布的helpers/typeof模块源码分别用“带插件”与“不带插件”两种方式转译断言两者输出逐字节一致const withPlugin babel.transformFromAstSync(ast, src, { configFile: false, plugins: [transformTypeofSymbol], }); const withoutPlugin babel.transformFromAstSync(ast, src, { configFile: false }); expect(withPlugin.code).toBe(withoutPlugin.code);这条测试从消费侧保证了babel/runtime里打包好的typeof帮助函数即使再次进入 Babel 流水线也不会被破坏与 src/index.ts#L41-L51 的 directive 检测逻辑形成闭环。六、小结与适用前提babel/plugin-transform-typeof-symbol的价值可以用一句话概括以最小的运行时成本一个自缓存的帮助函数把“typeof 能否正确报出 symbol”这一环境差异从用户代码中剥离出去。实现上的三个关键取舍——跳过symbol/object之外的等值比较、对未声明标识符保留typeof语义的 undefined 守卫、以及对自身帮助函数的免重复包裹——都直接服务于“转换后的代码在任意环境下的可观察行为与原生一致”这一目标并分别由 test/fixtures/symbols 与 test/helper.spec.js 中的 fixture 和回归测试锁定。适用前提方面需要注意该插件服务于目标环境不具备原生 Symbol 语义或混用了 Symbol polyfill的场景从当前仓库的 package.json 看插件版本为 8.0.1、以babel/core ^8.0.0为 peer 依赖且不提供任何可配置选项。若目标环境已完整支持原生 Symboltypeof本身即可正确返回symbol无需引入本插件。【免费下载链接】babel Babel is a compiler for writing next generation JavaScript.项目地址: https://gitcode.com/gh_mirrors/ba/babel创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考