TypeScript 7 foi reescrito em Go: o que muda no seu build e o que continua igual

O que aconteceu

A Microsoft anunciou em março de 2025 que estava portando o compilador do TypeScript para Go. O resultado saiu como TypeScript 7.0 em 8 de julho de 2026, depois de um RC em junho.

O número que circulou em todo lugar: o type-check da base de código do VS Code caiu de cerca de 125 segundos no TypeScript 6 para pouco mais de 10 segundos no 7 — quase 12x. Nos projetos em geral, a Microsoft descreve o ganho como algo entre 8x e 12x em builds completos, vindo de três lugares: código nativo, multithreading com memória compartilhada e otimizações novas que o runtime anterior não permitia.

O detalhe que mais importa: é um port, não uma reescrita

Essa distinção parece semântica, mas é a coisa mais relevante do lançamento. A equipe portou o compilador linha a linha, preservando a semântica de type-check. Isso significa que o mesmo código que compilava antes compila agora, com os mesmos erros e os mesmos tipos inferidos.

Se fosse uma reescrita, o risco de migração seria alto: comportamento sutilmente diferente em inferência genérica é o tipo de coisa que quebra um projeto grande de formas difíceis de rastrear. Sendo um port, o risco muda de lugar — sai do seu código e vai para o ecossistema ao redor do compilador.

Onde a migração realmente trava

O bloqueio prático não é o seu tsconfig.json. É quem depende da API programática do compilador:

• Regras de ESLint com type information (@typescript-eslint com parserOptions.project).
• Geradores de código e transformers que carregam o compilador como biblioteca.
• Ferramentas de build e frameworks que instrumentam o processo de type-check.

A API programática estável não veio no 7.0 — ela está prevista para o 7.1. Enquanto isso, qualquer ferramenta que importe o compilador como módulo precisa de uma versão adaptada. Antes de agendar a migração, o inventário certo não é "quais features eu uso", é "quais pacotes do meu projeto falam com o compilador por dentro".

Uma estratégia de migração sem drama

O caminho de menor risco é rodar os dois em paralelo por um tempo:

1. Mantenha o tsc atual como fonte da verdade no CI — é ele que reprova o PR.
2. Adicione um job paralelo rodando o compilador nativo, marcado como não bloqueante.
3. Compare a saída dos dois durante algumas semanas de trabalho real, não só num commit isolado.
4. Quando o job paralelo ficar limpo e as ferramentas dependentes tiverem suporte, inverta: o nativo passa a bloquear e o antigo vira o paralelo.
5. Só depois remova o antigo.

Esse roteiro custa alguns minutos de CI por PR e elimina praticamente todo o risco da troca.

O que o ganho de velocidade realmente compra

Vale calibrar a expectativa. O salto é no type-check, não necessariamente no seu tempo total de build. Se o gargalo do seu pipeline é bundling, testes ou deploy, um type-check 10x mais rápido melhora o número, mas não muda a sua vida.

Onde a diferença é sentida de verdade é no editor. Type-check rápido significa autocomplete que não trava, "ir para definição" instantâneo em monorepo grande e feedback de erro enquanto você ainda lembra o que estava pensando. Isso não aparece em nenhuma métrica de pipeline — e é, de longe, o maior ganho do lançamento.

O que fazer esta semana

Se o seu projeto é pequeno e as dependências são poucas, testar o compilador nativo localmente leva dez minutos e provavelmente já funciona. Se você mantém um monorepo com lint tipado e geração de código, o trabalho útil agora é levantar quais ferramentas dependem da API do compilador e acompanhar o suporte delas. Migrar cedo demais nesse cenário troca dez segundos de build por uma tarde de depuração de tooling.