Cloudflare 与 VoidZero 启动 tsrs：用 Rust 重写 TypeScript 编译器

Cloudflare 和 VoidZero 目前正与 Owner.com 的 Max Schwenk 合作开发 tsrs，这是 TypeScript 编译器的 Rust 移植版本。我们与 TypeScript 团队紧密协作，并将 tsrs 作为 Oxc JavaScript 编译器工具链的一部分进行孵化。

我们的目标是帮助开发者减少等待代码检查的时间，从而将更多精力投入到构建工作中。让 TypeScript 运行得更快、内存占用更低，也有助于将完整的开发环境带到更多场景中，包括直接在浏览器中运行。

需要明确的是，我们并非在分叉（fork）TypeScript。我们认为 TypeScript 团队应当继续完全掌控该语言的设计与发展方向。他们长期秉持愿景，引导 TypeScript 在整个 JavaScript 社区中的普及应用。我们不希望改变这一现状。

TypeScript 团队在许多方面都能快速推进，但对于某些功能，他们可能会花费数年时间有意地探索各种方案并制作原型，然后再选择最合适的实现方式。Rust 移植版必须严格遵循这些决策，否则最终会崩溃并变得不兼容。我们必须基于原始实现严格保留 TypeScript 的语言特性——而由谁来定义“原始实现”的样子，应 solely 由 TypeScript 团队负责决定。

性能与内存改进

我们对 TypeScript 的 Rust 移植版进行的早期基准测试结果令人鼓舞：在使用相同数量类型检查工作线程的情况下，tsrs 的速度比 TypeScript 7.0 快至多 8 倍，且内存占用减少约 70%：

正如你所见，TypeScript 的下一个版本已经带来了许多性能提升，使得 TypeScript 7.1 beta 版比 7.0 版快至多 2.5 倍。其中一些优化是从 tsrs 上游合并（upstreamed）而来的，我们希望未来能发现更多此类机会。

你可能见过近期关于不同 TypeScript 移植版本的基准测试，其中往往伴随着各种性能声明。这些差异通常源于使用了更大规格的机器类型，以及采用了与 TypeScript 默认设置不同的配置选项。我们与 TypeScript 团队合作，确保上述基准测试是在相同配置下进行的对比。

默认情况下，tsrs 采用一种依赖于机器类型的自适应配置，该配置虽然占用更多内存，但速度更快：

试用 tsrs

用 Rust 编写的 TypeScript 旨在成为 TypeScript 的忠实移植版本。你可以通过从 npm 安装 tsrs 包来尝试其实验性发布版本：

npm install tsrs
npx tsrs

为什么是现在？

多年来，我们看到了许多将 TypeScript 移植到其他语言的尝试。由于涉及极高的复杂性，只有其中一个移植项目取得了成功：即 TypeScript 团队将其从 JavaScript 移植到 Go 的版本。

然而，前沿 AI 模型如今几乎可以独立地在几天内完成大规模移植工作。我们已经看到了诸如 slopforks、忠实移植版，以及在 Rust 或 C++ 中完全重新架构的 TypeScript 版本。显然，市场对更快的 TypeScript 有着强烈的需求。

为什么选择 Rust？

你可能会想：“TypeScript 的 Go 移植版已经让 TypeScript 比之前用 TypeScript 编写的版本快了 10 倍，且内存效率更高。这还不够吗？”

然而，这不仅仅是速度的问题。Rust 提供了一些独特的优势：在 WebAssembly 中运行。Rust + Wasm 的组合一直表现强劲，原因之一在于 Rust 语言设计的基本原理。当你将 Go 程序编译为 Wasm 时，必须连同 Go 的垃圾回收器一起编译。但 Rust 的内存管理模型使得 WebAssembly 客户机（guest）和主机（host）之间的内存交互变得直接而简单。这正是使 Rust 更适合 WebAssembly 用例的关键因素之一：内存效率。

Cloudflare Workers 长期以来一直支持 Wasm。就在几周前，我们宣布 在 Workers 中支持原生 Rust，这得益于 wasm-bindgen 的新 Emscripten target。当你在 Workers 上以紧凑循环运行整个软件构建和部署系统时，小内存占用的优势会迅速显现。这意味着你可以如此高效地运行这些工作负载，以至于现在可以在以前无法运行的地方运行完全封装的开发系统。

当与 agents 结合使用时，这开启了新的可能性：你现在可以在 Cloudflare 上的完全沙盒环境中端到端地运行开发工具链。但借助 Wasm，你也可以在浏览器客户端、嵌入式设备或 IoT 应用中安全地运行这些环境。

tsrs 移植版将如何维护？

首先，我们正在与 Theo Browne 合作，将 tsc-rs 和 tsrs 合并为一个单一包，以支持 TypeScript 的所有功能，包括语言服务器协议 (LSP) 和内容映射器。其次，我们在保持 Vinext 与其上游 Next.js 同步方面取得了巨大成功。我们在 最近的一篇博客文章 中解释了我们的做法：

每天早晨，一个 agent 会审查变更，获取差异，并为任何可能影响 Vinext 的内容创建跟踪 issue。每晚，当我们针对 Vinext 运行 Next.js 测试套件时，兼容性矩阵都会重新生成。当这些测试或 issue 揭示出差距时，agents 现在能够识别两个代码库中的变更，构建复现案例，移植相关测试，并提出修复方案。

我们将把同样的流程应用于 TypeScript，并极其小心地确保不引入与上游 TypeScript 分叉的行为。当我们遇到性能改进时，我们会尝试将其贡献回 TypeScript Go 代码库，让所有人受益。

最后，我们认识到目前与上游 TypeScript 版本存在一些差异，例如诊断信息的打印顺序。我们旨在到发布稳定版本时将这些差异减少到最小。

下一步是什么？

Cloudflare 已经是众多驱动 JavaScript 生态系统的免费开源 Rust 工具的家园，例如 Vite、Rolldown、Oxlint 和 Oxfmt。随着超过 1000 万开发者在 Cloudflare 上进行构建，我们非常重视让底层开发者工具链更快、更具可移植性，并能在更多环境中轻松运行。我们很高兴能尝试将 tsrs 更深入地集成到我们的技术栈中，例如用于 Oxlint 的类型感知 lint 规则。

与 Vinext 类似，我们的目标是将 tsrs 作为一个维护良好、健康的开源项目来运行——同时不阻碍 TypeScript 本身的发展。Oxc 团队已经开始重构代码库，使其速度更快、内存占用更少且更易于维护。我们知道 TypeScript 团队对此高度重视——他们正在试验针对 tsc 的内存和性能改进。我们期待与 TypeScript 团队及 JavaScript 社区合作，共同构建最佳、最快的 TypeScript 实现。