TypeScript Weekly #3: Bun integriert nativen Typchecker, ts-rust übertrifft Go, ttsc bringt Compile-Time-Linting

📦 Versions-Updates

Offizielle Entwicklung stabiler Versionen und Build-Pipeline-Upgrades

Die aktuelle offizielle stabile Version bleibt TypeScript 7.0.2 (veröffentlicht am 20. August 2026). In den vergangenen sieben Tagen gab es keine neuen Compiler-Patch-Releases. Die am 30. September veröffentlichte Editor-Erweiterung vscode-typescript/v1.0.1 bündelt diesen Compiler vollständig. Eine detaillierte Aufarbeitung der architektonischen Änderungen findet sich in unserem Dossier: Übersicht zu den neuen Features in TypeScript 7.0.

In der aktuellen 7.0-Reihe sind folgende Kernmechanismen und deren praktische Auswirkungen auf die Softwareentwicklung besonders relevant:

Änderung	Regeländerung	Praktische Auswirkung
Parallele Überprüfung per Go-Architektur	Compiler von JS auf Go migriert; Parameter --checkers steuert Worker-Threads (Standard: 4).	Auf Multi-Core-Entwicklerrechnern beschleunigen sich Voll-Builds um das 8- bis 12-Fache; in ressourcenbeschränkten CI-Containern müssen Grenzwerte explizit gesetzt werden, um Speicherkonflikte zu vermeiden.
Programmatische API vorübergehend abwesend	7.0 wird rein als natives CLI-Binary verteilt; keine aufrufbare Node.js-Compiler-API vorhanden.	Werkzeuge, die auf internen AST-Kontext angewiesen sind (wie typescript-eslint), können nicht direkt angebunden werden; Übergangslösung erfordert @typescript/typescript6-Aliasing für Dual-Builds.
Strikter Modus standardmäßig fixiert	strict und rootDir: "./" sind standardmäßig aktiv; baseUrl und moduleResolution: node wurden entfernt, target: es5 wird nicht mehr unterstützt.	Ältere Projekte müssen veraltete Konfigurationsfelder bereinigen; Pfad-Aliase müssen vollständig auf die Auflösung nach nodenext oder bundler umgestellt werden.

Hinsichtlich der Plattformunterstützung decken die offiziellen TS-7.0-Binärpakete die gängigen Linux-, macOS- und Windows-Architekturen ab. Das Fehlen nativer C++-Bindings stellt die Ausführung von Typcheckern innerhalb von WebAssembly-Containern jedoch vor neue Herausforderungen.

📝 Deep Dives

Bun PR #44361 führt nativen Typchecker bun check ein

Was ist passiert: Jarred Sumner hat Bun PR #44361 eingereicht, der den Kern von typescript-go 7.0.2 portiert und einen nativen Typchecker mit rund 150.000 Zeilen neuem Code bereitstellt. Der PR führt den Befehl bun check sowie das Flag --check ein. In Tests mit einem Next.js-Projekt (2.881 Quelldateien) sank die CPU-Zeit für die vollständige Typüberprüfung von 6,9 Sekunden unter tsc 7.0.2 auf 2,4 Sekunden, während der Speicher-Peak von 1,78 GB auf 0,69 GB fiel.

Warum es wichtig ist: Frühere leichtgewichtige Runtimes entfernten lediglich Typen (Type Stripping), ohne sie semantisch zu validieren. Bun bettet die vollständige Typüberprüfung in einen einzigen Prozess ein und wickelt die Abhängigkeitsanalyse für Project References direkt im Arbeitsspeicher ab. Verifiziert an 72 quelloffenen Projekten (1.103 Konfigurationen) und 13.000 offiziellen Testfällen, erreicht die Implementierung eine Übereinstimmungsquote von 99,99 % und behebt das unter starker Thread-Konkurrenz im offiziellen Go-Compiler beobachtete Problem abweichender Zeilennummern.

Wen es betrifft: Frontend- und System-Engineers, die Microservices, Full-Stack-Frameworks und lokale Testumgebungen auf Basis von Bun betreiben. CI-Pipelines können künftig auf separate Node.js-Typcheck-Container verzichten.

Link: Bun PR #44361: bun check builtin type checker

Kommentar der Redaktion: Die Einbettung der Typüberprüfung in einen Einzelprozess ist die logische Weiterentwicklung moderner Laufzeitumgebungen. Der gemessene Spitzenverbrauch von nur 0,69 GB bannt OOM-Risiken in Containern weitgehend. Da jedoch weder .d.ts-Deklarationsdateien noch SourceMaps generiert werden, bleibt der offizielle Build-Workflow für die Paketveröffentlichung weiterhin unverzichtbar.

ts-rust (tsc-rs) betritt die Bühne: LLMs portieren TS 7 in zwei Wochen nach Rust – 3-mal schneller als Go

