Ihr TypeScript-Projekt wird immer grösser und langsamer, aber Sie wissen nicht, was diese Verlangsamungen verursacht? Wir werden anhand eines Beispiels zeigen, wie man die Teile identifiziert, die bei der Kompilierung die meiste Zeit in Anspruch nehmen.
Welche Tools verwenden?
Wir werden als Beispiel
dieses GitHub-Repo. Es ist ein React-Projekt mit einer Reihe von i18n-Übersetzungsschlüsseln (8 Workspaces mit je 150 Schlüsseln, also 1200 Schlüssel).
TypeScript bietet uns einige Tools, um Performance-Probleme zu untersuchen, die mit der Kompilierung zusammenhängen.
Zunächst kann man, wenn man den TypeScript-Compiler startet, den Parameter extendedDiagnostics übergeben.
npx tsc --extendedDiagnostics
ergibt etwa:
Files: 90
Lines of TypeScript: 83
Lines of JavaScript: 0
Lines of JSON: 2448
Parse time: 0.42s
ResolveModule time: 0.02s
ResolveTypeReference time: 0.00s
Program time: 0.48s
Bind time: 0.20s
Check time: 2.64s
Emit time: 0.00s
Total time: 3.32s
Done in 3.53s.
Man erkennt, dass in diesem Repo:
sehr wenig TypeScript vorhanden ist
viel JSON vorhanden ist (tatsächlich sind dies die Übersetzungsschlüssel, zum Beispiel
menu.json)
was am meisten Zeit in Anspruch nimmt, ist der Schritt des Type Checking
Gut, es ist gut zu wissen, dass der Type Checking Zeit in Anspruch nimmt, aber es wäre besser zu wissen, welche Zeilen im Code dafür verantwortlich sind!
Das trifft sich gut, wir können dies in 2 Schritten herausfinden.
Zuerst werden wir während der Kompilierung Debug-Dateien generieren:
npx tsc --generateTrace <path>
(man muss ersetzen
durch einen gültigen Pfad, wo tsc einen Ordner erstellen und dann die Debug-Dateien der Kompilierung schreiben wird)Um diese Debug-Datei zu lesen, werden wir den Reiter «Performance» der Entwicklungstools (in einem Chromium-basierten Browser) verwenden.
Dort finden Sie einen Button «Load profile...», um eine Debug-Datei (trace.json) zu laden:
Nachdem die Datei geladen wurde, muss man sich irgendwie durch die Oberfläche navigieren und auf die Abschnitte des Diagramms klicken, die am längsten dauern. Zum Beispiel:
Auf dem Bild sieht man, dass eine Operation vom Typ «checkExpression» in der Datei App.tsx 3.17 Sekunden dauert
Man kann dank der Angabe genau wissen, was dies im Code entspricht: pos 372 end 378
Man müsste also App.tsx öffnen und vom Zeichen 372 bis zum Zeichen 378 schauen.
Gut, es ist etwas mühsam, ich gebe zu, es wäre gut, wenn ein Tool die längsten Teile der Kompilierung automatisch finden und die Zeile / Spalte für uns berechnen könnte...
Um es zu verwenden, gibt es nichts Einfacheres:
npx @typescript/analyze-trace <path>
(ersetzen Sie
durch den Pfad zum Ordner, in dem die Debug-Dateien generiert wurden)In unserem Beispiel wird es Folgendes ergeben:
Hot Spots
└─ Check file /home/mayeul/Projects/tests/test-tsc/src/App.tsx (3700ms)
└─ Check deferred node from (line 17, char 27) to (line 18, char 34) (3186ms)
└─ Check expression from (line 18, char 11) to (line 18, char 21) (3172ms)
└─ Check expression from (line 18, char 22) to (line 18, char 30) (3170ms)
└─ Check expression from (line 18, char 23) to (line 18, char 29) (3170ms)
Wenn wir uns in App.tsx Zeile 18, Spalte 23 ansehen (genau unser Zeichen 372 von vorhin), stellen wir fest, dass das Problem in keys.map() liegt
(die Datei App.tsx)
export const App = () => {
const { t } = useTranslation();
const keys: AllI18nKeys[] = [
"anotherTest:anotherTest-100",
"hehe:hehe-30",
"login:login-103",
"common:common-126"
];
return (
<div>
<h1>{t("login:login-0")}</h1>
{keys.map((key) => (
<p key={key}>{t(key)}</p>
))}
</div>
);
};
Nun können wir uns fragen, warum es langsam ist.
Nun, um eine kleine Vorstellung zu bekommen, schauen wir uns das Microsoft-Wiki zu den
TypeScript-Leistungen.
Im
Abschnitt zu Unions, stellen wir fest, dass Microsoft davon abrät, Unions mit vielen Elementen zu verwenden, doch der Typ AllI18nKeys ist eine Union von 1200 Übersetzungs-Keys...
Und das war's! Jetzt sind Sie in der Lage, die Ursachen für langsame Kompilierungszeiten in Ihrem Projekt zu finden. Die Lösung dieser Probleme ist jedoch eine andere Sache 😉
