Startseite / Artikel / Benchmarking des Go-Compilers von TypeScript 7 in einer echten Next.js-Anwendung

TypeScript Next.js Performance CI/CD Compilers

Benchmarking des Go-Compilers von TypeScript 7 in einer echten Next.js-Anwendung

Ein praktischer Vergleich der Überprüfungszeiten von tsc zwischen TypeScript 6 und 7 in einer echten Next.js-Codebasis, einschließlich eines Fehlers durch Inkonsistenzen in CI und Anleitungen zur Aktualisierung.

3199 Wörter

Die gleichen 412 Dateien wurden unter zwei verschiedenen Compiler-Versionen zweimal überprüft. Mit TypeScript 6 dauerte die Überprüfung 3,8 Sekunden, mit TypeScript 7 nur 0,41 Sekunden. Der Typprüfer ist im Grunde genommen derselbe.

Die von Microsoft veröffentlichte Zahl gibt eine Geschwindigkeitssteigerung um das 8- bis 12-fache an, gemessen in VS Code. Entscheidend ist hier jedoch das Ergebnis, das tsc --extendedDiagnostics für ein bestimmtes Repository ausgibt. Ein CI-Job, der früher bei einem fehlgeschlagenen Prisma-Generierungs-Schritt blockierte, wird nicht einfach deshalb zehnmal schneller, nur weil der Typprüfer schneller arbeitet – lediglich dieser eine Schritt wird schneller, alles danach bleibt genauso langsam wie zuvor.

Öffnen Sie ein Terminal.

Überspringen Sie next dev. Gehen Sie direkt zum Typprüfer selbst und führen Sie ihn von der Wurzel der Anwendung aus aus:

pnpm exec tsc --noEmit --extendedDiagnostics

Achten Sie auf den von ihm ausgegebenen Wert Check time. Diese einzige Zeile ist die einzige Messgröße, die es hier bis zum Ende zu verfolgen lohnt.

Microsoft veröffentlichte TypeScript 7.0 am 8. Juli 2026. Das Typsystem selbst hat sich nicht geändert, und das Compiler-Binärdatei wird weiterhin tsc genannt, ist intern jedoch nun eine in Go umgesetzte Version des Compilers. Die Tabelle in der Ankündigung zur Version 1.0 zeigt, dass die Überprüfungszeit von VS Code von 125,7 Sekunden auf 10,6 Sekunden sank. Diese Zahl bezieht sich auf Microsofts eigenes Codebase, nicht auf ein typisches Next.js-Projekt.

Was tatsächlich nützlich ist, ist die entsprechende Zahl für eine kleine Next.js-Anwendung mit vier Routen, die bereits in allen anderen Bereichen benchmarkt wurde, sowie die zusätzliche Zahl: wie viel next build kostet, sobald der dahinterliegende Prüfer neu ist. Ebenso wichtig ist es, die Art von Fehler zu dokumentieren, der auftritt, wenn eine automatisierte Pull-Request-Prüfung annimmt, „schneller“ und „sich anders verhalten“ bedeuten dasselbe.

Der Nachmittag-CI log über einen Typfehler

Stellen Sie sich ein Team vor, das am Dienstag in einer Rechnungsstellungsanwendung die typescript-Abhängigkeit auf Version 7 aktualisierte, weil ein Blogbeitrag eine 10-fache Geschwindigkeitssteigerung versprach. Der CI zeigte deutlich schneller ein grünes Status an. Ermutigt davon genehmigte und führte ein Reviewer einen helper für branded-id ein, der sich jedoch auf dem lokalen Rechner eines Teamkollegen als fehlerhaft bei der Typüberprüfung herausstellte.

Der Helper wurde im CI einwandfrei kompiliert, weil das CI die Version 6 von typescript noch über eine in den Wurzel-Workspace eingebundene Abhängigkeit auflöste. Auf dem lokalen Rechner hingegen war direkt Version 7 installiert. Das Typsystem selbst hatte sich nicht verändert – das ist schließlich der Kern von Microsofts Behauptung – doch die tsconfig-Konfiguration im CI führte dazu, dass typescript auf einen Paket-Alias namens @typescript/typescript6 verweist, der aus einer während der Vorabphase hinzugefügten und nie entfernten Überschreibungs-Einträge stammt.