Was ist passiert: Theo Browne hat das Projekt pingdotgg/ts-rust (npm: tsc-rs) als Open Source bereitgestellt, das den offiziellen Go-Compiler auf Basis von TS 7.1-dev Commit 673a5f17d713 nach Rust portiert. Ein anfänglicher Versuch mit OpenAI-Modellen kostete 400.000 Dollar an Tokens für 1,3 Millionen Codezeilen, stagnierte jedoch bei einer Kompatibilitätsrate von 84 %. Anschließend wurde das Projekt von Claude Opus 5.5 innerhalb von zwei Wochen für 24.000 Dollar an Tokens von Grund auf neu geschrieben. Im T3-Code-Benchmark benötigte tsc-rs 5,27 Sekunden – 3,05-mal schneller als das offizielle Go-basierte tsc 7 (16,10 Sekunden) und 11,9-mal schneller als tsc 6 (62,63 Sekunden).

Warum es wichtig ist: Das Projekt besteht alle 181.711 offiziellen Transpilierungs- und Diagnosetests und liefert bei 120 echten Open-Source-Bibliotheken exakt identische Diagnoseausgaben. Es bringt native Diagnose-Regeln für Effect 4 mit (Codebereich 377xxx), ohne dass zusätzliche Plugins konfiguriert werden müssen. Die Rust-Architektur ohne Garbage Collector ebnet den Weg für Typchecker mit minimalem Overhead in WebAssembly. Microsofts TypeScript-Lead Dan Rosenwasser schaltete sich auf Hacker News ein und bestätigte das Interesse des Kernteams.

Wen es betrifft: Frontend-Architekten mit Fokus auf browserbasierte WASM-Typanalyse, Entwickler von Build-Toolchains wie Rolldown und Rspack sowie Ingenieure im Effect-Ökosystem.

Link: ts-rust: An experimental Rust port of TypeScript 7 compiler

Kommentar der Redaktion: Große Sprachmodelle beweisen bei der mechanischen Transformation von Syntaxbäumen eine beachtliche Effizienz. Dennoch fehlt maschinengeneriertem Code oft eine durchdachte menschliche Architekturstruktur. Sollte Microsoft künftig grundlegende Anpassungen an den Typprüfungsgrenzen vornehmen, droht ein Wartungsrisiko mit erneuten hohen Token-Kosten für Neugenerierungen.

ttsc: Compiler-integrierte Plugins und Lint-Engine auf Basis der typescript-go-Architektur

Was ist passiert: Samchon, Autor von Typia, hat die Toolchain ttsc zusammen mit der Vorprüfungs-Laufzeit ttsx und @ttsc/lint veröffentlicht. Aufgebaut auf Microsofts typescript-go-Architektur, reaktiviert das Projekt die mit TS 7.0 entfallene Erweiterbarkeit für AST-Transformations-Plugins und ermöglicht die gleichzeitige Ausführung von Code-Style- und Regelfrüfungen während des Typinferenz-Durchlaufs.

Warum es wichtig ist: Das Entfernen der Node.js-APIs in TS 7 verhinderte Upgrades für Bibliotheken, die auf Compile-Time-Makros und Typ-Metadaten-Transformationen angewiesen sind (wie Typia oder TS-Patch). ttsc schleift Middleware direkt in die Prüfphase des Compilers ein und bewahrt so Typ-Reflektionsfähigkeiten. Das integrierte @ttsc/lint deckt über 720 Regeln ab und erzielt in Projekten von der Größenordnung von VS Code einen bis zu 900-mal höheren Durchsatz als ein eigenständiges ESLint. Das Begleitwerkzeug @ttsc/graph senkt zudem den Token-Bedarf bei Codeanalysen durch KI-Agenten um 92 %.

Wen es betrifft: Teams im hochperformanten Backend-Bereich, die auf strikte Typsicherheit zur Compile-Zeit setzen, Monorepo-Verantwortliche sowie alle, die Linting und Typüberprüfung in der CI zusammenführen wollen.

Link: samchon/ttsc: A typescript-go toolchain for compiler plugins

Kommentar der Redaktion: Die Vorverlagerung von Lint-Regeln in den Typcheck-Schritt verkürzt Pipeline-Laufzeiten spürbar. Eine feste Bindung von Formatierungs- und Stilregeln an den Compiler zwingt Teams jedoch dazu, hochgradig maßgeschneiderte externe AST-Plugins aufzugeben – ein Migrationsaufwand, der sorgfältig kalkuliert werden muss.

🔥 Community-Trends

LLM-generierter Compiler entfacht Grundsatzdebatte über Performance zwischen Rust und Go

Am 8. Oktober sorgte das Projekt pingdotgg/ts-rust auf Hacker News für intensive Diskussionen (117 Punkte, 222 Kommentare).

