Handed to AI at 1:30 a.m., woke up to a Rust TypeScript: tsrs's 2,900 stars came from Cloudflare

Max Schwenk. One night in Sep 30, he had Claude Opus 5.5 port Microsoft's Go version of TypeScript to Rust line by line, writing none of the code himself. In Oct 1, his own HN post got only 4 points. Three weeks later Cloudflare and VoidZero announced they were taking it over, and the project gained 1,300 stars in two days. The same month, several other "AI ports TS to Rust" projects appeared, and only this one took off. Below: why it caught on, where the stars came from, which moves are worth learning, and why making another copy of the same thing isn't recommended.

A 19 GiB type check

Max works at Owner.com, a restaurant SaaS company. Their backend monorepo, Olympus, has about 37k TypeScript files. A single-threaded type check with TypeScript 7.0 (the Go rewrite Microsoft shipped last year, also called tsgo) takes 19 GiB of memory and 80 seconds. Adding lint and the language service pushes it past 50 GiB. In their engineering blog 10-19, they wrote that even on a $3,000 MacBook with 36 GiB of memory, engineers don't dare run several agents at once or the machine locks up. They tried having agents "take turns," written into the rules file, but "the agents don't always listen."

In Sep 30, he came up with an idea:

"I wonder if Opus 5.5 can port the TypeScript compiler to Rust in one go."

His rules were strict: algorithms, function structure, evaluation order, and error messages all match upstream; pin to one specific upstream commit; no redesigning; one Go package maps to one Rust crate; use TypeScript's own 15,197 conformance cases as the spec. Around 1:30 a.m., he set 20 sub-agents running in parallel all night. The next morning, the first end-to-end run had 78% of the error baseline byte-identical. After adding type printing, only 4 of 13,462 differed, with 99.97% consistency.

Then came weeks of "hill climbing": change one thing at a time, compare output against the Go version, benchmark, and throw away anything that doesn't meet the bar. The repo spells out a merge gate: cut single-thread instruction count by 1%, or wall time by 2%, or peak memory by 5%, and the output must match byte for byte, or the change isn't accepted. On Olympus, with 8 check threads, tsrs takes 5.8 seconds and 7.5 GiB, while tsgo takes 7.0 seconds and 56.6 GiB (49.8 GiB). Owner's blog, author's own measurements.

What it is

tsrs is a Rust port of the TypeScript 7 type checker and language service. pnpm add -D tsrs installs it as a drop-in replacement for tsc / tsgo for --noEmit checks. It also ships a Wasm package that runs in the browser and an online playground. The repo was created 10-01 under the author's personal account and has since moved to oxc-project (the org behind oxlint and Rolldown), Apache-2.0. In the commit history, the author has 1,321 commits and Oxc's Boshen has 357. PRs are closed to outside contributors, and the README says the maintainers "don't have the bandwidth." Releases have been frequent: v0.18 (10-19) through v0.22 (11-05), with a --fast mode added along the way.

Which two days the stars came in

(GitHub daily stars; 11-06 repo page live 2,933)

10-01 The author posted it on HN himself: 4 points, no one paid attention. The turn came from two blog posts:

• 10-19, Owner engineering blog: the full story behind the "19 GiB, handed to AI overnight, woke up 99.97% done" line above. Strong narrative, but it's one company's engineering blog, so its spread is limited.
• 10-20, Cloudflare's official blog "Introducing tsrs": Cloudflare and VoidZero (the company behind Vite / Oxc, which Cloudflare acquired) co-published it, stating "we work closely with the TypeScript team" and "we are not forking TypeScript". The headline numbers were "up to 8x faster, about 70% less memory". It hit the HN front page the same day, with 437 points and 213 comments.

The most weighty comment in the HN thread came from Daniel Rosenwasser of the TypeScript team: he said they were studying with the tsrs maintainers why it's fast, that part of TS 7.1's speed and memory gains "actually came from tsrs", and congratulated "the tsrs team for turning this into a formal project". When the official team backs you in public, for an AI-written port that does more than any benchmark.

Stars really took off on 10-21 and 10-22, a day or two after the blog and HN. My inference is secondary spread on X, Reddit, newsletters and YouTube (socket.dev and Flavio Copes wrote explainers, and there are YouTube videos like "TypeScript Got Ported To Rust"), but I didn't pin down which one pushed it. Heat has since cooled: +284 in the last 7 days, +655 over the first 7 days.

On npm, tsrs got about 9.45M downloads in the last 30 days, and since 10-22 it has run 420k to 1.07M per day (npm download stats, as of 11-05). That's already the same order of magnitude as Microsoft's official @typescript/native-preview, at 6.82M a week. How much of that is CI, mirrors and per-platform binaries counted repeatedly, you can't tell from outside, so don't read it as a user count.

In the same month, several people were doing the same thing

Some on HN also said outright, "you're all building the same thing." Technically, "porting a compiler in a few days with a frontier model" is no longer rare, as Cloudflare's own blog says.

Why this one

AI ports aren't all alike. tsrs differs from the others not in the code, but in three things:

