大家好，我卡頌。
最近，Typescript v5.0 beta發佈，主打特性是支持Decorators。
有同學會疑惑，Decorators不是早就有的特性麼？各種框架（比如Nest.js、Angular）早就用的飛起，ts不也早就支持了麼？
之所以會有這樣的疑惑，簡單的說，現階段大家使用的是老的Decorators規範，在ts中使用需要加上--experimentalDecorators flag。而ts本次更新支持的是2022年3月新的Decorator規範。
這背後更本質的原因，涉及到新的JS語法誕生的過程。今天，我們就以Decorators爲例聊聊一個新的JS語法是如何誕生的。
歡迎加入人類高質量前端交流羣，帶飛
新特性是如何產生的
所有ES語法的誕生都由國際標準組織Ecma International下屬的TC39（the 39nth Technical Committee）委員會負責。
這是個會員制的組織，由入會的公司、組織推舉的代表組成。這些代表通常是JS開發者、學者或編程語言領域的專家（比如大家熟悉的賀老）。國內的360、阿里、華爲、SujiTech都曾參與TC39。
委員會定期召開會議推進新的ES語法落地，這套語法落地的流程被稱爲The TC39 Process。
值得一提的是，這套流程起源於ES2015，也就是大名鼎鼎的ES6。
ES2015整個版本的落地用了整整6年，包含大量新特性。我想這也是爲什麼提到ES新特性，很多同學首先會想到ES2015（即ES6）的原因吧。
從ES2017開始，每年都會發布新的版本，包含那些通過The TC39 Process但在上個版本沒有發佈的特性。
The TC39 Process
整個流程包含5個階段，階段0～階段4。接下來簡要介紹下各階段的目標。
階段0:稻草人（Strawperson）
階段0被稱爲Strawperson（稻草人），由TC39成員發起，通常是提出新想法或是對未納入正式的提案進行修改。
比如，Decorator提案由Yehuda Katz於2014年4月10日提出。
等到這份提案到階段3，已經2022年3月了，可想而知一個新特性的誕生有多不容易。
階段1:提案（Proposal）
階段1被稱爲Proposal（提案），此時該提案已經成爲正式提案。該階段主要提出一些具體的問題和解決方案。此時會選出一名TC39成員（通常是該提案的發起者）負責推動該提案。
繼續以Decorator提案舉例，他在2015年3月24日到達階段1。
該階段指明瞭Decorator的：
- 設計目的
- 適用範圍
比如，適用於類本身：
@F("color")
@G
class Foo {
}
適用於類方法：
class Foo {
@F("color")
@G
bar() { }
}
除此之外，還能適用於類的訪問器屬性（getter、setter）、對象字面量、對象的訪問器屬性。
-
語法
![]()
在Decorator進入階段1的一個月後，Babel跟進了Decorator的polyfill實現。這個版本的polyfill被稱爲legacy。
我們可以在Babel官網看到，對於Decorator特性存在5個可選項：
不同版本的可選項對應了Decorator提案不同階段的落地時間，由於不同階段對Decorator規範提出了修改意見，所以相應的，Babel插件也就有了不同可選項。
類似的原因，ts中支持的Decorator也就有了不同版本，這也是造成我們開篇提到問題的本質原因。
階段2:草稿（Draft）
階段2被稱爲Draft（草稿）。在該階段會用ES語法儘可能精確地描述提案的語法、語義和API，並提供實驗性的實現。
到了該階段，意味着提案會有很大概率出現在正式版本的ES中。
Decorator到達階段2的時間是2016年7月28日，距離階段1已經過去一年多時間。
階段3:候選人（Candidate）
階段3被稱爲Candidate（候選人）。到了該階段，提案基本已經定型，僅根據外部反饋針對關鍵問題進行更改。
ts在最新的v5.0 beta版本中默認支持的Decorator就是階段3。
階段4:完成（Finished）
階段4被稱爲Finished（完成）。該提案會出現在正式的規範文檔中，並在下一個版本的ES中正式支持。
總結
語言特性的推進是個蠻長的過程，最終達成的是多方博弈的結果。對於ES來說，這些博弈就體現在這4個階段中。
還是以Decorator舉例，這個特性在oop框架（比如Angular、Mobx）中是很重要的特性。Angular團隊在實現Angular2時，最初考慮用AtScript實現。
而最終Angular用ts實現，其中很重要的一個原因是 —— ts團隊承諾實現一些AtScript特性，尤其是Decorator。