Daher lag das eigentliche Problem nicht darin, dass TypeScript 7 sich anders verhielt. Es ging vielmehr um zwei verschiedene Compiler-Binärdateien, eine inkonsistente Lockfile-Struktur sowie eine Slack-Nachricht, die behauptete, „7 sei bereits vorhanden“, obwohl das offensichtlich nicht der Fall war – zumindest nicht überall.

So sah die Umsetzung in der Praxis aus: ein Pull Request mit dem Titel „Entfernen der as InvoiceId-Typumwandlungen, 7 ist strenger.“ TypeScript 7 war in diesem Fall tatsächlich nicht strenger. Derselbe Commit aktivierte außerdem die Compiler-Flagge erasableSyntaxOnly, was eine völlig separate Richtlinienänderung darstellt und später eigens erörtert wird. Die Kombination einer reinen Leistungsverbesserung mit einer Verhaltensrichtlinienänderung ist genau der Grund, warum solche Mythen entstehen.

Die Lösung besteht darin, einen solchen Commit in zwei Teile aufzuteilen: zunächst nur den Versionsanstieg und anschließend getrennt die Richtlinienänderung. Erst dann hat die Zeitmessung eine Bedeutung.

Der Satz, den Microsoft tatsächlich veröffentlicht hat

In der offiziellen Ankündigung von TypeScript 7.0 vom 8. Juli 2026 beschrieb Daniel Rosenwasser die Veröffentlichung damit, dass sie eine nativere Codeausführung, mehrthreadige Verarbeitung über gemeinsam genutzte Speicherbereiche sowie eine Reihe von Optimierungen biete, die in der Regel Geschwindigkeitssteigerungen im Bereich von 8 bis 12 Mal bei vollständigen Builds bewirken.

Der Teil dieser Ankündigung, den die meisten Menschen überspringen, ist der Satz darüber, dass das Typsystem unverändert bleibt.

Laut der Ankündigung wurde die neue, auf Go basierende Implementierung durch einen sorgfältigen Portierungsprozess von der bestehenden Implementierung übernommen, anstatt sie von Grund auf neu zu entwickeln, und ihr Verhalten bei der Typüberprüfung entspricht strukturell dem von TypeScript 6.0.

In dieser Upgrade-Beschreibung gibt es keine neuen Syntaxen. Was sich geändert hat, ist die reine Ausführungsgeschwindigkeit bei derselben zugrundeliegenden Logik. Wenn sich Typfehler nach dem Versionsaufstieg ändern, handelt es sich dabei nicht um erwartetes Verhalten – das ist ein Fehler, der gemeldet werden sollte.

Next.js 16.3 fügte Dokumentation hinzu, die darauf hinweist, dass next build bei Installation von TypeScript 7 als direkter Abhängigkeit die Typüberprüfung mit TypeScript 7 durchführt. Dadurch gibt es einen zweiten Punkt, an dem man die Laufzeit messen kann, zusätzlich zur eigenständigen Ausführung von tsc.

Die beiden Timer, die ich tatsächlich verwendet habe

Gleiche Testanwendung bei allen Tests. Next.js 16.3, React 19, vier Routen, die Rechnungstabelle – und für diese Sitzung wurde das Compiler-Flag deaktiviert, damit die Werte nicht miteinander vermischt werden.

Timer eins: tsc --noEmit --extendedDiagnostics. Timer zwei: next build, wobei man die Zeile zur Typüberprüfung in der Ausgabe beobachtet.

Ich habe TypeScript 7 als Abhängigkeit zum Projekt hinzugefügt.

pnpm add -D typescript@7

Die Ausführbardatei wird weiterhin tsc genannt. Während der Vorabversion-Phase trug das Paket den Namen @typescript/native-preview und seine Binärdatei hieß tsgo. Diese Benennung wurde aufgegeben, da es sich nun um die stabile Version handelt. Wenn Sie auf einen Gist oder ein Thread stoßen, der weiterhin auf tsgo verweist, bezieht sich das auf die Vorabversion-Phase und nicht auf das aktuelle Tool.

