Quem trabalha com TypeScript em projetos grandes conhece a dor: abrir o editor, esperar o language server indexar, rodar um tsc --build e ir buscar um café enquanto o compilador processa centenas de milhares de linhas. A Microsoft decidiu atacar esse problema pela raiz. Em vez de otimizar o compilador existente, a equipe optou por reescrevê-lo do zero em Go sob o codinome Project Corsa. O resultado é um compilador que entrega builds até 10x mais rápidos — e que já pode ser testado hoje.

Por que reescrever o compilador do zero

O compilador atual do TypeScript é escrito em TypeScript e roda sobre o Node.js. Isso sempre foi uma decisão pragmática: o time que desenvolve a linguagem usa a própria linguagem, o que facilita contribuições e mantém o dogfooding. Mas essa arquitetura tem um teto de performance.

O Node.js é single-threaded por natureza. O garbage collector do V8 adiciona pausas imprevisíveis. E a representação de objetos em JavaScript consome mais memória do que o equivalente em linguagens com controle explícito de alocação. Para projetos pequenos, nada disso importa. Mas quando o codebase do VS Code — com 1,5 milhão de linhas de TypeScript — leva 78 segundos para compilar, o problema se torna real.

A equipe de TypeScript avaliou por anos alternativas incrementais: paralelismo via workers, caches mais agressivos, lazy loading de módulos. Nenhuma dessas abordagens conseguiu romper a barreira do runtime JavaScript. A reescrita nativa se tornou a única saída para um salto de ordem de grandeza.

Por que Go e não Rust

Quando a Microsoft anunciou a reescrita, a pergunta mais frequente na comunidade foi: por que Go e não Rust? A resposta está na natureza do código existente.

O compilador TypeScript é uma base de código gigante com padrões muito específicos de manipulação de árvores de sintaxe, resolução de tipos e transformação de AST. A estrutura do código — com muitas structs, interfaces implícitas e processamento sequencial de nós — mapeia naturalmente para Go. A equipe estimou que a portabilidade seria significativamente mais direta do que para Rust.

Rust exigiria repensar fundamentalmente a gestão de memória em cada ponto do compilador. O borrow checker, que é uma das maiores forças de Rust para software de sistemas, se tornaria um obstáculo constante num compilador que precisa manter referências cruzadas entre centenas de milhares de nós de AST. Go oferece garbage collection automática com controle fino sobre alocação — um meio-termo que combina performance nativa com produtividade de desenvolvimento.

Além disso, Go compila para binários nativos sem dependência de runtime externo, suporta paralelismo via goroutines de forma trivial e tem um ecossistema maduro para tooling de linha de comando. Para a equipe de TypeScript, que precisava portar centenas de milhares de linhas de código com fidelidade funcional, Go foi a escolha pragmática.

Benchmarks: onde os 10x aparecem de verdade

Os números que a Microsoft divulgou não são teóricos. São medições reais em projetos open source de grande porte.

O caso mais emblemático é o próprio VS Code. O build completo caiu de 78 segundos para 7,5 segundos — um ganho de 10,4x. Mas o VS Code não é um outlier. O Playwright (356 mil linhas) caiu de 11 para 1 segundo — 11x mais rápido. O TypeORM também registrou ganhos na faixa de 10x.

Esses números vêm de três fontes de otimização:

  • Compilação nativa — Go compila para código de máquina, eliminando o overhead do V8 e do Node.js
  • Paralelismo real — O novo compilador usa goroutines para processar múltiplos arquivos simultaneamente, aproveitando todos os cores disponíveis
  • Menor consumo de memória — Structs em Go são alocadas de forma mais eficiente que objetos JavaScript, reduzindo a pressão sobre o garbage collector

Na prática, para um projeto médio de 50-100 mil linhas, a diferença é entre esperar 15 segundos e esperar 1,5 segundo. Para quem usa tsc --watch no desenvolvimento diário, a experiência no editor melhora de forma perceptível.

# Instalar o preview e comparar tempos
npm install -D @typescript/native-preview

