简述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。
typescript：简史和一些数据
2010 年，微软发布了 typescript，它是 javascript 的超集，为该语言添加了静态类型。 typescript 旨在解决 javascript 的一些缺点，例如缺乏类型安全性和维护大型代码库的困难。自发布以来，typescript 受到了开发者的欢迎，许多项目都采用它作为主要语言。
根据最新的 js 现状调查，typescript 几乎无处不在。 78% 的开发者至少 50% 的开发时间都在使用 typescript，所以难怪“node.js 实现了 typescript” 的回声甚至到达了网络最深刻的角落。
但是，需要澄清的是，这并没有发生。而且可能永远不会。
问题
node.js 没有实现 typescript 有几个原因。以下是我认为最重要的两个：
#1：typescript 在运行时注入东西。
你知道enum在运行时会变成什么吗？一个物体.
内容：生产级 Node.js 后端模式，涵盖 Express/Fastify 配置、分层架构、中间件、错误处理、验证、数据库集成、身份验证及缓存。 时机：构建 REST API、搭建 Node.js 服务器、实施身份验证、集成数据库、添加验证/缓存或构建后端应用结构时。 关键词：nodejs, node, express, fastify, typescript, api, rest, 中间件, 身份验证, jwt, 验证, zod, postgres, mongodb, redis, 缓存, 速率限
幸运的是，这只是 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——一个著名的构建工具，它执行实际的剥离。
当然，限制是存在的，比如无法使用前面提到的enums等特定于typescript的功能。但是，这仍然是向前迈出的一大步，可以防止人们编写 135 个配置文件来使 sum 函数接受两个数字并返回第三个数字。
再见，
迈克尔.
