Réponse.

Historique de la question

TypeScript a été initialement conçu pour permettre une transition fluide de JavaScript, donc par défaut, les variables ou paramètres sans type explicitement spécifié obtenaient le type any. Cela facilitait la migration, mais réduisait les avantages de la typage statique. Afin d'améliorer la fiabilité et la prévisibilité du code, l'équipe de TypeScript a introduit le drapeau de compilation noImplicitAny, qui exige de spécifier explicitement les types ou de permettre à TypeScript de les inférer correctement.

Problème

Lorsque noImplicitAny est désactivé, les développeurs peuvent accidentellement omettre d'indiquer explicitement le type d'une variable, d'un paramètre ou de la valeur de retour d'une fonction. Cela rend le code moins sûr et complique le refactoring : toute erreur liée aux types ne sera pas détectée lors de la compilation, mais apparaîtra uniquement lors de l'exécution.

Solution

L'activation de noImplicitAny dans le fichier tsconfig.json oblige le compilateur TypeScript à générer une erreur à chaque utilisation implicite du type any. Cela exige des développeurs qu'ils prêtent attention aux types, rend les processus de refactoring moins risqués et rend le code lui-même plus fiable.

Exemple de code :

// tsconfig.json
{
  "compilerOptions": {
    "noImplicitAny": true
  }
}

// Exemple de fonction sans type de paramètre spécifié
function printUser(user) {
  console.log(user.name); // Erreur de compilation si le type n'est pas spécifié
}

// Correct :
function printUser(user: { name: string }) {
  console.log(user.name);
}

Caractéristiques clés :

Exige que les types soient spécifiés explicitement dans tous les endroits ambigus.
Permet d'identifier la plupart des erreurs de type au moment de la compilation.
Assure une haute prévisibilité et sécurité du code dans les grands projets.

Questions pièges.

Activer noImplicitAny empêche toujours toutes les erreurs potentielles de type dans le projet ?

Non, ce drapeau élimine seulement les any implicites. L'utilisation explicite de any est toujours autorisée. Pour une protection complète, il est conseillé de limiter également l'utilisation explicite de any via le linting et la revue de code.

Si le type est inféré automatiquement, noImplicitAny génère-t-il quand même une erreur ?

Non, si TypeScript a pu inférer correctement le type (par exemple, par l'initialisation), il n'y aura pas d'erreur. Par exemple :

let n = 123; // Type number, pas any

Activer strict active-t-il automatiquement noImplicitAny ?

Oui, le drapeau strict active de nombreuses vérifications strictes, y compris noImplicitAny. Mais il peut être désactivé manuellement si nécessaire.

Erreurs typiques et anti-patterns

Laisser des any explicites dans de nombreux endroits perd tout le sens de la typisation stricte.
Dans un code important, ne pas exécuter le projet avec noImplicitAny en comptant sur "peut-être" - de nombreuses erreurs cachées.
Ajouter des types "n'importe comment, tant que ça compile", sans réfléchir à leur justesse.

Exemple de la vie réelle

Cas négatif

Le noImplicitAny est désactivé dans le projet, la plupart des gestionnaires d'API acceptent des paramètres sans type explicite. Lors de la mise en œuvre de nouvelles logiques métier, les développeurs se trompent dans les noms de propriétés, mais les erreurs ne remontent qu'en production.

Avantages :

Démarrage du code simple et rapide.
Plus facile à migrer depuis JS.

Inconvénients :

En production, des erreurs apparaissent qui auraient pu être détectées statiquement.
Le refactoring et l'évolutivité deviennent plus difficiles.

Cas positif

Après avoir activé noImplicitAny, tout le code a été progressivement refactoré, les any implicites éliminés. On a commencé à utiliser un éditeur avec surlignement des types et autocomplétion. Les nouvelles erreurs sont immédiatement corrigées au moment de la build.