tsgolint chega ao v7 estável e leva linting type-aware em Go para o Oxlint

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

Quem 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 timings

Assim 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.

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

seguindo 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