# Build com compilador atual
time npx tsc --build

# Build com compilador nativo
time npx tsgo --build

Strict mode por padrão e outras mudanças

O TypeScript 7 não é apenas um compilador mais rápido. A equipe aproveitou a mudança de versão major para ajustar defaults que vinham sendo discutidos há anos.

A mudança mais significativa: strict mode ativado por padrão. Projetos novos criados com TypeScript 7 terão strict: true sem precisar configurar. Para projetos existentes que já usam strict (a maioria dos projetos modernos), nada muda. Para os que não usam, será necessário adicionar strict: false explicitamente no tsconfig.json — ou, melhor ainda, aproveitar a migração para corrigir os erros de tipo pendentes.

Outras mudanças de defaults:

  • module muda para esnext (era commonjs em muitos cenários)
  • target muda para es2025 (acompanhando o padrão ECMAScript atual)
  • rootDir agora aponta para o diretório do tsconfig.json por padrão
  • types passa a ser um array vazio por padrão, em vez de incluir automaticamente todos os pacotes @types/* instalados

Além disso, opções legadas como target ES5 e estratégias antigas de resolução de módulos serão removidas na versão 7.0 final. Se o seu projeto ainda depende de transpilação para ES5, será necessário manter o TypeScript 6.x ou usar um transpilador externo como SWC ou esbuild.

TypeScript 6: a ponte de transição

A Microsoft não vai pular direto do TypeScript 5.x para o 7. O TypeScript 6.0 existe como release de ponte — a última versão baseada no compilador JavaScript.

O papel do 6.0 é claro: introduzir deprecações e breaking changes que alinham o comportamento do compilador JS com o que será o padrão no 7.0. Isso permite que equipes migrem de forma gradual. Na prática, um projeto pode usar o TypeScript 6.0 no editor (para funcionalidades de language service como plugins e extensões) e o TypeScript 7.0 na linha de comando (para builds rápidos), sem conflito.

A equipe de TypeScript já sinalizou que não planeja um TypeScript 6.1. O 6.0 receberá apenas patches de segurança e correções de alta severidade. O investimento de engenharia está concentrado no compilador nativo.

Um dado que mostra a maturidade do 7.0: dos aproximadamente 6.000 casos de teste que produzem erros no TypeScript 6.0, o compilador nativo já reproduz todos exceto 74. A paridade funcional está próxima.

Como testar o TypeScript 7 agora

O preview nativo já está disponível e estável o suficiente para uso em desenvolvimento. Existem três formas de experimentar:

Via npm:

# Instalar como dependência de desenvolvimento
npm install -D @typescript/native-preview

# Usar o comando tsgo no lugar de tsc
npx tsgo --build

Via extensão do VS Code:

A extensão "TypeScript (Native Preview)" está disponível no Marketplace do VS Code. Ela substitui o language server padrão pelo compilador nativo, trazendo os ganhos de performance diretamente para o editor — auto-imports, find-all-references e rename já funcionam.

Substituindo no package.json:

Para projetos que querem testar a migração completa, basta trocar o pacote typescript por @typescript/native-preview no package.json, deletar node_modules e rodar npm install. O comando tsgo aceita as mesmas flags que o tsc.

Um ponto importante: o preview é atualizado diariamente. Bugs são corrigidos com frequência, e a cobertura de funcionalidades do language server cresce a cada release. Para projetos em produção, ainda é cedo para substituir o compilador principal. Mas para pipelines de CI, builds locais e validação de tipos, já é viável.

Conclusão

O TypeScript 7 não é uma atualização incremental. É uma reescrita de fundação que resolve o maior ponto de dor da linguagem: a velocidade do compilador. Com builds 10x mais rápidos, strict mode por padrão e um caminho de transição claro via TypeScript 6, a migração é uma questão de quando, não de se.

Para quem quer se antecipar, o preview nativo já está pronto para testes. Instale o @typescript/native-preview, rode no seu projeto e compare os tempos. A diferença é visível na primeira execução.

Referências pesquisadas nesta publicação