TypeScript 7.0 RC: o tsc nativo em Go chegou

O TypeScript 7.0 RC foi anunciado em 18 de junho de 2026 e marca uma das maiores mudanças técnicas da história do projeto: o compilador passa a usar uma nova implementação nativa em Go.

A notícia não é apenas “o TypeScript ficou mais rápido”. A mudança é mais estrutural. Segundo o anúncio oficial do TypeScript 7.0 RC, a equipe portou a base existente do TypeScript, antes escrita em TypeScript e executada como JavaScript em Node.js, para Go. Com código nativo e paralelismo com memória compartilhada, o novo compilador é frequentemente cerca de 10 vezes mais rápido que o TypeScript 6.0.

Isso coloca o TypeScript 7.0 RC em uma posição curiosa dentro do ecossistema: uma das ferramentas mais importantes para escrever JavaScript em escala agora depende de uma implementação nativa fora do JavaScript para continuar escalando.

Não é uma ruptura com a linguagem. É uma mudança na infraestrutura que sustenta a linguagem.

O que foi anunciado

O TypeScript 7.0 RC é a primeira versão candidata a release do novo compilador nativo. A equipe já vinha preparando esse movimento desde o anúncio do port em Go, publicado em março de 2025 no post A 10x Faster TypeScript, e depois com os previews nativos do TypeScript.

A diferença agora é que a mudança saiu do terreno de preview experimental e entrou no pacote principal do TypeScript.

Para instalar o RC, o comando é o mesmo esperado para uma release candidata comum:

npm install -D typescript@rc

Depois disso, o tsc continua sendo chamado como antes:

npx tsc --version

A saída esperada é algo como:

Version 7.0.1-rc

Durante os previews, a implementação nativa era distribuída pelo pacote @typescript/native-preview, com o binário tsgo. No TypeScript 7.0 RC, o compilador nativo passa a ser entregue pelo pacote typescript e pelo comando tsc.

Os nightlies ainda continuam sendo publicados em @typescript/native-preview com o binário tsgo, mas a direção já está definida: quando o TypeScript 7 for publicado como estável, o novo compilador passa a ocupar o fluxo principal do pacote typescript.

Um port para Go, não uma reescrita livre

Um ponto importante do anúncio é que a equipe não descreve o TypeScript 7.0 como uma reescrita do zero.

O texto oficial fala em um port metódico da implementação existente para Go. A lógica de type-checking foi mantida estruturalmente idêntica à do TypeScript 6.0. A intenção é preservar a semântica que os projetos já usam hoje, não criar um “TypeScript novo” incompatível com o comportamento anterior.

Essa diferença é relevante porque o TypeScript não é apenas um compilador chamado manualmente no terminal. Ele é base para editor, CI, monorepos, ferramentas de build, linters, frameworks, bibliotecas e integrações que dependem de detalhes do comportamento do compilador.

Uma reescrita livre poderia entregar performance, mas também abriria espaço para diferenças difíceis de rastrear. O caminho escolhido foi outro: portar a arquitetura e a lógica existentes para uma fundação nativa, tentando manter compatibilidade com o TypeScript 6.0.

A equipe afirma que o TypeScript 7.0 foi avaliado contra a suíte de testes acumulada ao longo de mais de uma década e já foi testado em bases com milhões de linhas de código dentro e fora da Microsoft.

Por que isso importa

O TypeScript deixou de ser apenas uma linguagem ou uma camada de tipos em cima do JavaScript. Em muitos projetos, ele virou infraestrutura.

O tsc parseia arquivos, resolve módulos, monta programas, checa tipos, emite JavaScript, gera arquivos de declaração e alimenta recursos usados por editores. Em projetos pequenos, esse trabalho costuma parecer invisível. Em projetos grandes, ele vira parte relevante do tempo de feedback do desenvolvedor.

Quando o type-checking demora demais, o impacto aparece no comportamento do time. Alguém passa a rodar menos o compilador localmente. Alguém deixa a checagem só para o CI. Alguém usa transpileOnly. Alguém aceita um editor lento como se fosse uma característica natural da vida adulta.

A mudança para Go tenta atacar exatamente esse gargalo: reduzir o custo de manter o TypeScript ativo no fluxo de desenvolvimento.

A mudança principal não está no nome do comando. Está no caminho que o comando percorre por dentro.

O que muda na execução do compilador

O ganho de performance vem de dois fatores principais: execução nativa e paralelismo.

Na implementação anterior, o compilador era escrito em TypeScript, compilado para JavaScript e executado em Node.js. Isso trouxe portabilidade e um modelo muito alinhado com o ecossistema, mas também impôs limitações para uma ferramenta que precisa lidar com grafos grandes de arquivos, análise semântica, cache, diagnósticos e editor.

Na nova implementação, o TypeScript 7.0 consegue paralelizar etapas do compilador, incluindo parsing, type-checking e emit.

