Strumenti di analisi statica TypeScript: la guida completa per i team di sviluppo

Il sistema di tipi di TypeScript individua una classe significativa di bug prima dell'esecuzione del codice, come incongruenze di tipo, proprietà mancanti e firme di funzione errate. Ciò che non riesce a individuare è tutto il resto: vulnerabilità di sicurezza che dipendono dal flusso di dati all'interno dell'applicazione, violazioni architetturali che si accumulano nel tempo man mano che i confini tra i team si fanno più sfumati, esportazioni inattive che rimangono nel codice sorgente anche dopo la rimozione dei relativi chiamanti ed errori di programmazione asincrona che compilano correttamente ma falliscono in specifiche condizioni di runtime. Gli strumenti di analisi statica colmano queste lacune e la scelta della combinazione più adatta dipende da ciò che si sta effettivamente cercando di individuare.

Questa guida illustra gli strumenti fondamentali per i team TypeScript nel 2026: il livello di linting (ESLint con typescript-eslint, Biome, OxcLint), il livello di sicurezza (Semgrep, Snyk Code, SonarQube), il livello architetturale (Dependency-Cruiser, Deptrac, Nx), il livello di individuazione del codice morto (Knip) e il livello di analisi approfondita (ts-morph, il compilatore TypeScript stesso). Per ciascuno di essi, l'attenzione si concentra su cosa fa effettivamente, come configurarlo e quando non è lo strumento più adatto.

Strumenti di analisi statica di TypeScript: tabella comparativa

Prima di analizzare i singoli strumenti, la tabella seguente illustra la funzione principale di ciascuno, l'idoneità all'integrazione continua (CI) e il caso d'uso ideale. Nessuno strumento singolo copre tutte le dimensioni; un'analisi efficace della qualità di TypeScript richiede l'utilizzo combinato di diversi strumenti.

Chiavetta	Funzione primaria	CI Adatto	Costo	Ideale per
ESLint + typescript-eslint	Linting, stile, regole sensibili al tipo	Si	Gratis	Convenzioni a livello di team, sicurezza dei tipi asincroni
bioma	Colorazione + formattazione	Si	Gratis	Sostituzione di ESLint + più carina, velocità
OxcLint	Linting (compatibile con ESLint)	Si	Gratis	Monorepo che necessitano di tempi di linting rapidi
Compilatore TypeScript (tsc)	Tipo di controllo	Si	Gratis	Errori di battitura, applicazione rigorosa della modalità
Segrep	SAST, modelli personalizzati	Si	Gratuito + a pagamento	Scansione di sicurezza, regole personalizzate dell'organizzazione
Codice Snyk	SAST, sicurezza delle dipendenze	Si	Gratuito + a pagamento	Team che privilegiano la sicurezza, integrazione con l'IDE
SonarQube / SonarCloud	Controlli di qualità, monitoraggio delle tendenze	Si	Gratuito + a pagamento	Dashboard di qualità aziendale
SonarLint	Feedback sulla qualità a livello IDE	Solo IDE	Gratis	Suggerimenti di sicurezza e qualità in linea
Cruiser della dipendenza	Applicazione del grafo di dipendenza	Si	Gratis	Validazione delle regole architettoniche
Dipartimento	imposizione dei confini di strato	Si	Gratis	Architettura pulita, confini DDD
Nx	Gestione delle dipendenze monorepo	Si	Gratuito + a pagamento	limiti del modulo Monorepo
taglio	Codice morto ed esportazioni non utilizzate	Si	Gratis	Riduzione su larga scala del codice inutilizzato
ts-morph	Analisi AST programmatica TS	Selettivo	Gratis	Analisi personalizzate, modifiche al codice, strumenti

Livello 1: Lining e stile

ESLint con typescript-eslint

ESLint rimane il fondamento del linting di TypeScript. Con il typescript-eslint Grazie a questo pacchetto, ha accesso alle informazioni sui tipi di TypeScript e può applicare regole che richiedono il contesto dei tipi, le più preziose delle quali sono le regole specifiche per l'asincronia che individuano gli errori comuni nelle Promise.

bash

npm install --save-dev typescript-eslint

javascript

// 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",
    },
  }
);

Le quattro regole asincrone sopra riportate sono l'aggiunta di maggior valore che typescript-eslint fornisce rispetto al semplice ESLint. Catturano: Promise non gestite (promise fluttuanti), await applicato a valori non Promise, Promise passate a callback che si aspettano funzioni sincrone e funzioni asincrone che non vengono mai utilizzate awaitSi tratta di modelli che vengono compilati correttamente ma che producono errori in fase di esecuzione in determinate condizioni.

Cosa non può fare ESLint : analisi del flusso di dati tra file, applicazione dei limiti architetturali, tracciamento di vulnerabilità di sicurezza o rilevamento di esportazioni non funzionanti. Per queste funzionalità, sono necessari gli altri livelli sottostanti.

