# tsrs tsrs is a port of the [[TypeScript]] compiler to [[Rust]]. More precisely, it's a function-by-function port of TypeScript 7, the [[Go]] rewrite of the compiler that Microsoft ships as the native TypeScript (tsgo). The README states the goal: a drop-in replacement for the TypeScript 7 compiler and language server, with 100% conformance, much lower memory use and faster type checking. On October 20, 2026, [[Cloudflare]] announced that it and VoidZero now work on tsrs together with Max Schwenk of Owner.com, who started it. The project is incubated inside [[Oxc]] (the repo lives at `oxc-project/tsrs`), and Cloudflare says the work happens "in close collaboration with the TypeScript team". ## It's NOT a fork Cloudflare is very clear on this. The TypeScript team stays in charge of the language's design and direction, and tsrs has to follow their decisions closely, or it drifts away and becomes incompatible. The compatibility doc treats the Go code as the spec: any difference in diagnostics, their order, message text or exit code is a tsrs bug, "even when tsrs's output looks better". Performance gains are supposed to flow back too. Cloudflare plans to contribute them to the Go codebase, and says some of the optimizations in TypeScript 7.1 beta were already upstreamed from tsrs. ## Where it comes from Max Schwenk tells the backstory on Owner.com's engineering blog (October 19, 2026). Owner's backend monolith is about 37,000 TypeScript files checked as a single program. On TypeScript 7.0, a single-threaded check of it needed 19 GiB of memory and 80 seconds. Running tsgolint (Oxlint's type-aware lint backend) next to it doubled the memory. With 36 GiB MacBooks, engineers couldn't run several coding agents in parallel without risking a frozen machine. On September 30, 2026, he asked Claude Opus 5.5 for a faithful port of the Go compiler to Rust, and he says he wrote zero code himself. The rules were strict: same algorithms, function structure, evaluation order and diagnostics, pinned to one upstream commit, one Rust crate per Go package, and TypeScript's own conformance suite as the spec. After a night of 20+ subagents working in parallel, 78% of the error baselines matched byte for byte. Once a type printer was added, 13,458 of 13,462 matched, plus every type and symbol baseline. The first build was faster than Go but used MORE memory. Memory came down through a long series of measured experiments: lazy member resolution, smaller structs, pointer compression (4-byte offsets instead of 8-byte pointers), freeing checked files nothing imports, grouping files by their imports per checker, and work stealing between checkers. The repo also sets a bar so agents can't micro-optimize forever: a change lands only if it cuts single-threaded instructions by 1%, wall time by 2% or peak memory by 5%, with byte-identical output. ## Performance Cloudflare's headline number is up to 8x faster and ~70% less memory than TypeScript 7.0, with the same number of type check workers. They say they checked the benchmark setup with the TypeScript team, because other ports' numbers often come from bigger machines and non-default options. Here's their default-config chart (`--noEmit --incremental false --pretty false --checkers 4`; tsrs's October 19 build against TypeScript 7.0.2 and the 7.1 nightly of the same day): | Project | tsrs | TS 7.1 nightly | TS 7.0.2 | Peak memory, tsrs vs 7.0.2 | |---|---|---|---|---| | VS Code | 1.73 s | 5.28 s | 6.62 s | 1.78 vs 7.68 GiB | | MUI docs | 1.29 s | 4.05 s | 10.44 s | 1.03 vs 7.70 GiB | | webpack | 0.23 s | 0.71 s | 0.91 s | 0.37 vs 1.18 GiB | | t3code server | 1.21 s | 7.17 s | 9.82 s | 1.15 vs 6.34 GiB | So the "8x" is measured against 7.0.2 (MUI docs and t3code server). Against the 7.1 nightly, tsrs is roughly 3x to 6x faster on these four projects. Upstream is moving fast as well: Cloudflare says TypeScript 7.1 beta is up to 2.5x faster than 7.0. By default, tsrs picks an adaptive configuration based on the machine, which uses more memory but runs even faster. In Cloudflare's "maximum resources" chart (14 checkers), VS Code checks in 1.01 s against 4.57 s for 7.0.2. Owner's own numbers on their monolith (an earlier tsrs build, 4 checkers): 8.75 s and 6.1 GiB, against 61.4 s and 36.0 GiB for tsgo 7.0.2. ## Why Rust when the Go port exists? The Go port already made TypeScript about 10x faster than the JavaScript version (Cloudflare's words). Cloudflare's argument for Rust is WebAssembly. When you compile Go to Wasm, Go's garbage collector comes along. Rust's memory model makes memory exchanges between a Wasm guest and its host straightforward, which means a smaller memory footprint. That matters for [[Cloudflare Workers]], which have supported Wasm for a long time and recently got native Rust support through an Emscripten target for wasm-bindgen. Cloudflare's goal is to run a complete development toolchain end to end in a sandbox on Cloudflare, for [[AI Agents]], or client-side in the browser, on an embedded device or in an IoT application. The `@tsrs/wasm` package exists today (single-threaded, `wasm32-wasip1`), and there's a browser playground. ## Scope and limits (October 2026) tsrs does full type checking, not a subset. According to its compatibility doc, it also handles JavaScript and `.d.ts` emit, source maps, incremental builds, `--build` with project references, `--watch` (Linux and macOS only), and a [[Language Server Protocol (LSP)|language server]] (4,074 of 4,546 fourslash test groups pass). What's still missing or different: - It's experimental: no stable release as of October 2026 (the latest build shipped on October 19). The stable release will target TypeScript 7.1, with 100% conformance as the bar - Diagnostics can come out in a different order than tsgo, because tsrs makes some checker choices deterministic while tsgo's output depends on parallel order. A Go-compatible mode exists for comparisons - No `--init`, no `--showConfig`, English messages only, no automatic type acquisition - Content mappers (`.vue`, `.svelte`, `.astro`) work in the CLI but not in the language server - Issues are open, but pull requests are closed for lack of review bandwidth - License: Apache-2.0, as a derivative of Microsoft's TypeScript, and "not affiliated with or endorsed by Microsoft" To try it: `npm install tsrs`, then `npx tsrs` (the README uses `--noEmit`). ## How it stays in sync Cloudflare plans to merge Theo Browne's tsc-rs (`pingdotgg/ts-rust`) with tsrs into a single package that supports all of TypeScript's features. For upstream sync, they reuse the agent workflow they run for Vinext against [[Next.js]]. Each morning, an agent reviews upstream changes and opens tracking issues. Each night, the compatibility matrix is regenerated. When a gap shows up, agents locate the change in both codebases, build a reproduction, port the relevant tests and propose a fix. ## How it relates to Oxc [[Oxc]] is the home: same GitHub org, the same Clippy lint baseline, and Cloudflare says the Oxc team has begun refactoring the codebase "to make it faster, use less memory, and make it maintainable". tsrs doesn't depend on Oxc's parser or AST crates (it ports TypeScript's own parser and checker), so what ties them together is the organization and the team. The first integration Cloudflare names is type-aware lint rules in Oxlint. Today, Oxlint's type-aware rules run on tsgolint, a separate Go backend built on typescript-go. Max Schwenk already ported that backend onto tsrs as `tsrslint` (all 60 rules, opt-in by pointing Oxlint at a different binary). On eight open source projects, he reports 37.3 s against 169.4 s for tsgolint, and 11.5 GiB peak memory against 45.0 GiB. ## My take What I find most interesting is HOW this was built. One engineer, one model, a pinned upstream commit, and a conformance suite of 15,000+ cases that Microsoft left behind from its own JavaScript-to-Go port. That suite is what made an agent-written port verifiable at all, and Owner added fault injection, a shadow mode that recomputes cached answers, and a determinism gate on top. The motivation matters as well. At Owner, memory was the bottleneck: type checking became a problem once several agents each check their own worktree in parallel. I expect more tooling to get rewritten for that reason. I'd still wait before switching a team's CI. TypeScript now has several implementations (Go, tsrs, Theo Browne's port), and the "Go code is the spec" rule only holds if the sync process keeps up. The stable release against TypeScript 7.1 is the milestone to watch. ## References - [Introducing tsrs: a port of TypeScript to Rust (Cloudflare blog, October 20, 2026)](https://blog.cloudflare.com/typescript-rust-port/) - [tsrs (Owner.com engineering blog, October 19, 2026)](https://building.owner.com/tsrs) - [tsrs on GitHub](https://github.com/oxc-project/tsrs) - [tsrs compatibility and evidence](https://github.com/oxc-project/tsrs/blob/main/docs/COMPATIBILITY.md) - [tsrs on npm](https://www.npmjs.com/package/tsrs) - [tsrslint on GitHub](https://github.com/maschwenk/tsrslint) - [tsc-rs (ts-rust) on GitHub](https://github.com/pingdotgg/ts-rust) - [Oxlint type-aware linting](https://oxc.rs/docs/guide/usage/linter/type-aware) ## Related - [[Oxc]]: incubates tsrs; type-aware rules in Oxlint are the first integration target - [[TypeScript]]: the language; Microsoft's team keeps control of its design - [[Go]]: the language of TypeScript 7, which tsrs ports function by function - [[Rust]] - [[Cloudflare]] · [[Cloudflare Workers]]: the sponsor and the Wasm target - [[Microsoft]] - [[Language Server Protocol (LSP)]] - [[AI Agents]]: the parallel-agent workloads that made memory the bottleneck - [[Vite]]: the other VoidZero project now under Cloudflare