为什么我们删除Babel的舞台预设：实验性提案的明确选择加入

by Henry Zhu

朱Henry

为什么我们删除Babel的舞台预设：实验性提案的明确选择加入 (Why We Removed Babel’s Stage Presets: Explicit Opt-In of Experimental Proposals)

Moving forward with v7, we’ve decided it’s best to stop publishing the Stage presets in Babel (for example,@babel/preset-stage-0).

随着v7的发展，我们决定最好停止在Babel中发布Stage预设(例如@babel/preset-stage-0 )。

We didn’t make this decision lightly, and wanted to show the context behind the interplay between TC39, Babel, and the community.

我们并没有轻易做出这个决定，而是想展示TC39，Babel和社区之间相互作用的背后背景。

一些历史 (Some History)

A Babel preset is a shareable list of plugins.

Babel预设是可共享的插件列表。

The official Babel Stage presets tracked the TC39 Staging process for new syntax proposals in JavaScript.

官方的Babel Stage预设跟踪了TC39过渡过程，以查找JavaScript 中的新语法建议 。

Each preset (ex. stage-3, stage-2, and so on) included all the plugins for that particular stage and the ones above it. For example, stage-2 included stage-3, and so on.

每个预设(例如stage-3 ， stage-2等)都包含该特定阶段及其上方的所有插件。 例如， stage-2包括stage-3 ，依此类推。

This allowed users who wanted to use experimental syntax to simply add the preset, instead of needing to configure/install each individual plugin.

这样，想要使用实验性语法的用户就可以简单地添加预设，而无需配置/安装每个单独的插件。

We actually added the Stage presets shortly after Babel’s v6 release (it was previously a config flag in v5). Shown below is an older example.

实际上，我们在Babel v6发行后不久添加了舞台预设(以前是v5中的配置标志)。 下面显示的是一个较旧的示例。

问题 (Problems)

These presets were a convenient way to use what we all wanted: the new, shiny, “yet-to-be-determined” future of JavaScript.

这些预设是使用我们所有人想要的便捷方式：新的，闪亮的，“尚待确定”JavaScript未来。

Looking back, it worked really well! (Maybe too well?)

往回看，它真的很好！ (也许太好了？)

太好了吗？ (Too Good a Job?)

Languages like CoffeeScript and tooling like Traceur helped establish the idea of compiling JavaScript. Babel made it even easier to both use new/future syntax and integrate with existing tooling. The expectations changed from skepticism and worry to completely embracing the experimental.

诸如CoffeeScript之类的语言和诸如Traceur之类的工具帮助建立了编译JavaScript的思想。 Babel使使用新的/未来的语法以及与现有工具集成变得更加容易。 期望从怀疑和担忧转变为完全接受实验。

We probably wouldn’t be where we are if not for the wide adoption of compilers such as Babel: it accelerated the usage (and teaching) of ES2015 to a much larger audience. The growth of React further fueled usage, as its JSX syntax, class properties, and object rest/spread led to people knowing a bit more about these syntax proposals.

如果不是像Babel这样的编译器被广泛采用的话，我们可能就不会在这里出现：它加快了ES2015在更多受众中的使用(和教学)。 React的增长进一步推动了用法的发展，因为它的JSX语法，类属性和对象保留/扩展使人们对这些语法建议有了更多的了解。

Babel became a one-time setup for people, never to be thought of again. It became the underlying infrastructure, hidden behind other tools until there was a SyntaxError, dependency issues, or integration issues. Simply use stage-0.

Babel成为人们的一次性装置，不用再想了。 它成为基础基础结构，隐藏在其他工具之后，直到出现SyntaxError ，依赖关系问题或集成问题。 只需使用stage-0 。

This was awesome to see in some ways, as it meant that these ideas were being tested in the wild, even in production environments. However, it also meant that many companies, tools, and people would encounter some trouble if a proposal changed in a significant way (or even got dropped altogether).

从某些方面来看，这真是太棒了，因为这意味着即使在生产环境中，也正在野外对这些想法进行测试。 但是，这也意味着，如果提案发生重大更改(甚至完全放弃)，那么许多公司，工具和人员都会遇到麻烦。

来来回回 (Back and Forth)

Over the years, we’ve raised many issues to discuss what to do with the Stage presets in #4914, #4955, #7770. I even wrote in an older post about Babel 7.0 that said we weren’t removing them ?.

多年来，我们提出了许多问题来讨论如何处理＃4914 ， ＃4955和＃7770中的舞台预设。 我什至在较早的关于Babel 7.0的文章中写道，我们是否要 删除它们 ？

