TypeScript statiska analysverktyg: Den kompletta guiden för utvecklingsteam

TypeScripts typsystem fångar upp en betydande klass av buggar innan kod körs, typavvikelser, saknade egenskaper, felaktiga funktionssignaturer. Vad det inte kan fånga är allt annat: säkerhetsbrister som beror på hur data flödar genom applikationen, arkitekturöverträdelser som ackumuleras över tid när teamgränser suddas ut, döda exporter som finns kvar i kodbasen långt efter att deras anropare har tagits bort och asynkrona programmeringsfel som kompileras korrekt men misslyckas under specifika körningsförhållanden. Statiska analysverktyg fyller dessa luckor, och att välja rätt kombination beror på vad du faktiskt försöker hitta.

Den här guiden täcker de verktyg som är viktiga för TypeScript-team år 2026: linting-lagret (ESLint med typescript-eslint, Biome, OxcLint), säkerhetslagret (Semgrep, Snyk Code, SonarQube), arkitekturlagret (Dependency-Cruiser, Deptrac, Nx), lagret med död kod (Knip) och djupanalyslagret (ts-morph, själva TypeScript-kompilatorn). För varje verktyg ligger fokus på vad det faktiskt gör, hur man konfigurerar det och när det inte är rätt verktyg för jobbet.

TypeScript statiska analysverktyg: Jämförelsetabell

Innan vi går in på enskilda verktyg kartlägger tabellen nedan varje verktyg utifrån dess primära funktion, CI-lämplighet och ideala användningsfall. Inget enskilt verktyg täcker alla dimensioner, effektiv TypeScript-kvalitetsanalys kräver att flera verktyg kombineras i lager.

Verktyget	Primär funktion	CI-lämplig	Pris	bäst för
ESLint + typescript-eslint	Linting, stil, typmedvetna regler	Ja	Gratis	Teamövergripande konventioner, asynkron säkerhet
Biome	Linting + formatering	Ja	Gratis	ESLint + Snyggare ersättning, snabbare
OxcLint	Linting (ESLint-kompatibel)	Ja	Gratis	Monorepos behöver snabba luddtider
TypeScript-kompilator (tsc)	Typkontroll	Ja	Gratis	Typfel, strikt lägesövervakning
Semgrep	SAST, anpassade mönster	Ja	Gratis + betalt	Säkerhetsskanning, anpassade organisationsregler
Snyk kod	SAST, beroendesäkerhet	Ja	Gratis + betalt	Säkerhetsfokuserade team, IDE-integration
SonarQube / SonarCloud	Kvalitetsgrindar, trendspårning	Ja	Gratis + betalt	Kvalitetsinstrumentpaneler för företag
Ekolod	IDE-nivå kvalitetsfeedback	Endast IDE	Gratis	Tips för inbyggd säkerhet och kvalitet
Beroendekryssare	Tillämpning av beroendegraf	Ja	Gratis	Validering av arkitekturregler
Deptrac	Tillämpning av lagergränser	Ja	Gratis	Ren arkitektur, DDD-gränser
Nx	Monorepo beroendehantering	Ja	Gratis + betalt	Monorepo-modulens gränser
Knip	Död kod och oanvända exporter	Ja	Gratis	Minska oanvänd kod i stor skala
ts-morph	Programmatisk TS AST-analys	Selektiv	Gratis	Anpassad analys, codemods, verktyg

Lager 1: Luddning och stil

ESLint med typescript-eslint

ESLint är fortfarande grunden för TypeScript-linting. Med typescript-eslint paketet får det tillgång till TypeScripts typinformation och kan tillämpa regler som kräver typkontext, varav de mest värdefulla är de async-specifika reglerna som fångar upp vanliga Promise-misstag.

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

De fyra async-reglerna ovan är det tillägg med högsta värde som typescript-eslint ger jämfört med vanlig ESLint. De fångar: ohanterade löften (flytande löften), await tillämpas på värden som inte är Promise-värden, löften som skickas till återanrop som förväntar sig synkrona funktioner och asynkrona funktioner som aldrig använder awaitDet här är mönster som kompileras utan problem men som orsakar körtidsfel under specifika förhållanden.