1. Faithful, and provably so. It pins the upstream commit, uses the official test suite as the spec, compares output byte for byte, and has deterministic checks and fault injection in CI. Others compete on "who's faster"; tsrs first answers "will it quietly miss errors".
2. Someone maintains it long-term. The biggest doubt about slopforks is "who keeps up with upstream later". tsrs's answer: Cloudflare, VoidZero and the Oxc team take it over, syncing with upstream daily using agents (the same approach they use to keep Vinext in sync with Next.js). The author says it plainly in the blog: he wants the project in the hands of "people who make a living building Rust tools", not "someone with a day job".
3. The people behind it have their own reasons. Compiling Go to Wasm drags the garbage collector along; Rust doesn't. Cloudflare wants the full TS toolchain running inside Workers sandboxes and browsers, and that's the commercial motive for its investment. Someone on HN got this: "It's not about making a faster compiler; it's about a compiler that can run in a pure Wasm sandbox."

So be clear on the order: the direct cause of the star surge was Cloudflare's backing and the TS team's endorsement, not the code itself. The author's own HN post got 4 points, while Cloudflare's blog reached the HN front page the same day. That contrast says it all.

How many people know about it

Plenty. Cloudflare's official blog broke it, HN hit 437 points, socket.dev and several tech blogs explained it, there are YouTube videos, and Theo's project even got covered by The Register. Anyone in front-end circles who cares about toolchains has basically heard of it, and a string of copycat port repos has followed.

If it were you

Verdict: C. tsrs's approach is worth learning from, but building another "AI-ported TypeScript" isn't worth it. Its stars came from Cloudflare taking it over and the TS team's endorsement, a starting point latecomers can't borrow. Within a month this topic already has four or five peers, and Cloudflare is merging tsrs and tsc-rs into one.

Who it suits: engineers with a big codebase who are genuinely held back by a tool's speed or memory; people fluent in a systems language who can read a profile and are willing to get the upstream test suite running.

Who it doesn't suit: people hoping to get stars with "I also had AI port XX". The default reaction to that headline now is "another slopfork": no test proof, no maintainer, and nobody looks at it a month later.

How to do it, ranked by how worthwhile:

1. Pick a slow tool nobody has ported yet. Criteria: upstream has a large, comprehensive official test suite (usable as the spec), users have real speed or memory pain, and a language switch enables something new like Wasm or embedding. Follow tsrs's rules: pin the upstream version, compare output byte for byte, publish the benchmark method, and write a merge gate. What gets stars is showing the compatibility rate on day one (e.g. "4 of 13,462 cases differ").
2. Build around tsrs. It's just starting and PRs aren't open, but issues are: integration guides for various frameworks and monorepo tools, CI templates, benchmarks on your own big repos, editor plugins. The star ceiling is low, but there's almost no bet involved.
3. Write the method up as a tool or tutorial. "How to run a verifiable large-scale port with an agent": test suite as spec, parallel by package, byte-level diff, merge gate, decision log to stop the agent retrying the same dead end. Make it a reusable template repo; that's easier to bookmark than another port. Others are already building similar port tools, so get specific rather than generic.

How to get users: first use it for real on your own team or at a company with a big warehouse, and get hard numbers like "was X seconds, now Y seconds." Then write an engineering blog post like Owner's, with people, timeline and numbers. Next, find a relevant org or upstream team to host or back it, and have them post it. tsrs proves the point: the same project got 4 points posted by its author and 437 points posted by an org. Without that backing, write your HN launch post as a full story, not a one-liner like "I ported XX."

Ship before when: the earlier the better for item #1, estimated before the first half of 2027. The "AI migration" trend is still hot and most tools haven't been ported yet. Once every popular tool has two or three AI versions, new ports are just noise.

What would show I'm wrong: ① If an unbacked personal port also reaches a thousand stars within a month, it means "AI port + test proof" alone draws traffic, and entry 1 is worth doing sooner and bolder; ② If star growth for tsrs and tsc-rs after the merge climbs back to several hundred a day within two to three months, the ceiling for this direction is higher than estimated here, and the value of building around it (entry 2) rises too; ③ If the official TS 7.x matches tsrs on memory before year-end, the case for "rewrite in another language" is weakening, and entry 1 needs more selectivity, picking only tools where a language switch brings something new (like Wasm).

Data and sources

GitHub: the oxc-project/tsrs repo page, README, commit history, release history, daily stars (10-17 to 11-06); peer repo stars (11-06). npm download stats: tsrs, tsc-rs, @typescript/native-preview (as of 11-05). Blogs: building.owner.com/tsrs (10-19), blog.cloudflare.com/typescript-rust-port (10-20), blog.cloudflare.com/voidzero-joins-cloudflare (6-04). HN: "Tsrs: A Port of TypeScript to Rust" (10-20,437 points) and comments, tsc-rs thread (119 points). Media and explainers: socket.dev, flaviocopes.com, The Register (10-15). Where it says "inference" or "unverified", that's inference or unverified.