L'analyse statique est un type de test qui permet une vérification automatisée de votre sans l'exécuter réellement ni avoir à écrire un test automatisé. Vous avez Ce type de test a sans doute déjà été fait si vous utilisez un IDE comme VSCode, effectuée par TypeScript est une sorte d'analyse statique qui peut montrer sous forme de lignes ondulées sous les erreurs ou les avertissements.
ESLint
ESLint est un outil qui peut fournir des commentaires sur les éventuels problèmes dans votre de votre codebase. Ces problèmes peuvent être du type safe,mais ils contiennent des erreurs ou des comportements non standards. à part entière. ESLint vous permet d'appliquer un certain nombre de règles vérifiées votre codebase, y compris dans sa version "recommandée" défini.
Un bon exemple de règle ESLint est son
no-unsafe-finally
d'une règle. Cela vous empêche d'écrire des déclarations qui modifient le
un flux de contrôle dans un bloc finally. C'est une excellente règle, car cela
est une manière inhabituelle d’écrire en JavaScript qui peut être difficile à suivre. Cependant, il est
et ce qu'un processus de revue de code
opérationnel doit être capable de détecter.
try {
const result = await complexFetchFromNetwork();
if (!result.ok) {
throw new Error("failed to fetch");
}
} finally {
// warning - this will 'overrule' the previous exception!
return false;
}
Par conséquent, ESLint ne remplace pas un processus d'examen sain (et un style qui définit votre codebase, car il ne va pas pour capturer toutes les approches peu orthodoxes qu'un développeur pourrait tenter d'introduire dans votre codebase. Le guide des pratiques de Google en matière d'ingénierie comporte une courte section visant à simplifier les choses.
ESLint vous permet d'enfreindre une règle et d'annoter le code comme "autorisé". Par exemple : peut autoriser la logique précédente en l'annotant comme suit:
finally {
// eslint-disable-next-line no-unsafe-finally
return false;
}
Si vous enfreignez constamment une règle, pensez à la désactiver. Ces vous encouragent à écrire du code d'une certaine manière, mais votre équipe peut être utilisée à écrire du code d'une autre manière, tout en étant conscient des risques approche.
Enfin, l'activation d'outils d'analyse statiques sur un codebase volumineux peut générer de nombreux de bruit inutile (et de tâches fastidieuses à refactoriser) sur du code qui fonctionnait autrement très bien. Il est donc plus facile de l'activer au début du cycle de vie d'un projet.
Plug-ins ESLint pour la compatibilité des navigateurs
Vous pouvez ajouter à ESLint un plug-in qui signale l'utilisation d'API dont la disponibilité compatibles ou non compatibles avec votre liste de navigateurs cibles. La eslint-plugin-compat peut vous avertir lorsqu'une API est susceptible de ne pas être disponible pour vos utilisateurs. n'avez pas à faire le suivi constamment pour vous-même.
Vérification du type pour l'analyse statique
Lorsqu'ils apprennent le JavaScript, les nouveaux développeurs découvrent généralement l'idée qu'il s'agit d'une langue faiblement typée. Autrement dit, il est possible de déclarer un comme un seul type, puis utiliser le même emplacement pour un élément complètement différent différentes. Ce langage est semblable à Python et aux autres langages de script, langages compilés tels que C/C++ et Rust.
Ce type de langage peut être un bon début, et c'est sans doute
la simplicité qui a rendu JavaScript si populaire, mais c'est souvent un point de défaillance.
pour certains codebases, ou du moins quelque chose qui permet à des erreurs déroutantes
se produisent. Par exemple, en transmettant un number où un string ou un type d'objet
était attendu, cette valeur mal saisie peut se propager à travers diverses
avant de provoquer une TypeError déroutante.
TypeScript
TypeScript est la solution la plus répandue face au manque de saisie dans JavaScript des informations. Ce cours l'utilise beaucoup. Bien qu'il ne s'agisse pas d'un cours sur TypeScript peut être un élément important de votre boîte à outils, car il fournit l'analyse statique.
À titre d'exemple, ce code, qui s'attend à recevoir un rappel acceptant une
Nom de string et âge de number:
const callback = (name: string, age: string): void => {
console.info(name, 'is now', age, 'years old!');
};
onBirthday(callback);
Génère l'erreur suivante lorsqu'elle est exécutée via TypeScript ou même lorsque l'utilisateur pointe dessus dans un IDE:
bad.ts:4:12 - error TS2345: Argument of type '(name: string, age: string) => void' is not assignable to parameter of type '(name: string, age: number) => void'.
Types of parameters 'age' and 'age' are incompatible.
Type 'number' is not assignable to type 'string'.
4 onBirthday(callback);
~~~~~~~~
Found 1 error in bad.ts:4
En fin de compte, l'objectif de l'utilisation de TypeScript est d'éviter les erreurs de ce type :
L'âge doit être un number, et non un string, et donc de se glisser dans votre projet. Ce
type d'erreur peut être difficile à détecter
en utilisant d'autres types de test.
De plus, le système de types peut fournir des commentaires avant même l'écriture d'un test.
Cela peut faciliter le processus d'écriture du code en vous donnant les premiers commentaires
sur les erreurs de type lorsque vous développez un logiciel, plutôt que lorsque le code
s'exécute finalement.
La partie la plus difficile de l'utilisation de TypeScript est sa configuration correcte. Toutes les
le projet a besoin d'un fichier tsconfig.json qui, bien qu'il soit principalement utilisé par tsc
est aussi lu par les IDE comme VSCode, avec de nombreux autres
des outils et des outils de compilation, y compris Vitest. Ce fichier contient des centaines
et des options. Vous trouverez des ressources utiles pour le configurer ici:
- Qu'est-ce qu'un fichier tsconfig.json ?
- Recommandations centralisées pour les bases TypeScript
- Vérifier votre code JS avec TS
Conseils généraux concernant TypeScript
Lorsque vous configurez et utilisez TypeScript via un fichier tsconfig.json, conservez la
à l'esprit ce qui suit:
- Assurez-vous que vos fichiers sources sont bien inclus et vérifiés. Si un fichier mystérieusement « ne contient aucune erreur », probablement parce qu’il n’est pas vérifié.
- Décrire explicitement les types et les interfaces dans des fichiers
.d.ts, plutôt que les décrire implicitement lorsque vous écrivez des fonctions, peut rendre vos du codebase à tester. Il est plus facile d'écrire des simulations et de « fausse » versions de code lorsque les interfaces impliquées sont claires. .
TypeScript implicite toute
L'une des options de configuration les plus puissantes et les plus gratifiantes de TypeScript est la
noImplicitAny. Cependant, c'est aussi souvent
le plus difficile à activer,
surtout si votre codebase est déjà volumineux. (L'indicateur noImplicitAny est
activée par défaut si vous êtes en mode strict, mais pas autrement.)
Cet indicateur obligera cette fonction à renvoyer une erreur:
export function fibonacci(n) {
if (n <= 1) {
return 0;
} else if (n === 2) {
return 1;
}
return fibonacci(n - 1) + fibonacci(n - 2);
}
Même si, pour un lecteur, il est assez clair que n doit être un nombre,
TypeScript ne peut pas confirmer cela avec certitude. Si vous utilisez VSCode, pointez sur
la fonction le décrira comme suit:
function fibonacci(n: any): any
Les appelants de cette fonction pourront transmettre une valeur de type any.
(un type qui accepte tout autre type), pas seulement number. En activant le paramètre
noImplicitAny, vous pouvez protéger ce type de code pendant le développement,
sans avoir à écrire des tests de logique métier approfondis pour transmettre votre code
les mauvais types de données
à des endroits spécifiques.
La solution simple ici consiste à marquer à la fois l'argument n et le type renvoyé de fibonacci comme number.
L'option noImplicitAny ne vous empêche pas d'écrire explicitement any dans
votre codebase. Vous pouvez toujours écrire une fonction qui accepte ou renvoie
le type any. Cela permet simplement de s'assurer que vous attribuez un type à chaque variable.