TypeScript 7: compilador em Go é 10x mais rápido, mas a migração trava é nas ferramentas

TypeScript 7: compilador em Go é 10x mais rápido, mas a migração trava nas ferramentas

O TypeScript 7.0 saiu em 8 de julho de 2026 com uma promessa difícil de ignorar: o compilador reescrito em Go entrega build de 8 a 12 vezes mais rápido, com a mesma lógica de checagem de tipos da versão anterior. Seis meses depois, o número que aparece na prática é menor, mas continua relevante — em relatos de migração, a checagem do próprio projeto caiu para uma fração do tempo anterior.

O problema é que a velocidade não foi o único efeito da reescrita. Ao portar o compilador, a equipe da Microsoft deixou a API programática de fora do 7.0. Toda ferramenta que importava o typescript para inspecionar a AST — linter, loader, plugin de bundler, gerador de código, framework com compilador próprio — ficou presa na 6.x por três meses. Em 20 de outubro, a 7.1 Beta trouxe essa API de volta, reorganizada em entry points separados, mais um recurso novo chamado content mappers .

Traduzindo: o ganho de performance é real e o custo de adoção não está no seu código de aplicação, está na ferramentaria em volta dele. É isso que este texto destrincha.

O que mudou de fato no componente que roda no seu terminal

O pacote continua se chamando typescript e o binário continua sendo tsc — o executável tsgo aparece em pacote de preview. A diferença é onde o trabalho acontece: um binário nativo, com paralelismo no checker e no project builder, em vez do JavaScript interpretado de antes.

Fato: a estrutura do checker é a mesma da 6.0, o que reduz o risco de divergência semântica. Avaliação: o risco de diferença de comportamento existe, mas é bem menor do que um "compilador novo" sugere.

O que pega de verdade são mudanças de default que vinham sendo anunciadas desde a 6.0 e viraram obrigatórias agora:

Na prática, types: [] por padrão é o que mais gera erro nos primeiros minutos: globais de @types/jest , @types/node ou de libs que dependiam de carregamento automático simplesmente somem do programa. A correção é declarativa e barata, mas precisa ser feita arquivo por arquivo, não dá para confiar em skipLibCheck .

A API sumiu — e é aí que o cronograma escorrega

Se a sua aplicação é só código de negócio, a 7.0 provavelmente compila. O problema aparece quando algum item da lista abaixo está no package.json :

typescript-eslint e pacotes que dependem dele

ts-node e carregadores equivalentes

ts-jest

geradores de código que leem a AST ( graphql-codegen , geradores de clientes OpenAPI)

ts-patch e transformadores customizados

tooling de framework com compilador próprio (Angular, Vue, Svelte)

Essas ferramentas importam typescript para ler a árvore sintática. Sem API, elas não instalam ou quebram em runtime. O caminho de meio termo que a comunidade validou é o toolchain dividido: 7 no tsc de CI, 6 nas ferramentas.

O ponto de atenção: dois compiladores no repositório exigem disciplina de versão. @typescript/typescript6 é um alias — quem importar typescript recebe a 7. Se a ferramenta não aceitar caminho alternativo, é preciso resolver o import explicitamente ou aceitar ficar na 6 até a versão estável da 7.1.

7.1: API de volta, entry points separados e arquivos não-padrão

A 7.1 Beta (anunciada em 20 de outubro por Daniel Rosenwasser) não é só "o que faltava". A API voltou reorganizada em pontos de entrada independentes, e o recurso mais interessante é o content mapper : um ponto de plug-in que permite ao TypeScript entender arquivos que embutem TypeScript dentro de outro formato — .vue , .svelte , .astro , .mdx — e mapear o erro para a linha certa do arquivo original.

Resultado reportado: um projeto Vue que levava 14,19 s na checagem passou a 3,10 s. O Vue Language Tools v4 alpha já usa content mappers no lugar do vue-tsc . Ainda há uma issue aberta no editor, então o ganho no terminal veio antes do ganho na IDE — o que muda a ordem da migração: CI primeiro, experiência de edição depois.

O caso Angular mostra o tamanho da conta

O Angular foi o exemplo mais claro do custo real. O compilador ngc dependia do Transformer API que a 7.0 removeu. A saída não foi adaptar: foi reescrever a fase de análise. O ngp , Angular Preprocessor, em beta desde 10–11 de novembro, move a análise para Rust sobre o Oxc — a mesma base do Vite —, separa a análise do framework da API do TypeScript e deixa a emissão de código com o compilador de templates existente.

Números do anúncio: builds frios de 2 a 3 vezes mais rápidos e pico de memória caindo de cerca de 2,8 GB para 1,4 GB. A adoção está prevista para uma minor do Angular 22, e o time recomenda ngc em produção por enquanto.

A lição vale para qualquer stack: se você mantém transformador customizado, plugin de build ou gerador que atravessa a AST do TypeScript, essa conta chega. Em times que sustentam bases grandes e múltiplos produtos, como os que a Maquinaweb atende com Python, Node.js, .NET e Angular, o trabalho de migração quase nunca está no código de aplicação — está em mapear quem consome o compilador e em que versão.

Riscos e armadilhas que passam batido

Concluir a migração cedo demais. tsc ficou rápido; o pipeline inteiro pode ter ficado mais lento se o lint rodou em dois processos. Meça o job de CI completo, não só o passo de type-check.

Monorepo com project references . É o cenário onde o paralelismo do builder nativo mais muda comportamento. Rode tsc --build --force antes de confiar no incremental.

Emissão de declarações em bibliotecas internas. Se você publica pacote com .d.ts , compare o output antes e depois. Divergência de declaração quebra consumidor, não o seu build.

Custom transformers. ts-patch / ttypescript dependem de API removida. Se o build usa isso para injetar código, é bloqueio duro, não atrito.

Rodar 6 e 7 no mesmo processo. Carregar as duas versões no mesmo node_modules funciona; misturar imports no mesmo script não.

Timing de calendário. A 7.1 está em beta com RC previsto "em cerca de um mês" segundo o time. Migrar no meio de um ciclo de release trava rollback.

Recomendação prática

Separe a migração em duas fases com critérios objetivos. Fase 1, só CI: instalar a 7, corrigir tsconfig ( types , strict , moduleDetection ), manter 6 via alias para lint, teste e geradores, e medir o tempo total do job por duas semanas. Fase 2, ferramentaria: trocar ts-node por tsx , migrar ts-jest para o executor nativo do seu runner e reavaliar cada plugin que importa o compilador. Uma semana de trabalho por repositório de porte médio é uma estimativa razoável — menos se o projeto não tem transformador customizado, mais se tem.

Se o seu time está decidindo entre migrar agora, esperar a 7.1 estável ou rever a stack de build, vale conversar com o time da Maquinaweb. Eles ajudam a mapear dependências de ferramentaria, planejar a migração sem parar entregas e, quando o caso é outro, desenvolver o projeto sob medida com a stack que fizer sentido.

Fontes