Vad ESLint inte kan göra : analys av dataflöden mellan filer, tillämpning av arkitektoniska gränser, spårning av säkerhetsföroreningar eller detektering av döda exporter. För dessa krävs de andra lagren nedan.

Biom: Den moderna ESLint + Snyggare ersättning

Biome ersätter både ESLint och Prettier med en enda Rust-baserad binärfil som körs 25–35 gånger snabbare. Den stöder JavaScript, TypeScript, JSX och JSON. För nya projekt eller team som är frustrerade över ESLints plugin-komplexitet och långsamma prestanda i stora kodbaser är Biome det starkaste moderna alternativet.

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/

Biomes plugin-ekosystem är mindre än ESLints, vilket är viktigt för team med omfattande anpassade regler eller ramverksspecifika plugins. För team som endast använder de grundläggande ESLint-reglerna och Prettier-formateringen ger Biome motsvarande täckning till en bråkdel av exekveringstiden.

OxcLint: Hastighet-Först ESLint-kompatibilitet

OxcLint (en del av Oxc-projektet) kör ESLint-kompatibla regler med 50–100 gånger snabbare exekvering. Det ersätter inte hela ESLint-ekosystemet men fungerar som det snabbaste alternativet för CI-pipelines där lint-tid är en flaskhals.

bash

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

OxcLint är rätt val för stora monorepos där standard ESLint tar minuter och feedback loop-latensen minskar pull request-kvaliteten. Det fungerar bäst tillsammans med ESLint snarare än att ersätta det, kör OxcLint för den snabba feedback-vägen och ESLint för fullständig regeltäckning i pre-merge gate.

Nivå 2: Typkontroll, TypeScript-kompilatorn

TypeScript-kompilatorn (tsc) är inte bara ett byggverktyg, det är den primära statiska analysmotorn för korrekthet på typnivå. Aktivering av strict-läge aktiverar de inställningar som fångar upp de flesta verkliga buggarna:

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 och noUnusedParameters på kompilatornivå fånga oanvända variabler och funktionsparametrar. useUnknownInCatchVariables (TypeScript 4.4+) typer fångade undantag som unknown snarare än any, vilket tvingar fram explicit typförträngning före användning.

TypeScript-kontrollflödesanalys är en inbyggd funktion som kompilatorn tillhandahåller för att begränsa typer inom villkorliga grenar. Det är inte ett separat verktyg som möjliggör strict läget säkerställer att det tillämpas med full rigoröshet. Kompilatorns kontrollflödesanalys förstår type guards, typeof checkar, instanceof, och diskriminerade fackföreningsmönster.

tsc-begränsningen : TypeScript-kompilatorn hittar inte säkerhetsbrister, brott mot arkitekturgränser eller döda exporter. Den hittar typfel, och den gör det definitivt.

Lager 3: Säkerhet, SAST för TypeScript

Semgrep: Mönsterbaserad säkerhetsskanning

Semgrep hittar säkerhetsbrister genom matchning av kodmönster. För TypeScript kan det upptäcka SQL-injektion, XSS, hårdkodade autentiseringsuppgifter, osäkra eval användning, prototypförorening och osäkra Express.js-konfigurationer, mönster som kompileras korrekt men introducerar exploaterbara sårbarheter.

jaml

# 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 kompletterar ESLint, inte konkurrerar med det. ESLint tillämpar konventioner; Semgrep hittar säkerhetsmässiga antimönster. De flesta TypeScript-team som bryr sig om säkerhet borde köra båda.

Snyk-kod: ML-baserad SAST med IDE-integration

Snyk Code utför SAST med en maskininlärningsbaserad analysmotor som spårar flöden av data från data över filer. Den integreras i VS Code och JetBrains IDE:er, vilket visar resultat direkt när utvecklare skriver kod istället för att vänta på en CI-körning.

bash

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

Snyk Codes fokus på utvecklarupplevelse, inbyggda IDE-feedback, förslag på korrigeringar bredvid varje fynd och exempel på åtgärder gör det till det bättre valet när säkerhetsutbildning är lika viktig som säkerhetsdetektering.

SonarQube och SonarLint: Kvalitetsgrindar och trendspårning