• Fraktion für Grenzperformance und GC-Freiheit: Rust-Befürworter argumentieren, dass die Typüberprüfung in TypeScript tief verschachtelte Union-Typen und komplexe Conditional Types umfasst. Die kurzzeitig entstehende Flut an AST-Knoten führt im Go-Garbage-Collector zu spürbarem Jitter. In dauerhaft laufenden LSP-Daemons stieg der Speicherbedarf der Go-Version von 4,9 GiB auf 7,4 GiB an, während die Rust-Version dank Arena-Allokatoren und deterministischer Lebensdauern stabil bei 2,9 GiB verharrte. Zudem mache die hocheffiziente WASM-Kompilierung von Rust den Typchecker zum idealen Unterbau für Web-IDEs.
• Fraktion für Wartbarkeit und formale Spezifikation: Zurückhaltendere Entwickler gaben zu bedenken, dass TypeScript keine formale Grammatikspezifikation besitzt; de facto wird der Standard durch Microsofts offizielle Implementierung definiert. Microsoft wählte Go bewusst wegen seiner geradlinigen Syntax, die eine klare logische Nähe zur ursprünglichen JS/TS-Basis wahrt. Ein von LLMs für Zehntausende Dollar generierter Codeberg ohne manuelle Zeilenprüfung drohe bei undokumentierten Corner Cases zur Blackbox zu werden. Die langfristigen Wartungskosten könnten die initialen Einsparungen schnell zunichtemachen.

Link: HN: Port of the TypeScript compiler, checker and lsp to Rust, by LLM

Gesamtes Team erzeugt 60 PRs komplett per KI: Das Typsystem im Stresstest der “Typen-Aufblähung”

Im Reddit-Thread Every PR on my team is written by AI now auf r/typescript (155 Punkte, 118 Kommentare) berichtete ein Monorepo-Engineer über die Erfahrung, dass fast 60 aufeinanderfolgende gemergte PRs vollständig von KI-Agenten stammten – was eine Debatte über den Wandel von Entwicklungsparadigmen auslöste.

• Befürworter gesteigerter Effizienz: Vertreter dieser Seite betonten, dass KI-Agenten unter klaren Architekturvorgaben in Kombination mit striktem Linting und CodeRabbit-Reviews eine statische Typsicherheit erzielen, die handgeschriebenen Code von Junior- bis Mid-Level-Entwicklern deutlich übertrifft. Laufzeitfehler durch Nullpointer wurden drastisch minimiert, sodass sich Entwickler auf Domänengrenzen konzentrieren konnten.
• Kritiker globaler Inkonsistenz: Erfahrene Softwarearchitekten wandten ein, dass KI-Agenten ohne umfassenden übergreifenden Repository-Kontext dazu neigen, lokal redundante Datenstrukturen abzuleiten. Dies führe zu parallelen, leicht voneinander abweichenden Typdefinitionen (etwa drei separate User-Typen für dieselbe Entität). Das Typsystem degradiere vom mentalen Domänenmodell zu einer rein lokalen Syntaxprüfung; die akkumulierte “Typ-Aufblähung” werde langfristig die Performance der topologischen Typanalyse im Build ausbremsen.

Link: Reddit: Every PR on my team is written by AI now

Deno-Team schließt sich Cloudflare an: Eigenständige Laufzeit wird nach einem Jahr eingestellt

Am 9. Oktober gab Ryan Dahl bekannt, dass das gesamte Deno-Team zu Cloudflare wechselt. Die eigenständige Deno-Laufzeitumgebung wird nach einer einjährigen Wartungsphase nicht mehr eigenständig weiterentwickelt, was in der r/typescript-Community hohe Wellen schlug (542 Punkte, 96 Kommentare).

• Realistische Betrachtung des Marktes: Viele Entwickler sahen darin eine Bestätigung der schwierigen Kommerzialisierung unabhängiger Runtimes. Deno leistete Pionierarbeit bei nativer TypeScript-Unterstützung, URL-Modulimporten und Berechtigungs-Sandboxes, konnte sich jedoch im Wettbewerb mit Hyperscalern und der Trägheit des npm-Ökosystems wirtschaftlich nicht dauerhaft behaupten.
• Würdigung des technischen Erbes: Andere betonten, dass Deno seine historische Mission erfüllt habe. Schlüsselkomponenten wie rusty_v8 und standardisierte Web-API-Abstraktionen fließen direkt in Cloudflares globale Edge-Infrastruktur workerd ein. Zudem hat Denos Vorstoß für native moderne TypeScript-Unterstützung alle modernen JavaScript-Runtimes nachhaltig geprägt.

Link: Reddit: Deno is dead, Deno Blog: Joining Cloudflare

🔭 Ausblick auf nächste Woche

• TypeScript 7.1 Programmatic API RFC: Verfolgung der Design-Diskussionen im offiziellen GitHub-Repository bezüglich der Wiederbereitstellung der Node.js-Compiler-API und Prüfung, ob neue Schnittstellen auf FFI-Zwischenschichten angewiesen sind;
• Bun check Canary-Verifikation: Beobachtung der Release-Pakete nach dem Merge von Bun PR #44361 in den Main-Branch mit speziellem Augenmerk auf Speicherstabilität und Diagnosepräzision in großen Monorepo-Pipelines.