Damit beide Hauptversionen gleichzeitig auf dem Datenträger existieren können, hat Microsoft ein Begleitpaket veröffentlicht, @typescript/typescript6. Es stellt eine tsc6-Binärdatei bereit, wodurch der reguläre tsc-Befehl auf Version 7 verweisen kann, ohne Teams oder Tools zu verlassen, die weiterhin auf Version 6 angewiesen sind.

pnpm add -D @typescript/typescript6

Daraufhin kann für beide dieselbe tsconfig.json-Datei verwendet werden:

pnpm exec tsc6 --noEmit --extendedDiagnostics
pnpm exec tsc --noEmit --extendedDiagnostics

Dieselben Quelldateien. D dieselbe strict-Einstellung. Dieselben Pfadaliasse, die Next.js beim Erstellen des Projekts mit create-next-app generiert hat.

Jeder Befehl wurde dreimal ausgeführt, wobei die erste Ausführung verworfen wurde, da ein vorwarmter Dateisystem-Cache keine realistische erste Überprüfung darstellt.

Wie die Zahlen in dieser Codebasis aussahen

Die Testanwendung verfügt über vier Routen sowie etwa 80 TypeScript-Dateien, die zum Projekt selbst gehören, zusätzlich zu den Dateien, die Next.js automatisch generiert.

Ausführung von TypeScript 6.0 über tsc6, mit Berücksichtigung des Medianwerts der beiden beibehaltenen Ausführungen:

Überprüfte Dateien: 412
Überprüfungszeit: 3,82 Sekunden
Gesamtzeit: 4,25 Sekunden

Ausführung von TypeScript 7.0 über tsc, unter Verwendung derselben Konfiguration:

Überprüfte Dateien: 412
Überprüfungszeit: 0,41 Sekunden

Gesamtzeit: 0,60 Sekunden

Das entspricht einer Verbesserung von etwa 9-fach speziell bei der Typüberprüfung. Nicht 12-fach, und auch keineswegs dem Rückgang von 125 Sekunden auf 10 Sekunden, der manchmal für VS Code-Szenarien angegeben wird. Das ist einfach das Ergebnis dieses spezifischen Repositoriums.

Betrachtet man den Schritt der Typüberprüfung innerhalb von next build:

In Version 6: 5,1 Sekunden
In Version 7: 1,4 Sekunden

Alles andere in next build – das Bündeln sowie die statische Generierung der vier Routen – blieb mehr oder weniger unverändert. Wenn Ihr CI-Pipeline zuerst Linting durchführt, anschließend die Typüberprüfung, danach das Kompilieren und schließlich End-to-End-Tests, dann wird der Anteil der Typüberprüfung deutlich kleiner, doch der End-to-End-Anteil bringt keine Verbesserung.

Ein weiteres Projekt, das reich an Zod-Schemata sowie etwa 300 Dateien mit Validierungslogik und -Handlern verfügt, zeigte einen größeren Sprung:

Überprüfungszeit für Version 6: 11,4 Sekunden
Überprüfungszeit für Version 7: 1,3 Sekunden

Code mit vielen Typen scheint zu einem größeren relativen Geschwindigkeitszuwachs zu führen. Eine kleine Marketing-Website mit einem Dutzend Dateien würde kaum eine Verzehnfachung der Geschwindigkeit zeigen, einfach weil es für den Prüfer kaum etwas zu prüfen gibt.

Der Fehler, der nach dem Upgrade auftrat

Es handelte sich dabei nicht um eine Änderung im Verhalten der Typprüfung – es war ein Problem mit den Werkzeugen.

eslint-plugin-react-hooks startete weiterhin typescript über seine Einstellung parserOptions.project. Das funktionierte unter Version 7 einwandfrei, war jedoch in den früheren tsgo-Vorabversionen nicht mehr funktionsfähig. Ein veralteter parserOptions-Block wies weiterhin auf eine separate Datei tsconfig.eslint.json hin, in der explizit "compilerOptions": { "strict": false } festgelegt war, um ältere Tests davon abzuhalten, Fehlermeldungen auszugeben.