Biome: il moderno sostituto di ESLint, più elegante.

Biome sostituisce sia ESLint che Prettier con un singolo eseguibile basato su Rust che offre prestazioni da 25 a 35 volte superiori. Supporta JavaScript, TypeScript, JSX e JSON. Per i nuovi progetti o i team frustrati dalla complessità dei plugin di ESLint e dalle sue prestazioni lente in codebase di grandi dimensioni, Biome rappresenta la migliore alternativa moderna.

bash

npm install --save-dev --save-exact @biomejs/biome
npx @biomejs/biome init

bash

# 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'ecosistema di plugin di Biome è più piccolo di quello di ESLint, un aspetto importante per i team che utilizzano numerose regole personalizzate o plugin specifici per determinati framework. Per i team che utilizzano solo le regole principali di ESLint e la formattazione Prettier, Biome offre una copertura equivalente in una frazione del tempo di esecuzione.

OxcLint: Compatibilità con ESLint all'insegna della velocità

OxcLint (parte del progetto Oxc) esegue le regole compatibili con ESLint con una velocità di esecuzione da 50 a 100 volte superiore. Non sostituisce l'intero ecosistema ESLint, ma rappresenta l'opzione più veloce per le pipeline di integrazione continua (CI) in cui il tempo di linting costituisce un collo di bottiglia.

bash

npm install --save-dev oxlint
npx oxlint src/

OxcLint è la scelta ideale per i monorepo di grandi dimensioni, dove ESLint standard impiega minuti e la latenza del ciclo di feedback riduce la qualità delle pull request. Funziona al meglio in combinazione con ESLint, piuttosto che in sostituzione: utilizzate OxcLint per un feedback rapido e ESLint per una copertura completa delle regole nella fase di pre-merge.

Livello 2: Controllo dei tipi, il compilatore TypeScript

Il compilatore TypeScript (tsc) non è solo uno strumento di compilazione, è il principale motore di analisi statica per la correttezza a livello di tipo. L'attivazione della modalità rigorosa attiva le impostazioni che individuano il maggior numero di bug reali:

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 --noEmit

noUnusedLocals and noUnusedParameters A livello di compilatore, intercetta le variabili e i parametri di funzione non utilizzati. useUnknownInCatchVariables (TypeScript 4.4+) tipi cattura eccezioni come unknown anziché any, imponendo una restrizione esplicita del tipo prima dell'uso.

Analisi del flusso di controllo di TypeScript è una funzionalità integrata fornita dal compilatore per restringere i tipi all'interno dei rami condizionali. Non è uno strumento separato che consente strict la modalità garantisce che venga applicata con il massimo rigore. L'analisi del flusso di controllo del compilatore comprende le protezioni dei tipi, typeof assegni, instanceofe modelli di unione discriminatori.

La limitazione di tsc : il compilatore TypeScript non rileva vulnerabilità di sicurezza, violazioni dei limiti architetturali o esportazioni non funzionanti. Rileva errori di tipo, e lo fa in modo definitivo.

Livello 3: Sicurezza, SAST per TypeScript

Semgrep: Scansione di sicurezza basata su modelli

Semgrep trova vulnerabilità di sicurezza tramite la corrispondenza di modelli di codice. Per TypeScript, può rilevare SQL injection, XSS, credenziali hardcoded, non sicure eval utilizzo, inquinamento da prototipi e configurazioni Express.js non sicure, modelli che compilano correttamente ma introducono vulnerabilità sfruttabili.

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: ERROR

bash

# Run with the community TypeScript security rules
semgrep scan --config=p/typescript --config=p/owasp-top-ten src/

Semgrep è complementare a ESLint, non in competizione con esso. ESLint impone le convenzioni; Semgrep individua gli anti-pattern di sicurezza. La maggior parte dei team TypeScript che tengono alla sicurezza dovrebbe utilizzare entrambi.

Snyk Code: SAST basato su machine learning con integrazione IDE

Snyk Code esegue SAST con un motore di analisi basato sull'apprendimento automatico che traccia i flussi di contaminazione tra i file. Si integra con gli IDE VS Code e JetBrains, evidenziando i risultati in tempo reale mentre gli sviluppatori scrivono codice, anziché dover attendere l'esecuzione di un processo di integrazione continua (CI).

bash

npm install --save-dev snyk
npx snyk auth
npx snyk code test

L'attenzione di Snyk Code all'esperienza di sviluppo, il feedback integrato nell'IDE, i suggerimenti di correzione accanto a ogni vulnerabilità rilevata e gli esempi di risoluzione, lo rendono la scelta migliore quando la formazione sulla sicurezza è importante quanto l'individuazione delle vulnerabilità.

SonarQube e SonarLint: Controlli di qualità e monitoraggio delle tendenze