However, we found that keeping the Stage presets would lead to issues even for Babel itself:

但是，我们发现即使保留Babel本身，保留舞台预设也会导致问题：

• It was a common issue to ask something like: “What presets(s) are needed to use async functions?” It would be unclear for people to know exactly what stage-0 meant, and few people would look at its package.json or source.

  常见的问题是： “使用异步功能需要哪些预设？” 人们尚不清楚确切地知道stage-0是什么意思，而且很少有人会看到它的package.json或源代码。

• Removing a proposal plugin in Stage 3 (once it moves to Stage 4) is actually a breaking change. This issue is exacerbated when you are trying to use @babel/preset-env to not compile a natively supported proposal.

  实际上，在第3阶段中删除提案插件(一旦移至第4阶段)是一项重大突破。 当您尝试使用@babel/preset-env不编译本机支持的建议时，此问题会更加严重。

“ ES7装饰器” (“ES7 Decorators”)

Part of the issue is precisely around naming things, and as we often hear, naming things is hard.

问题的一部分恰恰是围绕事物的命名，而正如我们经常听到的那样，命名事物很困难。

There were a lot of names for ES6 itself: Harmony, ES Next, ES6, ES2015. When people hear about new ideas, it makes sense to just pick the latest number and attach the name to it.

ES6本身有很多名称：Harmony，ES Next，ES6，ES2015。 当人们听到新的想法时，仅选择最新的数字并将名称附加在上面就很有意义。

It’s completely understandable that this happens without realizing it, but continuing to do so sets different expectations for how the language progresses. It’s nothing to feel guilty about — we learn as a community and remind one another of how JavaScript works.

完全可以理解，这是在没有意识到的情况下发生的，但是继续这样做对语言的发展设定了不同的期望。 不必感到内–我们作为一个社区学习，并相互提醒JavaScript如何工作。

Jay Phelps wrote a nice article about this subject. He explains it would be best to call them by the “Stage” they are currently at: “Stage 2 Decorators”, or just simply the “Decorators Proposal”.

杰伊·菲尔普斯 ( Jay Phelps)撰写了一篇有关该主题的不错的文章 。 他解释说，最好用当前的“阶段”来称呼他们：“第2阶段装饰者”，或者简称为“装饰者提案”。

The reasoning is that saying “ES7 Decorators” assumes that Decorators is expected to be in ES7. I mentioned this in my last post regarding compiling node_modules, but being in a particular Stage doesn’t guarantee much: a proposal can stall, move backward, or get removed entirely.

理由是说“ ES7 Decorators”假设Decorators预期在ES7中。 我在上一篇有关编译node_modules的文章中提到了这一点 ，但是处于特定阶段并不能保证太多：提案可能会停滞，向后移动或完全删除。

We wanted to highlight this fact when we decided to change the names of the proposal plugins from @babel/plugin-transform- to @babel/plugin-proposal-.

当我们决定将提案插件的名称从@babel/plugin-transform-更改为@babel/plugin-proposal-时，我们想强调这一事实。

BabelScript (BabelScript)

Having presets for proposals so early in the process may imply that these proposals are guaranteed to move forward or have a stable implementation.

在流程中如此之早就为提案准备好预设，可能意味着可以保证这些提案可以继续进行或稳定实施。