CI verwendete diese lockere Konfiguration für das Linting, während tsc die tatsächliche Projektkonfiguration nutzte. Zwei verschiedene Quellen der Wahrheit. Infolgedessen gab es eine noImplicitAny-Lücke in einer Test-Utility, die vom Linting nicht erkannt wurde. Als Version 7 es möglich machte, tsc so kostengünstig zu betreiben, dass es ständig ausgeführt werden konnte, fügte ich tsc --noEmit direkt zu den Prüfungen in den Pull-Requests hinzu und entfernte die abgeschwächte, ausschließlich für ESLint bestimmte tsconfig vollständig.

{
  "scripts": {
    "typecheck": "tsc --noEmit",
    "lint": "biome check .",
    "ci": "pnpm typecheck && pnpm lint && pnpm test && pnpm build"
  }
}

Die eigentliche Lösung war nicht besonders spektakulär. Die verbreitete Erklärung lautete: „Version 7 hat unsere Typen kaputtgemacht.“ Das stimmte nicht – die doppelte Konfiguration war schuld.

Überprüfen, was tatsächlich auf Ihrem System läuft

Bevor Sie irgendeiner Zahl vertrauen, prüfen Sie, welches Binärprogramm die Arbeit erledigt.

pnpm exec tsc -v

Suchen Sie in der Ausgabe nach Version 7.x. Wenn weiterhin 5 oder 6 angezeigt wird, lädt Ihr Arbeitsbereich eine veraltete Kopie von irgendwoher. In einem pnpm Monorepo weist which Sie an den falschen Ort. pnpm exec hingegen nicht.

Führen Sie die Diagnose dreimal getrennt aus und werfen Sie den ersten Versuch weg.

pnpm exec tsc --noEmit --extendedDiagnostics

Die Felder, auf die Sie in dieser Ausgabe achten sollten, sind: die Anzahl der verarbeiteten Dateien, welcher Anteil aus Bibliothekskodern stammt, welcher Anteil aus Typdefinitionen, wie viel Ihr eigener Quellcode ist, sowie die Dauer der Überprüfung und die Gesamtdauer.

Installieren Sie nun Version 6 neben Version 7 und weisen Sie sie auf dieselbe Dateiengruppe hin.

pnpm add -D @typescript/typescript6
pnpm exec tsc6 --noEmit --extendedDiagnostics

Falls die Prüfzeit in einer Codebasis mit Hunderten von Dateien nicht um einen signifikanten Faktor abnimmt, dann nutzen Sie entweder tatsächlich nicht Version 7 oder Ihr Beispiel ist zu klein – ein Dutzend Dateien werden Ihnen nichts zeigen.

Außerdem lohnt es sich, next build zweimal auszuführen, einmal mit jeder Binärdatei, und jedes Mal nur die Zeile zur Typprüfung aufzuzeichnen. Fassen Sie nicht die gesamte Build-Dauer zusammen, um die Geschwindigkeit von TypeScript darzustellen – Turbopack ist ein separates System, das eigene Aufgaben erledigt.

Falls Sie auf einen Typfehler stoßen, der unter Version 7, aber nicht unter Version 6 auftritt, bei identischem tsconfig, melden Sie ihn. Das fällt außerhalb des hier besprochenen Rahmens. Laut Microsofts eigenen Angaben ist die Prüflogik strukturell unverändert, weshalb ein solcher Unterschied ein Fehler ist und nicht als erwarteter Migrationsaufwand betrachtet werden sollte.

Woher die Geschwindigkeit tatsächlich stammt

Der Vorteil liegt im Checker selbst. Auch das Parsen und Binden wurde schneller, doch die Prüfzeit ist die Zahl, die in Ihren CI-Logs erscheint und die die Nutzer tatsächlich wahrnehmen.

Die Reaktionsgeschwindigkeit des Editors ist eine andere Geschichte – sie hängt vom Sprachdienst ab, nicht vom eigenständigen Compiler. In der Rechnungstabelle fühlten sich Navigationsschritte wie „Zur Definition“ subjektiv schneller an. Es wurden keine Zeiten auf Tastendruckebene erfasst, daher gibt es hier keine Tabelle mit Millisekundenangaben.

