我想知道Babel的Stage 0功能到底有多稳定。 Babel只实现了选择Stage 0 features。
一些开发人员表示使用Stage 0功能是“危险的”。但我想以这种方式看待这个问题：Babel的“stage-0”预设中的任何功能在历史上都被丢弃了吗？
答案 0 :(得分：4)
巴别不控制阶段。它们来自管理语言规范的标准组TC39。您可以查看更多信息on their Github repo for proposals。
预先了解＆＃34;阶段0＆＃34;是非常重要的。本质上意味着委员会的一名成员来参加会议并说“我想探索一下我认为可能很酷的事情”＃34;绝对不能保证此时某些东西会变得稳定。
Babel只实现了选择Stage 0功能。
确实如此，因为通常情况下，提案会在状态流程中迁移时发生变化。如果提案是一个可能更改的提案，我们（我是Babel的维护者之一）不太可能想要接受它的实施，因为随着时间的推移它很难维护可能会引起用户痛苦。
在Babel＆＃34; stage-0＆＃34;中有任何功能。历史上预设已被丢弃？
想到的主要内容：
RegExp.escape Map/Set.prototype.toJSON class constructors export default from "";代替export { default } from ""; 一些开发商表示，这是危险的＆＃34;使用Stage 0功能。
我认为确定人们的意思非常重要＆＃34;危险＆＃34;这里。危险可能并不意味着你的代码会随机破坏，但这可能意味着你最终会使用随后发生变化的功能。例如，装饰器是社区积极采用规范的一个例子，因为它最初是在Babel中实现的，而且规范现在已经从该实现大量改变。您可以编写一个装饰器来以编程方式检测这两种情况，但是没有编写用于处理旧行为的装饰器将在不更新的情况下使用新行为。巴贝尔尚未获得当前规范的实施。
另一个重要的＆＃34;危险＆＃34;对我来说，如果你使用非标准功能，开发人员就很难加快代码库的速度，特别是初级代码。如果您正在开发大型生产应用程序，那对人们来说可能是一个很大的障碍。这也意味着搜索关于给定语法的答案可能更难，或者更糟糕的是它可能是错误的，因为规范随着时间的推移而发生了变化。
我个人认为我们应该删除阶段0-2预设，以支持用户明确选择要激活的实验提案。我个人对使用低阶段提案的人没有任何问题，但你绝对应该明确决定使用什么，而不是全面启用stage-0。
另外请记住，虽然这些要点很重要，但它们也可能少用于一些小型爱好项目。如果它是你的项目并且你有时间维护它，那么无论如何都要做你想做的事。对我来说最危险的地方是代码库大多数增长，而且你使用的实验性功能越多，最不稳定的东西会随着时间的推移而增加，这可能会损害可维护性。