跳至主内容

Babel 发展路线图

非官方测试版翻译

本页面由 PageTurner AI 翻译（测试版）。未经项目官方认可。 发现错误？ 报告问题 →

本文概述了团队成员计划在本年度推进的若干改进方向。

尽管这远非 Babel 将引入的所有新特性或重要变更的完整清单，但若您关注项目的整体发展方向，本文提供了极佳的概览。我们可能无法实际完成所有列出的目标，或将部分目标推迟至下一年度。其中某些事项有明确的起止节点，而另一些则需要进一步研究或通过RFC流程推进。

如果贵公司有意向直接赞助特定项目，请联系我们！

Babel 2021 发展路线图​

Babel 8​

我们讨论 Babel 8 版本发布已逾一年（最初计划发布于约一年前）！但当前我们已比以往任何时候都更接近其正式发布！

剩余任务大多记录在跟踪工单中，目前仍存在若干关键阻碍：

  • 计划放弃对Node.js 10的支持（该版本将于2021年4月30日终止维护）

  • 拟将 Babel 发布为纯 ESM 包。我们正在转换源码以兼容 Node.js 的 ESM 实现，并同步研究如何优化当前用户使用 Babel 编译 ESM 转 CJS 的体验

  • 正尝试将 TypeScript AST 与typescript-eslint项目对齐。我们的AST结构已基本一致，但需引入少量破坏性变更以实现完全兼容

  • 当前发布基础设施尚不支持预发布版本或多"主分支"并行（即同时维护 Babel 8 和 Babel 7 分支）

  • 尚未制定 Babel 7 的长期维护策略

实现新 TC39 提案​

当前 Babel 可解析所有 Stage 3 提案，除顶层 await、import 断言和 JSON 模块（这些特性更适合由处理依赖图的打包器实现）外均可转换

我们支持所有 Stage 2 提案，但以下除外：

  • 装饰器提案的新迭代版本（需实现解析与转换功能）

  • 模块块提案的转换功能（已在 Babel 7.13.0 实现解析）

我们将实现装饰器支持，并研究为模块块实现转换功能的可行性方案

虽然我们支持 Stage 1 提案的数量有限，但管道操作符和 do 表达式提案近期有重要更新。鉴于社区对这些提案热情高涨且我们已有基础实现，我们将同步更新相关功能

另有部分提案（如模式匹配）因主导者预计将对语法语义进行重大调整而尚未实现。但我们正密切关注其进展，待其趋于稳定后将立即在 Babel 中实现

将 @babel/preset-env 整合至 @babel/core​

最简 Babel 转换环境至少需要三个包：

  • @babel/core

  • @babel/preset-env

  • Babel "运行器"（如 @babel/cli、babel-loader、@rollup/plugin-babel 等）

将 @babel/preset-env 直接整合至 @babel/core 有两大优势：

  • 在简单项目中配置 Babel 将更加便捷，只需在 babel.config.json 中启用 compileJS: true 选项（未来甚至可能成为默认行为——目前无法默认启用，因为 @babel/eslint-parser 不会编译源代码）

  • 确保插件版本与 @babel/core 版本同步，避免因包版本不匹配/不兼容导致的大部分错误

  • 迁移到 ESM 后，在 transformSync 中同步解析和加载插件将变得困难。此举可从根本上规避该问题

当前已有一份 RFC提议将稳定版 ECMAScript 特性的_插件_移入 @babel/core，这是实现该目标的第一步

在现有 @babel/preset-env 架构下，我们需要特殊处理官方插件，根据 targets 自动启用或禁用它们 但这存在两个缺陷：

  • 特定插件的兼容性数据与插件实现完全分离（甚至不存在依赖关系，更像是内部隐式对等依赖：plugin -> @babel/core -> @babel/compat-data）

  • 官方插件会获得 @babel/core 的特殊对待，但我们希望确保第三方插件能拥有与官方插件同等的能力

持续推进 babel-polyfills 项目开发​

我们已决定在 Babel 8 中移除 @babel/preset-env 对旧版 core-js@2 的支持。同时希望停止推广特定第三方 polyfill，避免用户误以为它是 Babel 的组成部分

具体可能通过两种方式实现：

  • 直接在 Babel 8 的 @babel/preset-env 中移除 core-js@3 支持，引导用户迁移至 babel-plugin-polyfill-corejs3（该插件自 7.10.0 版本起已被 @babel/preset-env 内部使用）

  • 保留 @babel/preset-env 对 core-js@3 的支持，但在迁移转换插件时不将其移至 @babel/core