SonarQube offre un'analisi continua della qualità del codice con dashboard, monitoraggio delle tendenze e decorazione delle pull request. Per TypeScript rileva bug, code smell, punti critici di sicurezza e duplicazioni. SonarLint è l'estensione dell'IDE che visualizza localmente le regole di SonarQube.

Per i team che utilizzano TypeScript, SonarCloud (la versione in cloud) rappresenta la soluzione più semplice: gratuita per i repository pubblici, con integrazione CI tramite GitHub Actions o GitLab CI in pochi minuti.

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 }}

Il principale vantaggio di SonarQube rispetto al semplice linting risiede nel suo modello di trend: come si evolve la qualità del codice nel tempo, quali componenti si stanno deteriorando e qual è il punteggio di qualità del nuovo codice per ogni pull request. Queste metriche, rivolte al management, sono ciò che SonarQube fa e che ESLint e Semgrep non possono fare.

Livello 4: Analisi architettonica

Dependency-Cruiser: applica le regole dei confini dei moduli

Dependency-Cruiser verifica che il grafico delle dipendenze rispetti le regole architetturali definite. Genera grafici visivi delle dipendenze e interrompe l'integrazione continua (CI) quando il codice viola i vincoli di confine tra i moduli.

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 risponde direttamente alle query "react dependency analysis cli tool" nei dati di Search Console; si tratta dello strumento standard per la generazione e la convalida dei grafici delle dipendenze nei progetti TypeScript/React.

Deptrac: Applicazione dei limiti basata su livelli

Deptrac impone l'applicazione di livelli architetturali, garantendo che il codice di persistenza non possa importare dalla presentazione, che gli oggetti di dominio non dipendano dall'infrastruttura e che i confini dei moduli siano rispettati nell'intera codebase.

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
      - Domain

Deptrac è particolarmente utile nei progetti che seguono i modelli Clean Architecture, DDD o Hexagonal Architecture, dove l'isolamento dei livelli è un vincolo di progettazione, non solo una preferenza.

Nx: Gestione delle dipendenze a livello di monorepo

Per i monorepo TypeScript, Nx offre funzionalità di controllo dei confini dei moduli, rilevamento delle build interessate e visualizzazione del grafo delle dipendenze per tutti i progetti presenti nel repository.

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's affected I comandi eseguono solo i test e il linting relativi ai moduli modificati, riducendo significativamente i tempi di CI nei grandi monorepo.

Livello 5: Rilevamento del codice morto

Knip: Trova esportazioni, file e dipendenze inutilizzati

Knip analizza il grafico completo del modulo per identificare esportazioni non utilizzate, file non utilizzati e non utilizzati package.json dipendenze, la classe di accumulo di codice che ESLint no-unused-vars non può essere rilevato perché cerca solo all'interno di un file.

bash

npm install --save-dev knip
npx knip

json

// knip.json
{
  "entry": ["src/index.ts", "src/**/*.test.ts"],
  "project": ["src/**/*.ts"],
  "ignore": ["src/generated/**"],
  "ignoreDependencies": ["vitest"]
}

Knip viene cercato direttamente nei dati di SC come "rilevamento di codice morto, esportazioni inutilizzate, javascript, typescript". È lo strumento attualmente più efficace per l'identificazione di codice morto a livello di modulo nei progetti TypeScript.

Livello 6: Analisi programmatica, ts-morph

ts-morph è un wrapper dell'API del compilatore TypeScript che semplifica la scrittura di analisi personalizzate, codemod e strumenti per l'AST di TypeScript. È possibile cercarlo direttamente nei dati di SC come "ts-morph" e "ts morph".

dattiloscritto

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 non è uno strumento di analisi pronto all'uso, bensì la libreria da utilizzare per crearne uno. È adatto a team che necessitano di analisi personalizzate che vadano oltre le funzionalità offerte dagli strumenti esistenti: script di migrazione, validatori architetturali personalizzati, refactoring automatizzato o pipeline di generazione del codice.

Analisi statica di TypeScript Async/Await

I dati di Search Console mostrano un gruppo specifico di query relative a "typescript static analysis async await paper tool" e "typescript static analysis async await vulnerability paper tool". Queste query riflettono la ricerca da parte di professionisti di strumenti in grado di comprendere gli errori di programmazione asincrona a livello di tipo.

La risposta pratica per i team TypeScript di produzione sono le quattro regole specifiche per l'asincronia di typescript-eslint (no-floating-promises, await-thenable, no-misused-promises, require-await) combinato con strictNullChecks and useUnknownInCatchVariablesInsieme, questi strumenti individuano gli errori di tipo asincrono più comuni senza richiedere strumenti di ricerca accademica.