Parsing e emit são mais naturalmente paralelizáveis porque muitos arquivos podem ser processados de maneira relativamente independente. Type-checking é mais complexo, porque tipos dependem de outros tipos, símbolos podem ser compartilhados, declarações globais interferem no programa inteiro e a ordem de análise pode afetar resultados.

Para lidar com isso, o TypeScript 7.0 usa workers de type-checking com uma visão consistente do programa. O número padrão de checkers é 4, mas pode ser ajustado com a flag --checkers.

npx tsc --noEmit --checkers 4

Aumentar esse número pode melhorar o tempo de build em máquinas com mais núcleos e projetos maiores, mas também aumenta consumo de memória. Em CI pequeno, container limitado ou runner compartilhado, mais paralelismo pode ser contraproducente.

Além disso, o TypeScript 7.0 adiciona a flag --builders, voltada para builds com project references. Ela controla quantos builders podem rodar em paralelo.

npx tsc --build --checkers 4 --builders 2

Esse ponto merece cuidado porque --builders e --checkers têm efeito multiplicativo. Um build com --checkers 4 --builders 4 pode permitir até 16 type-checkers ao mesmo tempo.

Para cenários de debug, comparação de performance ou ambientes com recursos limitados, existe também o modo single-threaded:

npx tsc --build --singleThreaded

A flag --singleThreaded força parsing, emit e type-checking a rodarem sem paralelismo.

O modo watch também mudou

Outra parte importante da notícia é a reconstrução do modo --watch.

O TypeScript 7.0 passa a usar uma fundação derivada do file watcher do Parcel, portada e refinada em Go. Segundo a equipe, a motivação veio da necessidade de ter um mecanismo eficiente, estável e multiplataforma para observar mudanças em arquivos sem depender de uma toolchain C++ completa.

Isso é menos chamativo do que “10 vezes mais rápido”, mas é uma mudança prática importante. O modo watch é parte central do ciclo de desenvolvimento em projetos TypeScript. Ele precisa reagir rápido a mudanças, evitar trabalho desnecessário e não consumir CPU demais em bases grandes.

File watching parece simples até envolver macOS, Linux, Windows, monorepos, node_modules, symlinks, volumes montados e diretórios gerados automaticamente. Se esse componente é ruim, o editor e o build incremental sofrem.

No anúncio, a equipe afirma que o novo watcher já mostra melhorias significativas de uso de recursos em diferentes plataformas.

O impacto no editor

O TypeScript 7.0 não mira apenas o terminal. A experiência de editor também faz parte da mudança.

O novo foundation é usado pela extensão TypeScript Native Preview para VS Code e passa a se apoiar no Language Server Protocol, o LSP. Isso permite que o servidor de linguagem aproveite múltiplas threads para responder requisições simultâneas.

Na prática, o impacto esperado aparece em operações como autocomplete, hover, go to definition, find references, rename, auto-imports, code actions, inlay hints e diagnósticos enquanto o código é editado.

A equipe afirma que funcionalidades que ainda estavam ausentes em fases anteriores, como semantic highlighting, sort imports e remove unused imports, já foram incorporadas ao estado atual do TypeScript 7.0. O anúncio também cita uma redução de mais de 20 vezes em comandos falhos no language server em comparação com o TypeScript 6.0, com base nos dados de teste da própria equipe.

Para quem trabalha em bases grandes, esse talvez seja o ganho mais importante. Build rápido ajuda. Editor responsivo muda o dia.

TypeScript 6.0 é parte da transição

O TypeScript 7.0 RC não deve ser visto isoladamente. Ele depende de mudanças preparadas no TypeScript 6.0, anunciado como uma versão de transição e como a última grande release baseada na implementação JavaScript tradicional.

A equipe recomenda que projetos adotem o TypeScript 6.0 antes de migrar para o 7.0. Isso porque o TypeScript 7.0 adota os novos defaults do 6.0 e transforma algumas depreciações em erros.

Entre as mudanças de configuração, o TypeScript 7.0 passa a considerar:

• strict como true por padrão;
• module como esnext por padrão;
• noUncheckedSideEffectImports como true por padrão;
• libReplacement como false por padrão;
• stableTypeOrdering como true e sem possibilidade de desligar;
• rootDir como ./ por padrão;
• types como [] por padrão.

Também entram como não suportadas ou com comportamento de erro algumas opções antigas, como target: es5, downlevelIteration, moduleResolution: node/node10, moduleResolution: classic, module: amd, umd, systemjs, none e baseUrl.

Essas mudanças reduzem compatibilidade com configurações legadas, mas também refletem um ecossistema mais moderno, com bundlers, ESM e runtimes evergreen ocupando o fluxo principal.

O ponto prático é simples: projeto que ainda depende de opções antigas deve fazer a limpeza no TypeScript 6.0 antes de testar o 7.0.

Mudanças para JavaScript e JSDoc

O TypeScript 7.0 também muda o suporte a arquivos JavaScript analisados com JSDoc.

Segundo o anúncio, a equipe revisitou essa camada para torná-la mais consistente com a forma como arquivos .ts são analisados. Isso remove alguns comportamentos especiais ligados a padrões antigos de JSDoc, Closure-style syntax e inferências baseadas em formas históricas de escrever JavaScript.

