Babel 中文文档

# Babel 路线图

本文档概述了我们的团队成员希望在今年进行的一些改进。

这远不是我们将给 Babel 带来的所有新功能或重要变化的完整列表，但如果您对项目的总体发展方向感兴趣，那么这是一个很好的总结。我们可能不会真正完成所有列出的要点，或者可能会将其中一些推迟到明年。其中一些有明确的起点和终点，而另一些则需要更多的研究或RFC (opens new window) 。

如果贵公司有兴趣并想直接赞助任何特定项目，请联系我们 ！

# Babel 2021路线图

# Babel8 (opens new window)

我们讨论 Babel 8 发布已经一年多了（我们最初计划在大约一年前发布）！然而，我们现在比以往任何时候都更接近它的发布！

剩下的大部分任务都在tracking issue (opens new window) 中，但仍然有一些阻碍：

  • 我们想放弃对* 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 提案，我们可以转换所有提案，除了顶级等待、导入断言和 JSON 模块（最好由使用依赖关系图的打包器处理）。

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

  • 装饰器提案的新迭代（我们需要同时实现解析和转换）；
  • 转换模块块提案（我们在 Babel 7.13.0 中实现了解析）。

我们将实现对装饰器的支持，并研究我们是否以及如何实现模块块的转换。

虽然我们不支持许多第一阶段提案，但最近对管道运算符和 to do 表达式进行了更新。由于我们已经支持这些提案并且社区对此非常兴奋，因此我们将更新我们的实施。

还有其他我们尚未实施的建议（例如模式匹配），因为他们的拥护者希望对语法和语义进行重大更改。但是，我们正在密切关注它们的发展，一旦它们稳定下来就会在 Babel 中实现它们。

# 搬进_ (opens new window) @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 会更容易，你只需要* compileJS: true在其中启用一个选项babel.config.json（或者它甚至可能在未来成为默认值——它不能是默认值，因为它不@babel/eslint-parser编译源代码）
  • 它将确保插件版本与版本同步* @babel/core，避免大多数由不匹配/不兼容的包版本引起的错误
  • 当我们转向 ESM 时，将很难在* transformSync. 这可以防止它成为一个问题。

已经有一个 RFC (opens new window) 来为稳定的 ECMAScript 特性移动插件@babel/core，这是朝这个方向迈出的第一步。

在我们当前的@babel/preset-env架构下，我们需要专门处理官方插件，以根据targets. 但是，这有两个缺点：

  • 特定插件的兼容性数据与插件实现完全分离（它甚至不是依赖，更像是内部隐式对等依赖：plugin -> @babel/core -> @babel/compat-data）；
  • 官方插件会得到特殊待遇* @babel/core，但我们希望确保第三方插件具有与官方插件相同的功能。

# 继续开发项目 (opens new window) babel-polyfills

我们已经决定core-js@2从 Babel 8 中删除旧的支持@babel/preset-env。我们还想停止推广特定的第三方 polyfill，这可能会给我们的用户留下它是 Babel 本身的一部分的印象。

这可能以两种不同的方式发生：

  • core-js@3我们只是从Babel 8 中删除@babel/preset-env，鼓励用户迁移到babel-plugin-polyfill-corejs3（这是@babel/preset-env从 7.10.0 版本开始内部使用的）
  • 我们可以* core-js@3在 中保留支持@babel/preset-env，但不会将其迁移到@babel/core我们将移动转换插件的时候。

无论我们采取哪种方式，我们都希望在用户需要更新其core-js配置中的集成时为他们提供至少一种替代方案。core-js是一个非常好的 polyfill，可确保尽可能高的规范合规性，但用户可能更喜欢不同的权衡。

( Nicolò ) 正在与@ljharb (opens new window) 合作，以确保该@es-shims项目 (opens new window) 至少支持所有 ES2015+ 功能（我们实际上是针对 ES5+），以便 Babel 用户可以在至少两个选项之间自由选择。

这需要在放弃对 的内置支持之前发生core-js@3，这样感兴趣的人es-shims就不必迁移两次。

# 扩展targets粒度转换 (opens new window)

从一开始，@babel/preset-env就使用了targets自动启用或禁用转换插件的选项。

但是，Babel 插件和浏览器中实现的功能之间并没有一对一的映射。