TC39 urges caution when using Stage 2-or below proposals, as it might result in inadvertent pressure from the community to keep the implementation as-is instead of improving it for fear of breaking existing code or ecosystem fragmentation (for example, using a different symbol like # instead of @ for decorators).

TC39在使用阶段2或以下建议时应谨慎行事，因为这可能会导致社区无意间施加压力，要求保持现状不变，而不是因为担心会破坏现有代码或生态系统碎片而对其进行改进(例如，使用其他符号如#而不是@作为装饰器)。

People joke that developers who use Babel are using “BabelScript” instead of JavaScript, implying that somehow once a Babel plugin is made for a certain feature, that must mean it’s “fixed” or officially part of the language already (which is not true). For some, the first thought for people when they see a new syntax/idea (Stage “-1”) is whether there is a Babel plugin for it.

人们开玩笑说使用Babel的开发人员正在使用“ BabelScript”而不是JavaScript，这意味着一旦为某个功能制作了Babel插件，就一定意味着它已经“固定”或正式成为语言的一部分(这是不正确的) 。 对于某些人来说，当人们看到一个新的语法/想法(阶段“ -1”)时，他们首先想到的是是否有Babel插件。

设定期望 (Setting Expectations)

After compilers like Babel made it common practice for people to write ES2015, it was natural for developers to want to try out even newer and more experimental “features”. The way this worked in Babel was to use the stage flag in previous versions or the stage-x presets.

在像Babel这样的编译器使人们编写ES2015成为惯例之后，对于开发人员来说，自然而然地想要尝试更新，更具实验性的“功能”。 在Babel中的工作方式是在先前版本或stage-x预设中使用stage标志。

Being the most convenient way of opting into any new feature, it quickly became the default for people when configuring Babel (even though in Babel v6 it moved to not doing anything by default, which caused lots of complaints).

作为选择任何新功能的最便捷方法，它很快成为配置Babel时人们的默认设置(即使在Babel v6中它默认也不做任何事情，这引起了很多抱怨)。

There were a lot of good discussions even years ago, but it wasn’t the easiest thing to navigate: we wouldn’t want to penalize users who understood the tradeoffs by putting console.warns when using it, and not having the option at all seemed unreasonable at the time.

即使在几年前，也有很多很好的讨论，但这并不是最简单的选择：我们不希望通过在使用console.warn时使用权衡来折衷那些理解权衡的用户，而不必在console.warn上选择当时似乎一切都不合理。

Blindly opting into Stage 0 (whether we had it by default) or people choosing to do so seems dangerous, but also never using any proposals is overly cautious. Ideally, everyone should able to make an informed decision about the kinds of features that seem reasonable to them and use them wisely, regardless of what stage they are in. Mike Pennisi wrote a great post about these concerns.

盲目选择第0阶段(默认情况下是否拥有)或选择这样做的人似乎很危险，但从不使用任何建议都过于谨慎。 理想情况下，每个人都应该能够就他们认为合理的各种功能做出明智的决定，并明智地使用它们，无论它们处于什么阶段。MikePennisi撰写了一篇有关这些问题的精彩文章 。

It isn’t our intention to threaten, rush, or force specific things into the ecosystem or JavaScript but to faithfully maintain the implementation/discussions around new ideas.

我们的目的不是威胁，匆忙或强迫特定事物进入生态系统或JavaScript，而是忠实地维护围绕新思想的实现/讨论。

其他注意事项 (Other Considerations)

We also could have tried to:

我们还可以尝试：

• Rename the presets to better signify the stability level (doesn’t solve the versioning problem)

  重命名预设以更好地表示稳定性级别(不能解决版本问题)

• Better versioning strategies: independently version the presets and update them immediately when needed, maybe use 0.x

  更好的版本控制策略：对版本进行独立版本控制，并在需要时立即更新，可能使用0.x

• Warn/Error for old out-of-date versions of presets
  旧版本的旧版本的警告/错误

In the end, people would still have to look up what proposals are at what Stage to know which ones to use if we kept the Stages in.

最后，人们仍然必须查找处于哪个阶段的提案，才能知道如果我们保留阶段，可以使用哪些提案。

为什么现在？ (Why Now?)

Why not remove it earlier? The Stage presets have been part of Babel for years, and there were concerns with adding more “complexity” to using Babel. A lot of tooling, documentation, articles, and knowledge were built around the Stage presets. Earlier, we thought it was better to officially maintain the presets since someone else would (and will) inevitably create them.

为什么不更早地删除它？ 舞台预设已经成为Babel的一部分，并且担心使用Babel会增加更多的“复杂性”。 围绕舞台预设构建了许多工具，文档，文章和知识。 早些时候，我们认为最好正式维护这些预设，因为其他人将(并且将)不可避免地创建它们。

We’re trying to determine the right level of feedback: if it’s only the committee that decides what goes into the language, it may lead to well-specified features that are not needed. But if the community expects that in-progress, experimental proposals are considered stable or ok to use in production without consequence, then we’ll have other issues. We all want to move forward and proceed with intention: not rushing, but not being too cautious. Babel is the right place to do that experimentation, but knowing where the boundaries are is necessary.

我们正在尝试确定正确的反馈水平：如果仅由委员会来决定使用哪种语言，则可能会导致不需要明确指定的功能。 但是，如果社区期望正在进行中的实验性建议被认为是稳定的或可以在生产中使用而没有任何后果，那么我们将遇到其他问题。 我们每个人都想向前迈进，并怀着坚定的意愿：不要着急，但不要太谨慎。 巴别塔(Babel)是进行该实验的正确地点，但要知道边界在哪里是必要的。

Removing the presets would be considered a “feature,” since it means someone would have to make an explicit decision to use each proposal. This is reasonable for any proposal, since they all have varying levels of instability, usefulness, and complexity.

删除预设将被视为“功能”，因为这意味着某人必须做出明确的决定才能使用每个建议。 这对于任何建议都是合理的，因为它们都有不同程度的不稳定，有用性和复杂性。

We fully expect some initial backlash from this, but ultimately feel that removing the Stage presets is a better decision for us all in the long run. However, removing previous defaults or removing the Stage presets doesn’t mean we don’t care about ease of use, new users, or documentation. We work with what we can to keep the project stable, provide tooling to make things better, and document what we know.

我们完全希望由此引起一些最初的强烈反对 ，但是从长远来看，最终感觉到删除舞台预设对于我们所有人来说是一个更好的决定。 但是，删除以前的默认设置或删除舞台预设并不意味着我们不在乎易用性，新用户或文档。 我们将竭尽所能，以保持项目的稳定，提供使情况变得更好的工具并记录我们所知道的内容。

正在迁移 (Migrating)

For a more automatic migration, we have updated babel-upgrade to do this for you (you can run npx babel-upgrade).

为了实现更自动的迁移，我们更新了babel-upgrade来为您执行此操作(您可以运行npx babel-upgrade )。

The TL;DR is that we’re removing the Stage presets. At some level, people will have to opt-in and know what kinds of proposals are being used instead of assuming what people should use, especially given the unstable nature of some of these proposals. If you use another preset or a toolchain, (e.g. create-react-app) it’s possible that this change doesn’t affect you directly.

TL; DR是我们要删除舞台预设。 在某种程度上，人们将不得不选择加入并知道正在使用哪种提议，而不是假设人们应该使用什么提议，特别是考虑到其中一些提议的不稳定性质。 如果您使用其他预设或工具链(例如create-react-app )，则此更改可能不会直接影响您。

We have deprecated the Stage presets as of 7.0.0-beta.52. If you don't want to change your config now, we would suggest you pin the versions to beta.54 until you can upgrade. After beta.54 we will throw an error with a message saying how to migrate. And check that all your versions are the same while in prerelease.

从7.0.0-beta.52我们已弃用舞台预设。 如果你现在不想改变你的配置，我们建议您固定的版本beta.54 ，直到你可以升级。 在beta.54之后，我们将抛出一条错误消息，提示如何迁移。 并在预发行版本中检查所有版本是否相同。

As an alternative, you are free to make your own preset that contains the same plugins and upgrade them as you please. In the future, we may want to work on a babel-init that can help you set up plugins interactively or update babel-upgrade itself to list and add the current Stage plugins. Maybe Babel should stay a low-level tool and rely on other higher-level/framework tools like create-react-app to handle these choices for people.

作为替代方案，您可以自由制作包含相同插件的自己的预设，并根据需要进行升级。 将来，我们可能希望使用babel-init来帮助您交互式地设置插件或更新babel-upgrade本身以列出并添加当​​前的Stage插件。 也许Babel应该保留低级工具，并依赖其他高级/框架工具(如create-react-app来为人们处理这些选择。

防止提案锁定 (Preventing Proposal Lock-In)

James DiGioia wrote a post recently about the changes to using the pipeline operator (|&gt;).

James DiGioia最近写了一篇关于使用管道运算符( |& gt;)的更改的文章 。

The main point in the post is that the proposal itself is in flux and has a few options to explore. Because we’d like to implement all three of the current possibilities as Babel plugins for both spec feedback and user feedback, we believed the way the plugin is used should change as well. This is a relatively new approach for TC39 and Babel!

帖子中的要点是，提案本身是不断变化的，并且有一些可供选择的选择。 因为我们希望将当前的所有三种可能性都实现为Babel插件，以用于规格反馈和用户反馈，所以我们相信使用该插件的方式也应有所变化。 对于TC39和Babel，这是一个相对较新的方法！

Previously, we would add the proposal plugin to the config and that was it. Now, we remove the default behavior and ask users to opt into a flag that shows which proposal is chosen. We make it clear that there isn’t a fixed (or even favored) option at the moment.

以前，我们会将提案插件添加到配置中，仅此而已。 现在，我们删除默认行为，并要求用户选择一个标志，以显示选择了哪个提议。 我们明确指出，目前没有固定(甚至不受欢迎)的选项。

This is something that we’d like to continue to do moving forward as another indication that these proposals are open to change and feedback from all of us. The removal of the Stage presets makes this even easier, as before we had to pass down these options even if you didn’t use the syntax.

这是我们希望继续做的事情，这又表明这些提议可以接受我们所有人的变化和反馈。 与之前一样，即使您不使用语法，也可以通过传递这些选项来删除Stage预设，从而更加轻松。

生态系统维护负担 (Ecosystem Maintenance Burden)

A language’s “syntax budget” doesn’t just apply to the complexity of the language itself but can extend down to the tooling. Each new syntax addition brings a new burden to the maintainers of other JavaScript projects.

语言的“语法预算”不仅适用于语言本身的复杂性，还可以扩展到工具。 每增加一个新语法都会给其他JavaScript项目的维护者带来新负担 。

Once new syntax is proposed, many things need updating: parsers (babylon), syntax highlighting (language-babel), linters (babel-eslint), test frameworks (jest/ava), formatters (prettier), code coverage (istanbul), minifiers (babel-minify), and more.

提出了新的语法后，需要进行很多更新：解析器( babylon )，语法突出显示( language-babel )，linters( babel-eslint )，测试框架( jest / ava )，格式化程序( prettier )，代码覆盖率( istanbul )， babel-minify器( babel-minify minify)等。

There have been many issues brought up on projects like acorn, eslint, jshint, typescript, and others to support Stage 0 proposals because they were in Babel. There aren't many projects that would adhere to a policy that required them to support any proposal, since that would be extremely demanding to maintain. In many ways, it's surprising we even attempt to handle it in Babel itself given the constant updates and churn.

已经有长大的项目一样，许多问题acorn ， eslint ， jshint ， typescript及其他支持0期的建议，因为他们在巴别塔。 很少有项目会遵循一项要求他们支持任何提案的政策，因为要维持该提案非常困难。 在许多方面，令人惊讶的是，鉴于不断的更新和流失，我们甚至尝试在Babel本身中处理它。

Who is doing that work, and is it our responsibility to make sure everything works? Every one of those projects (mostly volunteers) is lacking in help in almost every aspect, and yet we continually get complaints about this across the board. How are we, as a community, to take responsibility for dealing with our infrastructure (not dissimilar to open source as a whole)?

谁在做这项工作，确保一切正常，这是我们的责任吗？ 这些项目中的每个项目(大多数是志愿者)几乎在各个方面都缺乏帮助，但我们仍不断收到有关此方面的投诉。 作为一个社区，我们如何承担处理我们的基础架构的责任(与整个开放源代码一样)？

Babel has taken on the unusual burden of supporting these experimental features. At the same time, it’s reasonable that other projects take a more conservative policy. If you’d like to see new language features are supported across the ecosystem, contribute to TC39 and this project to bring these proposals to Stage 4.

Babel承担了支持这些实验功能的特殊负担。 同时，其他项目采取更保守的政策也是合理的。 如果您希望看到整个生态系统都支持新的语言功能，请为TC39和该项目做出贡献，以将这些建议带入第4阶段。

未来 (The Future)

The purpose of this project is to act as a part of the TC39 process: being a resource for both implementing newer (Stage 0–2) proposals and receiving feedback from users while also supporting older versions of JavaScript. We hope this post sheds more light on how we are trying, as best we can, to better align this project in the JavaScript ecosystem. We will be releasing a RC for v7 soon!

该项目的目的是充当TC39流程的一部分：既是实现较新的建议(第0–2阶段)并在获得用户反馈的同时还支持旧版JavaScript的资源。 我们希望这篇文章能更好地说明我们如何尽力使这个项目更好地与JavaScript生态系统保持一致。 我们即将发布v7的RC！

If you appreciate this post and the work we’re doing on Babel, you can support me on Patreon, ask your company to sponsor us on Open Collective, or better yet get your company involved with Babel as part of your work. We’d appreciate the collective ownership.

如果您喜欢这篇文章以及我们在Babel上所做的工作，可以在Patreon上为我提供支持 ，要求您的公司在Open Collective上为我们提供赞助，或者更好地让您的公司参与Babel的工作。 我们非常感谢集体所有权。

With thanks to all the reviewers! Feel free to give feedback on Twitter.

感谢所有评论者 ！ 随时在Twitter上提供反馈。

Originally published at https://babeljs.io/blog/2018/07/27/removing-babels-stage-presets.

最初发布于 https://babeljs.io/blog/2018/07/27/removing-babels-stage-presets 。

翻译自: https://www.freecodecamp.org/news/why-we-removed-babels-stage-presets-explicit-opt-in-of-experimental-proposals-cd038c69115a/