O sistema de tipos do TypeScript detecta uma classe significativa de erros antes da execução do código, como incompatibilidades de tipos, propriedades ausentes e assinaturas de funções incorretas. No entanto, ele não detecta todo o resto: vulnerabilidades de segurança que dependem do fluxo de dados na aplicação, violações arquiteturais que se acumulam ao longo do tempo à medida que os limites da equipe se tornam menos definidos, exportações obsoletas que permanecem no código-fonte muito tempo depois da remoção de seus chamadores e erros de programação assíncrona que compilam corretamente, mas falham sob condições específicas de execução. Ferramentas de análise estática preenchem essas lacunas, e a escolha da combinação certa depende do que você está tentando encontrar.
Este guia aborda as ferramentas essenciais para equipes TypeScript em 2026: a camada de linting (ESLint com typescript-eslint, Biome, OxcLint), a camada de segurança (Semgrep, Snyk Code, SonarQube), a camada arquitetural (Dependency-Cruiser, Deptrac, Nx), a camada de código morto (Knip) e a camada de análise profunda (ts-morph, o próprio compilador TypeScript). Para cada uma, o foco é em sua funcionalidade, como configurá-la e quando ela não é a ferramenta adequada para a tarefa.
Construído para bases de código que ninguém entende.
SMART TS XL detecta automaticamente alterações que causam incompatibilidade em toda a sua base de código.
Saber maisFerramentas de análise estática do TypeScript: tabela comparativa
Antes de analisarmos as ferramentas individualmente, a tabela abaixo relaciona cada ferramenta à sua função principal, adequação à CI e caso de uso ideal. Nenhuma ferramenta sozinha abrange todas as dimensões; uma análise eficaz da qualidade do TypeScript requer a combinação de várias ferramentas.
| ferramenta | Função primária | CI Adequado | Custo | Mais Adequada Para |
|---|---|---|---|---|
| ESLint + typescript-eslint | Linting, estilo, regras de reconhecimento de tipo | Sim | Gratuito | Convenções de toda a equipe, segurança de tipos assíncronos |
| Biome | Análise e formatação | Sim | Gratuito | Substituição do ESLint + Prettier, velocidade |
| OxcLint | Análise de erros (compatível com ESLint) | Sim | Gratuito | Monorepos que precisam de tempos de lint rápidos |
| Compilador TypeScript (tsc) | Verificação de tipo | Sim | Gratuito | Erros de digitação, aplicação do modo estrito |
| Semgrep | SAST, padrões personalizados | Sim | Gratuito + pago | Análise de segurança, regras personalizadas da organização |
| Código Snyk | SAST, segurança de dependências | Sim | Gratuito + pago | Equipes com foco em segurança, integração de IDE |
| SonarQube / SonarCloud | Portões de qualidade, monitoramento de tendências | Sim | Gratuito + pago | Painéis de controle de qualidade empresarial |
| SonarLintName | Feedback de qualidade no nível do IDE | Somente IDE | Gratuito | Dicas de segurança e qualidade embutidas |
| Cruzeiro de Dependência | Imposição de grafo de dependência | Sim | Gratuito | Validação de regras arquitetônicas |
| Deptrac | imposição de limites de camada | Sim | Gratuito | Arquitetura limpa, limites DDD |
| Nx | Gerenciamento de dependências Monorepo | Sim | Gratuito + pago | limites do módulo Monorepo |
| Corte | Código morto e exportações não utilizadas | Sim | Gratuito | Reduzir o código não utilizado em grande escala |
| ts-morfo | Análise programática de TS AST | Seletivo | Gratuito | Análise personalizada, codemods, ferramentas |
Camada 1: Remoção de fiapos e estilização
ESLint com typescript-eslint
O ESLint continua sendo a base da análise estática de código em TypeScript. Com o typescript-eslint O pacote obtém acesso às informações de tipo do TypeScript e pode impor regras que exigem contexto de tipo, sendo as mais valiosas as regras específicas para async que detectam erros comuns em Promises.
bater
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",
},
}
);As quatro regras assíncronas acima são o recurso adicional de maior valor que o typescript-eslint oferece em relação ao ESLint puro. Elas detectam: Promises não tratadas (promises flutuantes), await aplicado a valores que não são Promises, Promises passadas para callbacks que esperam funções síncronas e funções assíncronas que nunca usam awaitEsses são padrões que compilam sem erros, mas que produzem falhas em tempo de execução sob condições específicas.
O que o ESLint não consegue fazer : análise de fluxo de dados entre arquivos, imposição de limites arquitetônicos, rastreamento de contaminação de segurança ou detecção de exportações inativas. Para essas tarefas, são necessárias as outras camadas abaixo.
Biome: O ESLint moderno + substituto mais bonito
O Biome substitui o ESLint e o Prettier por um único binário baseado em Rust que roda de 25 a 35 vezes mais rápido. Ele suporta JavaScript, TypeScript, JSX e JSON. Para novos projetos ou equipes frustradas com a complexidade dos plugins do ESLint e o baixo desempenho em grandes bases de código, o Biome é a alternativa moderna mais robusta.
bater
npm install --save-dev --save-exact @biomejs/biome
npx @biomejs/biome initbater
# 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/O ecossistema de plugins do Biome é menor que o do ESLint, o que é importante para equipes com muitas regras personalizadas ou plugins específicos de frameworks. Para equipes que usam apenas as regras principais do ESLint e a formatação do Prettier, o Biome oferece cobertura equivalente em uma fração do tempo de execução.
OxcLint: Compatibilidade com ESLint priorizando a velocidade
O OxcLint (parte do projeto Oxc) executa regras compatíveis com o ESLint de 50 a 100 vezes mais rápido. Ele não substitui todo o ecossistema ESLint, mas serve como a opção mais rápida para pipelines de CI onde o tempo de lintagem é um gargalo.
bater
npm install --save-dev oxlint
npx oxlint src/O OxcLint é a escolha certa para grandes monorepos onde o ESLint padrão leva minutos e a latência do feedback reduz a qualidade dos pull requests. Ele funciona melhor em conjunto com o ESLint, em vez de substituí-lo; use o OxcLint para obter feedback rápido e o ESLint para garantir a cobertura completa das regras na etapa de pré-merge.
Camada 2: Verificação de Tipos, o Compilador TypeScript
O compilador TypeScript (tscO `npm run build` não é apenas uma ferramenta de compilação, mas sim o principal mecanismo de análise estática para correção de tipos. Habilitar o modo estrito ativa as configurações que detectam a maioria dos erros do mundo real:
json
{
"compilerOptions": {
"strict": true,
"noUnusedLocals": true,
"noUnusedParameters": true,
"noImplicitReturns": true,
"noFallthroughCasesInSwitch": true,
"exactOptionalPropertyTypes": true,
"useUnknownInCatchVariables": true
}
}bater
# Type-check only, no emit -- ideal for CI
npx tsc --noEmitnoUnusedLocals e noUnusedParameters No nível do compilador, capturar variáveis e parâmetros de função não utilizados. useUnknownInCatchVariables (TypeScript 4.4+) tipos capturaram exceções como unknown em vez de any, forçando o estreitamento explícito do tipo antes do uso.
Análise do fluxo de controle do TypeScript é uma funcionalidade integrada que o compilador fornece para restringir tipos dentro de ramificações condicionais. Não é uma ferramenta separada, habilitando strict O modo garante que seja aplicado com total rigor. A análise de fluxo de controle do compilador compreende as proteções de tipo. typeof Verificações, instanceofe padrões sindicais discriminatórios.
A limitação do tsc : o compilador TypeScript não encontra vulnerabilidades de segurança, violações de limites arquitetônicos ou exportações inválidas. Ele encontra erros de tipo, e o faz de forma definitiva.
Camada 3: Segurança, SAST para TypeScript
Semgrep: Varredura de segurança baseada em padrões
O Semgrep encontra vulnerabilidades de segurança através da correspondência de padrões de código. Para TypeScript, ele pode detectar injeção de SQL, XSS, credenciais embutidas no código e código inseguro. eval Uso inadequado, poluição de protótipos e configurações inseguras do Express.js são padrões que compilam corretamente, mas introduzem vulnerabilidades exploráveis.
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: ERRORbater
# Run with the community TypeScript security rules
semgrep scan --config=p/typescript --config=p/owasp-top-ten src/O Semgrep complementa o ESLint, não compete com ele. O ESLint impõe convenções; o Semgrep encontra antipadrões de segurança. A maioria das equipes de TypeScript que se preocupam com segurança deve usar ambos.
Snyk Code: SAST baseado em aprendizado de máquina com integração de IDE
O Snyk Code realiza SAST com um mecanismo de análise baseado em aprendizado de máquina que rastreia fluxos de contaminação em arquivos. Ele se integra ao VS Code e aos IDEs da JetBrains, exibindo as descobertas diretamente no código enquanto os desenvolvedores escrevem, em vez de esperar por uma execução de CI.
bater
npm install --save-dev snyk
npx snyk auth
npx snyk code testO foco do Snyk Code na experiência do desenvolvedor, o feedback direto no IDE, as sugestões de correção junto com cada descoberta e os exemplos de remediação fazem dele a melhor escolha quando a educação em segurança é tão importante quanto a detecção de vulnerabilidades.
SonarQube e SonarLint: Portões de Qualidade e Monitoramento de Tendências
O SonarQube oferece análise contínua da qualidade do código com um painel de controle, acompanhamento de tendências e personalização de pull requests. Para TypeScript, ele detecta bugs, problemas de código, vulnerabilidades de segurança e duplicações. O SonarLint é a extensão para IDE que exibe as regras do SonarQube localmente.
Para equipes TypeScript, o SonarCloud (a versão hospedada na nuvem) é o caminho mais simples: gratuito para repositórios públicos, com integração de CI por meio do GitHub Actions ou GitLab CI em minutos.
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 }}O principal diferencial do SonarQube em relação à análise estática de código (linting) tradicional é seu modelo de tendências: como a qualidade do código evolui ao longo do tempo, quais componentes estão se deteriorando e qual é a pontuação de qualidade do novo código para cada solicitação de pull request. Essas métricas voltadas para a gestão são o que o SonarQube faz que o ESLint e o Semgrep não conseguem.
Camada 4: Análise Arquitetônica
Dependency-Cruiser: Impor regras de limite de módulo
O Dependency-Cruiser valida se o seu grafo de importação segue as regras arquiteturais definidas. Ele gera grafos de dependência visuais e interrompe a integração contínua (CI) quando o código viola as restrições de limites de módulo.
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))" },
},
],
};bater
npx depcruise --validate .dependency-cruiser.cjs src/O Dependency-Cruiser responde diretamente às consultas "ferramenta CLI de análise de dependências React" nos dados do Search Console, sendo a ferramenta padrão para gerar e validar gráficos de dependências em projetos TypeScript/React.
Deptrac: Aplicação de Limites Baseada em Camadas
O Deptrac impõe camadas arquitetônicas, garantindo que o código de persistência não possa importar do código de apresentação, que os objetos de domínio não dependam da infraestrutura e que os limites dos módulos sejam respeitados em toda a base de código.
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
- DomainO Deptrac é mais valioso em projetos que seguem os padrões de Arquitetura Limpa, DDD ou Arquitetura Hexagonal, onde o isolamento de camadas é uma restrição de projeto, e não apenas uma preferência.
Nx: Gerenciamento de Dependências em Nível de Monorepo
Para monorepos TypeScript, o Nx oferece imposição de limites de módulo, detecção de builds afetados e visualização do gráfico de dependências em todos os projetos do repositório.
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 Os comandos executam apenas os testes e a verificação de código relevantes para os módulos alterados, reduzindo significativamente o tempo de CI em grandes monorepos.
Camada 5: Detecção de código morto
Knipe: Encontre exportações, arquivos e dependências não utilizados
O Knip analisa o gráfico completo do módulo para identificar exportações não utilizadas, arquivos não utilizados e recursos não utilizados. package.json dependências, a classe de acumulação de código que o ESLint no-unused-vars Não consegue capturar porque só procura dentro de um arquivo.
bater
npm install --save-dev knip
npx knipjson
// knip.json
{
"entry": ["src/index.ts", "src/**/*.test.ts"],
"project": ["src/**/*.ts"],
"ignore": ["src/generated/**"],
"ignoreDependencies": ["vitest"]
}O Knip é pesquisado diretamente nos dados do SC como “detecção de código morto, exportações não utilizadas, javascript, typescript”. É a ferramenta mais completa atualmente para identificação de código morto em nível de módulo em projetos TypeScript.
Camada 6: Análise Programática, ts-morph
ts-morph é um wrapper da API do compilador TypeScript que facilita a escrita de análises personalizadas, codemods e ferramentas para a AST do TypeScript. Ele pode ser encontrado diretamente nos dados do Service Worker como “ts-morph” e “ts morph”.
datilografado
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);O ts-morph não é uma ferramenta de análise pronta para uso, mas sim a biblioteca que você utiliza para criar uma. É adequado para equipes que precisam de análises personalizadas que vão além do que as ferramentas existentes oferecem: scripts de migração, validadores arquiteturais personalizados, refatoração automatizada ou pipelines de geração de código.
Análise Estática de Async/Await em TypeScript
Os dados do Search Console mostram um agrupamento específico de consultas em torno de “typescript static analysis async await paper tool” e “typescript static analysis async await vulnerability paper tool”. Essas consultas refletem profissionais buscando ferramentas que entendam erros de programação assíncrona no nível do tipo.
A resposta prática para equipes de TypeScript em produção são as quatro regras específicas para async do typescript-eslint (no-floating-promises, await-thenable, no-misused-promises, require-await) combinado com strictNullChecks e useUnknownInCatchVariablesEm conjunto, essas ferramentas detectam os erros de tipo assíncrono mais comuns sem exigir ferramentas de pesquisa acadêmica.
Para equipes que realizam pesquisas de segurança sobre padrões de vulnerabilidade assíncrona, o TAJS e o Jelly são analisadores estáticos acadêmicos que modelam a semântica de execução assíncrona do JavaScript, mas são ferramentas de pesquisa, não ferramentas de desenvolvimento para produção.
Angular e React: Análise Estática Específica de Cada Framework
Para equipes Angular, @angular-eslint Fornece regras de linting específicas para Angular, abrangendo padrões de componentes, análise de templates e injeção de serviços. Integra-se com a configuração ESLint + typescript-eslint acima.
Para equipes React, eslint-plugin-react, eslint-plugin-react-hooks e eslint-plugin-jsx-a11y Os plugins abrangem padrões específicos do React. O Dependency-Cruiser lida com a análise do grafo de dependências específico do React e é a ferramenta por trás das consultas "react dependency analysis cli tool" nos dados do Service Cruise.
Integração com IDEs: Ferramentas para VS Code e JetBrains
As buscas por “melhores ferramentas de qualidade de código para integração com o VS Code” e “melhores ferramentas de qualidade de código para integração com IDEs” refletem uma necessidade real: o feedback da CI chega tarde demais para alterar o comportamento. A análise integrada à IDE proporciona o ciclo de feedback mais eficiente.
VS Code : extensão ESLint com paridade com o Clippy e o rust-analyzer, extensão SonarLint para regras SonarQube embutidas, extensão Snyk para descobertas de segurança e o serviço de linguagem TypeScript integrado para feedback em nível de tipo.
JetBrains (WebStorm/IntelliJ) : O WebStorm vem com suporte integrado para TypeScript, que exibe erros de tipo diretamente no código, além de integração com ESLint, Prettier e SonarLint. O sistema de inspeção integrado abrange muitos dos mesmos padrões das regras do ESLint.
Configuração do VS Code para máxima cobertura de análise estática do 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"
}
}Como SMART TS XL Amplia a análise do TypeScript em toda a empresa.
As ferramentas acima abrangem o TypeScript dentro de um projeto TypeScript. Em organizações onde os serviços TypeScript interagem com programas em lote COBOL, APIs Java, pipelines de dados Python ou sistemas mainframe legados, ferramentas de linguagem única não conseguem enxergar as dependências que ultrapassam as fronteiras de linguagem.
SMART TS XL'S análise de código estático Abrange o TypeScript juntamente com todas as outras linguagens no ambiente corporativo, COBOL, JCL, Java, Python, RPG, SQL, e constrói um modelo de dependência unificado entre todas elas. Quando um serviço TypeScript chama uma API que é suportada por um programa COBOL, SMART TS XL pode rastrear essa relação e incluí-la em análise de impacto antes de qualquer alteração ser feita em qualquer um dos componentes.
A funcionalidade de busca corporativa torna todo o código-fonte multilíngue pesquisável: encontre cada importação TypeScript de um módulo específico, cada método Java que um serviço TypeScript chama, cada copybook COBOL que alimenta dados para uma API consumida por TypeScript, em segundos, em milhões de linhas de código em qualquer combinação de linguagens.
Para equipes corporativas que utilizam TypeScript como uma linguagem em um portfólio maior, SMART TS XL proporciona visibilidade arquitetônica e comunicação interlinguística mapeamento de dependência isso faz com que as ferramentas específicas do TypeScript examinem sua parte do sistema enquanto SMART TS XL vê o todo.
Construindo a pilha certa
Nenhuma ferramenta isolada abrange todas as dimensões de qualidade para TypeScript. A abordagem correta é em camadas, com cada camada visando uma classe distinta de problemas:
Conjunto mínimo de elementos viáveis (novo projeto, equipe pequena):
- Modo estrito do TypeScript
- ESLint com regras assíncronas do typescript-eslint
npm auditpara vulnerabilidades de dependência
Conjunto de aplicações de produção (equipe média, com foco em segurança):
- Tudo acima, além de:
- Biome ou Prettier para formatação
- Semgrep para segurança SAST
- Recorte para código morto
- SonarCloud para visibilidade de tendências de qualidade
Arquitetura empresarial/monorepo (equipe grande, restrições arquitetônicas):
- Tudo acima, além de:
- Dependency-Cruiser para aplicação de limites de módulo
- Nx para otimização de builds afetados por monorepo
- Deptrac para validação de limites de camadas
- SonarQube (hospedado localmente) para verificações de qualidade em infraestrutura própria
Pilha empresarial poliglota (TypeScript em conjunto com sistemas legados):
- Tudo acima, além de:
- SMART TS XL para análise de impacto entre idiomas e mapeamento de dependências
