Du verstehst, was der Strict-Modus wirklich aktiviert, und weißt, wie du mit den typischen Fehlern umgehst, die er in einem bestehenden Projekt aufdeckt.
Diese Lektion in Kodokon öffnen"strict": true ist keine einzelne Option, sondern ein Sammelschalter, der eine ganze Familie von Prüfungen aktiviert: strictNullChecks, noImplicitAny, strictFunctionTypes, strictBindCallApply, strictPropertyInitialization, noImplicitThis, useUnknownInCatchVariables und alwaysStrict. Jede neue TypeScript-Version kann weitere hinzufügen: strict zu aktivieren abonniert dich also für künftige Prüfungen. Jedes Flag lässt sich weiterhin einzeln deaktivieren, was eine schrittweise Migration in einer bestehenden Codebasis ermöglicht.
{
"compilerOptions": {
"strict": true,
"noUncheckedIndexedAccess": true,
"noImplicitOverride": true,
"noFallthroughCasesInSwitch": true,
"exactOptionalPropertyTypes": true,
"verbatimModuleSyntax": true,
"skipLibCheck": true
}
}Die zwei wirkungsvollsten Flags sind strictNullChecks und noImplicitAny. Das erste entfernt null und undefined aus allen Typen: Jeder möglicherweise fehlende Wert muss als T | undefined deklariert und vor der Verwendung behandelt werden. Das zweite weigert sich, einen nicht annotierten Parameter auf any zurückfallen zu lassen. Zusammen beseitigen sie die zwei großen Bug-Familien von JavaScript: "cannot read property of undefined" und die Weitergabe ungeprüfter Werte. useUnknownInCatchVariables vervollständigt das Bild: Die Variable in einem catch ist unknown, denn JavaScript erlaubt es, alles Mögliche zu werfen.
function findPort(
env: Record<string, string | undefined>
): number {
const raw = env["PORT"];
if (raw === undefined) {
return 3000;
}
return Number.parseInt(raw, 10);
}
declare function riskyOperation(): void;
try {
riskyOperation();
} catch (err) {
const message =
err instanceof Error ? err.message : String(err);
console.error(message);
}Häufige Fehler bei der Migration und ihre echten Gegenmittel. "Object is possibly undefined": Bevorzuge eine Verengung (if), Optional Chaining ?. oder einen ??-Standardwert gegenüber der Non-Null-Assertion !, die den Absturz nur woandershin verschiebt. "Property has no initializer" (strictPropertyInitialization): Initialisiere im Konstruktor, statt zum ! auf dem Feld zu greifen. Achte außerdem auf die Falle ?? gegenüber ||: port || 3000 ersetzt auch 0 und "", während port ?? 3000 nur null und undefined ersetzt.
interface Settings { retries?: number }
function resolveRetries(s: Settings): number {
const bad = s.retries || 3;
const good = s.retries ?? 3;
return good;
}
const names = ["Ada", "Linus"];
const first = names[0];
const upper = first?.toUpperCase() ?? "N/A";Über den Sammelschalter hinaus verdienen drei Optionen eine Diskussion im Team. noUncheckedIndexedAccess fügt jedem indizierten Zugriff (arr[i], dict[key]) undefined hinzu: sicherer, aber wortreich in Code, der viel mit Arrays arbeitet - viele Teams übernehmen es nur in neuen Projekten. exactOptionalPropertyTypes unterscheidet "Eigenschaft fehlt" von "Eigenschaft auf undefined gesetzt", entscheidend für Patches. skipLibCheck überspringt die Prüfung der .d.ts-Dateien deiner Abhängigkeiten: ein bewusster Kompromiss zwischen Build-Zeit und dem Erkennen von Konflikten zwischen Bibliotheken.
"strict": true in der tsconfig.json?retries?: number den Wert 0 hat, was ist der Unterschied zwischen retries || 3 und retries ?? 3?// @ts-expect-error besser als // @ts-ignore, um Typisierungsschuld zu markieren?