Algumas diferenças citadas incluem:

• valores não podem mais ser usados onde tipos são esperados;
• @enum deixa de ter tratamento especial;
• ? sozinho deixa de ser aceito como tipo;
• @class não transforma uma função em construtor;
• postfix ! deixa de ser suportado;
• sintaxe Closure-style de função deixa de ser suportada;
• alias de this e reatribuição completa de prototype deixam de receber tratamento especial.

Esse é um dos pontos de maior atenção para projetos JavaScript que usam TypeScript apenas como ferramenta de análise, especialmente bases antigas com JSDoc muito flexível.

A API programática ainda não está pronta

A maior limitação prática do TypeScript 7.0 RC está na API programática.

Embora o novo tsc já esteja disponível no pacote typescript@rc, a equipe afirma que uma API programática estável só deve chegar depois, pelo menos no TypeScript 7.1.

Isso importa porque muitas ferramentas não usam apenas o binário tsc. Elas importam o pacote typescript diretamente para acessar AST, diagnósticos, programas, tipos e outros recursos internos.

Para reduzir o impacto dessa transição, a equipe publicou o pacote @typescript/typescript6. Ele fornece o executável tsc6 e reexporta a API do TypeScript 6.0. Assim, um projeto pode usar o novo tsc do TypeScript 7 para compilação, enquanto ferramentas que dependem da API antiga continuam usando TypeScript 6.

Um exemplo de configuração com alias no package.json seria:

{
  "devDependencies": {
    "typescript": "npm:@typescript/typescript6@^6.0.0",
    "typescript-7": "npm:typescript@rc"
  }
}

A migração pode separar o uso do compilador pela CLI do uso da API programática por ferramentas.

Esse é um detalhe essencial para projetos com ESLint, test runners, frameworks, plugins internos ou qualquer ferramenta que dependa diretamente do pacote typescript.

Como testar com segurança

O TypeScript 7.0 RC já foi apresentado como estável o suficiente para testes em fluxos diários e CI, mas ainda é uma release candidate. O caminho mais seguro é tratar a migração como mudança de ferramenta central, não como atualização trivial.

Um roteiro razoável seria começar pelo TypeScript 6.0, remover depreciações e garantir que o projeto compila limpo sem ignoreDeprecations.

Depois disso, instalar o RC:

npm install -D typescript@rc

Rodar a checagem principal:

npx tsc --noEmit

Em projetos com build mode:

npx tsc --build

Em monorepos, testar project references e paralelismo:

npx tsc --build --checkers 4 --builders 2

E comparar com o modo single-threaded:

npx tsc --build --singleThreaded

A comparação deve considerar não apenas tempo total de build, mas também diagnósticos, saída gerada, consumo de memória, comportamento no CI, modo watch e experiência no editor.

RC em ferramenta central merece roteiro, não fé.

O que ainda observar

O TypeScript 7.0 RC é uma mudança grande, mesmo com o esforço de compatibilidade.

Os principais pontos de atenção são:

• projetos que dependem da API programática do pacote typescript;
• monorepos com project references;
• CI com poucos recursos de CPU e memória;
• bases JavaScript com JSDoc legado;
• configurações antigas de tsconfig;
• ferramentas que ainda esperam comportamento específico do TypeScript 5.x ou 6.x.

A equipe planeja lançar o TypeScript 7.0 estável dentro de aproximadamente um mês após o RC e concentrar os próximos esforços em coordenação de release, regressões reportadas e futuras capacidades de API no TypeScript 7.1.

Enquanto isso, o RC já permite testar o novo compilador em projetos reais e medir o impacto da troca de fundação.

O significado da mudança

O TypeScript 7.0 RC mostra uma tendência que já vinha acontecendo no ecossistema JavaScript: ferramentas de infraestrutura estão migrando para implementações nativas quando o custo de performance começa a afetar o fluxo de desenvolvimento.

Bundlers, linters, formatadores, transpiladores e runtimes já vinham explorando Go, Rust e Zig. Agora, o próprio compilador oficial do TypeScript entra nessa lista.

Isso não significa que JavaScript perdeu espaço como linguagem de aplicação. O ponto é outro: tooling de linguagem tem exigências diferentes. Compiladores e language servers precisam lidar com grandes volumes de código, grafos de dependência, análise semântica, cache, concorrência e resposta rápida no editor.

O TypeScript 7.0 RC é uma resposta a essa escala.

Para quem escreve TypeScript, a promessa é menos tempo esperando o compilador. Para quem escreve Go, é mais um exemplo de Go sendo usado em infraestrutura de desenvolvimento. Para quem escreve os dois, é aquele momento raro em que dois mundos do dia a dia resolvem se encontrar sem precisar de um microserviço no meio.

No fim, a notícia é simples: o tsc mudou de motor.

O comando continua familiar. A linguagem continua sendo TypeScript. Mas a fundação por baixo agora é outra.