next dev sowie sein Fast Refresh-Modus wurden durch diese Änderung nicht dramatisch schneller, weil Fast Refresh von Anfang an bei einem vollständigen tsc-Ausführungsvorgang nicht blockiert wurde.

Das bringt wirklich Vorteile, wenn es um Agenten oder automatisierte Schleifen geht, die nach jedem bearbeiteten Datei tsc --noEmit auslösen. Die Schleife läuft nun schnell genug, sodass das Überspringen der Überprüfung kein verlockender Abkürzungsweg mehr ist. Das ist der eigentliche, wenn auch nicht beworbene Vorteil. Der gleiche Agent, der weiterhin einfache Enums anstelle von as const-Objekten verwendet, erfährt nun nur schneller davon.

Berechnung der tatsächlichen Kosten

Installation: eine Anpassung einer Abhängigkeit sowie das Löschen eines übrig gebliebenen tsgo-Skripts, das nicht mehr benötigt wurde.

Einfluss auf CI: Bei der Hauptanwendung sank die Zeit für die Typüberprüfung von 3,8 Sekunden auf 0,4 Sekunden; im Worker-Tree ging sie von 11,4 Sekunden auf 1,3 Sekunden zurück. Die verbleibenden acht Minuten und mehr der Pipeline blieben unverändert.

Kosten durch Gerüchte: Ein Pull Request machte Version 7 für eine Rückfallerscheinung verantwortlich, die tatsächlich durch einen Flag-Wechsel in derselben Commit-Kombination verursacht wurde. Halten Sie diese Commits getrennt.

Editor-Erlebnis: Eine angenehme Verbesserung, aber nicht eine, die es lohnt, in den Kommentaren mit einer Zahl zu quantifizieren.

Namenkennung: tsc bezieht sich nun auf Version 7, und tsc6 dient als Ersatz. Wenn beide Binärdateien im PATH vorhanden sind, dokumentieren Sie dies klar im README, damit später niemand verwirrt wird.

Sollten Sie auf 7 upgraden oder bei 6 bleiben?

Wechseln Sie auf Version 7. Das Verhalten der Typüberprüfung bleibt beim selben Engine – sie läuft nur schneller – und es gibt keine neue Syntax, die man zusätzlich lernen müsste.

Bleiben Sie nur bei Version 6, wenn es ein bestimmtes Plugin gibt, dessen Name Sie nennen können und das noch keine Unterstützung für Version 7 hinzugefügt hat. Geben Sie den Namen dieses Plugins direkt in Ihren Versionspin ein. „Auf Stabilisierungen warten“ ist an sich kein gültiger Grund.

Bündeln Sie den Upgrade auf Version 7 nicht zusammen mit einer Änderung von erasableSyntaxOnly in derselben Pull-Request – wenn etwas kaputtgeht, können Sie nicht erkennen, welche Änderung dafür verantwortlich ist.

Auch sollten Sie tsc --noEmit nicht aus Ihrem CI-Pipeline entfernen, nur weil Version 7 dadurch schneller wird. Die Geschwindigkeit ist der Grund, den Check beizubehalten – nicht der Grund, ihn zu entfernen.

Die ehrlichen Grenzen dieses Vergleichs

Die Verkürzung von 3,82 Sekunden auf 0,41 Sekunden gilt für diese spezielle Anwendung mit vier Routen. Der Rückgang von 11,4 Sekunden auf 1,3 Sekunden stammt aus einer separaten Codebasis, die sich auf Worker konzentriert. Die von Microsoft angeführte Verbesserung um das 8- bis 12-fache bezieht sich auf vollständige Builds in Repositorien der Größe von VS Code. Hier wurde VS Code nicht neu ausgeführt.

Der Ausdruck „strukturell identisch“, datiert vom 8. Juli 2026, stammt direkt aus Microsofts eigenen Ankündigung. Wenn sich die Fehler, die Ihr Projekt meldet, nach dem Upgrade tatsächlich ändern, sollten Sie dies als Defekt melden und nicht als irgendeinen seltsamen Nebeneffekt ignorieren.

Es gibt keine Möglichkeit, hier die Hoisting-Operationen Ihrer Abhängigkeiten zu überprüfen. Wenn pnpm exec tsc -v lokal eine bestimmte Hauptversion anzeigt, während Ihre CI-Logs eine andere anzeigen, haben Sie TypeScript 7 noch nicht tatsächlich validiert – es handelt sich dabei um ein PATH-Lösungsproblem, das als Versionvergleich getarnt ist.

Führen Sie sowohl tsc6 als auch tsc jeweils dreimal aus. Notieren Sie die Überprüfungszeit sowie die Anzahl der Dateien bei jedem Durchlauf. Diese vier Zahlen bilden das Rohdatensatz, den Sie teilen können, falls Sie Feedback zu Ihrer spezifischen Konfiguration erhalten möchten.

Eine minimale Nachbildung für ein Scratch-Verzeichnis

Falls Sie Ihre eigentliche Anwendung vorerst unberührt lassen möchten, hier ist das kleinste mögliche Paar an Installationen, das dennoch das Hoisting-Problem veranschaulicht.

mkdir ts7-lab && cd ts7-lab
pnpm init
pnpm add -D typescript@7 @typescript/typescript6
echo '{ "compilerOptions": { "strict": true, "noEmit": true } }' > tsconfig.json
echo 'export type InvoiceId = string; export const n: InvoiceId = "inv_1";' > index.ts
pnpm exec tsc -v
pnpm exec tsc6 -v
pnpm exec tsc --extendedDiagnostics
pnpm exec tsc6 --extendedDiagnostics

Notieren Sie die Versionssätze sowie die Überprüfungszeiten für beide. Fügen Sie anschließend ein Arbeitsplatzpaket hinzu, das weiterhin typescript@6 als Abhängigkeit festlegt, und beobachten Sie, was pnpm exec tsc -v aus der Repository-Root ausgibt. Genau dieses Ungleichgewicht ist die Art von Überraschung, mit der CI Sie konfrontieren kann.

Zum Invoices-Projekt war noch etwas zu vermerken: Ob next build tatsächlich eine Zeile mit „Finished TypeScript“ aus Version 7 ausgibt. Wenn diese Zeile nie erscheint, verwendet Next.js einen anderen Typprüfer als den, den Ihr typecheck-Skript aufruft. Stellen Sie sicher, dass beide Tools übereinstimmen – das parallele Ausführen zweier unterschiedlicher Prüfer war genau der Grund, warum der branded-id-Bug zuvor unentdeckt blieb.

Eine einminütige Überprüfung für Reviewer: Öffnen Sie app/invoices/page.tsx, legen Sie den Mauszeiger auf einen searchParams-Typ und warten Sie auf die Hilfetextanzeige. Wiederholen Sie dies in Version 6 und Version 7. Dabei ist kein Stoppuhr erforderlich – es geht lediglich darum, dass sich der Hilfetext selbst zwischen den Versionen nicht geändert hat. Dasselbe Verhalten, nur ein schnellerer Unterbau.

Falls Ihr Projekt eine separate tsconfig.eslint.json-Datei mit lockeren Einstellungen verwendet, entfernen Sie sie in derselben Woche, in der Sie aufrüsten. Ein einfacher Typüberprüfer beseitigt den Grund dafür, dass ESLint nach anderen Regeln prüft als Ihr Build-Prozess.

Eine Messgröße, die man bereits ab dem ersten Tag aufzeichnen sollte: Führen Sie tsc --noEmit --pretty false 2>&1 anschließend durch wc -l, vor und nach dem Upgrade. Die Fehlerzahlen müssen exakt übereinstimmen. In der Rechnungs-App waren es null und null. Im Worker-Tree-Projekt waren es vier und vier – dieselben Dateien, dieselben Fehlermeldungen beides Mal. Genau diese Übereinstimmung ist im Grunde die gesamte Migrationsgeschichte. Wenn Ihre Zahlen nicht übereinstimmen, hören Sie auf, ständig den „10x-Grundsatz“ zu zitieren, und vergleichen Sie stattdessen die beiden Ausgabe-Logs direkt miteinander.

Speichern Sie beide Protokolle als /tmp/tsc6.txt und /tmp/tsc7.txt, mindestens eine Woche nach jedem Update. Löschen Sie sie, sobald sich die Situation beruhigt hat – aber nicht in der Nacht, in der Sie tatsächlich das Update veröffentlichen.

Ratgeber für die Person, die später diese Codebasis übernimmt

Fordern Sie im Pull-Request-Vorlage die Ausgabe von pnpm exec tsc -v an. Wenn dort nicht „7“ steht, wurde die Leistungsverbesserung tatsächlich nicht veröffentlicht.

Kombinieren Sie dieses Update nicht mit erasableSyntaxOnly, verbatimModuleSyntax oder einer umfassenderen Reinigung der tsconfig im selben Änderungsvorschlag. Diese gehören zu einem späteren Schritt. Hier geht es nur darum, dass ein schnellerer Compiler dieselbe Arbeit erledigt.

Lassen Sie tsc --noEmit weiterhin im CI laufen, obwohl es jetzt fast keine Kosten verursacht. Genau diese geringen Kosten sind der Grund, warum es beibehalten werden sollte.

Labor-Sitzung, live aufgezeichnet: Befehle und Ausgaben

Dieser Abschnitt beschreibt das gleiche vier-Route-Invoicen-Labor, das in dieser gesamten Serie verwendet wird. Die vor dem Start festgelegten Versionen sind: Node 24, TypeScript 7, Next 16.3.

Diese Schritte befinden sich im notes/lab.md des Repositories, damit eine zukünftige Sitzung nicht auf dem Gedächtnis beruht. Sie können sie nacheinander kopieren.

node -v
pnpm exec tsc -v
pnpm exec next --version

Notieren Sie alle drei Versionennummern oben in Ihren Notizen. Falls eine der Hauptversionen nicht mit dem übereinstimmt, was Sie für laufend halten, stoppen Sie hier – alles danach wird auf subtilere Weise irreführende Ergebnisse liefern.

Danach folgt die Durchsuchung der Routen:

pnpm exec next dev

Besuchen Sie /, /invoices, /invoices/1, /settings und anschließend wieder /invoices. Aktivieren Sie in den DevTools die Option „Protokoll beibehalten“. Machen Sie einen Screenshot sowohl des Filterfeldes als auch der Adressleiste. Diese Kombination erweist sich in weitaus mehr dieser Überprüfungen als erwartet als der nützlichste Datensatz.

Führen Sie anschließend den Typprüfer aus:

pnpm exec tsc --noEmit --pretty false
echo $?

Ein Ausgabecode von null ist nicht das Endergebnis – es handelt sich dabei lediglich um die grüne Genehmigung, das Laufzeitverhalten zu überprüfen.

Zum Schluss der eigentliche Kern dieses Textes: Führen Sie die bereits unter „Wie man es auf dem eigenen Rechner sieht“ aufgeführten Befehle aus. Überspringen Sie sie nicht nur deshalb, weil Sie hier bereits Zahlen gesehen haben – Ihr Rechner ist schließlich nicht derjenige, von dem diese Zahlen stammen. Umgebungsbedingte Wärme, ein 16 GB großer Laptop sowie alles, was Chrome im Hintergrund tut, beeinflussen die Werte für RSS, Überprüfungszeit und Abbruchzeit der Datenabfrage stärker als irgendeine kleine Aktualisierung des Frameworks.

Noch eine Gewohnheit, die sich lohnt: Eine einzige Zeile mit „fehlgeschlagener Behebung“ in den Notizen – ein Satz wie „Ich habe X ausprobiert, aber immer noch Y.“ Genau diese Zeile sorgt dafür, dass es sich um ein funktionsfähiges Protokoll und nicht um eine perfekt gestaltete Präsentation handelt. Eine nützliche Ergänzung sind eine Versionsliste, der genaue Befehl, die Ausgabe sowie die Beschreibung der fehlgeschlagenen Behebung. Ein Screenshot des Dashboards reicht dafür nicht aus.