Nodejs 没有实现 TypeScript

本篇文章主要是结合我之前面试的各种经历和实战开发中遇到的问题解决经验整理的，希望这篇《Nodejs 没有实现 TypeScript》对你有很大帮助！欢迎收藏，分享给更多的需要的朋友学习~

简述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在运行时会变成什么吗？一个物体.

幸运的是，这只是 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 函数接受两个数字并返回第三个数字。

再见，
迈克尔.

文中关于的知识介绍，希望对你的学习有所帮助！若是受益匪浅，那就动动鼠标收藏这篇《Nodejs 没有实现 TypeScript》文章吧，也可关注golang学习网公众号了解相关技术文章。