
O tsgolint, motor de linting type-aware que alimenta o Oxlint, chegou à versão v7 estável. Ele traz para dentro do Oxlint aquelas regras de lint que exigem análise semântica de TypeScript↳TypeScript23 conteúdosTypeScript: ReadonlyArrayDev (Back & Front) · jun 2019Onde usar ANY no TypeScriptDev (Back & Front) · out 2025Tudo sobre o Node rodar TypeScript nativamente!Dev (Back & Front) · jul 2025Ver tudo em Dev (Back & Front) →, as que respondem perguntas como "esse Promise chega a ser aguardado com await?", só que rodando em velocidade nativa de Go em vez de passar pelo ESLint.
Para quem constrói software com TypeScript no dia a dia, a mudança é concreta: o passo mais caro do lint, o type-aware, é justamente o que trava pipeline de CI e deixa o feedback local lento. É esse gargalo que o tsgolint mira.
Como o motor funciona por dentro
A sacada de arquitetura é não reimplementar um type checker. Em vez disso, o tsgolint constrói programas TypeScript reais em cima do typescript-go, o port oficial do compilador em Go que passa a ser distribuído como TypeScript 7.
A divisão de trabalho fica assim:
- O Oxlint, escrito em Rust, cuida da descoberta de arquivos, da configuração e das regras sintáticas baratas (que olham um arquivo isolado).
- O trabalho type-aware é delegado ao binário Go, que devolve diagnósticos estruturados.
O release acompanha o TypeScript v7.0.2 e cobre 59 das 61 regras type-aware do typescript-eslint, ante 43 na alpha de dezembro. O salto direto da linha experimental 0.x para um v7 estável é deliberado: o tsgolint agora é versionado contra o compilador que embute, e a versão v7.0.2000 casa com o TypeScript 7.0.2.
Como colocar pra rodar
São duas linhas para começar:
pnpm add -D oxlint oxlint-tsgolint@7
pnpm oxlint --type-awareQuem quiser ver erros de compilação junto dos diagnósticos de lint, vindos do mesmo programa TypeScript, adiciona --type-check. Os dois flags podem ser fixados num arquivo oxlint.config.ts ou .oxlintrc.json.
O release também traz medição de tempo por regra, exposta com:
oxlint --type-aware --debug timingsAssim dá pra enxergar quais regras type-aware dominam a execução, informação útil quando o objetivo é enxugar o tempo de CI.
Os números que a equipe divulga
Os benchmarks do próprio time colocam o build estável de 12 a 18 vezes mais rápido que o ESLint com typescript-eslint, medidos sobre os repositórios microsoft/vscode, microsoft/typescript, typeorm e vuejs/core, em um Apple M4 Pro.
| Item | Detalhe |
|---|---|
| Regras type-aware cobertas | 59 de 61 (era 43 na alpha) |
| TypeScript alvo | v7.0.2 |
| Ganho de velocidade | 12x a 18x vs. ESLint + typescript-eslint |
| Repos testados | vscode, typescript, typeorm, vuejs/core |
São números da equipe, não medições independentes: vale rodar no seu próprio monorepo antes de prometer ganho para a liderança.
A aposta de longo prazo, e o contraponto
Escrevendo antes do release, Jökull Sólberg avaliou que o caminho escolhido faz sentido estrategicamente:
Oxlint está fazendo a aposta certa de longo prazo, herdando toda otimização futura que o time do TypeScript enviar, enquanto mantém a superfície de regras idêntica à do typescript-eslint.
Jökull Sólberg
O mesmo argumento aparece em uma discussão sobre o Biome adotar ou não o typescript-go. O Biome v2 sintetiza os próprios tipos sem o compilador, e uma análise coloca sua regra noFloatingPromises em torno de 75% dos casos que o typescript-eslint pega, lacuna que o criador do Vite, Evan You, já questionou publicamente.
O ponto de fundo é filosófico e prático: reaproveitar o compilador oficial (caminho do tsgolint) versus reimplementar a inferência de tipos (caminho do Biome). O primeiro herda correção e otimizações de graça, mas amarra a ferramenta às exigências do compilador.
O que ainda está em aberto
O release não é isento de arestas. O time do typescript-eslint, cujo contribuidor auvred criou o protótipo original, ainda classifica seu próprio fork do tsgolint como um experimento que "não está sob desenvolvimento ativo". No lado do oxc, a correção ainda está sendo refinada: usuários já reportaram casos como um autofix que removeu uma type assertion que o tsc de fato exigia.
Há também o custo de entrada. O linting type-aware precisa de TypeScript 7.0 ou superior, algumas opções legadas de tsconfig como baseUrl não são suportadas, e projetos que usam recursos removidos no TypeScript 6 precisam migrar antes.
Quem já usa ESLint pode traduzir a config existente com:
npx @oxlint/migrate --type-awareseguindo o guia de migração a partir do ESLint.
O que muda para quem desenvolve no Brasil
O contexto maior é a reescrita do toolchain JavaScript em linguagens nativas, de bundlers e formatadores até o próprio compilador do TypeScript. O Oxlint é o linter do oxc, a suíte de ferramentas em Rust desenvolvida sob a VoidZero, empresa que Evan You fundou para consolidar uma cadeia de ferramentas historicamente fragmentada.
Para times brasileiros que rodam monorepos grandes com CI cronometrado, a promessa é direta: menos minutos de pipeline gastos em lint semântico e feedback local mais rápido. Mas as ressalvas pesam. A cobertura de 59 de 61 regras é alta, porém não é 100%; a correção ainda está amadurecendo; e a dependência de TypeScript 7 pode virar um bloqueio real em bases que arrastam tsconfig antigo.
O caminho mais sensato hoje é experimental: rodar o Oxlint com --type-aware em paralelo ao ESLint atual, comparar os diagnósticos nos seus próprios repositórios e medir o tempo de CI antes de trocar de vez. O foco do time agora está nas regras finais, na integração com editores e na performance em monorepo, os três pontos que decidem se a ferramenta serve para produção no seu contexto.
Fonte: InfoQ
Este artigo foi escrito por Redação iMasters, um agente de inteligência artificial com revisão editorial humana. Publicado sob revisão editorial de Rafael Chinaglia - iMasters e validação técnica de Tiago Baeta. Saiba como produzimos no expediente.








Comentários
Ninguém comentou ainda. Começa a conversa?