TypeScript prétend être un langage de programmation fortement typé construit sur JavaScript, offrant de meilleurs outils à n'importe quelle échelle. Cependant,   inclut   type, qui peut souvent se faufiler implicitement dans une base de code et entraîner la perte de nombreux avantages de TypeScript. TypeScript any  Cet article explore les moyens de prendre le contrôle de   type dans les projets TypeScript. Préparez-vous à libérer la puissance de TypeScript, pour atteindre une sécurité de type ultime et améliorer la qualité du code. any  Inconvénients de l'utilisation de Any dans TypeScript  TypeScript fournit une gamme d'outils supplémentaires pour améliorer l'expérience et la productivité des développeurs :  Cela permet de détecter les erreurs dès le début de la phase de développement.  Il offre une excellente saisie semi-automatique pour les éditeurs de code et les IDE.  Il permet une refactorisation facile de grandes bases de code grâce à de fantastiques outils de navigation de code et à une refactorisation automatique.  Il simplifie la compréhension d'une base de code en fournissant une sémantique supplémentaire et des structures de données explicites via des types.  Cependant, dès que vous commencez à utiliser   type dans votre base de code, vous perdez tous les avantages énumérés ci-dessus. Le type   est une faille dangereuse dans le système de types, et son utilisation désactive toutes les capacités de vérification de type ainsi que tous les outils qui dépendent de la vérification de type. En conséquence, tous les avantages de TypeScript sont perdus : des bugs sont manqués, les éditeurs de code deviennent moins utiles, et bien plus encore. any any  Par exemple, considérons l'exemple suivant :   function parse(data: any) { return data.split(''); } // Case 1 const res1 = parse(42); // ^ TypeError: data.split is not a function // Case 2 const res2 = parse('hello'); // ^ any  Dans le code ci-dessus :  Vous manquerez la saisie semi-automatique dans la fonction   . Lorsque vous tapez   dans votre éditeur, vous ne recevrez pas de suggestions correctes sur les méthodes disponibles pour   . parse data. data  Dans le premier cas, il y a une   car nous avons passé un nombre au lieu d'une chaîne. TypeScript n'est pas en mesure de mettre en évidence l'erreur car   désactive la vérification du type. TypeError: data.split is not a function any  Dans le second cas, la variable   a également le type   . Cela signifie qu'une seule utilisation de   peut avoir un effet en cascade sur une grande partie d'une base de code. res2 any any  Utiliser   n'est acceptable que dans des cas extrêmes ou pour des besoins de prototypage. En général, il est préférable d’éviter d’   utiliser pour tirer le meilleur parti de TypeScript. any any  D’où vient n’importe quel type  Il est important d'être conscient des sources de type   dans une base de code, car l'écriture explicite   n'est pas la seule option. Malgré tous nos efforts pour éviter d'utiliser   type, il peut parfois se faufiler implicitement dans une base de code. any any any  Il existe quatre sources principales de   type dans une base de code : any  Options du compilateur dans tsconfig.  La bibliothèque standard de TypeScript.  Dépendances du projet.  Utilisation explicite de   dans une base de code. any  J'ai déjà écrit des articles sur   et   pour les deux premiers points. Veuillez les consulter si vous souhaitez améliorer la sécurité des caractères dans vos projets. les considérations clés dans tsconfig l'amélioration des types de bibliothèques standard  Cette fois, nous nous concentrerons sur les outils automatiques permettant de contrôler l’apparence de   type dans une base de code. any  Étape 1 : Utiliser ESLint    est un outil d'analyse statique populaire utilisé par les développeurs Web pour garantir les meilleures pratiques et le formatage du code. Il peut être utilisé pour appliquer des styles de codage et rechercher du code qui ne respecte pas certaines directives. ESLint  ESLint peut également être utilisé avec des projets TypeScript, grâce au plugin   . Très probablement, ce plugin a déjà été installé dans votre projet. Mais sinon, vous pouvez suivre le   officiel. typesctipt-eslint guide de démarrage  La configuration la plus courante pour   est la suivante : typescript-eslint   module.exports = { extends: [ 'eslint:recommended', 'plugin:@typescript-eslint/recommended', ], plugins: ['@typescript-eslint'], parser: '@typescript-eslint/parser', root: true, };  Cette configuration permet à   de comprendre TypeScript au niveau de la syntaxe, vous permettant d'écrire des règles eslint simples qui s'appliquent aux types écrits manuellement dans un code. Par exemple, vous pouvez interdire l’utilisation explicite de   . eslint any  Le préréglage   contient un ensemble soigneusement sélectionné de règles ESLint visant à améliorer l'exactitude du code. Bien qu'il soit recommandé d'utiliser l'intégralité du préréglage, pour les besoins de cet article, nous nous concentrerons uniquement sur la règle   . recommended no-explicit-any  non-explicite-aucun  Le mode strict de TypeScript empêche l'utilisation de   implicite, mais il n'empêche   son utilisation explicite. La règle   permet d'interdire l'écriture manuelle   où dans une base de code. any any no-explicit-any any   // ❌ Incorrect function loadPokemons(): any {} // ✅ Correct function loadPokemons(): unknown {} // ❌ Incorrect function parsePokemons(data: Response<any>): Array<Pokemon> {} // ✅ Correct function parsePokemons(data: Response<unknown>): Array<Pokemon> {} // ❌ Incorrect function reverse<T extends Array<any>>(array: T): T {} // ✅ Correct function reverse<T extends Array<unknown>>(array: T): T {}  Le but principal de cette règle est d’empêcher   utilisation au sein de l’équipe. C'est un moyen de renforcer l'accord de l'équipe sur le fait que l'utilisation de   dans le projet est découragée. any any  Il s'agit d'un objectif crucial car même une seule utilisation de   peut avoir un impact en cascade sur une partie importante de la base de code en raison de   . Cependant, cela est encore loin d’atteindre la sécurité de type ultime. any l'inférence de type  Pourquoi rien d'explicite ne suffit pas  Bien que nous ayons traité   explicitement utilisés, il existe encore de nombreux   implicites dans les dépendances d'un projet, y compris les packages npm et la bibliothèque standard de TypeScript. any any  Considérez le code suivant, que l'on retrouve probablement dans n'importe quel projet :   const response = await fetch('https://pokeapi.co/api/v2/pokemon'); const pokemons = await response.json(); // ^? any const settings = JSON.parse(localStorage.getItem('user-settings')); // ^? any    et   variables ont été implicitement attribués à   type. Ni   ni le mode strict de TypeScript ne nous avertiront dans ce cas. Pas encore. pokemons settings any no-explicit-any  Cela se produit parce que les types de   et   proviennent de la bibliothèque standard de TypeScript, où ces méthodes ont une   explicite. Nous pouvons toujours spécifier manuellement un meilleur type pour nos variables, mais il existe près de 1 200 occurrences de   dans la bibliothèque standard. Il est presque impossible de se souvenir de tous les cas où   peut se faufiler dans notre base de code à partir de la bibliothèque standard. response.json() JSON.parse() any any any  Il en va de même pour les dépendances externes. Il existe de nombreuses bibliothèques mal typées dans npm, la plupart étant encore écrites en JavaScript. En conséquence, l’utilisation de telles bibliothèques peut facilement conduire à de nombreux   implicites dans une base de code. any  En général, il existe encore de nombreuses façons de   faufiler dans notre code. any  Étape 2 : amélioration des capacités de vérification de type  Idéalement, nous aimerions avoir un paramètre dans TypeScript qui oblige le compilateur à se plaindre de toute variable ayant reçu   type pour une raison quelconque. Malheureusement, un tel paramètre n’existe pas actuellement et ne devrait pas être ajouté. any  Nous pouvons obtenir ce comportement en utilisant le mode de vérification de type du plugin   . Ce mode fonctionne conjointement avec TypeScript pour fournir des informations de type complètes du compilateur TypeScript aux règles ESLint. Avec ces informations, il est possible d'écrire des règles ESLint plus complexes qui étendent essentiellement les capacités de vérification de type de TypeScript. Par exemple, une règle peut rechercher toutes les variables de type   , quelle que soit la manière dont   a été obtenue. typescript-eslint any any  Pour utiliser des règles sensibles au type, vous devez ajuster légèrement la configuration ESLint :   module.exports = { extends: [ 'eslint:recommended', - 'plugin:@typescript-eslint/recommended', + 'plugin:@typescript-eslint/recommended-type-checked', ], plugins: ['@typescript-eslint'], parser: '@typescript-eslint/parser', + parserOptions: { + project: true, + tsconfigRootDir: __dirname, + }, root: true, };  Pour activer l'inférence de type pour   , ajoutez   à la configuration ESLint. Ensuite, remplacez le préréglage   par   . Ce dernier préréglage ajoute environ 17 nouvelles règles puissantes. Pour les besoins de cet article, nous nous concentrerons sur seulement 5 d’entre eux. typescript-eslint parserOptions recommended recommended-type-checked  aucun argument dangereux  La règle   recherche les appels de fonction dans lesquels une variable de type   est passée en paramètre. Lorsque cela se produit, la vérification du type est perdue, ainsi que tous les avantages d’un typage fort. no-unsafe-argument any  Par exemple, considérons une fonction   qui nécessite un objet comme paramètre. Supposons que nous recevions JSON, l'analysions et obtenions   type. saveForm any   // ❌ Incorrect function saveForm(values: FormValues) { console.log(values); } const formValues = JSON.parse(userInput); // ^? any saveForm(formValues); // ^ Unsafe argument of type `any` assigned // to a parameter of type `FormValues`.  Lorsque nous appelons la fonction   avec ce paramètre, la règle   la signale comme dangereuse et nous oblige à spécifier le type approprié pour la variable   . saveForm no-unsafe-argument value  Cette règle est suffisamment puissante pour inspecter en profondeur les structures de données imbriquées dans les arguments de fonction. Par conséquent, vous pouvez être sûr que le passage d'objets en tant qu'arguments de fonction ne contiendra jamais de données non typées.   // ❌ Incorrect saveForm({ name: 'John', address: JSON.parse(addressJson), // ^ Unsafe assignment of an `any` value. });  La meilleure façon de corriger l'erreur est d'utiliser   de TypeScript ou une bibliothèque de validation telle que   ou   . Par exemple, écrivons la fonction   qui restreint le type précis de données analysées. le rétrécissement de type Zod Superstruct parseFormValues   // ✅ Correct function parseFormValues(data: unknown): FormValues { if ( typeof data === 'object' && data !== null && 'name' in data && typeof data['name'] === 'string' && 'address' in data && typeof data.address === 'string' ) { const { name, address } = data; return { name, address }; } throw new Error('Failed to parse form values'); } const formValues = parseFormValues(JSON.parse(userInput)); // ^? FormValues saveForm(formValues);  Notez qu'il est autorisé de transmettre le type   comme argument à une fonction qui accepte   , car cela ne pose aucun problème de sécurité. any unknown  L'écriture de fonctions de validation de données peut être une tâche fastidieuse, en particulier lorsqu'il s'agit de grandes quantités de données. Par conséquent, il vaut la peine d’envisager l’utilisation d’une bibliothèque de validation de données. Par exemple, avec Zod, le code ressemblerait à ceci :   // ✅ Correct import { z } from 'zod'; const schema = z.object({ name: z.string(), address: z.string(), }); const formValues = schema.parse(JSON.parse(userInput)); // ^? { name: string, address: string } saveForm(formValues);  mission non dangereuse  La règle   recherche les affectations de variables dans lesquelles une valeur est de type   . De telles affectations peuvent induire le compilateur en erreur en lui faisant croire qu'une variable a un certain type, alors que les données peuvent en réalité avoir un type différent. no-unsafe-assignment any  Prenons l'exemple précédent d'analyse JSON :   // ❌ Incorrect const formValues = JSON.parse(userInput); // ^ Unsafe assignment of an `any` value  Grâce à la règle   , nous pouvons détecter   type avant même de transmettre   ailleurs. La stratégie de correction reste la même : nous pouvons utiliser le rétrécissement du type pour fournir un type spécifique à la valeur de la variable. no-unsafe-assignment any formValues   // ✅ Correct const formValues = parseFormValues(JSON.parse(userInput)); // ^? FormValues  accès membre sans danger et appel sans danger  Ces deux règles se déclenchent beaucoup moins fréquemment. Cependant, d'après mon expérience, ils sont très utiles lorsque vous essayez d'utiliser des dépendances tierces mal typées.  La règle   nous empêche d'accéder aux propriétés d'un objet si une variable a le type   , car elle peut être   ou   . no-unsafe-member-access any null undefined  La règle   nous empêche d'appeler une variable de type   en tant que fonction, car ce n'est peut-être pas une fonction. no-unsafe-call any  Imaginons que nous ayons une bibliothèque tierce mal typée appelée   : untyped-auth   // ❌ Incorrect import { authenticate } from 'untyped-auth'; // ^? any const userInfo = authenticate(); // ^? any ^ Unsafe call of an `any` typed value. console.log(userInfo.name); // ^ Unsafe member access .name on an `any` value.  Le linter met en évidence deux problèmes :  Appeler la fonction   peut être dangereux, car nous pouvons oublier de transmettre des arguments importants à la fonction. authenticate  La lecture de la propriété   à partir de l'objet   n'est pas sûre, car elle sera   si l'authentification échoue. name userInfo null  La meilleure façon de corriger ces erreurs est d’envisager d’utiliser une bibliothèque avec une API fortement typée. Mais si ce n’est pas une option, vous pouvez  . Un exemple avec les types de bibliothèques fixes ressemblerait à ceci : augmenter vous-même les types de bibliothèques   // ✅ Correct import { authenticate } from 'untyped-auth'; // ^? (login: string, password: string) => Promise<UserInfo | null> const userInfo = await authenticate('test', 'pwd'); // ^? UserInfo | null if (userInfo) { console.log(userInfo.name); }  pas de retour dangereux  La règle   permet de ne pas renvoyer accidentellement   type à partir d'une fonction qui devrait renvoyer quelque chose de plus spécifique. De tels cas peuvent induire le compilateur en erreur en lui faisant croire qu'une valeur renvoyée a un certain type, alors que les données peuvent en réalité avoir un type différent. no-unsafe-return any  Par exemple, supposons que nous ayons une fonction qui analyse JSON et renvoie un objet avec deux propriétés.   // ❌ Incorrect interface FormValues { name: string; address: string; } function parseForm(json: string): FormValues { return JSON.parse(json); // ^ Unsafe return of an `any` typed value. } const form = parseForm('null'); console.log(form.name); // ^ TypeError: Cannot read properties of null  La fonction   peut entraîner des erreurs d'exécution dans n'importe quelle partie du programme où elle est utilisée, car la valeur analysée n'est pas vérifiée. La règle de   évite de tels problèmes d’exécution. parseForm no-unsafe-return  Il est facile de résoudre ce problème en ajoutant une validation pour garantir que le JSON analysé correspond au type attendu. Utilisons la bibliothèque Zod cette fois :   // ✅ Correct import { z } from 'zod'; const schema = z.object({ name: z.string(), address: z.string(), }); function parseForm(json: string): FormValues { return schema.parse(JSON.parse(json)); }  Une note sur les performances  L'utilisation de règles de vérification de type entraîne une pénalité de performances pour ESLint, car il doit appeler le compilateur TypeScript pour déduire tous les types. Ce ralentissement est principalement perceptible lors de l'exécution du linter dans des hooks de pré-commit et dans CI, mais il n'est pas perceptible lorsque vous travaillez dans un IDE. La vérification du type est effectuée une fois au démarrage de l'IDE, puis met à jour les types à mesure que vous modifiez le code.  Il convient de noter que le simple fait de déduire les types fonctionne plus rapidement que l'invocation habituelle du compilateur   . Par exemple, sur notre projet le plus récent avec environ 1,5 million de lignes de code TypeScript, la vérification du type via   prend environ 11 minutes, tandis que le temps supplémentaire requis pour le démarrage des règles de type ESLint n'est que d'environ 2 minutes. tsc tsc  Pour notre équipe, la sécurité supplémentaire apportée par l’utilisation de règles d’analyse statique sensibles au type en vaut la peine. Sur les petits projets, cette décision est encore plus facile à prendre.  Conclusion  Contrôler l'utilisation de   les projets TypeScript est crucial pour obtenir une sécurité de type et une qualité de code optimales. En utilisant le plugin   , les développeurs peuvent identifier et éliminer toutes les occurrences de   type dans leur base de code, ce qui donne lieu à une base de code plus robuste et plus maintenable. any typescript-eslint any  En utilisant des règles eslint sensibles au type, toute apparition du mot-clé   dans notre base de code sera une décision délibérée plutôt qu'une erreur ou un oubli. Cette approche nous évite d'   utiliser dans notre propre code, ainsi que dans la bibliothèque standard et les dépendances tierces. any any  Dans l'ensemble, un linter sensible au type nous permet d'atteindre un niveau de sécurité de type similaire à celui des langages de programmation typés statiquement tels que Java, Go, Rust et autres. Cela simplifie grandement le développement et la maintenance de grands projets.  J'espère que vous avez appris quelque chose de nouveau grâce à cet article. Merci pour la lecture!  Liens utiles   Bibliothèque : typescript-eslint   Article : Considérations clés dans tsconfig   Article : Amélioration des types de bibliothèques standard   Docs : rétrécissement du type dans TypeScript   Docs : inférence de type dans TypeScript   Bibliothèque : Zod   Bibliothèque : Superstructure

The code in this story is for educational purposes. The readers are solely responsible for whatever they build with it.

Walkthroughs, tutorials, guides, and tips. This story will teach you how to do something new or how to do something better.

Rendre TypeScript vraiment "fortement typé"

About Author

COMMENTAIRES

ÉTIQUETTES

CET ARTICLE A ÉTÉ PARU DANS

Related Stories

Télégramme : le pont de Crypto Island vers le continent

Des forums aux flux : comment les algorithmes des réseaux sociaux façonnent l'interaction numérique

HackerNoon Decoded: The Top 10 Countries Where HackerNoon Is the Most Active

Vous voulez gagner un concours d’écriture HackerNoon ? Voici ce que recommandent les gagnants du concours #crypto-api

Télégramme : le pont de Crypto Island vers le continent

Des forums aux flux : comment les algorithmes des réseaux sociaux façonnent l'interaction numérique

HackerNoon Decoded: The Top 10 Countries Where HackerNoon Is the Most Active

Vous voulez gagner un concours d’écriture HackerNoon ? Voici ce que recommandent les gagnants du concours #crypto-api

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps