21. Oktober 2026 · 9 Min.

TypeScript in Rust: erst messen, dann migrieren

Cloudflare und VoidZero haben am 20. Oktober den experimentellen TypeScript-Checker tsrs vorgestellt. So testet man Tempo, Speicher und Kompatibilität parallel zum bestehenden Compiler — ohne die CI zum Experiment zu machen.

TypeScript in Rust: erst messen, dann migrieren

Ein schneller Benchmark ist noch kein Migrationsplan

Am 20. Oktober 2026 haben Cloudflare und VoidZero gemeinsam mit Owner.com tsrs vorgestellt: einen Rust-Port des TypeScript-7-Typecheckers, der im Oxc-Projekt entwickelt wird. Die frühen Zahlen klingen spektakulär. Cloudflare berichtet bei gleicher Zahl von Typecheck-Workern von bis zu achtfacher Geschwindigkeit und ungefähr 70 Prozent weniger Speicher gegenüber TypeScript 7.0.

Die falsche Reaktion wäre, am nächsten Morgen in jeder Pipeline tsc durch tsrs zu ersetzen. Die richtige Reaktion ist ein kontrollierter Paralleltest. Denn ein Typechecker spart nur dann Zeit, wenn er denselben Code zuverlässig bewertet, dieselben relevanten Fehler findet und sich in Editor, CI und Build-Prozess einfügt.

Dieser Artikel zeigt, wie wir einen neuen Checker prüfen würden: mit einer reproduzierbaren Baseline, getrennten Messgrößen, einem Diagnostics-Vergleich und einem Rollback, der keine Heldentat braucht.

Was genau angekündigt wurde

tsrs ist kein neuer TypeScript-Dialekt und laut Cloudflare ausdrücklich kein Fork, der die Sprache in eine andere Richtung ziehen soll. Das Projekt will TypeScript 7 möglichst treu nach Rust portieren. Die TypeScript-Mannschaft soll weiterhin allein über Sprache und Semantik entscheiden; Verbesserungen sollen, wo sinnvoll, auch zurück in die offizielle Go-Implementierung fließen.

Der Checker ist heute experimentell. Das Repository nennt eine stabile Version gegen TypeScript 7.1 mit 100 Prozent Konformität als Ziel, dokumentiert aber noch Unterschiede und fehlende Funktionen. Unter anderem sind --init und --showConfig derzeit nicht unterstützt; auch die Reihenfolge von Diagnosen kann abweichen.

Das ist keine Randnotiz. „Drop-in replacement“ beschreibt das Ziel und den Bedienweg — nicht die Garantie, dass jedes Tooling, Plugin und jede interne Compiler-API heute schon identisch funktioniert.

Die Benchmark-Zahl gehört in ihren Kontext

„Bis zu 8× schneller“ ist eine Messung, kein Naturgesetz. Cloudflare vergleicht tsrs und TypeScript 7.0 mit derselben Zahl von Typecheck-Workern. Gleichzeitig zeigt der Beitrag, dass TypeScript 7.1 beta selbst bis zu 2,5-mal schneller als 7.0 sein kann. Außerdem nutzt tsrs standardmäßig eine adaptive Konfiguration, die abhängig von der Maschine mehr Speicher einsetzen kann, um noch schneller zu sein.

Für ein Produktteam folgen daraus drei Regeln:

dieselben Versionen, Worker-Zahlen und Compiler-Optionen vergleichen;
kalte und warme Läufe getrennt messen;
Zeit, Peak Memory und Ergebnisqualität gemeinsam betrachten.

Ein schneller Lauf auf einem großen CI-Runner sagt wenig über einen Entwickler-Laptop, einen kleinen Container oder ein Monorepo mit warmem Cache. Wir übernehmen deshalb keine fremde Zahl in den Business Case. Wir übernehmen nur die Messmethode.

Zuerst eine ehrliche Baseline bauen

Vor dem neuen Werkzeug messen wir den bestehenden Prozess. Sonst optimieren wir gegen eine Erinnerung.

Eine brauchbare Baseline enthält pro repräsentativem Projekt:

exakten Commit und sauberen Checkout;
Node-, TypeScript- und Package-Manager-Version;
unveränderte tsconfig-Dateien und Lockfiles;
Maschinenprofil oder CI-Runner-Klasse;
fünf kalte und zehn warme Läufe;
Wall-Clock-Zeit, CPU-Zeit und maximalen Speicher;
Exit-Code und vollständige Diagnostics;
getrennte Werte für lokale Entwicklung und CI.

Wir nehmen nicht nur das größte Repository. Eine UI-App, ein API-Service, eine Shared-Library und ein Projekt mit Project References decken verschiedene Lastprofile ab. Wenn ein Tool nur in einem synthetischen Giganten glänzt, aber den normalen Feedback-Loop kaum verändert, ist der Nutzen kleiner als die Headline.

Parallel prüfen, nicht sofort ersetzen

Der erste Einsatz läuft außerhalb des kritischen Pfads. Der bestehende TypeScript-Check bleibt verbindlich; tsrs arbeitet daneben und veröffentlicht sein Ergebnis als nicht blockierenden Job.

Der aktuelle Projekt-README empfiehlt für einen Test:

pnpm add -D tsrs
pnpm exec tsrs --noEmit

Wir pinnen dabei die exakte Version im Lockfile und speichern Messwerte als CI-Artefakt. Ein Vergleichsskript normalisiert Pfade und Laufzeitrauschen, verändert aber nicht die eigentlichen Fehlermeldungen.

Dieser Shadow Mode beantwortet vier Fragen ohne Produktionsrisiko:

Läuft der Checker auf allen relevanten tsconfig-Varianten?
Findet er dieselben Fehler wie der bestehende Check?
Wie stabil sind Zeit und Speicher über mehrere Läufe?
Welche Integrationen greifen direkt auf TypeScript-APIs zu und umgehen die CLI?

Erst wenn diese Daten über mehrere Tage stabil sind, darf der neue Job optional blockierend werden.

Diagnostics zählen, aber Bedeutung entscheidet

Nur Exit-Codes zu vergleichen ist zu grob. Zwei Checker können beide mit 1 enden und trotzdem unterschiedliche Fehler finden. Umgekehrt können identische Fehler in anderer Reihenfolge erscheinen — ein bereits dokumentierter Unterschied bei tsrs.

Wir vergleichen deshalb strukturierte Merkmale:

Fehlercode;
Datei und Position;
Severity;
Kernbotschaft nach Entfernung instabiler Pfade;
Anzahl und Art zusätzlicher oder fehlender Diagnosen.

Jede Abweichung landet in einer kleinen Compatibility-Liste mit drei Zuständen: erklärt, akzeptiert oder Blocker. Eine andere Sortierung ist meist erklärt. Ein fehlender Fehler bei einem unsicheren Typ ist ein Blocker. Eine zusätzliche korrekte Diagnose kann akzeptiert sein, verlangt aber möglicherweise eine geplante Codebereinigung.

Das Ziel ist nicht „gleiche Textdatei um jeden Preis“. Das Ziel ist nachweisbar gleiche Schutzwirkung für den eigenen Code.

Speicher ist ein Produktmerkmal des Toolings

Weniger Speicher ist nicht nur eine hübsche Infrastrukturmetrik. Es beeinflusst, wie viele CI-Jobs parallel laufen, ob ein Agent seinen gesamten Prüfzyklus in einer Sandbox ausführen kann und ob ein Entwickler neben Editor, Browser und Containern noch flüssig arbeitet.

Wir messen deshalb Peak RSS und nicht nur durchschnittlichen Verbrauch. Besonders wichtig sind:

vollständiger Monorepo-Check;
inkrementeller Lauf nach einer kleinen Änderung;
mehrere parallele Packages;
wiederholte Läufe in derselben CI-Klasse;
kleine Runner mit einem realistischen Memory Limit.

Wenn ein schnellerer Checker nur mit deutlich mehr parallelen Workern gewinnt, müssen deren Speicher- und CI-Kosten in denselben Vergleich. Cloudflare weist selbst darauf hin, dass die adaptive Standardkonfiguration Geschwindigkeit gegen zusätzlichen Speicher tauschen kann. Genau deshalb braucht der Benchmark feste Parameter.

Editor und CI sind zwei verschiedene Migrationen

Ein schneller CLI-Check macht den Editor noch nicht schneller. Autocomplete, Go to Definition, Rename, Project Loading und Plugins hängen am Language Server und oft an APIs, die weit über tsc --noEmit hinausgehen.

Wir trennen daher drei Ebenen:

CI Checker: Am einfachsten isoliert zu testen, weil Eingabe und Ausgabe klar sind.

Lokaler Watch-Modus: Relevant für den Feedback-Loop, aber empfindlicher gegenüber inkrementellem Zustand.

Language Server: Muss mit den tatsächlich verwendeten Editoren, Workspace-Größen und Plugins geprüft werden.

Ein Team kann den CI-Checker früher übernehmen und den Editor zunächst unverändert lassen. Eine gemeinsame Big-Bang-Migration erzeugt dagegen schwer zuzuordnende Fehler und macht einen Rollback unnötig groß.

WebAssembly ist eine Chance, keine Pflicht

