tsgolint v7 liefert in Go geschriebenes typbewusstes Linting

Typbewusstes Linting (type-aware linting) für TypeScript hat jetzt eine stabile, in Go geschriebene Implementierung. Das Oxc-Projekt kündigte tsgolint v7.0.2000 am 22. Juli 2026 an, und der Bericht von InfoQ vom 11. September 2026 verschaffte ihm breitere Aufmerksamkeit. Es deckt 59 der 61 typbewussten Regeln von typescript-eslint ab.

Der Unterschied wiegt schwerer, als es klingt. Die meisten Lint-Regeln müssen nur die Form Ihres Codes lesen: ein fehlendes Semikolon, eine ungenutzte Variable. Typbewusste Regeln müssen wissen, was die Dinge tatsächlich sind. Zu fragen, ob ein Promise jemals per await abgewartet wird, heißt, den Typprüfer zu fragen, und der Typprüfer ist der langsame Teil.

Deshalb haben diese Regeln den Ruf, einen Lint-Lauf Minuten dauern zu lassen. tsgolint implementiert den Typprüfer nicht neu, um diese Kosten zu vermeiden. Es baut echte TypeScript-Programme auf typescript-go auf, das die GitHub-README des Projekts als „Microsofts TypeScript-Implementierung“ beschreibt, und zielt auf TypeScript 7 mit dem Codenamen Project Corsa.

Die eigenen Zahlen des Projekts widersprechen sich

Hier wird die Berichterstattung unbequem, und es lohnt sich, das offen zu sagen, statt die freundlichere Zahl zu wählen.

Der Blogbeitrag von Oxc nennt detaillierte Laufzeiten auf einem Apple M4 Pro mit 12 Kernen, verglichen mit ESLint plus typescript-eslint bei abgestimmten Konfigurationen. Sie zeigen eine Verbesserung um das 12- bis 18-Fache: microsoft/vscode von 83,2 Sekunden auf 6,96 Sekunden, microsoft/typescript von 27,2 auf 1,94, typeorm von 13,2 auf 0,75 und vuejs/core von 12,3 auf 0,95.

Die eigene README des Projekts fasst seine Benchmarks anders zusammen. Sie meldet das 22- bis 34-Fache auf denselben vier Repositories und erklärt, das Werkzeug sei „20-40x schneller als ESLint + typescript-eslint auf großen Repositories“.

Beide Aussagen stammen vom selben Projekt, über dasselbe Werkzeug, gegen denselben Vergleich. Der Bericht von InfoQ zitiert die niedrigere Spanne. Wir haben keine Erklärung für die Lücke gesehen, und keine der beiden Zahlen wurde unabhängig reproduziert. Behandeln Sie die 12-18x des Blogs als die Zahl mit sichtbarem Rechenweg dahinter, und messen Sie Ihr eigenes Repository, bevor Sie mit einer von beiden planen.

Der Blog erklärt durchaus, woher die Gewinne kommen: „schnelle Pfade, die teure Anfragen an den Typprüfer vermeiden, wenn die Syntax die Antwort bereits liefert“. Eine Regel, heißt es dort, kam „35-mal schneller auf VS Code“ heraus.

Version 7 eines Projekts, das nie eine Version 1 hatte

tsgolint sprang direkt von einer experimentellen 0.x-Linie zu einem stabilen v7, was wie ein Marketing-Sprung aussieht und keiner ist.

Die Version folgt jetzt dem Compiler, den sie einbettet. In v7.0.2000 ist 7.0.2 die TypeScript-Version, und der Zähler am Ende ist tsgolints eigene Patch-Nummer, die zurückgesetzt wird, sobald sich die TypeScript-Version bewegt. InfoQ zitiert die Begründung: „tsgolint wird jetzt gegen den Compiler versioniert, den es einbettet.“ Der praktische Effekt ist, dass die Versionszeichenkette Ihnen sagt, welchen Typprüfer Sie bekommen.

	Detail
Stabile Version	v7.0.2000, 22. Juli 2026
Verfolgte TypeScript-Version	v7.0.2
Implementierte Regeln	59 von 61, gegenüber 43 bei der Alpha im Dezember
Mindestens TypeScript	7.0
Installation	pnpm add -D oxlint oxlint-tsgolint@7
Ausführen	pnpm oxlint --type-aware

Der Code begann als Prototyp in der typescript-eslint-Organisation, erstellt vom Mitwirkenden auvred, und der Oxc-Fork führt ihn mit der Erlaubnis dieses Autors weiter.

Was das für Entwickler bedeutet

Die zuerst zu prüfende Einschränkung ist TypeScript 7. Typbewusstes Linting setzt hier 7.0 oder neuer voraus, und InfoQ merkt an, dass einige ältere tsconfig-Optionen und TypeScript-6-Funktionen noch nicht unterstützt werden. Läuft Ihr Build auf TypeScript 6, ist das etwas zum Einplanen, nicht etwas, das Sie heute Nachmittag einführen.

Sind Sie bereits auf 7, ist das ehrliche Experiment ein einzelner gestoppter Lauf. Installieren Sie die zwei Pakete, führen Sie pnpm oxlint --type-aware gegen Ihr Repository aus und vergleichen Sie mit Ihrem bestehenden ESLint-Aufruf. Ihre eigene Zahl ist mehr wert als jede Benchmark-Tabelle, und das ist ein Fall, in dem die veröffentlichten Zahlen nicht einmal untereinander stimmig sind.

Die zwei fehlenden Regeln wiegen schwerer, als die Zahl vermuten lässt. Prüfen Sie, ob eine der beiden, die es nicht geschafft haben, eine ist, auf die sich Ihr Team verlässt. Eine Lint-Suite, die 12-mal schneller läuft, aber stillschweigend die Regel weglässt, die Ihre Fehlerklasse fängt, ist ein schlechter Tausch.

Hier zeigt sich ein breiteres Muster, das eine Erwähnung verdient. Entwicklerwerkzeuge für mehr Tempo in einer kompilierten Sprache neu zu schreiben ist in diesem Jahr Routine geworden. Debian Code Search hat seine letzte C-Abhängigkeit zugunsten von reinem Go aufgegeben und die C-Version eingeholt. Der Autor des mold-Linkers schreibt ihn von C++ nach Rust um. Was tsgolint unterscheidet, ist, dass es den schweren Teil nicht neu geschrieben hat. Es hat Microsofts eigenen Compiler eingebettet und darum herum optimiert, was ein weit günstigerer Weg ist, korrekt zu sein.