TypeScript 6.0: was sich wirklich geändert hat, was nach dem Upgrade bricht und ob sich das Update jetzt schon lohnt

Im März 2026 hat Microsoft TypeScript 6.0 veröffentlicht. Praktisch gesehen ist das kein Release rund um ein einziges großes Feature. Es ist ein Release mit neuen Grundregeln. Das Team hat Defaults geändert, einen Teil alten Konfigurationsballasts entfernt und das Ökosystem zu einem moderneren Ausgangspunkt geschoben. [1][2]

Das merkt man schon am Ton der offiziellen Ankündigung. Sie versucht nicht, das Release als etwas Magisches zu verkaufen. Stattdessen benennt sie offen die Stellen, die Teams zuerst anfassen müssen: types, rootDir und alte Annahmen über Compiler-Defaults. Das ist unbequem, aber so sehen reife Infrastruktur-Releases oft aus. [1]

Wichtig ist auch: TypeScript 6 steht nicht für sich allein. Man muss es zusammen mit der Richtung auf TypeScript 7 lesen. Schon 2025 erklärte das Team, dass 6.x die JavaScript-Linie mit Übergangs-Deprecations sein würde, während 7.x die native Richtung mit tsgo, neuer Architektur und deutlich schnellerem Type-Checking tragen soll. [3][4]

Der interessanteste Teil von TypeScript 6 liegt nicht in der Oberfläche, sondern darin, wie das Team Defaults und interne Kosten großer Repositories neu bewertet hat.

TS 6.0 besteht nicht nur aus schmerzhaften Konfigurationsänderungen. Es gibt auch echte Sprach- und Plattform-Verbesserungen, die mit der Zeit einfach normal wirken werden.

Für die meisten Teams schmerzt dieses Release nicht wegen der Sprache, sondern wegen angesammelter Konfigurationsschulden. Genau hier legt TypeScript 6 reale Projektprobleme offen. [1][2][4]

Diese Reihenfolge funktioniert in der Regel besser, als einfach die Version zu erhöhen und dann zu schauen, was explodiert.

TypeScript 6 ist nicht für jedes Team gleich attraktiv. Die echte Antwort hängt davon ab, wie modern Ihre Konfiguration schon ist und wie stark große Repositories unter Compiler-Kosten leiden.

Diskussionen in der Community zeigen oft am besten, wo reale Schmerzen erwartet werden und wo der größte praktische Nutzen liegt.

Wenn man 6.0 nur als weiteres Compiler-Release betrachtet, übersieht man leicht die größere Geschichte. TypeScript 6 existiert auch, um das Ökosystem auf 7.0 vorzubereiten. Das Team spricht seit der Ankündigung des nativen Ports ziemlich offen darüber. [3]

Im Fortschrittsupdate zu TypeScript 7 vom Dezember 2025 schrieb das Team, dass tsgo schon verlässlich für Type-Checking nutzbar sei, dass --build, project references und --incremental sich ernsthafter Parität nähern und dass manche Voll-Builds bereits ungefähr 10x schneller seien als in der 6.0-Linie. [4]

Aber auch das ist kein Märchen. Im selben Update ist das Team offen über API-Unterschiede und darüber, dass einige Deprecations aus 6.0 in 7.0 härter werden. Der saubere Blick auf TypeScript 6 ist daher: ein Übergangsfenster, in dem Teams ihre Konfiguration modernisieren können, bevor die native Ära zur Standarderwartung wird. [4]

TypeScript 6.0 wurde nicht veröffentlicht, damit sich alle wohlfühlen. Es wurde veröffentlicht, damit der Compiler alte Gewohnheiten nicht ewig weitertragen muss. In diesem Sinn ist es ein sehr ehrliches Release.

Wenn Ihr Projekt bereits modern und diszipliniert ist, ist ein Upgrade auf 6.0 jetzt nachvollziehbar. Sie bekommen eine berechenbarere tsconfig, weniger verschwendete Arbeit rund um globale Typen und einen saubereren Weg in das, was TypeScript 7 für Ihren Stack bedeuten wird.

Wenn das Repository jahrelang auf impliziten Defaults beruhte, wird TypeScript 6 das einfach sichtbar machen. Auch das ist nützlich. Es ist viel besser, Konfigurationsschulden unter 6.0 zu entdecken, als ihnen später zu begegnen, wenn das Team ernsthaft tsgo und die native Linie einsetzen will.