TypeScript 7.0: o compilador nativo em Go chega com builds até 12x mais rápidos
Em 8 de julho de 2026, o time do TypeScript publicou o anúncio do TypeScript 7.0, a primeira versão estável do port nativo do compilador, escrito em Go. Depois de muito tempo em preview, a promessa de um tsc muito mais rápido virou o pacote padrão no npm. E, como toda reescrita grande, ela vem com ganhos enormes e algumas arestas.
Os números
Segundo a Microsoft, builds completos ficam tipicamente de 8 a 12 vezes mais rápidos. A tabela do anúncio, com o padrão de 4 checkers, mostra:
| Projeto | TS 6 | TS 7 | Ganho |
|---|---|---|---|
| vscode | 125,7 s | 10,6 s | 11,9x |
| sentry | 139,8 s | 15,7 s | 8,9x |
| bluesky | 24,3 s | 2,8 s | 8,7x |
| playwright | 12,8 s | 1,47 s | 8,7x |
| tldraw | 11,2 s | 1,46 s | 7,7x |
Com --checkers 8, o build do vscode caiu para 7,51 s. O uso de memória também diminuiu, entre 6% e 26% conforme o projeto. No editor, o tempo até o primeiro erro em um arquivo do código do VS Code foi de cerca de 17,5 segundos para menos de 1,3 segundo. Esse é o número que, para mim, mais muda o dia a dia: abrir um projeto grande e ver erros quase imediatamente.
Instalação e paralelismo
A instalação continua a mesma:
npm install -D typescript
npx tscO 7.0 traz flags novas para controlar o paralelismo. --checkers define quantos workers de type-check rodam, com padrão 4. --builders define quantas project references são construídas em paralelo com --build, e o efeito se multiplica com --checkers (4 × 4 pode dar até 16 type-checkers ao mesmo tempo). --singleThreaded desliga o paralelismo, inclusive no parsing e no emit. --checkers e --builders ainda são experimentais. O modo watch também foi refeito, sobre um port em Go do file watcher do Parcel.
Novos padrões e o que quebra
Esta é a parte que exige atenção na migração. Os padrões mudaram: strict agora é true, module é esnext, target é a versão estável mais recente do ECMAScript antes de esnext, noUncheckedSideEffectImports é true, rootDir passa a ser ./ e types passa a ser uma lista vazia. Isso significa, por exemplo, que tipos globais como os do Node ou do Jest precisam ser listados explicitamente:
{
"compilerOptions": {
"rootDir": "./src",
"types": ["node", "jest"]
}
}Várias opções antigas agora são erro: target es5, downlevelIteration, moduleResolution node/node10 ou classic, module amd, umd, systemjs ou none, baseUrl, esModuleInterop ou allowSyntheticDefaultImports como false, alwaysStrict como false e a palavra-chave asserts em imports (use with). Quem ainda arrasta configuração de 2018 vai ter trabalho.
Sem API programática, por enquanto
A ressalva mais importante: o TypeScript 7.0 sai sem API programática. O time diz que espera lançar uma API nova, e diferente, no 7.1. Enquanto isso, o pacote @typescript/typescript6 fornece um executável tsc6 e reexporta a API do 6.0, para que ferramentas como o typescript-eslint continuem funcionando lado a lado com o 7.0.
A consequência direta é que Vue, MDX, Astro, Svelte e outros precisam ficar no TypeScript 6.0 por enquanto, porque ferramentas que embutem o TypeScript, como o Volar, dependem de uma API programática estável. O Angular pode usar o tsc do 7.0 para checagens de projeto inteiro na CLI e o 6.0 para o editor. O time diz que planeja suportar esses fluxos.
Isso me afeta diretamente: este blog é feito em Astro e com MDX, e por isso continua no TypeScript 6 até o ecossistema acompanhar.
Minha leitura
O TypeScript 7.0 entrega o que prometeu em velocidade, e os números são de projetos reais, não de benchmark sintético. Para backends, bibliotecas e monorepos em TypeScript puro, eu migraria logo, começando pelos novos padrões do tsconfig, que são a maior fonte de atrito.
Para quem depende de frameworks com templates próprios, a resposta honesta é esperar. A falta de API no 7.0 é uma decisão consciente para não congelar a interface errada, e faz sentido, mas significa que boa parte do ecossistema front-end vai viver em duas versões por um tempo. A versão a acompanhar agora é a 7.1.