无论采用哪种方案，我们都希望在用户需要更新 core-js 集成配置时提供至少一种替代方案。core-js 虽是确保最高规范兼容性的优质 polyfill，但用户可能倾向不同的取舍方案

(Nicolò) 正与 @ljharb 合作，确保 @es-shims 项目至少支持所有 ES2015+ 特性（实际目标是 ES5+），让 Babel 用户能自由选择至少两种方案

这必须在停止内置支持 core-js@3 _之前_完成，避免关注 es-shims 的用户需要二次迁移

扩展 targets 在精细化转换中的应用​

自诞生之初，@babel/preset-env 就通过 targets 选项自动启用或禁用转换插件

但 Babel 插件与浏览器实现的功能并非一一对应

例如我们为不同类型类字段（公有/私有、静态/实例）提供单一插件，但浏览器的兼容性矩阵各不相同：

  • Firefox 73 和 Safari 14 仅支持公有实例字段

  • Firefox 75+ 支持公有实例字段和静态字段

  • Chrome 79+ 支持公有/私有字段，但在部分可选链表达式中不支持私有字段

  • Chrome 84+ 完全支持私有字段及私有方法

  • Safari TP 121 已完全支持私有字段（包括 ?. 语法），但尚未支持私有方法

为每个特性单独创建插件并非最优方案。例如，我们可以先将私有方法转换为私有字段，再根据需要降级为旧语法。但如果我们明确知道需要转译，直接降级私有方法（无需中间步骤）能生成更优/优化的输出。

自 Babel 7.13.0 起，插件内部可直接读取 targets 选项。我们可以改造插件，使其自动执行 ECMAScript 特性的_部分_编译，从而优化输出体积和运行时性能。

现有实践

此方案并非全新。得益于与 @_developit 的合作，我们在 Babel 7.9.0 中为 @babel/preset-env 引入了 bugfixes: true 选项。启用该选项且编译目标设为 esmodules: true 时，我们仅对部分特性进行部分编译。这启发了当前方案，但现有部分转译在较现代目标（如 defaults, not ie 11）中作用有限。

我们已在使用 targets 选项决定编译对象展开时是否使用 Object.assign。

行动计划

此目标可拆分为两个可并行推进的任务：

  • 通过收集真实世界的 browserslist 配置，并模拟流行配置（如 defaults 或 >2%, not dead）的未来演变，识别优化适用场景

  • 实际实现必要优化，确保与其他插件兼容（因优化会大幅增加转译组合可能性）

探索新的编译 assumptions​

在 Babel 7.13.0 中，我们引入了顶层 assumptions 选项，用于规范 loose 模式行为，并为用户提供更细粒度的控制（用户常需仅启用_部分_假设而非全部）。

但目前仅包含已有 loose 模式的假设选项。我们可进一步探索用户可能需要的新假设。

现有提案包括：

  • #8222 - 假设所有 ESM 导入均为不可变，省略动态绑定的冗余代码

  • #11356 - 假设编译后的类不继承原生类，避免实例化可能为原生类的运行时性能开销

可通过以下方式确定应实现的新假设：

  • 人工检查转译后出现的"非预期"输出（通常由开发者不关心的边缘情况导致）

  • 向社区征集反馈（开发者可测试各假设在其应用中的有效性）

重构 Babel REPL​

Babel REPL 是学习 Babel 转译原理的便捷实验场。

当前限制：

期望实现的功能：

  • 集成 AST Explorer（与现有工具对接）

  • 将完整堆栈跟踪作为错误日志输出到 stderr

  • 将 stdout 作为输出通道

  • 支持在用户界面切换 Babel 版本

babel-website 仓库中至少 15% 的未解决问题与 REPL 相关：https://github.com/babel/website/issues?q=is%3Aissue+is%3Aopen+label%3Arepl

教学与调试工具​

与 REPL/ASTExplorer 相关，我们需要更多工具来辅助开发官方及第三方插件。这本质上是探索性工作：包括 AST 可视化方案、调试工具等不同方向。

Henry 正在断断续续开发的部分成果：

  • Codesandbox 简易 Babel 插件开发环境，类似 https://astexplorer.net 但支持自定义配置

  • 输入输出可视化映射，帮助理解 Babel 的代码转换机制。该功能也可用于文档演示，帮助开发者熟悉新语法或特定转换效果

  • 类 sourcemap 的输入输出映射系统，支持反向追踪定位代码生成来源，显著提升调试效率

交互式概念演示：https://babel-explorer.netlify.app/ （在底部区域点击并长按鼠标体验！）