SonarQube tillhandahåller kontinuerlig kodkvalitetsanalys med en instrumentpanel, trendspårning och dekoration av pull requests. För TypeScript upptäcker den buggar, kodlukter, säkerhetshotspots och dubbletter. SonarLint är IDE-tillägget som lokalt visar SonarQube-regler.

För TypeScript-team är SonarCloud (molnbaserad version) den enklare vägen: gratis för publika arkiv, med CI-integration via GitHub Actions eller GitLab CI på några minuter.

jaml

# .github/workflows/sonar.yml
- name: SonarCloud Scan
  uses: SonarSource/sonarcloud-github-action@master
  env:
    GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
    SONAR_TOKEN: ${{ secrets.SONAR_TOKEN }}

SonarQubes främsta värde jämfört med rå linting är dess trendmodell: hur utvecklas kodkvaliteten över tid, vilka komponenter försämras och vad är nykodskvalitetspoängen för varje pull request. Dessa hanteringsorienterade mätvärden är vad SonarQube gör som ESLint och Semgrep inte kan.

Nivå 4: Arkitektonisk analys

Dependency-Cruiser: Tillämpa modulgränsregler

Dependency-Cruiser validerar att din importgraf följer definierade arkitekturregler. Den genererar visuella beroendegrafer och misslyckas med CI när kod bryter mot modulgränsbegränsningar.

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 adresserar direkt frågorna "react dependency analysis cli tool" i Search Console-data. Det är standardverktyget för att generera och validera beroendegrafer i TypeScript/React-projekt.

Deptrac: Lagerbaserad gränskontroll

Deptrac tillämpar arkitektoniska lager, vilket säkerställer att persistenskod inte kan importeras från presentationer, att domänobjekt inte är beroende av infrastruktur och att modulgränser respekteras över hela kodbasen.

jaml

# 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 är mest värdefullt i projekt som följer Clean Architecture, DDD eller Hexagonal Architecture-mönster där lagerisolering är en designbegränsning, inte bara en preferens.

Nx: Beroendehantering på Monorepo-nivå

För TypeScript-monorepos tillhandahåller Nx modulgränsövervakning, detektering av påverkade byggen och visualisering av beroendegrafer över alla projekt i repositoriet.

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:er affected Kommandon kör endast tester och linting som är relevanta för ändrade moduler, vilket avsevärt minskar CI-tiden i stora monorepos.

Lager 5: Detektering av död kod

Knip: Hitta oanvända exporter, filer och beroenden

Knip analyserar hela modulgrafen för att identifiera oanvända exporter, oanvända filer och oanvända package.json beroenden, den klass av kodackumulering som ESLints no-unused-vars kan inte fånga eftersom den bara tittar i en fil.

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 söks direkt i SC-data som "dead code detection unused exports javascript typescript". Det är det mest kapabla nuvarande verktyget för identifiering av död kod på modulnivå i TypeScript-projekt.

Lager 6: Programmatisk analys, ts-morph

ts-morph är ett API-omslag för TypeScript-kompilatorer som gör det enkelt att skriva anpassade analyser, kodmoddar och verktyg mot TypeScript AST. Det söks direkt i SC-data som "ts-morph" och "ts morph".

skrivmaskin

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 är inte ett färdigt analysverktyg, det är biblioteket du använder för att bygga ett. Det är lämpligt för team som behöver anpassad analys utöver vad befintliga verktyg stöder: migreringsskript, anpassade arkitekturvaliderare, automatiserad refaktorering eller kodgenereringspipelines.

TypeScript Async/Await Static Analysis

Search Console-data visar ett specifikt kluster av frågor kring "typescript static analysis async await paper tool" och "typescript static analysis async await vulnerability paper tool". Dessa återspeglar yrkesverksamma som söker efter verktyg som förstår async-programmeringsfel på typnivå.

Det praktiska svaret för produktionsteam inom TypeScript är typescript-eslints fyra asynkronspecifika regler (no-floating-promises, await-thenable, no-misused-promises, require-await) kombinerat med strictNullChecks och useUnknownInCatchVariablesTillsammans fångar dessa upp de vanligaste asynkrona felen utan att akademiska forskningsverktyg krävs.

För team som utför säkerhetsforskning om asynkrona sårbarhetsmönster är TAJS och Jelly akademiska statiska analysverktyg som modellerar JavaScripts asynkrona exekveringssemantik, men de är forskningsverktyg, inte produktionsutvecklingsverktyg.

