
O TypeScript 7 chegou: o compilador nativo em Go que compila 10x mais rápido (2026)
- vuetelemetry
- Notícias
- 8 min de leitura
O TypeScript 7.0 reescreve o compilador em Go e compila cerca de 10x mais rápido - mesmos tipos, novo motor. O que mudou, os benchmarks reais (VS Code 77,8s para 7,5s), como experimentar o tsc hoje, os breaking changes e os compromissos honestos.
O TypeScript 7.0 saiu a 8 de julho de 2026, e o resumo é simples: o compilador passou a ser escrito em Go em vez de no próprio TypeScript, e compila cerca de 10 vezes mais rápido. Para quem mantém uma base de código grande em Vue, Nuxt ou React, é a maior mudança no dia a dia do TypeScript em anos: não uma nova sintaxe, mas um novo motor sob o mesmo comando tsc.
Nada muda na forma como escreve os tipos. Os seus ficheiros .ts, o seu tsconfig.json e os seus erros de tipo continuam iguais. O que muda é a rapidez com que o compilador analisa, verifica e emite o seu projeto, e o quão reativo o seu editor fica enquanto trabalha. Este guia cobre o que mudou de facto, os números reais dos benchmarks, como experimentá-lo hoje e os compromissos honestos antes de migrar.
O que mudou de facto

O projeto, de nome de código Corsa, é um port e não uma reescrita. A equipa da Microsoft, liderada pelo arquiteto principal do TypeScript Anders Hejlsberg, transpôs para Go os algoritmos e estruturas de dados existentes para que o comportamento da verificação de tipos se mantenha idêntico: a mesma inferência, os mesmos erros. Go foi escolhido em vez de Rust sobretudo porque as árvores de sintaxe e as tabelas de símbolos do TypeScript dependem de referências cíclicas, que combinam muito melhor com o garbage collector e as goroutines de Go do que com as regras de posse de Rust.
A velocidade vem de duas coisas. O código nativo compilado é simplesmente mais rápido do que o antigo compilador escrito em JavaScript, e o novo compilador trabalha em paralelo: análise, verificação de tipos e emissão podem acontecer em várias threads em vez de uma só. O uso de memória cai cerca de metade face ao compilador JavaScript, e o serviço de linguagem do editor carrega os projetos grandes muito mais depressa.
A velocidade, em números reais
A Microsoft publicou números de antes e depois em projetos reais. Compilar a base de código do VS Code (cerca de 1,5 milhões de linhas) passou de 77,8 segundos para 7,5 segundos, uma melhoria de 10,4x. O Playwright compilou cerca de 10x mais rápido e o TypeORM cerca de 13,5x. São builds completas e limpas, precisamente as que dominam o tempo de CI e atrasam as verificações de tipos locais em repositórios grandes.
- TypeScript 7.0 (lançado a 8 de julho de 2026) substitui o compilador escrito em JavaScript por um port nativo escrito em Go: mesmos tipos, novo motor
- Builds completas cerca de 10x mais rápidas (VS Code 77,8s para 7,5s), carregamento do projeto no editor cerca de 8x mais rápido e cerca de 50% menos memória
- É um port (nome de código Corsa) liderado por Anders Hejlsberg: comportamento de verificação de tipos idêntico, agora paralelizado em várias threads
- Instala-se e corre como tsc; as pré-visualizações noturnas continuam a usar o nome tsgo sob @typescript/native-preview
- Breaking changes: target es5, modo de resolução node, baseUrl e AMD/UMD/SystemJS removidos; alguns valores por omissão (rootDir, types) mudaram
- As ferramentas na API programática (typescript-eslint, ts-morph, transformadores) esperam uma versão 7.x posterior: adote lado a lado por agora
Os ganhos no editor contam tanto no dia a dia. Carregar um projeto grande no serviço de linguagem caiu de cerca de 9,6 segundos para 1,2 segundos, cerca de 8x. É a diferença entre esperar que o IntelliSense acorde e ter o preenchimento automático, o ir-para-a-definição e o sublinhado de erros a responder quase de imediato numa base de código que antes parecia lenta.
Como experimentá-lo hoje
A instalação é propositadamente banal: o compilador nativo instala-se a partir do pacote habitual e corre como tsc, por isso a maioria dos projetos pode experimentá-lo com uma única atualização de dependência. As pré-visualizações anteriores traziam um binário tsgo separado, e as builds noturnas continuam a ser publicadas sob @typescript/native-preview com esse nome, mas a versão estável chama-se apenas tsc. Novas flags permitem afinar o paralelismo, por exemplo o número de workers de verificação, ou desativá-lo com um modo de thread única quando precisa de uma saída serial reproduzível.
Uma forma segura de o adotar é lado a lado. Pode manter o compilador 6.x anterior instalado sob um alias (muitas vezes invocado como tsc6) enquanto aponta a sua build principal para a 7.0. Isso deixa-o usar o novo compilador rápido para builds e edição, enquanto qualquer ferramenta que ainda dependa da antiga API programática estável continua a funcionar sem alterações.
Breaking changes a vigiar
Há breaking changes reais, por isso leia as notas de versão antes de atualizar no lugar. Várias opções há muito descontinuadas desaparecem, incluindo o target es5, o antigo modo de resolução de módulos node, baseUrl e os formatos de módulo AMD, UMD e SystemJS. Alguns valores por omissão também mudam, como rootDir e o conjunto por omissão de pacotes de tipos ambientais, o que pode fazer surgir novos erros em configurações que dependiam do antigo comportamento implícito.
Os compromissos, com honestidade
O ganho de velocidade é real, mas o ecossistema precisa de um tempo para acompanhar. As ferramentas construídas sobre a API programática do TypeScript (typescript-eslint, ts-morph, transformadores de compilador personalizados) dependem de interfaces que só devem estabilizar numa versão 7.x posterior. Até lá, as equipas que se apoiam muito nessas ferramentas talvez queiram usar a 7.0 para builds e edição, mantendo a linha 6.x disponível para as partes da toolchain que ainda não estão prontas.
Vale também manter as expectativas com os pés na terra: o TypeScript 7 torna o compilador mais rápido, não a sua aplicação em produção. A saída continua a ser o mesmo JavaScript a correr nos mesmos navegadores e versões de Node, por isso o desempenho em tempo de execução não muda. O que ganha são tempos de build e de CI mais curtos e um editor mais ágil, o que, numa base de código front-end grande, é exatamente onde estava o atrito. Para a maioria das equipas de Vue, Nuxt e React o passo prático é experimentá-lo num branch, ficar atento às opções removidas e adotá-lo para a build e o editor assim que os números confirmarem.



Há breaking changes reais, por isso leia as notas de versão antes de atualizar no lugar. Várias opções há muito descontinuadas desaparecem, incluindo o target es5, o antigo modo de resolução de módulos node, baseUrl e os formatos de módulo AMD, UMD e SystemJS. Alguns valores por omissão também mudam, como rootDir e o conjunto por omissão de pacotes de tipos ambientais, o que pode fazer surgir novos erros em configurações que dependiam do antigo comportamento implícito.