Ein Grund für Rust ist laut Cloudflare die gute WebAssembly-Passung. Das Projekt bietet mit @tsrs/wasm bereits einen WASM-Build für Node und Browser an. Damit werden neue Szenarien denkbar: Typechecks in Browser-IDEs, isolierte Build-Umgebungen oder vollständig sandboxed Agenten-Workflows.

Für eine normale Produktpipeline ist das zunächst kein Migrationsgrund. Ein WASM-Demo-Check im Browser beantwortet nicht automatisch Fragen zu Dateisystem, Project References, Package Resolution oder Editor-Plugins.

Wir behandeln WASM daher als separates Produkt-Experiment:

Was soll clientseitig geprüft werden?
Welche Dateien dürfen den Browser erreichen?
Wie groß ist Download und Initialisierung?
Welche APIs fehlen gegenüber dem nativen Prozess?
Wie wird dieselbe TypeScript-Version serverseitig reproduziert?

Erst ein konkreter Nutzer- oder Plattformvorteil rechtfertigt diese zusätzliche Laufzeit.

Ein Migrations-Gate braucht klare Kriterien

„Fühlt sich schneller an“ ist kein Release-Kriterium. Vor einer blockierenden Einführung definieren wir eine kleine Scorecard:

Konformität: keine ungeklärten fehlenden Diagnostics in den Referenzprojekten;
Kompatibilität: alle benötigten CLI-Optionen und Projektmodi funktionieren;
Performance: mediane Laufzeit verbessert sich im eigenen Runner messbar;
Stabilität: keine sporadischen Crashes oder nicht reproduzierbaren Ergebnisse;
Betrieb: Version ist gepinnt, Cache-Verhalten verstanden, Rollback dokumentiert;
Tooling: Owner für Editor-, CI- und Plugin-Fragen ist benannt.

Ein Kriterium darf bewusst noch nicht erfüllt sein. Dann bleibt der Einsatz enger: zum Beispiel als schneller zusätzlicher Check, aber nicht als alleinige Merge-Schranke.

Drei Phasen statt eines Schalters

Phase 1 — Beobachten: tsrs läuft nicht blockierend auf ausgewählten Projekten. Wir sammeln Zeit, Speicher und Diagnostics-Diffs.

Phase 2 — Begrenzen: Der neue Checker wird für kompatible Projekte blockierend, der offizielle Checker läuft weiterhin als Fallback und meldet Abweichungen. Eine einfache CI-Variable schaltet zurück.

Phase 3 — Vereinfachen: Erst nach mehreren stabilen Releases entfernen wir den doppelten Lauf dort, wo Konformität und Integrationen belegt sind. Sonderprojekte behalten den alten Pfad, bis ihr Blocker gelöst ist.

Der Rollback wird vor Phase 2 getestet: ein Commit oder eine Pipeline-Variable muss genügen. Wenn die Rückkehr mehrere Teams und eine Neuinstallation auf Runnern braucht, ist die Einführung noch nicht fertig.

Typische Benchmark-Fehler

Die häufigsten falschen Schlüsse entstehen nicht im Compiler, sondern im Versuchsaufbau:

einen kalten alten Lauf mit einem warmen neuen Lauf vergleichen;
unterschiedliche Worker-Zahlen oder Maschinen verwenden;
nur das schnellste Ergebnis veröffentlichen;
einen Cache-Hit als Typechecker-Leistung verkaufen;
Diagnostics nur zählen, aber nicht zuordnen;
Editor-Performance aus einem CLI-Test ableiten;
ein experimentelles Paket mit unfixierter Version in die Hauptpipeline setzen;
nach einem guten Demo-Repository sofort das ganze Monorepo umstellen.

Ein guter Benchmark ist langweilig: feste Inputs, wiederholte Läufe, vollständige Ergebnisse und dokumentierte Ausnahmen. Genau diese Langeweile macht eine technische Entscheidung belastbar.

Was wir heute tun würden

tsrs ist ein spannendes Signal: TypeScript-Tooling wird weiter schneller, portabler und besser für isolierte Entwicklungsumgebungen. Es ist zugleich ausdrücklich ein experimenteller Port mit einem klar formulierten Konformitätsziel.

Unser pragmatischer nächster Schritt wäre ein einwöchiger Shadow-Test in zwei bis vier repräsentativen Repositories. Wir würden die offizielle TypeScript-Pipeline nicht verändern, Messwerte und Diagnostics-Diffs sammeln und nach einer Woche anhand der Scorecard entscheiden.

Wenn der neue Checker gewinnt, haben wir nicht nur eine schnellere Pipeline. Wir haben einen belegten Migrationspfad. Wenn er noch nicht gewinnt, bleibt ebenfalls etwas Wertvolles: eine saubere Baseline, mit der sich auch TypeScript 7.1 und künftige Versionen ehrlich bewerten lassen.