TypeScript 7.1 Beta devolve a API do compilador — e o 7.0 em Go já está no seu npm

O TypeScript 7.0 saiu em 8 de julho de 2026 e é a maior mudança interna da linguagem em anos: o compilador deixou de ser escrito em TypeScript e virou um port nativo em Go, feito sob o nome de projeto Corsa. O time da Microsoft não reescreveu a lógica de checagem — portou código, função por função, rodando a suíte de testes histórica e bases de milhões de linhas para garantir paridade de diagnóstico.

Na prática, builds completos ficaram de 8x a 12x mais rápidos que no 6.0. O número mais citado é do próprio código do VS Code: 125,7 segundos no 6.0 contra 10,6 segundos no 7.0, com cerca de 18% menos memória. O language server multi-thread também derrubou a latência de "abrir arquivo com erro" de aproximadamente 17,5 s para menos de 1,3 s. Para quem trabalha em monorepo grande, isso muda o hábito: o tsc deixa de ser aquele passo final que você roda e vai tomar café.

Mas velocidade é só metade da história. O 7.0 chegou com duas dívidas que aparecem no primeiro dia de upgrade: tsconfig antigo quebra, e o compilador saiu sem API programática — o que travou praticamente todo o ecossistema de ferramentas no TypeScript 6.

O que quebra primeiro: o tsconfig

A migração começa em erros duros, não em lentidão. Opções depreciadas no 6.0 viraram remoção no 7.0, e ignoreDeprecations não as silencia mais:

O conserto é mecânico, mas precisa ser feito em ordem — baseUrl some e paths passa a ser relativo ao próprio tsconfig :

A mudança silenciosa que ninguém anuncia

O 7.0 tem pelo menos uma alteração de default que não gera erro, gera comportamento diferente: types passa a valer [] . Antes, todo pacote em node_modules/@types entrava no programa automaticamente. Se o seu projeto dependia de @types/node , @types/jest ou dos tipos globais de um framework sem declará-los, os símbolos simplesmente deixam de existir e você vê uma enxurrada de Cannot find name . A correção é explícita:

Vale conferir também a ordem dos membros de união nas mensagens de erro — o 6.0 já tinha stableTypeOrdering para pré-visualizar essa diferença. Se o time compara saída de tsc em snapshot test, o diff vai mudar sem que o código tenha mudado.

Sem API, metade do tooling fica para trás

A decisão mais impactante do 7.0 foi de escopo: o port nativo saiu sem a API programática que typescript-eslint , ts-jest , ts-node , TypeDoc , vue-tsc , svelte-check e astro check consomem. Resultado: essas ferramentas se recusam a instalar ao lado do 7.0 e continuam presas ao 6.0. Não é bug — é um recorte de release.

O 7.1 Beta, anunciado em 20 de outubro de 2026, começa a fechar esse buraco com uma API modular em novos pontos de entrada: typescript/sync , typescript/async , typescript/fs e typescript/ast , além de um mecanismo de content mappers que permite ao tsc checar .vue , .svelte , .mdx e .astro via plugin. Vêm junto: import attributes em módulos ambient, source phase imports ( import source ) para WebAssembly, target / lib es2026 estáveis e novas APIs de biblioteca como Promise.allKeyed e Iterator.zip .

Atenção ao detalhe que os posts de release não destacam: em testes publicados por quem rodou o 7.1.0-beta contra projetos reais, ts-jest , typescript-eslint , ts-node e TypeDoc falharam exatamente como no 7.0 — e NestJS , Angular , vue-tsc , svelte-check e astro check também. A API existe, mas em entry points novos que nenhuma dessas ferramentas ainda consome. Ou seja: o 7.1 resolve o bloqueio de arquitetura, não o problema do seu pipeline hoje.

Como migrar sem parar o time: toolchain dividida

A estratégia que tem funcionado em projetos reais é separar responsabilidades — o compilador rápido no CI, o compilador completo onde as ferramentas exigem API:

Ferramentas que precisam da API apontam para typescript6 explicitamente, e o typecheck do CI usa o binário nativo. Ganha-se o feedback rápido sem travar ESLint e testes. Só não faça isso em produção de longo prazo: é uma ponte, não um destino.

Riscos e armadilhas

types: [] em silêncio. É a falha mais comum e a que mais consome tempo, porque não aponta para a causa.

Pinagem frouxa. "typescript": "latest" em CI reprodutível é convite a build vermelho na segunda-feira. Use versão exata e lockfile.

Editor diferente do CI. A extensão do editor e o compilador do pipeline precisam da mesma versão principal; misturar 6 e 7 gera "funciona na minha máquina" com erros que ninguém reproduz.

Custo real de adoção. Em projeto pequeno, o ganho de tempo é irrelevante e a migração de tsconfig custa algumas horas. Em monorepo com centenas de pacotes, a conta se paga na primeira semana.

Expectativa errada sobre o 7.1. Ele não libera ESLint type-aware automaticamente. Planeje o upgrade das ferramentas como um segundo projeto, com o beta só em branch de teste.

Recomendação prática

Se você tem TypeScript 5.x ou 6.0, o caminho de menor risco é: primeiro migrar para o 6.0 e resolver todos os avisos de depreciação, depois subir para o 7.0 apenas na checagem de tipos, mantendo o 6.0 para o restante do tooling. Se seu time usa Vue, Svelte, Astro ou Angular com checagem de tipo integrada, espere o 7.1 estável e a atualização dos respectivos plugins antes de mover o pipeline inteiro. Times com stack mista — Python no back-end, Node.js e TypeScript no front, C# e .NET em serviços corporativos, bancos relacionais por trás — costumam sentir mais dor na coordenação de versões entre repositórios do que no compilador em si; é exatamente esse tipo de decisão de engenharia, e não só de ferramenta, que a Maquinaweb trata junto aos times antes de propor uma migração de stack.

Se a sua equipe está avaliando subir para o TypeScript 7, ou precisa de um projeto sob medida com stack moderna e decisões de arquitetura documentadas, fale com o time da Maquinaweb para discutir o cenário — dá para montar um plano de migração por etapas, com o tooling atual funcionando enquanto isso.

Fontes