Angular och React: Ramverksspecifik statisk analys

För Angular-team, @angular-eslint tillhandahåller Angular-specifika lintingregler som täcker komponentmönster, mallanalys och tjänsteinjektion. Den integreras med ESLint + typescript-eslint-konfigurationen ovan.

För React-team, den eslint-plugin-react, eslint-plugin-react-hooksoch eslint-plugin-jsx-a11y Plugins täcker React-specifika mönster. Dependency-Cruiser hanterar React-specifik beroendegrafanalys och är verktyget bakom frågorna "react dependency analysis cli tool" i SC-data.

IDE-integration: Verktyg för VS Code och JetBrains

Frågorna ”verktyg av högsta kodkvalitet för VS-kodintegration” och ”verktyg av högsta kodkvalitet för IDE-integration” återspeglar ett verkligt behov: CI-feedback kommer för sent för att ändra beteende. IDE-integrerad analys ger den tätaste feedback-slingan.

VS-kod : ESLint-tillägg med rostanalysatorn Clippy-paritet, SonarLint-tillägg för inline SonarQube-regler, Snyk-tillägg för säkerhetsfynd och den inbyggda TypeScript-språktjänsten för feedback på typnivå.

JetBrains (WebStorm/IntelliJ) : WebStorm levereras med inbyggt TypeScript-stöd som avslöjar typfel direkt, plus integration med ESLint, Prettier och SonarLint. Det inbyggda inspektionssystemet täcker många av samma mönster som ESLint-regler.

VS-kodkonfiguration för maximal statisk analys av 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"
  }
}

Hur SMART TS XL Utökar TypeScript-analys i hela företaget

Verktygen ovan täcker TypeScript inom ett TypeScript-projekt. I organisationer där TypeScript-tjänster interagerar med COBOL-batchprogram, Java API:er, Python-datapipelines eller äldre stordatorsystem kan inte enspråkiga verktyg se beroenden som korsar språkgränser.

SMART TS XLÄr statisk kodanalys täcker TypeScript tillsammans med alla andra språk i företagsmiljön, COBOL, JCL, Java, Python, RPG, SQL, och bygger en enhetlig beroendemodell över dem alla. När en TypeScript-tjänst anropar ett API som stöds av ett COBOL-program, SMART TS XL kan spåra det sambandet och inkludera det i konsekvensanalys innan någon ändring görs på någon av komponenterna.

Företagssökningsfunktionen gör hela den flerspråkiga kodbasen sökbar: hitta varje TypeScript-import av en specifik modul, varje Java - metod som en TypeScript-tjänst anropar, varje COBOL-kopibok som matar data till ett TypeScript-konsumerat API, på några sekunder, över miljontals kodrader i valfri språkkombination.

För företagsteam som använder TypeScript som ett språk i en större portfölj, SMART TS XL ger arkitektonisk synlighet och språköverskridande beroendekartläggning som gör att TypeScript-specifika verktyg tittar på sin del av systemet medan SMART TS XL ser helheten.

Bygga rätt stack

Inget enskilt verktyg täcker alla kvalitetsdimensioner för TypeScript. Rätt metod är skiktad, där varje lager riktar sig mot en distinkt problemklass:

Minsta möjliga stack (nytt projekt, litet team):

• TypeScript strikt läge
• ESLint med Typescript-eslint async-regler
• npm audit för beroendesårbarheter

Produktionsapplikationsstack (medelstort team, säkerhetsmedvetet):

• Allt ovan, plus:
• Biom eller Vackrare för formatering
• Semgrep för säkerhets-SAST
• Knip för död kod
• SonarCloud för kvalitetsöverblick över trender

Enterprise / monorepo-stack (stort team, arkitektoniska begränsningar):

• Allt ovan, plus:
• Dependency-Cruiser för modulgränstillämpning
• Nx för optimering av påverkad byggprocess från monorepo
• Deptrac för validering av lagergränser
• SonarQube (egenhostad) för lokala kvalitetsportar

Polyglot företagsstack (TypeScript tillsammans med äldre system):

• Allt ovan, plus:
• SMART TS XL för språkövergripande konsekvensanalys och beroendekartläggning