一篇关于 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 函数接受两个数字并返回第三个数字。

再见，
迈克尔。