了解 TC39 与 ECMAScript 提案

[LightXJ]

一、谁设计ECMAScript

TC39（技术委员会39）
TC39 全称 Ecma International, Technical Committee 39（ECMA国际技术委员会39)，是制定 ECMA-262 号标准制的组织，由各个主流浏览器厂商的代表构成。

二、ECMAScript提案流程中的5个stage

Stage 0 : Strawman “稻草人阶段” —— 这是所有提案的起点。在进入下一阶段之前，提案的内容可能会发生重大变化。目前还没有提案的接收标准，任何人都可以为这一阶段提交新的提案。无需任何代码实现，规范也无需合乎标准。这个阶段的目的是开始针对该功能特性的讨论。目前处于stage0阶段的提案：https://github.com/tc39/proposals/blob/master/stage-0-proposals.md

Stage 1 : proposal “提案” —— 一个真正的正式提案。此阶段的提案需要一个“拥护者”（即 TC39 委员会的成员）。此阶段需仔细考虑 API 并描述出任何潜在的、代码实现方面的挑战。此阶段也需开发 polyfill 并产出 demo。在这一阶段之后提案可能会发生重大变化，因此需小心使用。目前仍处于这一阶段的提案包括了已望穿秋水的 Observables type 与 Promise.try 功能。

Stage 2 :draft “草案” —— 此阶段将使用正式的 TC39 规范语言来精确描述语法。在此阶段后仍由可能发生一些小修改，但是规范应该足够完整，无需进行重大修订。如果一个提案走到了这一步，那么很有可能委员会是希望最终可以实现该功能的。
Stage 3 candidate “候选” —— 该提案已获批准，仅当执行作者提出要求时才会做进一步的修改。此时你可以期待 JavaScript 引擎中开始实现提案的功能了。在这一阶段草案的 polyfill 可以安全无忧使用。
Stage 4 finished “完成” —— 说明提案已被采纳，提案规范将与 JavaScript 规范合并。预计不会再发生变化。JavaScript 引擎将发布它们的实现。截至 2020 年 7月，已完成的提案有这些：https://github.com/tc39/proposals/blob/master/finished-proposals.md，其中最引人注目的是Async functions

三、去哪里查看TC39标准的进程

https://github.com/tc39/ecma262

四、我们怎么在程序中应用这些新特性呢

使用babel
注: 从 Babel v7 开始，所有针对标准提案阶段的功能所编写的预设(stage preset)都已被弃用，官方已经移除了 @babel/preset-stage-x。
根据官方博客的解释，stage-x插件原本是对应于ECMAScript提案中的不同阶段，每个阶段有不同特性，而stage-x插件事实上就是集合这个阶段中几种特性转译的插件，比如我们最经常看到的babel-preset-stage-0，其实就是这样的：

module.exports = {
  presets: [
    require("babel-preset-stage-1")
  ],
  plugins: [
    require("babel-plugin-transform-do-expressions"),
    require("babel-plugin-transform-function-bind")
  ]
};

每个stage插件都会包含下一阶段的所有插件，这就导致大家为了能用上大多数特性，纷纷采用了babel-preset-stage-0，React项目中，我们最经常看到的babelrc配置是这样的：

{
  "presets": ["es2015", "react", "stage-0"]
}

然而，提案一直在变，如今是stage 0的特性，可能之后就进入到了stage 1，也可能之后直接被否决抛弃掉，并不会进入到ES规范中。那么babel是不是应该更新这些stage插件呢？如果更新了，现阶段大量前端项目、npm库都在使用这个stage插件，会不会突然发现就编译不了某个特性了呢？

到底应该遵循规范，还是应该迁就老项目做兼容呢？
最后Babel团队做出来的决定是，废弃掉stage-x插件！这不仅仅是关乎上面这个问题，由于大家已经习惯了stage的配置，对于其中封装的各个特性早已不再关心，废除掉stage-x插件，开发者就得加上自己需要的插件，每个插件对应一个提案中的特性，这样项目中的配置也能更清晰。

另外，之前的命名也由@babel/plugin-transform-改为@babel/plugin-proposal-，就是为了强调这只是一个提案中的特性，并不能确保它会出现在下一代的ES规范中。

参考：https://zhuanlan.zhihu.com/p/27762556