一篇關於 Node.js 沒有實作 TypeScript 的原因的簡短文章。

首先要事

接下來是 Node.js 中關於 TypeScript 的已經和尚未完成的解釋。

本文無意批評 Node.js 團隊或 TypeScript 團隊。

事實上，恰恰相反。

我認真地認為 Node.js 團隊在按照他們的方式「實現」TypeScript 方面做出了最佳選擇。

我在這裡真正強調的是 Node.js 沒有實作 TypeScript。他們只是添加了某種支持。我認為這是一個重要的區別，在 Node.js 和 TypeScript 的討論中經常被忽略。

在過去的幾周里，我統計了我讀過的電子報中引用的 50 多篇文章提到 Node.js 實作了 TypeScript。

我認為是時候徹底澄清這一點了。

劇透警告：Node.js 未實作 TypeScript。

TypeScript：簡史和一些數據

2010 年，微軟發布了 TypeScript，這是 JavaScript 的超集，為該語言添加了靜態類型。 TypeScript 旨在解決 JavaScript 的一些缺點，例如缺乏類型安全性和維護大型程式碼庫的困難。自發布以來，TypeScript 受到了開發人員的歡迎，許多專案都採用它作為主要語言。

根據最新的 JS 現狀調查，TypeScript 幾乎無所不在。 78% 的開發人員至少 50% 的開發時間都在使用 TypeScript，因此難怪 「Node.js 實現了 TypeScript」 的迴聲甚至到達了 Web 最深刻的角落。

但是，需要澄清的是，這並沒有發生。它可能永遠不會。

問題

Node.js 沒有實作 TypeScript 有幾個原因。以下是我認為最重要的兩個：

#1：TypeScript 在運行時注入東西。

你知道枚舉在運行時會變成什麼嗎？一個對象。

幸運的是，這只是 TypeScript 如何在運行時注入東西的幾個例子之一。這對於 Node.js 來說是一個問題，因為這意味著運行時必須了解 TypeScript 的功能，這會帶來大量的複雜性和開銷。

如果 Node.js 希望保持與 ECMAScript 的一致性，並且在其餘下的存在中不必處理依賴關係管理，則它不能接受 TypeScript 作為當前形式的依賴關係。

#2：語意版本控制。

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 特定的功能，如前面提到的 enums。但是，這仍然是向前邁出的一大步，可以防止人們編寫 135 個設定檔來使 sum 函數接受兩個數字並傳回第三個數字。

再見，
麥可。