在今天早些时候合并的一个 PR 中，Node.js添加了对 TypeScript的实验性支持。初始实现通过设置实验性标志 --experimental-strip-types 来执行 TypeScript 文件。
Node.js TSC 代表 Marco Ippolito 在添加实验性支持的 PR 中表示：“Node.js 将 TypeScript 源代码转换为 JavaScript 源代码。在转换过程中，不进行类型检查，类型被丢弃。”
“我认为使用户能够执行 TypeScript文件对于推动生态系统向前发展至关重要，这在所有调查中都被提到，并且不能被忽视。我们必须承认，用户希望在不安装外部依赖或加载器的情况下运行 node foo.ts。”
如果您正在运行最新的Nightly版本 Node，可以立即体验，或者在 CodeSandbox 上试用。
Ippolito 还发布了一个关于实验性 TypeScript 支持的路线图，概述了当前的限制：
不支持需要转换的 TypeScript 特性（枚举、命名空间等）。
.ts 文件不能使用 .js 扩展名。
不支持在 node_modules 中运行 TypeScript。
没有源映射，但由于我们执行空白处理（用空白替换删除的代码），所以不需要。
他还解释了选择 @swc/wasm-typescript 进行实现的原因：
简单性。
我考虑过其他工具，但它们需要将 rust 或 go 添加到工具链中。
@swc/wasm-typescript 是一个小包，包含一个 wasm 和一个 js 文件来绑定它。
Swc 目前被 Deno 用于同样的目的，已经过实际测试。
我预计未来会在本地层实现这一点。
TypeScript 支持的下一步
路线图中规划了项目在扩大支持过程中的几个演进步骤。第二步是解耦 TypeScript 转译器，使其可以像npm一样单独升级。之后，贡献者们旨在支持需要转换的TypeScript特性，并考虑 Node.js 是否应该在 node_modules 内运行 TypeScript文件的问题。
Ippolito 概述了第三步，重点是优化 Node和 SWC 之间的交互，使其高效运行，而不会影响 Node 的构建过程。
“这是我们衡量性能并使其在生产中可用而不带来性能损失的阶段，”他说。
第四步是添加更多核心中未使用但能减轻用户痛苦的功能。
今天合并的 PR是该功能的一个非常早期的实现，但社区的反应极为积极，清楚地表明了这一需求。
许多人还评论了 Bun 和 Deno 在推动Node中 TypeScript 支持方面的竞争重要性。这表明人们越来越认识到 TypeScript在现代开发中的重要性。即使在其初期阶段，Node.js对TypeScript 支持的承诺也表明，Node.js 的贡献者致力于保持相关性，并响应开发者社区不断发展的需求。
