strict & ses drapeaux, ou chaque drapeau est un théorème strict & its flags, or each flag is a theorem

Chaque drapeau strict active un théorème. Encore faut-il savoir lequel.Each strict flag turns on a theorem. You just need to know which.

Le réglage du compilateur est le terrain le plus exposé au cargo cult : on copie un tsconfig trouvé en ligne sans savoir ce qu'il prouve. Or chaque drapeau strict active une garantie précise — un théorème que le compilateur s'engage à démontrer — pour un coût précis. Le plus fondamental, strictNullChecks : sans lui, null et undefined se glissent silencieusement dans tous les types, et un User peut être null sans que le type l'avoue. Avec lui, l'absence devient explicite, et le compilateur force à la traiter.Compiler configuration is the terrain most exposed to cargo cult: you copy a tsconfig found online without knowing what it proves. Yet each strict flag turns on a precise guarantee — a theorem the compiler commits to proving — for a precise cost. The most fundamental, strictNullChecks: without it, null and undefined silently slip into all types, and a User can be null without the type admitting it. With it, absence becomes explicit, and the compiler forces you to handle it.

// strictNullChecks: false  →  null et undefined se glissent dans TOUS les types
function greet(user: User) {
  return "Bonjour " + user.name;   // user pourrait être null… le type ne le dit pas
}
greet(null);   // ✓ accepté ! 💥 null.name à l'exécution

// strictNullChecks: true  →  null/undefined deviennent explicites
function greet(user: User) {        // User n'inclut PLUS null
  return "Bonjour " + user.name;
}
greet(null);   // ✗ Argument of type 'null' is not assignable to parameter of type 'User' — attrapé

function greetMaybe(user: User | null) {
  if (user) return "Bonjour " + user.name;   // ✓ on doit prouver la non-nullité
  return "Bonjour inconnu";
}

Même en strict, arr[i] est typé T — alors qu'il peut être undefined.Even in strict, arr[i] is typed T — though it can be undefined.

La surprise que presque tout le monde rate : strict n'inclut pas noUncheckedIndexedAccess. Par défaut, donc, xs[10] est typé number même si l'indice est hors limites, et cfg["absent"] est typé string même si la clé n'existe pas. Le compilateur ne peut pas prouver qu'un indice est valide — mais il fait comme si. Le drapeau noUncheckedIndexedAccess corrige ce mensonge : tout accès indexé devient T | undefined, et l'on doit prouver la présence. C'est le drapeau le plus sous-utilisé, et l'un des plus honnêtes.The surprise almost everyone misses: strict does not include noUncheckedIndexedAccess. By default, then, xs[10] is typed number even out of bounds, and cfg["absent"] is typed string even if the key doesn't exist. The compiler can't prove an index is valid — but it pretends to. The noUncheckedIndexedAccess flag fixes this lie: every indexed access becomes T | undefined, and you must prove presence. It's the most underused flag, and one of the most honest.

// noUncheckedIndexedAccess: false (le défaut, même en strict)
const xs: number[] = [1, 2, 3];
const x = xs[10];        // x : number — alors que xs[10] est undefined !
x.toFixed();             // 💥 aucune erreur, mais undefined.toFixed à l'exécution

const cfg: Record<string, string> = {};
cfg["absent"].trim();    // 💥 même mensonge : type string, valeur undefined

Hors limites ou clé absente, le type reste number / string : le compilateur affirme une présence qu'il n'a pas prouvée. C'est un mensonge structurel toléré par défaut, même sous strict — et une source classique de undefined is not a function.Out of bounds or missing key, the type stays number / string: the compiler asserts a presence it never proved. It's a structural lie tolerated by default, even under strict — and a classic source of undefined is not a function.

strict est un parapluie — et plusieurs de ses drapeaux, on les a déjà rencontrés.strict is an umbrella — and several of its flags we've already met.

strict: true n'est pas un drapeau, c'est un parapluie qui en active une famille. La plupart ont déjà traversé cette série : noImplicitAny attrape les any implicites des entrées (Vol 4.1), strictFunctionTypes rend les paramètres de fonction contravariants (Vol 5.3), useUnknownInCatchVariables type le catch en unknown (Vol 8.2), strictNullChecks rend l'absence explicite (chapitre 1). Mais deux théorèmes utiles restent hors parapluie : noUncheckedIndexedAccess et exactOptionalPropertyTypes. Connaître la liste, c'est savoir ce qu'on prouve — et ce qu'on a oublié d'activer.strict: true isn't a flag, it's an umbrella that turns on a family. Most have already crossed this series: noImplicitAny catches input implicit anys (Vol 4.1), strictFunctionTypes makes function parameters contravariant (Vol 5.3), useUnknownInCatchVariables types catch as unknown (Vol 8.2), strictNullChecks makes absence explicit (chapter 1). But two useful theorems stay outside the umbrella: noUncheckedIndexedAccess and exactOptionalPropertyTypes. Knowing the list means knowing what you prove — and what you forgot to enable.

// "strict": true active d'un coup, entre autres :
{
  "strictNullChecks": true,          // null/undefined explicites      (ch. 1)
  "noImplicitAny": true,             // les any implicites = erreur     (Vol 4.1)
  "strictFunctionTypes": true,       // params de fonction contravariants (Vol 5.3)
  "useUnknownInCatchVariables": true // catch (e) : unknown             (Vol 8.2)
}
// mais PAS noUncheckedIndexedAccess ni exactOptionalPropertyTypes — à activer en plus
// (depuis TS 6.0, strict est activé par défaut ; l'écrire reste le plus clair)

// Hors du parapluie strict — à demander explicitement :
{
  "noUncheckedIndexedAccess": true,    // arr[i] : T | undefined          (ch. 2)
  "exactOptionalPropertyTypes": true   // { x?: number } refuse x: undefined
}

Copier un tsconfig et tout activer d'un coup — puis tout désactiver, vaincu.Copy a tsconfig and enable it all at once — then disable it all, defeated.

Le contre-exemple du volume : prendre une config trouvée en ligne, activer tous les drapeaux d'un coup sur un projet existant, voir des milliers d'erreurs, paniquer, et tout remettre à false. On en ressort avec moins de garanties qu'avant, et la conviction tenace que strict est inadapté. C'est l'inverse de la règle : on ne touche un drapeau qu'en comprenant son théorème, et l'on migre progressivement — le socle d'abord, puis un drapeau à la fois, chacun avec ses erreurs traitées avant de passer au suivant.The volume's counter-example: take a config found online, enable every flag at once on an existing project, see thousands of errors, panic, and set it all back to false. You come out with fewer guarantees than before, and the stubborn belief that strict is unsuited. It's the opposite of the rule: you touch a flag only by understanding its theorem, and you migrate progressively — the base first, then one flag at a time, each with its errors handled before moving on.

// Repris d'un gist, collé tel quel sur un projet legacy :
{
  "strict": true,
  "noUncheckedIndexedAccess": true,
  "exactOptionalPropertyTypes": true
}
// 4 800 erreurs au premier tsc. On panique, on remet "strict": false.
// Résultat : zéro garantie, et la conviction que strict "ne marche pas ici".

Tout activer sur du code non préparé, c'est se noyer sous des erreurs qu'on n'a pas le temps de traiter — et le réflexe de survie est de tout couper. On se retrouve sans aucune garantie, en croyant que c'est strict le problème. Le cargo cult ne punit pas l'ignorance : il la fige.Enabling everything on unprepared code is drowning under errors you have no time to handle — and the survival reflex is to cut it all. You end up with no guarantee at all, believing strict is the problem. Cargo cult doesn't punish ignorance: it freezes it.