Cloudflare and VoidZero release tsrs, a Rust port of TypeScript 7 that they say type-checks up to 8x faster

Cloudflare and VoidZero said on 20 October 2026 that they are working with Max Schwenk of Owner.com on tsrs, a Rust port of the TypeScript compiler. It is an experimental, drop-in candidate for TypeScript 7, the Go-based compiler Microsoft shipped in July. The project says it type-checks up to 8x faster than TypeScript 7.0 and uses about 70% less memory at the same number of checker workers. Those are the project's own measurements, and they matter mainly to teams whose type-check step has become a bottleneck in CI and in editors.

Key points

• Cloudflare announced on 20 October 2026 that it and VoidZero are working with Max Schwenk of Owner.com on tsrs, a Rust port of the TypeScript compiler, incubated as part of the Oxc toolchain and built "in close collaboration" with the TypeScript team.
• Cloudflare's headline benchmark: tsrs is up to 8x faster and uses about 70% less memory than TypeScript 7.0 with the same number of type-check workers.
• tsrs is a function-by-function port of the Go implementation of TypeScript, and the repository reports a match on 13,458 of 13,462 error baselines in TypeScript's conformance suite (the other four are described as test-harness artifacts).
• The package is experimental. The target is a stable release against TypeScript 7.1 with 100% conformance, and the repository's pull requests are closed.
• Cloudflare says it is not forking TypeScript: the TypeScript team stays in charge of the language, and tsrs follows its decisions.

What happened

In a post on the Cloudflare blog, the company said it and VoidZero are now working with Max Schwenk of Owner.com on tsrs, "a Rust port of the TypeScript compiler", and are incubating it as part of the Oxc JavaScript compiler toolchain. Cloudflare says the work is done in close collaboration with the TypeScript team. The company is explicit about what it is not doing: it is not forking TypeScript, because "the TypeScript team should remain in full control of the language's design and direction."

You can try it today. The announcement and the repository both say to install the tsrs package from npm and run it, for example pnpm exec tsrs --noEmit to type-check without writing JavaScript. The repository describes tsrs as a drop-in replacement for the TypeScript 7 compiler and language server. It also ships a WebAssembly build (@tsrs/wasm, targeting wasm32-wasip1), and there is a browser playground linked from the README.

The project is licensed under Apache-2.0 according to the badge in the repository README. Pull requests are closed because the maintainers say they don't have the bandwidth to review them; the issue tracker is open for bug reports with minimal reproductions.

Cloudflare also made a point about benchmarking. The post says recent benchmarks of different TypeScript ports have made varied performance claims, often because of larger machines and different options than TypeScript's defaults, and that it worked with the TypeScript team so its comparison uses the same configuration on both sides. It also says the next TypeScript version already brings improvements: TypeScript 7.1 beta is "up to 2.5x faster than TypeScript 7.0", and some of those optimisations were upstreamed from tsrs.

Background

TypeScript's team announced a native port of the compiler to Go in 2025, and on 8 July 2026 released TypeScript 7.0, which the TypeScript blog called "a 10x faster native port of TypeScript". The 7.0 release candidate post, from 18 June, said 7.0 is often about 10 times faster than TypeScript 6.0, thanks to native code speed and shared-memory parallelism. That Go port is the reference that tsrs follows.

Cloudflare's post argues why a second native port is worth having. Its first answer is "frontier AI models can now do large-scale ports almost independently in a matter of days", and it says there are now "slopforks, faithful ports, and completely re-architected versions of TypeScript in Rust or C++". Its second answer is WebAssembly. When a Go program is compiled to Wasm, the Go garbage collector comes along with it; Rust's memory model, Cloudflare argues, makes interaction between a Wasm guest and its host more straightforward and keeps memory use down. That matters for running whole development environments in sandboxes: Cloudflare says that with Wasm you can run a toolchain end to end in a fully sandboxed environment on Cloudflare, in a browser, or on an embedded device.

The company also has a stake in the surrounding toolchain. Cloudflare says it is already the home of several open-source Rust tools in the JavaScript ecosystem, naming Vite, Rolldown, Oxlint and Oxfmt, and that it is considering deeper tsrs integration, for example for type-aware lint rules in Oxlint.

The numbers

The Cloudflare post shows its headline charts as images; the figures in the text are "up to 8x faster" and "~70% less memory" against TypeScript 7.0 with the same number of type-check workers. The tsrs repository publishes a fuller benchmark snapshot in bench/RESULTS.md, which we used for the chart below. It compares tsrs with typescript@7.0.2 (tsgo) on 17 projects, on a 16-vCPU, 63 GB machine, using the median of 10 interleaved runs for tsrs and 3 for tsgo. The tsrs build ports a later 7.1-dev commit than tsgo 7.0.2, and the file notes that benchmark CI is currently disabled and that this is a historical snapshot.

At four checker threads, tsgo's default, tsrs was between 4.37x and 11.81x faster on wall time across those projects. Here are the largest and a few mid-range ones:

mui-docs11.81

t3code-server8.96

mikro-orm6.87

next-packages-next6.73

drizzle-orm6.5

formbricks-web5.93

storybook5.81

vscode4.95

Compiler4.37

tsrs speed-up over TypeScript 7.0.2 (tsgo) at 4 checker threads (times faster)

	times faster
mui-docs	11.81
t3code-server	8.96
mikro-orm	6.87
next-packages-next	6.73
drizzle-orm	6.5
formbricks-web	5.93
storybook	5.81
vscode	4.95
Compiler	4.37

Source: oxc-project/tsrs bench/RESULTS.md (snapshot)

Absolute times show what that means in practice. On the VS Code codebase at four checkers, the table lists 10.94 s for tsgo and 2.21 s for tsrs. For mui-docs it lists 12.69 s against 1.07 s. Peak memory at four checkers falls from 7.61 GiB to 1.05 GiB on mui-docs and from 7.49 GiB to 1.80 GiB on VS Code.

Two caveats are worth keeping in view. First, the figures differ from Cloudflare's headline: the repository snapshot shows up to 11.81x at four checkers, while the announcement says up to 8x at equal worker counts. The two come from different configurations and commits, so treat the headline as the conservative one. Second, tsrs by default uses more threads than tsgo (on a 16-core machine, 16 checkers against tsgo's 4). In that default comparison the snapshot lists speed-ups of up to 16.87x, but that mixes a speed-up from the port with a speed-up from simply using more cores, which is why Cloudflare's post stresses same-worker comparisons. Memory is also traded: the project notes that its default adaptive configuration "uses more memory but is even faster".

How it works

tsrs is described in its compatibility notes as a function-by-function port of the Go implementation, taken from a specific TypeScript 7.1.0-dev commit (b85298b6a81f). The Go code is treated as the specification: any difference in diagnostics, their order, message text or exit code is a tsrs bug, "even when tsrs's output looks better". That rule is what makes it plausible as a drop-in replacement, because editors underline code from diagnostic locations and CI scripts depend on exit statuses.

On correctness, the repository says tsrs matches the reference on 13,458 of 13,462 error baselines in TypeScript's own conformance suite, with the other four attributed to test-harness artifacts, and on all 12,779 .types and .symbols baselines. It adds that in testing on existing projects the maintainers have not yet found a correctness bug. The README is open about known gaps: --init and --showConfig are not supported, and diagnostics can come out in a different order than in the pinned Go compiler because the Go compiler's own output depends on parallel parse, resolution and check order while tsrs canonicalises some of it by default. For the closest comparison the README suggests --checkerAssignment go --noLazyMembers.

Speed beyond a straight translation comes from changes the project documents, according to an independent write-up by developer Flavio Copes, who lists memory-layout changes, checker caches and changes to how work is split between threads. The compiler's job is unchanged: read the project configuration, parse, bind names to declarations, check types and optionally emit JavaScript and declarations. The compiler is not your application's runtime, so a faster type checker shortens the wait during development and builds but does not make the JavaScript you ship run faster.

What it means

For teams on large TypeScript monorepos, the practical question is whether type-checking time in CI and in the editor is a problem after moving to TypeScript 7. TypeScript 7.0 already cut it by roughly an order of magnitude compared with 6.0 according to the TypeScript team, so tsrs competes for the remaining gain. If it holds up, the largest benefits in the benchmarks are on big projects with many files, where the memory reduction (about 2x to 7x in the repository's four-checker table) also lets CI runners with less RAM do the job.

For tool builders, the Wasm angle is the more distinctive part. Running a complete type checker inside a browser tab or a Workers sandbox is what in-browser editors and coding agents need. For the Oxc and Vite ecosystem, it opens the way to type-aware linting without shelling out to a separate compiler.

For the TypeScript project itself, tsrs puts a well-resourced, differently-implemented second compiler beside the official one, with a stated commitment to follow upstream rather than diverge. Cloudflare says it will keep tsrs in sync with the Go compiler the way it keeps its Next.js-compatible framework Vinext in sync: an agent reviews upstream changes each morning and a compatibility matrix is regenerated nightly. Whether that works over years is the open question, and it is where past ports have failed: Cloudflare itself notes that of many attempts over the years to port TypeScript, only the TypeScript team's Go port succeeded.

What we don't know yet

• Independent benchmarks. All performance numbers so far come from the project and Cloudflare. We have not seen results from third parties on private codebases.
• Maintenance over time. The post describes a process, not a track record. Staying faithful to a fast-moving upstream is the hard part, and tsrs targets a development commit of the Go compiler.
• Stability. The npm package is experimental, and a stable release is planned against TypeScript 7.1. No date was given.
• Differences to upstream. Cloudflare acknowledges differences such as the order in which diagnostics are printed and says it aims to reduce them before a stable release.
• Governance. Pull requests are closed for now; how outside contributors will be involved later is not stated.

What to watch next

Watch for the 7.1 release of TypeScript itself, since Cloudflare says some of its speed-ups were upstreamed and tsrs targets 7.1. Also watch the tsrs issue tracker for conformance reports from large real-world repositories, the planned merge with Theo Browne's tsc-rs into a single package including language server support, and any Oxlint integration for type-aware rules.

Sources

• Introducing tsrs: a port of TypeScript to Rust, Cloudflare blog (primary source)
• oxc-project/tsrs README and compatibility notes
• tsrs benchmark results
• A deep dive into tsrs, Flavio Copes
• TypeScript team blog, Microsoft (TypeScript 7.0 and 7.0 RC announcements)