ts-rust: the TypeScript 7 compiler ported to Rust, by models

The premise is a question about model capability

The README opens with the reason the project exists. The author wanted to see if LLMs could port the TypeScript compiler, checker and lsp to Rust, and the answer turned out to be yes.

The project itself is called ts-rust, also known as tsc-rs, and it is a direct port of Microsoft's native TypeScript compiler, which is written in Go, in the microsoft/TypeScript repository, formerly known as typescript-go. It keeps Go's algorithms and behaviour, and it has the same command line, tsc, the same language server and the same API.

That last point is what makes it interesting rather than a curiosity. A type checker that is a faithful reimplementation of a specific upstream commit, with the same interface, is the kind of thing that can replace a build step. A type checker that is merely fast is a different tool.

The warnings section is where the honesty lives. This is an early release. It has 100% compatibility in every real world project the author has tested, and it should work as a drop-in replacement for the vast majority of apps, with a link to the known problems section for the rest. And then the line that is worth reading twice: also worth mentioning, I've never read a line of this code.

The project is MIT and Apache-2.0 licensed, the npm package is tsc-rs so that it does not clash with the typescript package, and the last push was on 2026-10-14, the same day as the v0.7.0 release.

The cost, in two rounds

The story of how the port was produced is the most unusual part of the README, and it comes with numbers.

The first attempt used a lot of OpenAI models, GPT-5.6 Sol and GPT 6 Astra, and it cost over 400,000 dollars in API priced tokens. The models wrote over 1.3 million lines of Rust over multiple months of goal loops, and the author says they never got past about 84% compatibility.

Then the second attempt. The author noticed how little his Claude Code limits were burning, decided it would be fun to throw Opus 5.5 at the problem, and it had a working v0 in 10 hours. He assumed it was continuing from the existing code and was wrong: Opus 5.5 started from scratch and got further than Astra in a tenth of the time.

He let it keep going. The total token spend was about 24,047 dollars of API spend over 2 weeks, using his Claude accounts, which worked out to somewhere between 925% and 983% of his 200 dollar plan weekly limits.

The summary line is worth keeping in view: expensive, for sure, but not that bad considering how much work has gone into typescript-go.

There is a structural detail behind that framing. The repository has a ts-rust-recovery-plan.html file, and the README marks a section called The Slop Line, below which everything was written by the models rather than by the author, including the explanation of what the project actually is.

So the provenance of this codebase is not a rhetorical flourish, it is the central fact about it, and it is the reason the warnings section reads the way it does.

The benchmark, and the footnotes under it

The benchmark table is a full type check of the T3 Code project with Effect diagnostics on, and the time is the sum of the medians for its five checked projects, with lower being faster.

The results are that tsc-rs in fast mode takes 9.77s and plain tsc-rs takes 14.30s, against 42.55s for tsc 7 as the baseline, 59.24s for bun check and 191.00s for tsc 6. The footnotes are where the honesty is. The tsc-rs figure is version 0.6.0 with Effect diagnostics built in. The tsc 7 figure comes from @effect/tsgo, so it is the native preview compiler rather than the JavaScript one. The bun check time adds a separate effect-tsgo diagnostics run on top, so it is not a like for like comparison. And tsc 6 uses the JavaScript Effect plugin, which is why it is four times slower than the native tsc 7.

Read with those footnotes, the honest summary is that the Rust port is roughly two to three times faster than the Go native compiler on this project, and that the older JavaScript tsc is in a different class entirely.

The wider compatibility claim is in the status section rather than the benchmark. On 60 open-source projects, type checking takes about half of Go's time, with a geometric mean. On 120 open-source repositories, the command line output differs from Go's only in the listed known problems and where Go's own output changes from run to run. And all 184,773 ported Go tests pass, with the language server and API answers matching Go on the oracle test sets.

Pinned to one upstream commit, and how to compare it fairly

The status section explains a detail that determines whether you can trust any comparison you do.

The port is pinned to one upstream revision, a specific commit in microsoft/TypeScript dated 2026-10-08, which is TypeScript 7.1.0-dev, and the pin is recorded in UPSTREAM.md with a matching UPSTREAM.json. To compare fairly you use [email protected], the same commit, and explicitly not 7.0.x and not @typescript/native-preview.

The README then makes the point that matters most for interpretation. A difference that this build also shows is upstream behaviour, and it goes away when the port moves to a newer pin. In other words, some of the gaps you will see are not port defects, they are the port being a faithful copy of a moving target.

