Pourquoi je préfère TypeScript strict sur mes side-projects

La tentation du loose

Au début d'un side-project, on a envie d'aller vite. strict: false, any partout quand TypeScript râle, on commitera proprement plus tard. Sauf que "plus tard" arrive rarement.

Ce que strict t'oblige à faire

Avec "strict": true dans tsconfig (qui active strictNullChecks, noImplicitAny, etc.) :

• Tu modélises tes données dès le début. Une variable nullable est explicite.
• Tu gères les cas d'erreur plutôt que de les ignorer. Un fetch peut échouer ? Le compilateur te le rappelle.
• Tu réfléchis aux contrats entre fonctions. Plus de "ça devrait marcher".

Le coût réel

Sur les premières heures d'un projet, c'est lent. Tu passes du temps à typer correctement. Mais à partir de la 2e ou 3e session de code, le retour sur investissement est immédiat :

• Refactor sans peur : le compilateur te montre tout ce qui casse
• Onboarding plus simple si quelqu'un d'autre rejoint (même 6 mois plus tard, toi-même)
• Moins de bugs au runtime sur les cas null/undefined

La règle que je m'impose

Si une fonction a besoin d'un any ou d'un as unknown as X, je m'arrête et je me demande si c'est un signe que mon modèle de données est mauvais. Dans 90 % des cas, oui.

Les exceptions raisonnables

• Code de parsing d'une API tierce mal documentée : unknown + validation runtime (Zod, Valibot) plutôt que des hacks de typage
• Glue code temporaire : OK pour un script one-shot, pas OK pour un module qui restera

Ma config tsconfig de base

{
  "compilerOptions": {
    "strict": true,
    "noUncheckedIndexedAccess": true,
    "noImplicitOverride": true,
    "noFallthroughCasesInSwitch": true,
    "exactOptionalPropertyTypes": true
  }
}

noUncheckedIndexedAccess est sous-utilisé : il rend l'accès à un index de tableau ou objet T | undefined. Ça force à gérer le cas où l'élément n'existe pas, ce qui correspond à la réalité.

Conclusion

Strict, c'est l'investissement initial qui te rend la vie facile pendant des années. Ne pas l'activer dès le départ, c'est se condamner à le faire plus tard, sur 10x plus de code, en mode crise.