tsrs：TypeScript 编译器的 Rust 移植版
Cloudflare 和 VoidZero 目前正在与 Owner.com 的 Max Schwenk 合作开发 tsrs，即 TypeScript 编译器的 Rust 移植版。我们正与 TypeScript 团队紧密协作，并将 tsrs 作为 Oxc JavaScript 编译器工具链的一部分进行孵化。
我们的目标是让开发者少花时间等待代码检查，多花时间构建产品。让 TypeScript 更快、更省内存，也有助于将完整的开发环境带入更多场景，包括直接在浏览器中运行。
需要明确的是，我们没有分叉 TypeScript。我们坚信 TypeScript 团队应保持对语言设计和演进方向的完全控制权。他们在推动 JavaScript 社区采用 TypeScript 的同时，始终保持着长期的愿景。我们不希望改变这一现状。
TypeScript 团队在许多方面行动迅速，但对于某些功能，他们可能花费数年刻意探索各种选项并制作原型，以确保选择正确的实现方式。Rust 移植版必须紧随这些决策，否则最终会支离破碎并变得不兼容。我们必须严格基于原始实现来保留 TypeScript 语言特性——而定义这一标准 solely 属于 TypeScript 团队的责任。
性能与内存优化
我们对 TypeScript 的 Rust 移植版进行的早期基准测试结果显示了良好的前景：在使用相同数量的类型检查工作线程的情况下，tsrs 比 TypeScript 7.0 快最高 8 倍，内存使用量减少约 70%：
如图所示，TypeScript 的下一个版本已带来诸多性能改进，使 TypeScript 7.1 beta 比 7.0 版本快最高 2.5 倍。其中部分优化源自 tsrs 的上游贡献，我们期待发现更多类似成果。
您可能见过近期关于不同 TypeScript 移植版本的性能基准测试，这些测试往往因使用了更大规格的机器或不同于 TypeScript 默认值的选项，得出了不同的性能结论。我们与 TypeScript 团队协作，确保上述基准测试是在完全相同的配置下进行的。
默认情况下，tsrs 采用自适应配置，会根据机器类型自动调整。这种配置虽然会占用更多内存，但速度更快：
试用 tsrs
用 Rust 实现的 TypeScript 旨在对原版进行忠实的移植。您可以安装 npm 上的tsrs包，试用其实验版本：
npm install tsrs
npx tsrs为什么是现在？
多年来，我们见证了许多将 TypeScript 移植到其他语言的尝试。由于涉及极高的复杂性，目前只有 TypeScript 团队将 TypeScript 从 JavaScript 移植到 Go 这一案例取得了成功。
不过，如今前沿 AI 模型已经能在短短几天内几乎独立地大规模完成代码移植。我们已看到用 Rust 或 C++ 编写的 TypeScript 变体，包括粗糙的衍生版本、忠实的移植版以及彻底重构的版本。显然，市场对更快的 TypeScript 存在明确需求。
为什么选择 Rust？
您可能会想：“TypeScript 的 Go 移植版已经比用 TypeScript 编写的旧版本快了 10 倍，且内存效率更高，这还不够吗？”
然而，考量因素不仅仅是速度。Rust 具备一些独特优势：能在 WebAssembly 中运行。Rust 与 Wasm 的契合度一直很强，原因之一在于 Rust 的语言设计基础。将 Go 程序编译为 Wasm 时，必须连同 Go 的垃圾回收器一起编译。而 Rust 的内存管理模型使得 WebAssembly 来宾与宿主之间的内存交互变得直接且简单。这是 Rust 更适合 WebAssembly 场景的关键所在：内存效率。
Cloudflare Workers 对 Wasm 的支持由来已久。就在几周前，我们宣布了通过面向 wasm-bindgen 的新 Emscripten target，在 Workers 中原生支持 Rust。当你需要 Workers 在紧密循环中运行完整的软件构建和部署系统时，小内存占用带来的收益会很快显现——这些工作负载的运行效率之高，使得以前无法运行完全封装开发系统的地方，现在都能跑起来了。
这与 Agent 结合后打开了新的可能：你现在可以在 Cloudflare 上，在一个完全沙箱化的环境中端到端地运行整套开发工具链。而借助 Wasm，这些环境还可以安全地跑在浏览器客户端、嵌入式设备或 IoT 应用上。
tsrs 移植版将如何维护？
首先，我们正与 Theo Browne 合作，将 tsc-rs 和 tsrs 合并为一个包，支持 TypeScript 的全部特性，包括 Language Server Protocol（LSP）和内容映射器。其次，我们在维护 Vinext 与其上游 Next.js 同步方面积累了不少成功经验，并在最近的一篇博客中做过介绍：
每天早上，Agent 会审查变更、抓取 diff，并为任何可能影响 Vinext 的改动创建跟踪 issue。每晚，我们都会用 Next.js 测试套件跑一遍 Vinext，重新生成兼容性矩阵。当这些测试或 issue 暴露出差距时，Agent 就能定位两个代码库中对应的改动，构建复现用例、移植相关测试并提出修复方案。
我们会把同样的流程应用到 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 实现。