Aller au contenu

TypeScript : adoptez le mode strict

Découvrez le "strict mode" de TypeScript, une option essentielle qui vous permet d’écrire un code plus sûr, plus robuste et plus stable en production !

Pyramide Maya : design strict pour un monument robuste et stable dans les années !

Qu'est-ce que l'option strict dans TypeScript ?

Contrairement au mode par défaut (Sloppy mode), la propriété strict dans TypeScript est une option de configuration qui active un ensemble de sous-options pour des vérifications de type plus rigoureuses. Lorsqu'elle est activée, elle impose un code plus explicite, réduisant ainsi les risques d'erreurs et améliorant la qualité globale du projet, tout en facilitant sa maintenabilité

Les avantages de l'option strict

Ce mode apporte une multitude d'avantages, mais le plus important reste d'avoir un code plus stable en production.

  • Prévention des erreurs d'exécution : le strict mode élimine de nombreuses catégories d'erreurs courantes, comme les fautes de typage ou les valeurs indéfinies utilisées sans vérification préalable.
  • Meilleure inférence de type : l'inférence de type est particulièrement utile avec les fonctions génériques et les tableaux.
  • "Refactoring" plus sûr : comme un GPS fiable, le strict mode vous guide à travers les changements de code, vous alertant immédiatement si vous oubliez quelque chose lors de votre refactoring.
  • Amélioration de la lisibilité : dans un projet d'équipe, la lisibilité du code est cruciale. Le strict mode vous oblige à être explicite sur les types, rendant les intentions du code plus claires.
  • Détection précoce des erreurs : élimine de nombreuses catégories d'erreurs courantes, comme les fautes de typage ou les valeurs indéfinies utilisées sans vérification préalable.
  • Meilleure maintenabilité : le code devient plus lisible et plus fiable, ce qui est particulièrement utile dans les grandes bases de code ou dans les projets collaboratifs.

Des obstacles surmontables

  • Courbe d'apprentissage. On doit maintenant bien définir les types.
  • Cas où les règles strictes peuvent être perçues comme trop restrictives dans des projets spécifiques.
  • Pour certains, voir des null et des undefined dans les définitions de types peut être rédhibitoire (ndlr : un dev chez mon client a trouvé ça peu esthétique).

Une propriété pour les gouverner tous !

Activer strict: true dans votre fichier tsconfig.json active automatiquement 9 sous options différentes :

  1. noImplicitAny (TS v1.0 - documentation)
    Empêche l’utilisation implicite du type any. Si un type n’est pas explicitement déclaré ou inféré, TypeScript génère une erreur. Réduit les risques d'erreurs liées à des types mal définis ou non définis.
  2. strictNullChecks (TS v2.0 - documentation) :
    Empêche l’utilisation de null ou undefined sans vérification explicite. Cela réduit les erreurs d’exécution liées à des valeurs non initialisées ou absentes. Par exemple, la fameuse erreur Cannot read properties of undefined.
  3. noImplicitThis (TS v2.0 - documentation)
    Empêche l’utilisation de this avec un type implicite. Évite les erreurs liées à un contexte mal défini pour this.
  4. alwaysStrict (TS v2.1 - documentation)
    Active automatiquement le ECMAScript strict mode ("use strict") dans tous les fichiers. Garantit que les règles strictes de JavaScript s’appliquent, évitant les erreurs subtiles.
  5. strictFunctionTypes (TS v2.6 - documentation)
    Active une vérification stricte des types des fonctions dans le système de sous-typage. Évite les erreurs lors de l'assignation de fonctions incompatibles.
  6. strictPropertyInitialization (TS v2.7 - documentation)
    Exige que toutes les propriétés d’une classe soient initialisées dans le constructeur ou marquées comme optionnelles et permet de garantir qu'aucune propriété ne reste non définie.
  7. strictBindCallApply (TS v3.2 - documentation)
    Vérifie les types lors de l’utilisation des méthodes bind, call et apply. Cela évite les erreurs lors de l'assignation de fonctions incompatibles.
  8. useUnknownInCatchVariables (TS v4.4 - documentation)
    Dans les blocs catch, remplace le type par défaut any pour les variables capturées par unknown.
  9. strictBuiltinIteratorReturn (TS v5.6 - documentation)
    Cette option impose que les itérateurs intégrés respectent strictement leur type de retour défini dans l'interface Iterator<T>. Elle empêche qu'un itérateur retourne un type inattendu via la méthode return().

Mise en place du mode strict

Une migration en brute force

  1. Activer le strict mode (tsconfig.json)
{
    "compilerOptions": {
        "strict": true
    }
}
  1. Analyser les erreurs de compilation : Une fois le strict mode activé, TypeScript signalera toutes les erreurs liées aux règles strictes. S'il s'avère que la migration vers le strict mode est trop importante, je vous conseille de le faire progressivement.

Une migration progressive
Cela arrive souvent lorsqu'un un projet volumineux comporte une multitude d'erreurs.

  • Commencez par les options à fort impact comme noImplicitAny et strictNullChecks, car elles ciblent les erreurs les plus courantes.
  • Ajoutez progressivement les options plus spécifiques comme strictFunctionTypes et strictPropertyInitialization.
  • Quand toutes les options sont activées, vous pouvez les remplacer par strict: true
{
    "compilerOptions": {
      "alwaysStrict": false,
      "noImplicitAny": false,
      "noImplicitThis": false,
      "strictBindCallApply": false,
      "strictBuiltinIteratorReturn": false,
      "strictFunctionTypes": false,
      "strictNullChecks": false,
      "strictPropertyInitialization": false,
      "useUnknownInCatchVariables": false
    }
}

En résumé

Le strict mode transforme TypeScript d’un simple ajout de typage à JavaScript en un véritable outil de qualité et de sécurité, tout en réduisant les erreurs avant le déploiement en production et en améliorant la productivité.
Pour aller plus loin, vous pouvez utiliser des librairies comme Zod ou AJV pour vérifier les données au moment du runtime car ce mode strict de Typescript vérifie seulement au moment du codage/compilation du code et non lors de l’exécution en production.

Dernier