TypeScript 7.0 chegou: a reescrita em Go que deixa o compilador até 10x mais rápido

Published on: 2026-07-09

pt typescript javascript go microsoft compilador web frontend devtools performance

Em 8 de julho de 2026, a Microsoft lançou oficialmente o TypeScript 7.0 — e ele não é só mais uma versão. É o resultado de reescrever todo o compilador e o serviço de linguagem em Go, a chamada porta nativa. O motivo é um só: velocidade. Nos testes da própria Microsoft, a compilação ficou entre 7 e quase 12 vezes mais rápida, e o editor abre projetos grandes num piscar de olhos.

Este artigo explica, em detalhe, o que mudou, os números reais, o que quebra ao migrar e como testar hoje — sem drama e sem hype.

O que é o TypeScript 7.0 (a reescrita em Go)

O tsc antigo era escrito em TypeScript (ou seja, rodava como JavaScript, sobre um motor JS). Isso trazia um teto: o modelo era praticamente single-thread, então, mesmo numa máquina com vários núcleos, não havia um jeito limpo de paralelizar a checagem de tipos num projeto grande.

A solução foi portar o compilador para Go, uma linguagem compilada e com concorrência nativa. O time manteve compatibilidade estrutural e lógica com o código original — ou seja, as mesmas regras de tipo, o mesmo comportamento —, mas agora rodando como código nativo e capaz de usar vários núcleos. É a mesma linguagem TypeScript; o que mudou é a máquina por baixo.

Os números: quão mais rápido?

Os tempos de compilação divulgados pela Microsoft (TypeScript 7.0 comparado ao 6.x) falam por si:

VS Code: 125,7s → 10,6s (11,9x mais rápido);
Sentry: 139,8s → 15,7s (8,9x);
Bluesky: 24,3s → 2,8s (8,7x);
Playwright: 12,8s → 1,47s (8,7x);
Tldraw: 11,2s → 1,46s (7,7x).

Não é só CPU. O uso de memória também caiu (VS Code −18%, de 5,2GB para 4,2GB; Bluesky −26%; Playwright −11%). E no editor a diferença é a que mais se sente no dia a dia: abrir um arquivo com erros no VS Code caiu de 17,5s para menos de 1,3s — cerca de 13x mais rápido.

O que isso muda no dia a dia

Velocidade de compilador não é vaidade de benchmark: ela encurta o ciclo de feedback e barateia o CI. Alguns resultados reais citados no anúncio:

Slack: eliminou 40% do tempo de fila de merge e reduziu a checagem de tipos no CI de 7,5 min para 1,25 min;
Vanta: builds até 9x mais rápidos;
Microsoft News Services: economia de 400 horas por mês em builds de CI.

Como testar hoje

A instalação é a de sempre — o pacote typescript no npm agora aponta para o compilador nativo:

# instala o TypeScript 7.0 no projeto
npm install -D typescript

# compila com o novo tsc nativo
npx tsc

No VS Code, por enquanto, o suporte vem por uma extensão dedicada (“TypeScript 7”) na marketplace — o suporte nativo do editor está a caminho. No Visual Studio, ele é ativado automaticamente conforme o projeto. Por baixo, o serviço de linguagem agora fala LSP (Language Server Protocol), o padrão que qualquer editor moderno entende.

Paralelismo: as flags novas

Como o compilador nativo finalmente usa vários núcleos, surgiram controles novos:

# nº de workers de checagem de tipos (padrão 4; ainda experimental)
npx tsc --checkers 8

# paraleliza a build de project references
npx tsc --builders 4

# desliga toda a paralelização (comportamento serial)
npx tsc --singleThreaded

O observador de arquivos (file watching) também foi refeito, com uma porta em Go do watcher do Parcel no lugar da abordagem antiga baseada em polling — mais estável entre sistemas operacionais.

Breaking changes: o que muda na configuração

Aqui mora a parte que exige atenção. O plano anunciado foi: o TypeScript 6.0 serviu de transição, marcando como obsoletas (deprecated) várias opções antigas; o 7.0 transforma boa parte dessas obsolescências em erro. As mudanças mais relevantes:

Novos padrões:

strict agora é true por padrão;
module passa a ser esnext por padrão;
target passa a ser, por padrão, a versão estável mais recente do ECMAScript;
stableTypeOrdering é true e não pode ser desligado.

Removidos (viraram erro):

target: es5 não é mais suportado (o piso agora é ES2015);
moduleResolution: node/node10 foram removidos — a recomendação é nodenext ou bundler;
os formatos de módulo amd, umd e systemjs saíram;
baseUrl foi removido — use paths relativos à raiz do projeto.

Na prática, o ajuste no tsconfig.json costuma ser pequeno:

{
  "compilerOptions": {
    // "target": "es5" foi removido; use es2015 ou superior
    "target": "es2020",
    // "moduleResolution": "node" saiu; prefira "nodenext" ou "bundler"
    "moduleResolution": "nodenext",
    // "baseUrl" removido; troque por paths relativos à raiz
    "paths": { "@/*": ["./src/*"] }
  }
}

Compatibilidade: rodando o 6 e o 7 lado a lado

Nem tudo migra de imediato — e a Microsoft já previu isso. Dá para instalar o compilador antigo (baseado em JavaScript, com a API completa) ao lado do novo, por um pacote com alias:

# mantém o TypeScript 6 disponível lado a lado (para ferramentas que dependem da API)
npm install -D typescript@npm:@typescript/typescript6

A estratégia recomendada é rodar os dois: mover build e checagem de tipos para o compilador nativo (rápido) e deixar as ferramentas que dependem da API do compilador antigo no binário legado, até que a nova API amadureça.

O ponto de atenção: linguagens incorporadas

Se o seu projeto usa Vue, Svelte, Astro, MDX ou templates do Angular, segure a migração dessas partes. Essas ferramentas dependem de uma API programática estável do compilador para entender o TypeScript embutido nos arquivos — e essa API ainda não está pronta no 7.0. O suporte é esperado para o TypeScript 7.1. Até lá, essas ferramentas continuam no compilador 6.

Confiabilidade: não é só velocidade

A reescrita também foi acompanhada de ganhos de estabilidade no serviço de linguagem: segundo a Microsoft, houve 80% menos comandos falhos e 60% menos travamentos em relação ao 6.0. O 7.0 foi testado em produção com empresas como Slack, Figma, Google, Linear, Notion, Sentry, Vercel, Vanta e vários times internos da Microsoft (Teams, Xbox, PowerBI, entre outros).

Como migrar sem susto

Atualize o pacote e rode o novo tsc no CI em paralelo ao fluxo atual, só para comparar resultados antes de trocar de vez.
Ajuste o tsconfig: revise target, moduleResolution e baseUrl — são as remoções que mais aparecem.
Ligue o strict com calma se o projeto ainda não usava: pode revelar erros reais que estavam escondidos.
Mantenha o typescript6 lado a lado enquanto suas ferramentas de build dependerem da API antiga.
Não migre ainda as partes com Vue/Svelte/Astro/MDX/Angular — espere o 7.1.

Linha do tempo

O 6.0 foi a ponte (marcou as obsolescências); o 7.0 chegou em 8 de julho de 2026 com o compilador nativo; e o 7.1 é esperado para trazer a nova API programática (destravando as linguagens incorporadas) e retomar o desenvolvimento de novos recursos, num ciclo de lançamentos a cada 3 a 4 meses.

Conclusão

O TypeScript 7.0 não inventa sintaxe nova — ele ataca a maior dor de quem trabalha com projetos grandes: o tempo. Compilação e editor várias vezes mais rápidos, menos memória e CI mais barato são ganhos que se sentem no primeiro dia. O cuidado fica por conta das breaking changes de configuração e das ferramentas de linguagem incorporada, que ainda esperam o 7.1. Para a maioria dos projetos, dá para testar hoje — de preferência em paralelo — e já colher a velocidade. 🚀

Referências

Microsoft — Announcing TypeScript 7.0 (anúncio oficial)
Visual Studio Magazine — TypeScript 7 Arrives to Rock VS Code with Go-Powered Speed
Neowin — Microsoft releases TypeScript 7.0, and it’s 10x faster

← Back to blog