Earlier versions used an older pin, with 0.3.0 and earlier on the 2026-09-29 revision, so a difference in behaviour between two versions of tsc-rs is not automatically a regression either.

The fast mode has the same honesty attached. --fast, or the GOPORT_FAST environment variable, turns on the last two switches and more checkers. It runs one checker per core, up to 16, and at most one per 32 source files, but never fewer than Go's 4, and the checker count can be set explicitly while tsc -b keeps 4. The number of cores is what the process can actually use, with CPU affinity and cgroup limits, so the checker count can differ on another machine. And each file goes to the checker that Go's split gives it, so the output of --fast is the same on every run.

Effect diagnostics came along with the port

The Effect integration is the most substantial feature beyond the checker itself, and it is worth understanding because it changes what the tool is for.

tsc-rust has the Effect language service diagnostics built in, with codes in the 377xxx range, so an Effect project needs no second compiler. The diagnostics come from the same check as the TypeScript diagnostics, and the language server shows them too. They run only when the tsconfig has the plugin.

{ "compilerOptions": { "plugins": [{ "name": "@effect/language-service" }] } }

The rules, options and @effect-diagnostics comments are a port of Effect-TS/tsgo 0.51.1, and so are the editor features: the Effect hover with its Layer summary, inlay hints, the auto-import style, quick fixes, document symbols, completions and refactors. The lightbulb, the quick fix menu and the editor's Refactor menu show the Effect refactors, and the server lists refactor.rewrite among its code action kinds.

The API stability rules are ported too, and they read the @stability JSDoc tags of Effect 4. unstableApiUsage, TS377136, and experimentalApiUsage, TS377135, report each use of an unstable or experimental API as a warning by default, with allowedUnstableApis and allowedExperimentalApis in the plugin entry to allow a module or a single export. apiStabilityLeak, TS377137, is off by default and is for library maintainers.

The practical effect for a project on effect@4 is that it gets the same TS377136 warnings for unstable imports as it would from effect-tsgo 0.51.1, which is the compatibility claim stated in terms of behaviour rather than in terms of output.

The Rust build, the two profiles, and the WASM target

The Cargo workspace is organised around the port itself. The members are crates/ts_goport with parts for the core, the language server protocol and the utilities, crates/ts_wasm, and two code generation tools, ts_ast_codegen and ts_diagnostics_codegen. The resolver is 3, the edition is 2024, and the workspace lints are strict, with unsafe_code forbidden outright and clippy running both the all and pedantic groups as warnings, plus redundant_clone as a warning.

Two release profiles matter, and the comments in the manifest explain why.

The goport profile inherits release with fat LTO and a single codegen unit, and it is built with cargo build --profile goport, with the binaries landing in the target/goport directory. Other crates keep the default release settings, and the test and dev profiles do not inherit it.

The wasm profile exists because the project wants a checker that runs in WASM with high performance, which is one of the stated motivations. It inherits release, uses opt-level z, which is the smallest, with fat LTO, one codegen unit, panic abort because WASM cannot unwind so panics abort, and strip. The size difference is quantified: opt-level z gives 4.2 MB where s with a lower inline limit is 5.2 MB and checks 13 to 18% faster, with scripts/wasm/build.sh holding the details.

That is a good example of a project documenting a trade-off instead of asserting a win, and it lines up with the README's stated motivation list, which includes making a ts checker that can work in WASM with high performance, alongside the more obvious one of making a fast TypeScript type checker, and the two more reflective ones, testing model capabilities and memes.

Editorial conclusion

ts-rust fits a TypeScript shop that wants a faster type checker today, especially one on the Effect language service, where the bundled diagnostics remove the need for a second compiler pass. It does not fit a team that needs a guaranteed drop-in replacement, because the README itself warns that this is an early release and that the author has never read the code, and it does not fit anyone who needs the checker to track upstream on their own schedule, since each port is pinned to one upstream commit. Verify three things before you adopt it: that your project matches one of the compatibility claims, which are stated for 60 and 120 repository samples rather than universally, that you pin the exact version you tested rather than tracking the weekly releases, and that the upstream revision it is pinned to has not moved on, because the README is explicit that differences in the output are upstream behaviour that disappears with a newer pin.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. pingdotgg/ts-rust on GitHub
4. README
5. Releases