Le système de types de TypeScript détecte un grand nombre d'erreurs avant l'exécution du code : incompatibilités de types, propriétés manquantes, signatures de fonctions incorrectes. En revanche, il ne détecte pas tout le reste : les failles de sécurité liées au flux de données dans l'application, les violations d'architecture qui s'accumulent avec le temps à mesure que les frontières entre les équipes s'estompent, les exportations obsolètes qui persistent dans le code longtemps après la suppression de leurs appelants, et les erreurs de programmation asynchrone qui compilent correctement mais échouent dans certaines conditions d'exécution. Les outils d'analyse statique comblent ces lacunes, et le choix de la combinaison appropriée dépend de ce que vous cherchez à détecter.
Ce guide présente les outils essentiels pour les équipes TypeScript en 2026 : la couche de linting (ESLint avec typescript-eslint, Biome, OxcLint), la couche de sécurité (Semgrep, Snyk Code, SonarQube), la couche d’architecture (Dependency-Cruiser, Deptrac, Nx), la couche de détection de code mort (Knip) et la couche d’analyse approfondie (ts-morph, le compilateur TypeScript lui-même). Pour chacun, l’accent est mis sur son fonctionnement, sa configuration et les situations où il n’est pas adapté.
Conçu pour des bases de code que personne ne comprend
SMART TS XL Détecte automatiquement les changements importants dans l'ensemble de votre code source.
Apprendre encore plusOutils d'analyse statique TypeScript : Tableau comparatif
Avant d'examiner chaque outil individuellement, le tableau ci-dessous associe chaque outil à sa fonction principale, à son adéquation à l'intégration continue et à son cas d'utilisation idéal. Aucun outil ne couvre à lui seul toutes les dimensions ; une analyse de qualité efficace de TypeScript nécessite donc d'en combiner plusieurs.
| Outil | Fonction primaire | CI adapté | Prix | Idéal pour |
|---|---|---|---|---|
| ESLint + typescript-eslint | Règles de linting, de style et de prise en compte des types | Oui | Gratuit | Conventions à l'échelle de l'équipe, sécurité des types asynchrones |
| biome | Linting + formatage | Oui | Gratuit | Remplacement ESLint + Prettier, vitesse |
| OxcLint | Analyse statique (compatible ESLint) | Oui | Gratuit | Les monorepos nécessitent des temps de lint rapides |
| Compilateur TypeScript (tsc) | Vérification de type | Oui | Gratuit | Erreurs de frappe, application stricte du mode |
| SemgrepName | SAST, modèles personnalisés | Oui | Gratuit + payant | Analyse de sécurité, règles d'organisation personnalisées |
| Code Snyk | SAST, sécurité des dépendances | Oui | Gratuit + payant | Équipes axées sur la sécurité, intégration IDE |
| SonarQube / SonarCloud | Contrôles de qualité, suivi des tendances | Oui | Gratuit + payant | Tableaux de bord de qualité d'entreprise |
| SonarLint | Commentaires sur la qualité au niveau de l'IDE | IDE uniquement | Gratuit | Conseils de sécurité et de qualité en ligne |
| Croiseur de dépendance | Application des graphes de dépendance | Oui | Gratuit | Validation des règles architecturales |
| Deptrac | Application des limites de couche | Oui | Gratuit | Architecture propre, limites DDD |
| Nx | Gestion des dépendances Monorepo | Oui | Gratuit + payant | limites du module Monorepo |
| Couper | Code mort et exportations inutilisées | Oui | Gratuit | Réduire le code inutilisé à grande échelle |
| ts-morph | Analyse AST TS programmatique | Sélectif | Gratuit | Analyse personnalisée, modifications de code, outils |
Couche 1 : Peluches et style
ESLint avec typescript-eslint
ESLint demeure la base du linting TypeScript. typescript-eslint Ce package permet d'accéder aux informations de type de TypeScript et d'appliquer des règles nécessitant un contexte de type, dont les plus précieuses sont les règles spécifiques à l'asynchrone qui permettent de détecter les erreurs courantes liées aux promesses.
bash
npm install --save-dev typescript-eslintjavascript
// eslint.config.js
import tseslint from "typescript-eslint";
export default tseslint.config(
...tseslint.configs.strictTypeChecked,
{
languageOptions: {
parserOptions: {
project: true,
tsconfigRootDir: import.meta.dirname,
},
},
rules: {
// Async safety rules -- highest value TypeScript-specific rules
"@typescript-eslint/no-floating-promises": "error",
"@typescript-eslint/await-thenable": "error",
"@typescript-eslint/no-misused-promises": "error",
"@typescript-eslint/require-await": "warn",
// Type safety
"@typescript-eslint/no-explicit-any": "warn",
"@typescript-eslint/no-unsafe-assignment": "error",
"@typescript-eslint/no-unsafe-return": "error",
},
}
);Les quatre règles asynchrones ci-dessus constituent la plus grande valeur ajoutée de typescript-eslint par rapport à ESLint standard. Elles détectent : les promesses non gérées (promesses flottantes), await appliqué aux valeurs non-Promise, aux Promises transmises aux rappels attendant des fonctions synchrones et aux fonctions asynchrones qui ne sont jamais utilisées awaitCe sont des modèles qui se compilent sans problème mais qui produisent des erreurs d'exécution dans des conditions spécifiques.
Ce qu'ESLint ne peut pas faire : l'analyse des flux de données entre fichiers, le respect des limites architecturales, le suivi des failles de sécurité ni la détection des exportations mortes. Pour ces fonctions, les couches inférieures sont nécessaires.
Biome : Le remplaçant moderne d'ESLint + Pretty
Biome remplace ESLint et Prettier par un seul binaire Rust, 25 à 35 fois plus rapide. Il prend en charge JavaScript, TypeScript, JSX et JSON. Pour les nouveaux projets ou les équipes frustrées par la complexité des plugins d'ESLint et ses performances médiocres sur les grands projets, Biome est la meilleure alternative moderne.
bash
npm install --save-dev --save-exact @biomejs/biome
npx @biomejs/biome initbash
# Check and format in one pass
npx @biomejs/biome check --write src/
# CI mode -- no modifications, exit non-zero on any finding
npx @biomejs/biome ci src/L'écosystème de plugins de Biome est plus restreint que celui d'ESLint, ce qui a son importance pour les équipes utilisant de nombreuses règles personnalisées ou des plugins spécifiques à un framework. Pour les équipes utilisant uniquement les règles de base d'ESLint et le formatage Prettier, Biome offre une couverture équivalente avec un temps d'exécution considérablement réduit.
OxcLint : Compatibilité ESLint axée sur la vitesse
OxcLint (qui fait partie du projet Oxc) exécute les règles compatibles ESLint 50 à 100 fois plus rapidement. Il ne remplace pas l'écosystème ESLint complet, mais constitue l'option la plus rapide pour les pipelines d'intégration continue où le temps d'exécution est un facteur limitant.
bash
npm install --save-dev oxlint
npx oxlint src/OxcLint est la solution idéale pour les grands monorepos où ESLint standard prend plusieurs minutes et où la latence du cycle de retour d'information nuit à la qualité des demandes de fusion. Il est préférable de l'utiliser en complément d'ESLint plutôt qu'en remplacement : OxcLint permet un retour d'information rapide, tandis qu'ESLint assure une couverture complète des règles avant la fusion.
Couche 2 : Vérification des types, le compilateur TypeScript
Le compilateur TypeScript (tscIl ne s'agit pas seulement d'un outil de construction, mais du principal moteur d'analyse statique pour la correction au niveau des types. L'activation du mode strict active les paramètres qui détectent la plupart des bogues en conditions réelles :
json
{
"compilerOptions": {
"strict": true,
"noUnusedLocals": true,
"noUnusedParameters": true,
"noImplicitReturns": true,
"noFallthroughCasesInSwitch": true,
"exactOptionalPropertyTypes": true,
"useUnknownInCatchVariables": true
}
}bash
# Type-check only, no emit -- ideal for CI
npx tsc --noEmitnoUnusedLocals et noUnusedParameters Au niveau du compilateur, interceptez les variables et paramètres de fonction inutilisés. useUnknownInCatchVariables (TypeScript 4.4+) types interceptant les exceptions comme unknown plutôt que des any, imposant une restriction explicite du type avant utilisation.
Analyse du flux de contrôle TypeScript est une fonctionnalité intégrée du compilateur permettant de restreindre les types dans les branches conditionnelles. Il ne s'agit pas d'un outil distinct. strict Ce mode garantit son application avec une rigueur absolue. L'analyse du flux de contrôle du compilateur prend en compte les gardes de type. typeof vérifications, instanceofet des modèles syndicaux discriminatoires.
La limitation de tsc : le compilateur TypeScript ne détecte pas les failles de sécurité, les violations des limites architecturales ni les exportations mortes. Il détecte les erreurs de type, et ce de manière définitive.
Couche 3 : Sécurité, SAST pour TypeScript
Semgrep : Analyse de sécurité basée sur des modèles
Semgrep détecte les failles de sécurité grâce à la correspondance de modèles de code. Pour TypeScript, il peut détecter les injections SQL, les attaques XSS, les identifiants codés en dur et les éléments non sécurisés. eval L’utilisation, la pollution des prototypes et les configurations Express.js non sécurisées sont des modèles qui compilent correctement mais introduisent des vulnérabilités exploitables.
yaml
# Custom rule: flag user input in SQL queries (TypeScript)
rules:
- id: ts-sql-injection-risk
patterns:
- pattern: |
const query = `SELECT ... ${$USER_INPUT} ...`;
message: "User input directly interpolated into SQL -- use parameterized queries"
languages: [typescript]
severity: ERRORbash
# Run with the community TypeScript security rules
semgrep scan --config=p/typescript --config=p/owasp-top-ten src/Semgrep est complémentaire à ESLint, et non concurrent. ESLint veille au respect des conventions ; Semgrep détecte les failles de sécurité. La plupart des équipes TypeScript soucieuses de la sécurité devraient utiliser les deux.
Code Snyk : SAST basé sur l’apprentissage automatique avec intégration IDE
Snyk Code effectue une analyse SAST grâce à un moteur d'analyse basé sur l'apprentissage automatique qui suit les flux de contamination dans les fichiers. Il s'intègre aux environnements de développement intégrés VS Code et JetBrains, et affiche les résultats directement dans le code pendant que les développeurs écrivent, sans attendre une exécution d'intégration continue.
bash
npm install --save-dev snyk
npx snyk auth
npx snyk code testL'accent mis par Snyk Code sur l'expérience développeur, les retours intégrés à l'IDE, les suggestions de correction accompagnant chaque détection et les exemples de remédiation en font le meilleur choix lorsque la formation à la sécurité est aussi importante que la détection des failles de sécurité.
SonarQube et SonarLint : Contrôles qualité et suivi des tendances
SonarQube propose une analyse continue de la qualité du code grâce à un tableau de bord, un suivi des tendances et l'annotation des demandes de fusion. Pour TypeScript, il détecte les bogues, les anomalies de conception, les failles de sécurité et les duplications de code. SonarLint est l'extension IDE qui permet d'afficher localement les règles SonarQube.
Pour les équipes TypeScript, SonarCloud (la version hébergée dans le cloud) est la solution la plus simple : gratuit pour les dépôts publics, avec une intégration CI via GitHub Actions ou GitLab CI en quelques minutes.
yaml
# .github/workflows/sonar.yml
- name: SonarCloud Scan
uses: SonarSource/sonarcloud-github-action@master
env:
GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
SONAR_TOKEN: ${{ secrets.SONAR_TOKEN }}La principale valeur ajoutée de SonarQube par rapport à l'analyse statique de code brute réside dans son modèle de tendances : comment la qualité du code évolue-t-elle au fil du temps ? Quels composants se dégradent ? Quel est le score de qualité du nouveau code pour chaque requête d'extraction ? Ces indicateurs destinés à la direction constituent un atout majeur de SonarQube, contrairement à ESLint et Semgrep.
Couche 4 : Analyse architecturale
Dependency-Cruiser : Appliquer les règles de délimitation des modules
Dependency-Cruiser vérifie que votre graphe d'importations respecte les règles architecturales définies. Il génère des graphes de dépendances visuels et signale une erreur d'intégration continue lorsque le code enfreint les contraintes de limites des modules.
javascript
// .dependency-cruiser.cjs
module.exports = {
forbidden: [
{
name: "no-circular",
severity: "error",
comment: "Circular dependencies make code hard to test and maintain",
from: {},
to: { circular: true },
},
{
name: "no-ui-in-domain",
severity: "error",
comment: "Domain modules must not import from UI layer",
from: { path: "^src/domain" },
to: { path: "^src/ui" },
},
{
name: "no-external-in-shared",
severity: "warn",
comment: "Shared utilities should minimize external dependencies",
from: { path: "^src/shared" },
to: { pathNot: "^(src|node_modules/(lodash|date-fns))" },
},
],
};bash
npx depcruise --validate .dependency-cruiser.cjs src/Dependency-Cruiser répond directement aux requêtes « outil cli d'analyse des dépendances React » dans les données de la Search Console ; c'est l'outil standard pour générer et valider les graphes de dépendances dans les projets TypeScript/React.
Deptrac : Application des limites basée sur les couches
Deptrac impose des couches architecturales, garantissant que le code de persistance ne peut pas importer le code de présentation, que les objets de domaine ne dépendent pas de l'infrastructure et que les limites des modules sont respectées dans l'ensemble du code source.
yaml
# deptrac.yaml
parameters:
layers:
- name: Domain
collectors:
- type: directory
value: src/domain
- name: Application
collectors:
- type: directory
value: src/application
- name: Infrastructure
collectors:
- type: directory
value: src/infrastructure
ruleset:
Domain:
- ~Infrastructure # Domain must not depend on Infrastructure
Application:
- Domain
Infrastructure:
- Application
- DomainDeptrac est particulièrement utile dans les projets suivant les modèles d'architecture propre, DDD ou hexagonale, où l'isolation des couches est une contrainte de conception et non une simple préférence.
Nx : Gestion des dépendances au niveau du monorepo
Pour les monorepos TypeScript, Nx assure le contrôle des limites des modules, la détection des builds affectés et la visualisation du graphe de dépendances pour tous les projets du dépôt.
json
// .eslintrc.json -- Nx module boundary rules
{
"rules": {
"@nx/enforce-module-boundaries": [
"error",
{
"allow": [],
"depConstraints": [
{ "sourceTag": "scope:shared", "onlyDependOnLibsWithTags": ["scope:shared"] },
{ "sourceTag": "scope:feature", "onlyDependOnLibsWithTags": ["scope:shared", "scope:feature"] },
{ "sourceTag": "scope:app", "onlyDependOnLibsWithTags": ["scope:shared", "scope:feature"] }
]
}
]
}
}Nx affected Les commandes n'exécutent que les tests et l'analyse statique pertinents pour les modules modifiés, ce qui réduit considérablement le temps d'intégration continue dans les grands monorepos.
Couche 5 : Détection de code mort
Knip : Trouver les exportations, les fichiers et les dépendances inutilisés
Knip analyse le graphe complet des modules pour identifier les exportations inutilisées, les fichiers inutilisés et les éléments inutilisés. package.json les dépendances, la classe d'accumulation de code qu'ESLint no-unused-vars Impossible de détecter car la recherche se limite au contenu d'un fichier.
bash
npm install --save-dev knip
npx knipjson
// knip.json
{
"entry": ["src/index.ts", "src/**/*.test.ts"],
"project": ["src/**/*.ts"],
"ignore": ["src/generated/**"],
"ignoreDependencies": ["vitest"]
}Knip est directement recherché dans les données SC sous le nom de « détection de code mort, exportations inutilisées, JavaScript, TypeScript ». C'est actuellement l'outil le plus performant pour l'identification du code mort au niveau des modules dans les projets TypeScript.
Couche 6 : Analyse programmatique, ts-morph
ts-morph est une surcouche de l'API du compilateur TypeScript qui simplifie l'écriture d'analyses personnalisées, de modifications de code et d'outils pour l'AST de TypeScript. Elle est directement référencée dans les données SC sous les noms « ts-morph » et « ts morph ».
manuscrit
import { Project } from "ts-morph";
const project = new Project({ tsConfigFilePath: "tsconfig.json" });
// Find all async functions that never await anything
const suspiciousAsyncFns: string[] = [];
for (const sourceFile of project.getSourceFiles()) {
for (const fn of sourceFile.getFunctions()) {
if (fn.isAsync()) {
const hasAwait = fn.getDescendantsOfKind(
SyntaxKind.AwaitExpression
).length > 0;
if (!hasAwait) {
suspiciousAsyncFns.push(
`${sourceFile.getFilePath()}:${fn.getName() ?? "anonymous"}`
);
}
}
}
}
console.log("Async functions with no await:", suspiciousAsyncFns);ts-morph n'est pas un outil d'analyse prêt à l'emploi, mais une bibliothèque permettant d'en construire un. Il convient aux équipes ayant besoin d'analyses personnalisées allant au-delà des fonctionnalités des outils existants : scripts de migration, validateurs d'architecture sur mesure, refactorisation automatisée ou pipelines de génération de code.
Analyse statique asynchrone/await de TypeScript
Les données de la Search Console montrent un groupe spécifique de requêtes autour de « outil de documentation sur l'analyse statique TypeScript asynchrone et l'analyse des vulnérabilités TypeScript ». Celles-ci reflètent la recherche, par des praticiens, d'outils capables de comprendre les erreurs de programmation asynchrone au niveau du type.
La solution pratique pour les équipes TypeScript en production réside dans les quatre règles spécifiques à l'asynchrone de typescript-eslint (no-floating-promises, await-thenable, no-misused-promises, require-await) combiné avec strictNullChecks et useUnknownInCatchVariablesEnsemble, ces outils permettent de détecter les erreurs de type asynchrone les plus courantes sans nécessiter d'outils de recherche universitaires.
Pour les équipes effectuant des recherches en sécurité sur les modèles de vulnérabilité asynchrones, TAJS et Jelly sont des analyseurs statiques académiques qui modélisent la sémantique d'exécution asynchrone de JavaScript, mais ce sont des outils de recherche, et non des outils de développement pour la production.
Angular et React : Analyse statique spécifique au framework
Pour les équipes Angular, @angular-eslint Il fournit des règles de linting spécifiques à Angular couvrant les modèles de composants, l'analyse des templates et l'injection de services. Il s'intègre à la configuration ESLint + typescript-eslint mentionnée ci-dessus.
Pour les équipes React, le eslint-plugin-react, eslint-plugin-react-hooks et eslint-plugin-jsx-a11y Les plugins couvrent les modèles spécifiques à React. Dependency-Cruiser gère l'analyse des graphes de dépendances spécifiques à React et est l'outil qui sous-tend les requêtes « outil en ligne de commande d'analyse des dépendances React » dans les données SC.
Intégration IDE : Outils pour VS Code et JetBrains
Les requêtes « meilleurs outils d'analyse de la qualité du code pour l'intégration à VS Code » et « meilleurs outils d'analyse de la qualité du code pour l'intégration à un IDE » reflètent un besoin réel : les retours d'information de l'intégration continue arrivent trop tard pour modifier les pratiques. L'analyse intégrée à l'IDE offre le cycle de rétroaction le plus court.
VS Code : extension ESLint avec l’analyseur rust Clippy, extension SonarLint pour les règles SonarQube intégrées, extension Snyk pour les résultats de sécurité et le service de langage TypeScript intégré pour les retours au niveau du type.
JetBrains (WebStorm/IntelliJ) : WebStorm intègre une prise en charge native de TypeScript qui détecte les erreurs de typage directement dans le code, ainsi qu’une intégration avec ESLint, Prettier et SonarLint. Son système d’inspection intégré couvre de nombreux modèles similaires aux règles ESLint.
Configuration de VS Code pour une couverture d'analyse statique TypeScript maximale :
json
// .vscode/settings.json
{
"typescript.tsdk": "node_modules/typescript/lib",
"typescript.enablePromptUseWorkspaceTsdk": true,
"editor.codeActionsOnSave": {
"source.fixAll.eslint": "explicit"
},
"eslint.validate": ["javascript", "typescript", "typescriptreact"],
"sonarlint.connectedMode.project": {
"connectionId": "my-sonarcloud",
"projectKey": "my-org_my-project"
}
}Comment SMART TS XL Étend l'analyse TypeScript à l'échelle de l'entreprise
Les outils mentionnés ci-dessus couvrent TypeScript au sein d'un projet TypeScript. Dans les organisations où les services TypeScript interagissent avec des programmes batch COBOL, des API Java, des pipelines de données Python ou des systèmes mainframe existants, les outils monolangage ne peuvent pas détecter les dépendances qui transcendent les frontières linguistiques.
SMART TS XL's analyse de code statique Il couvre TypeScript ainsi que tous les autres langages de l'environnement d'entreprise, COBOL, JCL, Java, Python, RPG et SQL, et établit un modèle de dépendance unifié entre eux. Lorsqu'un service TypeScript appelle une API exécutée par un programme COBOL, SMART TS XL peut retracer cette relation et l'inclure dans analyse d’impact avant toute modification apportée à l'un ou l'autre des composants.
La fonctionnalité de recherche d'entreprise permet d'interroger l'intégralité du code source multilingue : trouvez chaque importation TypeScript d'un module spécifique, chaque méthode Java appelée par un service TypeScript, chaque copybook COBOL qui alimente une API consommée par TypeScript, en quelques secondes, sur des millions de lignes de code dans n'importe quelle combinaison de langages.
Pour les équipes d'entreprise qui utilisent TypeScript comme l'un des langages d'un portefeuille plus large, SMART TS XL assure la visibilité architecturale et la compatibilité multilingue mappage des dépendances cela permet aux outils spécifiques à TypeScript d'examiner leur partie du système tandis que SMART TS XL voit l'ensemble.
Construire la pile adéquate
Aucun outil unique ne couvre tous les aspects de la qualité pour TypeScript. La bonne approche consiste à utiliser plusieurs couches, chacune ciblant une catégorie de problèmes distincte :
Configuration minimale viable (nouveau projet, petite équipe) :
- Mode strict TypeScript
- ESLint avec les règles asynchrones de typescript-eslint
npm auditpour les vulnérabilités de dépendance
Pile applicative de production (équipe de taille moyenne, soucieuse de la sécurité) :
- Tout ce qui précède, plus:
- Biome ou Prettier pour la mise en forme
- Semgrep pour la sécurité SAST
- Knip pour code mort
- SonarCloud pour une meilleure visibilité des tendances de qualité
Architecture d'entreprise / monorepo (grande équipe, contraintes architecturales) :
- Tout ce qui précède, plus:
- Dependency-Cruiser pour le contrôle des limites des modules
- Nx pour l'optimisation des builds affectés par le monorepo
- Deptrac pour la validation des limites de couches
- SonarQube (auto-hébergé) pour les contrôles qualité sur site
Pile technologique d'entreprise polyglotte (TypeScript et systèmes existants) :
- Tout ce qui précède, plus:
- SMART TS XL pour l'analyse d'impact interlinguistique et la cartographie des dépendances
