TypeScript 7 Port to Rust Proved Up to 6.5x Faster than tsc (and It's Coming in 7.1)

tsrs is a Rust port of the TypeScript 7 compiler that you can already install from npm, and in our test it was between 2.9x and 6.5x faster than tsc 7.0.2, with between 2x and 4.2x less memory. Cloudflare, VoidZero, and Max Schwenk from Owner.com announced it on October 20, 2026. The project is incubated within the Oxc toolchain and is being developed in collaboration with the TypeScript team.

:white_check_mark: yoDEV Tested · October 20, 2026 We ran tsrs 0.18.0 against tsc 7.0.2, tsc-rs 0.7.0, and bun check 1.4.3 on zod, playwright, and hono, on a Linux machine with 2 vCPUs. The results we report as ours come from that test.

What is tsrs, the TypeScript compiler in Rust?

tsrs is a drop-in replacement for the TypeScript 7 compiler (tsc) and its language server, written in Rust. It reads your current tsconfig.json, emits JavaScript and declarations just like tsc, and supports --watch, -b, and an LSP mode for editors. Its stated goal is 100 percent conformance with TypeScript, with less memory and faster type checking.

It’s not a fork. The Cloudflare announcement makes it clear: the TypeScript team still controls the language design, and tsrs must follow upstream decisions, not make its own. Today it follows the main branch of microsoft/TypeScript, and each version of the package indicates the commit it ports: 0.18.0-ts7.1.0-dev.20260929 is tsrs 0.18.0 following TypeScript 7.1.0-dev.20260929.

Two things worth knowing from the start:

  • AI agents wrote it. Max Schwenk, Head of AI Developer Experience at Owner.com, started it on September 30 by wondering if Claude Opus 5.5 could port the compiler from TypeScript’s Go code. According to his account, he didn’t write any code himself: the agents worked with the TypeScript conformance suite as specification. On October 19, the project moved to oxc-project/tsrs, under Cloudflare and VoidZero.
  • Why Owner.com built it. Their main codebase has about 37,000 TypeScript files. With TypeScript 7.0, a single-threaded check took 80 seconds and used 19 GiB of memory. With tsrs, Owner reports about 7 seconds in CI.

License: Apache-2.0, as a derivative of TypeScript. The README clarifies that it is not affiliated with or endorsed by Microsoft.

How to install tsrs?

Add it as a dev dependency and run it where you’d run tsc:

pnpm add -D tsrs
pnpm exec tsrs --noEmit

With npm, the Cloudflare announcement uses:

npm install tsrs
npx tsrs

To try it without adding it to the project: pnpm dlx tsrs -p .

Useful commands from the usage documentation:

pnpm exec tsrs -p path/to/project           # compile
pnpm exec tsrs -p path/to/project --noEmit  # type check only
pnpm exec tsrs -p . --extendedDiagnostics   # counters and timing
pnpm exec tsrs --version
tsrs --watch -p .                           # recompile on save
tsrs --lsp -stdio                           # language server for editor

The npm launcher installs a native binary for your platform as an optional dependency @tsrs/<os>-<arch>. There’s also a browser playground (tsrs-playground.void.app) and a WebAssembly build, @tsrs/wasm, for Node and browsers.

What it doesn’t do yet: --init and --showConfig are not supported, so keep tsc handy to generate configuration.

Is tsrs faster than tsc? Our benchmark

Yes: in our test it was between 2.9x and 6.5x faster than tsc 7.0.2 (the Go compiler, also known as tsgo). The figure of up to 8x faster with around 70 percent less memory is Cloudflare’s own benchmark: tsrs against TypeScript 7.0 with the same number of checking workers. The benchmark published by the project used 17 projects on a CI machine with 16 vCPUs and 63 GB, and the code is in the repo under bench/.

We wanted numbers on a smaller machine, so we repeated our bun check test setup: the same three repos, 2 vCPUs, 7 GB of RAM, one warm-up run plus five measurements (ten for hono), median total time and peak memory.

Project tsc 7.0.2 tsrs 0.18.0 tsc-rs 0.7.0 bun check 1.4.3
zod (593 errors) 5.82 s · 1.118 MB 0.90 s · 266 MB 1.46 s · 632 MB 1.42 s · 192 MB
playwright (5,664 errors) 3.12 s · 581 MB 0.73 s · 195 MB 1.19 s · 417 MB 1.05 s · 189 MB
hono, build config (clean, 364 files) 0.32 s · 98 MB 0.11 s · 49 MB 0.10 s · 103 MB —

Compared to tsc 7.0.2, tsrs was:

  • zod: 6.5x faster, 4.2x less memory
  • playwright: 4.3x faster, 3.0x less memory
  • hono: 2.9x faster, 2.0x less memory

Two things stood out. First, the gain isn’t just parallelism: with a single checking thread in both (--checkers 1), tsrs was still 4.8x faster on zod and 3.3x on playwright. Second, it holds up on small projects. In our previous test, bun check was slower than tsc on the clean hono build; tsrs was almost three times faster with the same configuration.

tsrs or bun check?

tsrs was faster than bun check on the two large repos. Memory was about the same on playwright, but on zod tsrs used more (266 MB vs. 192 MB). If memory matters more to you than speed, --checkers 1 brought tsrs down to 195 MB on zod and stayed below 1.2 seconds.

What flags control speed and memory?

tsrs adds some performance options to tsc’s standard flags:

  • --checkers N sets how many checking threads to use. By default, one per core up to 16.
  • --singleThreaded uses a single thread, for the lowest memory consumption.
  • --maxMemory <size> (e.g. 12G, only with --noEmit) keeps the process near that limit, trading CPU for memory.
  • --checkerCostCache <file> remembers how long each file took to better distribute threads on the next run.

Does tsrs give the same errors as tsc? The shift to TypeScript 7.1

Yes, as long as you compare it with the version of TypeScript it actually ports, and that’s the catch: tsrs follows TypeScript 7.1-dev, not 7.0.

On zod, tsrs and tsc 7.0.2 reported the same 593 errors, line by line. On playwright, both reported 5,664 errors, but 20 appeared on different lines and columns. On hono’s build configuration, tsc 7.0.2 came back clean and tsrs reported two new TS7031 errors (implicit any).

Then we ran typescript@7.1.0-dev.20260930.4, the build of the commit tsrs ports. Its output matched tsrs exactly on both repos. The differences are TypeScript 7.1 behavior, not tsrs bugs.

In practice: switching tsc 7.0 to tsrs in your CI means moving your type check to 7.1-dev semantics. A repo that’s clean today might start failing. Test it locally first and treat it as an upgrade, not a transparent swap.

One more detail for CI: with errors, tsc 7.0.2 exited with code 1 and tsrs with code 2. TypeScript 7.1-dev also returns 2. Both are nonzero, so the CI step fails the same, but a script that compares exactly to 1 won’t.

The project itself says it wants to reduce the remaining differences, like the order diagnostics are printed, before a stable release. For the closest comparison with the Go compiler, the README suggests --checkerAssignment go --noLazyMembers.

tsrs vs tsc-rs: which TypeScript-to-Rust port to use?

They’re two different npm packages with nearly identical names, and it’s easy to mix them up.

tsrs tsc-rs
npm package tsrs tsc-rs
Repo oxc-project/tsrs pingdotgg/ts-rust
Behind it Oxc, Cloudflare, VoidZero; born at Owner.com pingdotgg (Theo Browne)
License Apache-2.0 MIT AND Apache-2.0 (npm)
Ports TypeScript 7.1-dev TypeScript 7.1-dev
How it was written AI agents (Claude Opus 5.5) AI agents: first OpenAI models, then Claude Opus 5.5

Both are LLM ports from the same Go compiler. The tsc-rs README tells how the first attempt with OpenAI models cost over 400,000 dollars in API tokens and stalled at around 84 percent compatibility, and how the restart with Claude Opus 5.5 took about two weeks and around 24,000 dollars.

In our test, both gave identical diagnostics on all three repos. tsrs was about 1.6x faster on the large repos and used about half the memory; on hono they tied on time and tsrs used half the memory.

The choice may not last. The Cloudflare announcement says they’re working with Theo Browne to merge tsc-rs and tsrs into a single package. As of October 20, 2026, that merge is announced but not released, and the ts-rust README doesn’t mention it yet.

Is tsrs ready for production?

It’s an experimental version with a clear path to a stable one. Cloudflare calls it experimental; the README, however, names concrete limitations instead of a general warning, and says that in their tests on existing projects they haven’t found a correctness bug. The stated goal is a stable release on TypeScript 7.1 with 100 percent conformance.

Before adopting it:

  • Open issues, closed PRs. The tracker accepts bug reports with a minimal reproduction; maintainers say they don’t have capacity to review pull requests.
  • Pin the version. Each version of the package indicates the TypeScript commit it follows, so updating can change diagnostics.
  • Good first use: a local check or in pre-commit, or a CI job that runs alongside tsc until you trust the output.
  • Where it’s headed: Cloudflare mentions lint rules with type information in Oxlint, and Rust-to-WebAssembly compilation is one of the stated reasons for choosing Rust over Go: running a complete TypeScript toolchain in the browser or in an isolated Worker.

What about you? What do you use today for type checking in your CI, and how long does it take?

What type checker do you use in your CI today?
  • tsc 7 (tsgo)
  • bun check
  • Going to try tsrs
  • I prefer another option (tell us which)
0 votantes

Comment below or, if this article reached you by email, reply directly to the email: your reply gets published here.

Related: bun check vs tsc: we tested Bun’s new type checker on zod, playwright, and hono