简述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 有几个原因。以下是我认为最重要的两个:
你知道enum在运行时会变成什么吗?一个物体.
幸运的是,这只是 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——一个著名的构建工具,它执行实际的剥离。
当然,限制是存在的,比如无法使用前面提到的enums等特定于typescript的功能。但是,这仍然是向前迈出的一大步,可以防止人们编写 135 个配置文件来使 sum 函数接受两个数字并返回第三个数字。
再见,
迈克尔.