Em 8 de julho de 2026, a Microsoft lançou o TypeScript 7.0 — e pela primeira vez em treze anos, o compilador do TypeScript não é mais escrito em TypeScript. É um port nativo em Go. O resultado, medido pela própria equipe em projetos reais como VS Code e Playwright, chega a 12x mais rápido que a versão anterior. O preço: ESLint, Vue, Angular e Svelte ainda não conseguem rodar em cima dele.
O que exatamente mudou
Até a versão 6.0, todo compilador do TypeScript — o tsc, o language server que alimenta o autocomplete do editor, o verificador de tipos — era escrito no próprio TypeScript, rodando sobre o motor JavaScript do Node.js. Funcionava, mas tinha um teto: JavaScript de single-thread não escala com o tamanho do projeto, e a Microsoft já vinha absorvendo reclamações de times grandes (VS Code, Office, Teams) sobre tempo de build crescendo junto com a base de código.
A resposta, anunciada em 11 de março de 2025 sob o codinome interno Project Corsa, foi portar o compilador inteiro para Go. Não reescrever do zero seguindo as convenções idiomáticas de Go — portar, mantendo a estrutura de código e a lógica originais linha a linha, para garantir que o novo compilador produza exatamente os mesmos diagnósticos de tipo que o antigo. O nome interno do compilador antigo, agora mantido como referência de compatibilidade, é Strada.
O caminho até a 7.0 foi público e documentado: preview experimental como pacote @typescript/native-preview a partir de meados de 2025, beta em 21 de abril de 2026, release candidate em 18 de junho, e a versão estável em 8 de julho de 2026 — conforme o anúncio oficial no DevBlog do TypeScript, assinado por Daniel Rosenwasser, gerente principal de produto do time.
Por que Go, e não C#
A pergunta mais repetida na discussão oficial do repositório microsoft/typescript-go quando o projeto foi anunciado foi por que não C#, a linguagem de Anders Hejlsberg — criador do próprio TypeScript e do C#. Quem respondeu ao contraponto do C# foi o próprio Hejlsberg: "depois de avaliar diversas linguagens e fazer múltiplos protótipos — inclusive em C# — Go se mostrou a escolha ideal". Ele apontou o que diferenciava esse porte de um projeto novo: "Num cenário green field, essa seria uma conversa totalmente diferente. Mas isso não era um green field — é um porte de uma base de código existente com 100 homens-ano de investimento." E foi direto sobre por que não usou a própria linguagem que criou: "Sim, poderíamos ter redesenhado o compilador em C# do zero, e teria funcionado. De fato, o próprio compilador do C#, o Roslyn, é escrito em C# e se autocompila. Mas isso não era um redesenho de compilador, e a passagem de TypeScript para Go era muito mais automatizável e mais um-para-um no mapeamento. Nossa base de código existente é toda funções e estruturas de dados — sem classes."
A resposta sobre compatibilidade estrutural e forma do código veio de Ryan Cavanaugh, do time do TypeScript, sem apontar nenhuma linguagem rival por nome: "precisamos manter a nova base de código o mais compatível possível, tanto em termos de semântica quanto de estrutura de código" — e "Go idiomático se assemelha fortemente aos padrões de código já existentes na base do TypeScript, o que torna esse esforço de porte muito mais tratável". O compilador do TypeScript é escrito em estilo funcional, com muito grafo de dados cíclico (tipos que referenciam outros tipos que referenciam de volta). Go, com coletor de lixo automático e goroutines nativas, aceitou a mesma forma do código quase sem alteração — sem exigir reescrever a base em torno de um sistema de ownership.
Cavanaugh também descreveu o que Go entregava mesmo sem ownership explícito: "Go também oferece excelente controle de layout de memória e alocação [...] sem exigir que toda a base de código se preocupe constantemente com gerenciamento de memória." Ou seja: o time não tratou isso como abrir mão de performance — tratou como o encaixe que permitia portar a estrutura existente linha a linha, em vez de reformular o compilador do zero em torno das restrições de outra linguagem.
Os números, medidos em projetos reais
A equipe do TypeScript não publicou só microbenchmarks sintéticos — mediu builds completos de projetos open source conhecidos, comparando TypeScript 6.0 contra 7.0 nas mesmas máquinas:
| Projeto | TS 6.0 | TS 7.0 | Ganho |
|---|---|---|---|
| VS Code | 125,7s | 10,6s | 11,9x |
| 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 |
A checagem de erro por arquivo no editor do VS Code caiu de 17,5 segundos para menos de 1,3 segundo. Uso de memória caiu entre 6% e 26%, dependendo do projeto — números detalhados no próprio anúncio de GA.
Vale um alerta de honestidade: esses ganhos de dois dígitos aparecem em bases de código grandes — o VS Code da própria tabela acima tem cerca de 2,3 milhões de linhas, conforme reportou o The Register ao cobrir os benchmarks da Microsoft. Em projetos pequenos ou já bem otimizados, o ganho encolhe. A Prisma migrou seu monorepo de produção da versão 5.8.2 para a 7.0.2 e documentou a checagem de tipos do repositório inteiro caindo de cerca de 74s para cerca de 24s — cerca de 3x, ainda expressivo, mas longe do "10x" de manchete, porque o type-check é só uma fatia do tempo total de CI, que também inclui bundling, testes e geração de código, etapas que o compilador nativo não acelera. O ganho é real; o multiplicador depende do tamanho do que você compila e de quanto do seu pipeline é, de fato, checagem de tipo.
O que ficou pra trás — e por que quebrou tanta coisa
Aqui está o detalhe que separa "atualizar o TypeScript" de "atualizar o TypeScript com cautela": a versão 7.0 saiu sem API programática. O anúncio oficial é direto sobre isso: "TypeScript 7.0 não vem com uma API. Esperamos que o TypeScript 7.1 traga uma API nova — e diferente."
Isso importa porque a maioria das ferramentas que dependem do TypeScript não fala com o compilador pela linha de comando — fala com ele por código, chamando funções como ts.createProgram ou ts.transform para inspecionar e reescrever árvores de sintaxe. É assim que o typescript-eslint analisa tipos para aplicar regras de lint, que o ts-jest transforma arquivos antes de rodar testes, e que frameworks com suporte a template — Vue, Angular, Svelte, Astro, MDX — fazem checagem de tipo dentro de arquivos que misturam HTML e TypeScript. Sem a API, essas integrações simplesmente não têm com o que conversar.
O próprio typescript-eslint documentou o problema como issue aberta no seu repositório, tratando o suporte ao compilador nativo como trabalho pendente, não como algo já resolvido. A recomendação prática que circulou nos primeiros dias — fixar typescript em 6.x para as ferramentas de build e rodar o compilador nativo separadamente só para checagem de tipo — nasceu exatamente dessa lacuna.
A Microsoft previu a fricção e publicou uma saída de compatibilidade: o pacote @typescript/typescript6 dá acesso ao binário tsc6 e à API 6.0 completa. Mas rodar só npm install -D typescript@npm:@typescript/typescript6 não cria um ambiente side-by-side — isso sobrescreve a entrada typescript do package.json e deixa o projeto só com o tsc6, sem o tsc 7 novo. Para ter os dois binários ao mesmo tempo, o package.json precisa declarar as duas dependências lado a lado:
{
"devDependencies": {
"@typescript/native": "npm:typescript@^7.0.2",
"typescript": "npm:@typescript/typescript6@^6.0.2"
}
}
Times que dependem de ferramentas ainda não migradas continuam rodando a versão anterior sem downgrade formal — desde que instalem os dois pacotes, não só um.
Como migrar sem quebrar o pipeline
Para quem decide adotar o TypeScript 7.0 hoje, vale conferir duas categorias de mudança antes de rodar o build em produção: defaults que mudaram silenciosamente, e depreciações que viraram erro obrigatório.
rootDiragora tem outro valor padrão. O default passou a ser./; se as pastas de código-fonte do seu projeto ficam abaixo da raiz (por exemplo, dentro desrc), é preciso declararrootDirexplicitamente.typesagora tem default vazio ([]). Pacotes@types/*que antes eram carregados automaticamente agora precisam estar listados no arraytypesdotsconfig.json— o comportamento antigo volta ao declarartypes: ["*"].strictagora étruepor padrão. É o default com maior potencial de quebrar pipeline: projetos que nunca declararamstrictexplicitamente podem ver erros de tipo novos surgirem no build, não por regressão do compilador, mas porque checagens que antes estavam desligadas passaram a rodar.- Flags descontinuadas viraram erro, não aviso.
target: "es5",baseUrl— independentemente depathsestar declarado —,downlevelIteratione algumas estratégias antigas de resolução de módulo interrompem o build em vez de só gerar warning, e ospathsdevem ser reescritos relativos à raiz do projeto, em vez de abaseUrl.
A instalação em si não muda: npm install -D typescript já traz a versão 7 pelo pacote padrão — o preview experimental @typescript/native-preview, por onde a maior parte dos desenvolvedores instalou o TypeScript 7 até agora, deixa de ser o caminho dos builds noturnos: eles passam a sair, em breve, pelo próprio pacote typescript, na tag next.
O caminho recomendado para times com dependência pesada em ferramentas ainda não atualizadas é adoção em duas velocidades: rodar o compilador 7.0 (via alias @typescript/native) para checagem de tipo e no editor — onde o ganho de velocidade é sentido o tempo todo — e manter typescript apontando para @typescript/typescript6 isolado para o passo do pipeline que ainda depende da API antiga, até esses pacotes anunciarem suporte nativo.
O que isso muda para quem constrói ferramentas de código
A lição estrutural do TypeScript 7.0 não é só "ficou mais rápido" — é que qualquer ferramenta construída em cima da API programática de um compilador está, na prática, apostando na estabilidade dessa API entre versões maiores. Times que constroem agentes de IA para desenvolvimento, linters customizados ou integrações de editor sentem essa dependência primeiro, porque cada um desses componentes só volta a funcionar quando o fornecedor upstream (aqui, o próprio time do TypeScript) publica a peça que falta.
É o mesmo tipo de dependência que qualquer ferramenta de terminal orientada a código carrega ao processar projetos TypeScript — do MaxVision Code a qualquer assistente que analisa ou reescreve arquivos .ts: o ganho de velocidade do compilador nativo é bem-vindo, mas a checagem de compatibilidade da API entra na lista de coisas a confirmar antes de trocar a versão do TypeScript em produção, não depois.
Perguntas Frequentes
O TypeScript 7.0 muda o comportamento de checagem de tipos?
Não é essa a intenção. O port foi feito para preservar a semântica original — os mesmos erros de tipo que o compilador 6.0 reportava devem aparecer no 7.0. É um porte de implementação, não uma reescrita de regras.
Preciso migrar agora?
Não necessariamente. Se seu pipeline depende de ferramentas que ainda não suportam a API do TypeScript 7 (ESLint com plugin de tipos, Vue, Angular, Svelte, Astro, MDX), o caminho mais seguro é manter o typescript@npm:@typescript/typescript6 para essas etapas e usar o compilador 7.0 só onde ele já funciona sozinho — no editor e na checagem de tipo pura.
Por que o ganho de performance varia tanto entre projetos?
Os números de "10x" vêm de bases de código grandes, como o VS Code, com mais de 1 milhão de linhas. Projetos pequenos ou já otimizados mostram ganhos menores, na faixa de 3x, porque boa parte do tempo do TypeScript 6.0 nesses casos já não é dominado pelo overhead que o compilador nativo elimina.
O TypeScript vai continuar sendo mantido em JavaScript?
O código-fonte anterior, chamado internamente de Strada, segue disponível como referência e como base do pacote de compatibilidade @typescript/typescript6, mas o desenvolvimento ativo do compilador migrou para a base em Go.
Conclusão
O TypeScript 7.0 é o tipo de mudança que só acontece uma vez por geração de ferramenta: trocar a linguagem de implementação de um compilador usado por milhões de projetos, mantendo compatibilidade de tipos, e entregando ganho de velocidade de dois dígitos em builds grandes. A parte que a manchete "10x mais rápido" não conta é que a modernização veio em etapas — e a etapa que faltou, a API programática, é exatamente a que decide se o resto do seu pipeline acompanha a migração hoje ou espera a versão 7.1.
Para quem constrói ou opera ferramentas de desenvolvimento, o caso do TypeScript 7 é um lembrete direto: performance de compilador importa, mas a superfície de compatibilidade da API é o que determina quando essa performance chega ao seu projeto de verdade.