例如，我们有一个插件用于不同的类字段类型（公共和私有、静态和实例），但浏览器具有不同的兼容性矩阵：

  • Firefox 73 和 Safari 14 仅支持公共实例字段
  • Firefox 75+ 支持公共实例和静态字段
  • Chrome 79+ 支持 public 和 private 字段，但不支持某些可选链接表达式中的 private 字段
  • Chrome 84+ 完全支持私有字段，也支持私有方法
  • Safari TP 121 完全支持私有字段（即使有* ?.），但不支持私有方法

为每个功能创建一个插件是次优的。例如，我们可以将私有方法转换为私有字段，然后，如果需要，将它们转换为旧语法。但是，如果我们知道它需要向下编译，我们可以通过直接将私有方法向下转换为旧语法而无需中间步骤来生成更好/优化的输出。

从 Babel 7.13.0 开始，我们可以targets直接在插件中读取选项，我们可以修改我们的插件以自动执行给定 ECMAScript 功能的部分编译，这将在输出大小和运行时性能方面带来优势。

现有技术

这种方法并不是全新的。感谢与@_developit (opens new window) 的合作，在 Babel 7.9.0 中，我们bugfixes: true为@babel/preset-env. 启用此选项并用作esmodules: true编译目标时，我们只会部分编译某些功能 (opens new window) 。这让我们最初想到了这种可能性，但当前的部分转换在使用更现代的目标（例如，defaults, not ie 11）时不太有用。

我们也已经使用该targets选项来决定我们是否可以Object.assign在编译对象传播时使用。

动作要点

这个目标可以分成两个可以并行完成的大任务：

  • 我们需要通过收集真实世界的浏览器列表查询并模拟* 未来流行的查询（例如，* 或）将如何演变来确定这些优化在哪些* 方面* 有用。* defaults``>2%, not dead
  • 我们需要实际实施必要的优化，确保它们仍然可以与其他插件一起正常工作（因为它们会大大增加可能的变换组合的数量）。

# 研究新的assumptions编译器 (opens new window)

在 Babel 7.13.0 中，我们引入了一个新的顶级assumptions (opens new window) 选项，以形式化loose模式选项的作用，并为我们的用户提供更精细的控制（因为他们通常只能启用一些假设，而不是全部）。

但是，我们只包含了我们在模式下编译时已经做出的假设的选项loose。我们现在可以调查我们的用户可能需要哪些新假设。

已经有一些建议，例如：

  • #8222 - 假设所有 ESM 导入实际上都是不可变的，避免了实时绑定所需的代码。
  • #11356 - 假设编译类不扩展本机类，避免实例化可能的本机类所需的运行时性能成本。

我们可以通过以下方式找到我们应该实施哪些新假设：

  • 手动检查我们将哪些功能编译为“非显而易见”的输出，这通常是由许多开发人员不关心的边缘情况引起的。
  • 征求社区的反馈，因为开发人员可以测试哪些假设在他们的应用程序上有效，哪些无效。

# 彻底改造 Babel REPL

Babel REPL 是学习 Babel 如何转译源代码的便捷游乐场。

当前限制：

有以下特点：

  • AST 资源管理器（与现有的集成）
  • 带有完整堆栈跟踪的 stderr 作为错误日志
  • 标准输出作为输出
  • 从 UI 更改 Babel 版本

babel-website 中至少 15% 的开放问题与 REPL 相关：https://github.com/babel/website/issues? q=is%3Aissue+is%3Aopen+label%3Arepl (opens new window)

# 教育/调试工具 (opens new window)

与 REPL/ASTExplorer 相关，我们可以使用更多工具来帮助我们自己和第三方插件的一般插件开发。这本质上是探索性的：AST 本身的不同可视化、调试等。

一些已经在进行中的事情 Henry 一直在断断续续地工作：

  • Codesandbox用于制作一个简单的 Babel 插件，与 https://astexplorer.net 相同，但具有自定义配置。
  • 输入到输出映射的可视化 ，以帮助理解 Babel 如何转换其代码。甚至对于让 JavaScript 用户熟悉新语法或转换的特定演示的文档也很有用。
  • 输入 到输出的映射，如 sourcemap 类型结构。可以做一个反向映射，找出是什么插件导致代码以某种方式输出，这有助于调试。

有关我们正在考虑的交互示例：https://babel-explorer.netlify.app/ (opens new window) （在底部区域单击并按住鼠标！）

Last Updated: 6/14/2023, 8:56:23 AM

← 附加说明 →