Skip to content

SYSTEM Cited by 1 source

tsrs

tsrs (github.com/oxc-project/tsrs) is a faithful Rust port of the TypeScript compiler, incubated as part of the Oxc JavaScript-compiler toolchain. It is a joint effort of Cloudflare, VoidZero, and Max Schwenk (Owner.com), developed "in close collaboration with the TypeScript team." It is installable today as an experimental release:

npm install tsrs
npx tsrs

A WebAssembly build ships separately as @tsrs/wasm.

tsrs is explicitly not a fork. The goal is to preserve the TypeScript language "strictly based on its original implementation," leaving the TypeScript team "solely responsible" for language design and direction. (strict upstream compatibility as a first-class constraint.)

Why it exists

TypeScript's own Go port (tsgo) already made tsc roughly 10× faster and far more memory-efficient than the original JavaScript implementation. tsrs's justification is not raw speed alone but WebAssembly fit:

"When you compile a Go program to Wasm, you have to compile Go's garbage collector along with it. But Rust's memory management model enables straightforward memory interactions between a WebAssembly guest and host. This is one of the key things that makes Rust a much better fit for the WebAssembly use-case: memory efficiency."

Because the Go runtime must ship its GC into every Wasm binary (a binary-size + footprint cost), a Go port is a worse Wasm citizen than a Rust port whose ownership model (concepts/memory-safety) allows direct guest↔host memory interaction. This is the load-bearing architectural claim of the project.

Strategic payoff: toolchains that run anywhere

Cloudflare's angle is running entire software build-and-deploy systems in tight loops on Workers, where a small memory footprint compounds. It had "just a few weeks ago" shipped native Rust in Workers via the new Emscripten target for wasm-bindgen. Combined with a Wasm-friendly TypeScript checker, the end state is:

  • a development toolchain running end-to-end in a fully sandboxed environment on Cloudflare;
  • the same environment running client-side in the browser, or on an embedded / IoT device;
  • "new possibilities when combined with agents" — an agent can drive a full dev toolchain inside a sandbox.

Performance

Early benchmarks (same type-check-worker count, same configuration, vs TypeScript 7.0):

Metric tsrs vs TS 7.0
Speed up to 8× faster
Memory ~70% less

Separately, TypeScript 7.1 beta is "up to 2.5x faster than TypeScript 7.0" — and "some of these optimizations were upstreamed from tsrs." By default tsrs ships an adaptive configuration dependent on the machine type that uses more memory but is even faster.

The post is deliberate about benchmark methodology: it warns that other TS-port benchmarks inflate results by "using larger machine types and different options compared to TypeScript's defaults," and that Cloudflare worked with the TypeScript team to compare "the same configuration."

How it is maintained (upstream-sync)

tsrs borrows the agent-driven upstream-sync process Cloudflare uses to keep Vinext in lockstep with Next.js:

  • Each morning, an agent reviews upstream changes, fetches diffs, and opens tracking issues for anything that could affect the port.
  • Each night, the compatibility matrix is regenerated by running the upstream TypeScript test suite against tsrs.
  • When a test or issue reveals a gap, agents "identify the change across both codebases, build a reproduction, port any relevant tests, and propose a fix."
  • Performance improvements discovered in tsrs are contributed back to the TypeScript Go codebase "so everyone wins" — upstream the fix + upstream while integrating, applied at whole-compiler scale.

Because tsrs is a faithful port that tracks upstream rather than forking, its correctness is only as good as this sync loop — which is why the project insists it is "not forking TypeScript" and defers all language-design authority to the TypeScript team.

Ecosystem consolidation + roadmap

  • Merging with tsc-rs. Cloudflare is working with Theo Browne to merge tsc-rs (ts-rust) and tsrs into a single package supporting all TypeScript features including Language Server Protocol (LSP) and content mappers.
  • Oxc integration. The Oxc team is refactoring the ported codebase to make it "faster, use less memory, and … maintainable." Planned: type-aware lint rules in Oxlint. tsrs sits alongside Cloudflare's other OSS Rust JS tools (Vite, Rolldown, Oxlint, Oxfmt).
  • "Why now." The port is feasible because "frontier AI models can now do large-scale ports almost independently in a matter of days" (concepts/agentic-development-loop); the field has already produced "slopforks, faithful ports, and completely re-architected versions of TypeScript in Rust or C++."

Caveats

  • Experimental. Early build; known divergences from upstream remain (e.g. diagnostic print order), targeted for elimination before a stable release.
  • Ratio-only, config-sensitive benchmarks. 8× / 70% are against TS 7.0 at matched configuration, not a broad representative suite — directional.
  • Compatibility is only as good as the sync process. The whole maintenance model exists because upstream TypeScript keeps evolving; a faithful port must not drift.

Seen in

Last updated · 854 distilled / 2,448 read