一篇關於 Node.js 沒有實現 TypeScript 的原因的簡短文章。
接下來是關於 TypeScript 在 Node.js 中已完成以及尚未完成的內容的解釋。
本文無意批評 Node.js 團隊或 TypeScript 團隊。
事實上,恰恰相反。
我認真地認為 Node.js 團隊在按照他們的方式「實現」TypeScript 方面做出了最佳選擇。
我在這裡真正強調的是 Node.js 沒有實作 TypeScript。他們只是添加了某種支持。我認為這是一個重要的區別,在 Node.js 和 TypeScript 的討論中經常被忽略。
在過去的幾周里,我統計了我讀過的電子報中引用的 50 多篇文章提到 Node.js 實作了 TypeScript。
我認為是時候徹底澄清這一點了。
劇透警告:Node.js 沒有實作 TypeScript。
2010 年,微軟發布了 TypeScript,它是 JavaScript 的超集,為該語言添加了靜態類型。 TypeScript 旨在解決 JavaScript 的一些缺點,例如缺乏類型安全性和維護大型程式碼庫的困難。自發布以來,TypeScript 受到了開發人員的歡迎,許多專案都採用它作為主要語言。
根據最新的 JS 現狀調查,TypeScript 幾乎無處不在。 78% 的開發人員至少 50% 的開發時間都在使用 TypeScript,因此難怪「Node.js 實現了 TypeScript」 的迴聲甚至到達了網路最深遠的角落。
但是,需要澄清的是,這並沒有發生。而且可能永遠不會。
Node.js 沒有實作 TypeScript 有幾個原因。以下是我認為最重要的兩個:
你知道枚舉運行時會變成什麼嗎?一個物體。
幸運的是,這只是 TypeScript 如何在運行時注入東西的幾個例子之一。這對於 Node.js 來說是一個問題,因為這意味著運行時必須了解 TypeScript 的功能,這會帶來大量的複雜性和開銷。
如果 Node.js 想要保持與 ECMAScript 的一致性,並且在其餘下的存在中不必處理依賴關係管理,它就不能接受 TypeScript 作為當前形式的依賴關係。
TypeScript 不遵循語意版本控制 (semver)。
另一方面,Node.js 嚴格遵循 semver,並有三個不同的發行版(目前,我們有 18.x、20.x、22.x)。這意味著可以在次要版本或補丁版本中引入重大更改,這可能會導致與現有程式碼的相容性問題。
此外,支援的平台數量龐大,因此要控制一切並不容易。
Node.js 根本無法接受 TypeScript 作為依賴項,因為它會破壞 semver。這是阻止 Node.js 實作 TypeScript 的一個根本問題。
這就是混亂產生的地方。 Node.js 沒有實作 TypeScript,但他們確實在實驗性標誌下添加了類型剝離。此功能允許開發人員編寫 TypeScript 程式碼並將其編譯為 JavaScript,而無需類型資訊。這是一種妥協,允許開發者在 Node.js 中使用 TypeScript,而不會引入上述問題。
你想要一個例子嗎?給你:
function sum(a: number, b: number): number { return a + b; }
這個函數,當使用 --experimental-strip-types 標誌編譯時,就會變成:
function sum(a , b ) { return a + b; }
你看到了嗎?類型消失了,並被空格取代。 但是,為什麼? ,你可能會問。好吧,因為這樣做可以保留來源映射引用,而無需為這些引用建立單獨的建置過程。
在內部,這是透過一個名為 amaro 的套件來完成的,它包裝了 swc——一個著名的建造工具,它執行實際的剝離。
當然,限制是存在的,例如無法使用 TypeScript 特定的功能,如前面提到的 枚舉。但是,這仍然是向前邁出的一大步,可以防止人們編寫 135 個設定檔來使 sum 函數接受兩個數字並傳回第三個數字。
再見,
麥可。
以上是Node.js 沒有實作 TypeScript的詳細內容。更多資訊請關注PHP中文網其他相關文章!