Per i team che conducono ricerche sulla sicurezza relative a modelli di vulnerabilità asincrone, TAJS e Jelly sono analizzatori statici accademici che modellano la semantica dell'esecuzione asincrona di JavaScript, ma sono strumenti di ricerca, non strumenti di sviluppo per la produzione.

Angular e React: analisi statica specifica per framework

Per i team Angular, @angular-eslint Fornisce regole di linting specifiche per Angular che coprono i pattern dei componenti, l'analisi dei template e l'iniezione dei servizi. Si integra con la configurazione ESLint + typescript-eslint descritta sopra.

Per i team React, il eslint-plugin-react, eslint-plugin-react-hookse eslint-plugin-jsx-a11y I plugin coprono i pattern specifici di React. Dependency-Cruiser gestisce l'analisi del grafo delle dipendenze specifico di React ed è lo strumento alla base delle query "react dependency analysis cli tool" nei dati di SC.

Integrazione con l'IDE: strumenti per VS Code e JetBrains

Le query "migliori strumenti per la qualità del codice per l'integrazione con VS Code" e "migliori strumenti per la qualità del codice per l'integrazione con gli IDE" riflettono un'esigenza reale: il feedback della CI arriva troppo tardi per modificare i comportamenti. L'analisi integrata con l'IDE fornisce il ciclo di feedback più rapido.

VS Code : estensione ESLint con compatibilità Clippy per l'analizzatore di codice Rust, estensione SonarLint per le regole SonarQube inline, estensione Snyk per i risultati relativi alla sicurezza e servizio linguistico TypeScript integrato per il feedback a livello di tipo.

JetBrains (WebStorm/IntelliJ) : WebStorm include il supporto integrato per TypeScript che evidenzia gli errori di tipo direttamente nel codice, oltre all'integrazione con ESLint, Prettier e SonarLint. Il sistema di ispezione integrato copre molti degli stessi modelli delle regole di ESLint.

Configurazione di VS Code per la massima copertura dell'analisi statica di TypeScript :

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"
  }
}

Come SMART TS XL Estende l'analisi TypeScript a tutta l'azienda

Gli strumenti sopra descritti coprono TypeScript all'interno di un progetto TypeScript. Nelle organizzazioni in cui i servizi TypeScript interagiscono con programmi batch COBOL, API Java, pipeline di dati Python o sistemi mainframe legacy, gli strumenti monolingue non sono in grado di rilevare le dipendenze che trascendono i confini dei linguaggi.

SMART TS XL'S analisi statica del codice copre TypeScript insieme a ogni altro linguaggio nell'ambiente aziendale, COBOL, JCL, Java, Python, RPG, SQL e crea un modello di dipendenza unificato per tutti. Quando un servizio TypeScript chiama un'API supportata da un programma COBOL, SMART TS XL può tracciare quella relazione e includerla in analisi d'impatto prima di apportare qualsiasi modifica a uno dei due componenti.

La funzionalità di ricerca aziendale rende interrogabile l'intera codebase multilingue: trova ogni importazione TypeScript di un modulo specifico, ogni metodo Java chiamato da un servizio TypeScript, ogni copybook COBOL che fornisce dati a un'API che utilizza TypeScript, in pochi secondi, attraverso milioni di righe di codice in qualsiasi combinazione di linguaggi.

Per i team aziendali che utilizzano TypeScript come linguaggio all'interno di un portfolio più ampio, SMART TS XL fornisce la visibilità architettonica e la comunicazione interlinguistica mappatura delle dipendenze che fa sì che gli strumenti specifici di TypeScript considerino la loro parte del sistema mentre SMART TS XL vede l'insieme.

Costruire lo stack giusto

Nessuno strumento singolo copre tutte le dimensioni qualitative per TypeScript. L'approccio corretto è a strati, con ogni strato mirato a una classe di problemi distinta:

Stack minimo indispensabile (nuovo progetto, team ridotto):

• Modalità rigorosa di TypeScript
• ESLint con regole asincrone di typescript-eslint
• npm audit per vulnerabilità di dipendenza

Stack applicativo di produzione (team di medie dimensioni, con particolare attenzione alla sicurezza):

• Tutto sopra, oltre a:
• Biome o Prettier per la formattazione
• Semgrep per la sicurezza SAST
• Tagliare il codice morto
• SonarCloud per una visibilità ottimale delle tendenze qualitative

Stack aziendale/monorepo (team numeroso, vincoli architetturali):

• Tutto sopra, oltre a:
• Dependency-Cruiser per il controllo dei confini dei moduli
• Nx per l'ottimizzazione delle build interessate del monorepo
• Deptrac per la convalida dei confini di strato
• SonarQube (self-hosted) per i controlli di qualità on-premise

Stack aziendale poliglotta (TypeScript insieme a sistemi legacy):

• Tutto sopra, oltre a:
• SMART TS XL per l'analisi dell'impatto interlinguistico e la mappatura delle dipendenze