Vous comprenez ce que le mode strict active réellement et savez traiter les erreurs typiques qu'il révèle dans un projet existant.
Ouvrir cette leçon dans Kodokon"strict": true n'est pas une option mais un agrégat qui active une famille de vérifications : strictNullChecks, noImplicitAny, strictFunctionTypes, strictBindCallApply, strictPropertyInitialization, noImplicitThis, useUnknownInCatchVariables et alwaysStrict. Chaque nouvelle version de TypeScript peut en ajouter : activer strict vous abonne aux futures vérifications. Chaque drapeau reste désactivable individuellement, ce qui permet une migration progressive sur une base de code existante.
{
"compilerOptions": {
"strict": true,
"noUncheckedIndexedAccess": true,
"noImplicitOverride": true,
"noFallthroughCasesInSwitch": true,
"exactOptionalPropertyTypes": true,
"verbatimModuleSyntax": true,
"skipLibCheck": true
}
}Les deux drapeaux au plus fort impact sont strictNullChecks et noImplicitAny. Le premier retire null et undefined de tous les types : chaque valeur potentiellement absente doit être déclarée T | undefined et traitée avant usage. Le second refuse qu'un paramètre sans annotation retombe sur any. Ensemble, ils éliminent les deux grandes familles de bugs JavaScript : le « cannot read property of undefined » et la propagation de valeurs non vérifiées. useUnknownInCatchVariables complète le tableau : la variable d'un catch est unknown, car JavaScript autorise de lancer n'importe quoi.
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);
}Erreurs courantes en migration, et leurs vrais remèdes. « Object is possibly undefined » : préférez le narrowing (if), l'optional chaining ?. ou un défaut ?? à l'assertion non nulle !, qui ne fait que déplacer le crash. « Property has no initializer » (strictPropertyInitialization) : initialisez dans le constructeur plutôt que de dégainer ! sur le champ. Attention aussi au piège de ?? contre || : port || 3000 remplace aussi 0 et "", alors que port ?? 3000 ne remplace que null et undefined.
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";Au-delà de l'agrégat, trois options méritent le débat en équipe. noUncheckedIndexedAccess ajoute undefined à tout accès indexé (arr[i], dict[key]) : plus sûr, mais verbeux sur du code de manipulation de tableaux - beaucoup d'équipes l'adoptent sur les nouveaux projets seulement. exactOptionalPropertyTypes distingue « propriété absente » de « propriété valant undefined », crucial pour les patchs. skipLibCheck ignore la vérification des .d.ts des dépendances : compromis assumé entre temps de build et détection de conflits entre bibliothèques.
"strict": true dans tsconfig.json ?retries?: number valant 0, quelle est la différence entre retries || 3 et retries ?? 3 ?// @ts-expect-error à // @ts-ignore pour marquer une dette de typage ?