TypeScript 7 inaugura uma nova era com compilador em Go e builds até 12 vezes mais rápidos

O TypeScript 7 foi lançado oficialmente em 8 de julho de 2026 e representa uma das maiores transformações da história da linguagem. Diferentemente das versões anteriores, a principal novidade não está em uma nova sintaxe, mas na substituição da infraestrutura que sustenta o compilador e as ferramentas de desenvolvimento.

O compilador, que anteriormente era escrito em TypeScript e executado sobre JavaScript, ganhou uma nova implementação nativa desenvolvida em Go. A mudança permite aproveitar melhor múltiplos núcleos do processador, memória compartilhada e execução paralela.

Segundo os testes divulgados pela equipe do TypeScript, a nova versão consegue executar compilações completas entre 8 e 12 vezes mais rápido na maioria dos grandes projetos. Em determinadas configurações, com mais processadores dedicados à verificação de tipos, os ganhos podem ultrapassar 16 vezes. Microsoft — anúncio oficial do TypeScript 7

TypeScript continua sendo TypeScript

A troca da implementação poderia sugerir uma ruptura completa com a linguagem, mas esse não é o objetivo do projeto.

A equipe realizou uma portabilidade cuidadosa da estrutura e da lógica do compilador anterior. Dessa forma, o TypeScript 7 procura produzir os mesmos diagnósticos, realizar as mesmas verificações e gerar resultados compatíveis com o TypeScript 6.

Isso significa que os desenvolvedores não precisam aprender uma nova linguagem nem adaptar toda a base de código apenas porque o compilador agora foi desenvolvido em Go.

O Go faz parte da infraestrutura interna. Os projetos continuam utilizando arquivos .ts, .tsx, .js, tsconfig.json e o tradicional comando tsc.

O salto de desempenho na prática

Os números apresentados pela Microsoft ajudam a dimensionar a mudança:

| Projeto | TypeScript 6 | TypeScript 7 | Ganho | | :--- | :--- | :--- | :--- | | Visual Studio Code | 125,7 segundos | 10,6 segundos | 11,9 vezes | | Sentry | 139,8 segundos | 15,7 segundos | 8,9 vezes | | Bluesky | 24,3 segundos | 2,8 segundos | 8,7 vezes | | Playwright | 12,8 segundos | 1,47 segundo | 8,7 vezes | | tldraw | 11,2 segundos | 1,46 segundo | 7,7 vezes |

O benefício também aparece no consumo de memória. Nos projetos avaliados, a redução ficou entre 6% e 26%.

No código do Visual Studio Code, por exemplo, o tempo entre abrir o editor e visualizar o primeiro erro caiu de aproximadamente 17,5 segundos para menos de 1,3 segundo.

Esses ganhos afetam diretamente tarefas comuns, como:

• inicialização de projetos no editor;
• exibição de erros em tempo real;
• preenchimento automático;
• busca de referências;
• navegação entre definições;
• verificação de tipos;
• compilação local;
• execução do modo de observação;
• pipelines de integração contínua.

Em projetos pequenos, a diferença pode parecer apenas conveniente. Em monorepos e aplicações com milhões de linhas, ela pode representar horas economizadas todos os meses.

Paralelismo é o motor do TypeScript 7

A implementação anterior encontrava limitações para aproveitar completamente os processadores modernos. O TypeScript 7 passa a distribuir diferentes etapas da compilação entre múltiplas threads.

Operações como análise dos arquivos, verificação de tipos e emissão do código podem ser executadas paralelamente.

Por padrão, o compilador utiliza quatro verificadores de tipos. O número pode ser ajustado por meio da opção experimental --checkers:

npx tsc --checkers 8

Nos testes oficiais, o Visual Studio Code foi compilado em 7,51 segundos com oito verificadores, contra 125,7 segundos no TypeScript 6 — um ganho de aproximadamente 16,7 vezes.

Aumentar o paralelismo, entretanto, também pode elevar o consumo de memória. Em máquinas menores ou executores econômicos de CI, uma quantidade reduzida pode ser mais adequada:

npx tsc --checkers 2

O TypeScript 7 também oferece a opção --builders, voltada à construção paralela de projetos referenciados:

npx tsc --build --builders 4

Esse recurso pode beneficiar especialmente monorepos compostos por diversos pacotes. É preciso observar que --checkers e --builders possuem efeito multiplicativo. Usar quatro builders e quatro checkers pode permitir até 16 verificadores simultâneos.

Para depuração ou ambientes com recursos limitados, é possível desativar o paralelismo:

npx tsc --singleThreaded

Um novo modo --watch

O modo de observação foi reconstruído sobre uma nova implementação baseada no sistema de monitoramento de arquivos do Parcel.

A equipe inicialmente avaliou soluções baseadas em consultas periódicas ao sistema de arquivos. Entretanto, essa estratégia se mostrou cara em projetos grandes, principalmente quando existem milhares de dependências dentro do node_modules.

A solução adotada foi portar para Go parte da tecnologia do @parcel/watcher, mantendo compatibilidade entre sistemas operacionais e eliminando a necessidade de uma cadeia completa de compilação em C++.

Na prática, o novo --watch deve oferecer respostas mais rápidas às alterações e consumir menos recursos:

npx tsc --watch

A experiência nos editores também ficou mais rápida

O ganho de desempenho não está restrito ao terminal. O servidor de linguagem do TypeScript também foi reconstruído sobre a nova base nativa.

Ele utiliza o Language Server Protocol, conhecido como LSP, facilitando a integração com diferentes editores. Recursos como preenchimento automático, importações automáticas, referências, renomeação, dicas de tipos e diagnósticos passam a aproveitar processamento paralelo.

No VS Code, a Microsoft disponibilizou uma extensão dedicada ao TypeScript 7, enquanto o Visual Studio pode ativar a nova experiência de acordo com a versão instalada no projeto.

Entre os recursos já disponíveis estão:

• importações automáticas;
• destaque semântico;
• dicas de parâmetros e tipos;
• CodeLens;
• navegação até definições;
• edição vinculada de tags JSX;
• ordenação de imports;
• remoção de imports não utilizados;
• busca e renomeação de referências.

A telemetria divulgada pela equipe aponta redução superior a 80% nas falhas de comandos do servidor de linguagem e queda de mais de 60% nos encerramentos inesperados, em comparação com o TypeScript 6.

Novas configurações padrão

O TypeScript 7 herda mudanças introduzidas na versão 6 e transforma algumas delas no novo comportamento padrão.

Entre as principais estão:

{
  "compilerOptions": {
    "strict": true,
    "module": "esnext",
    "noUncheckedSideEffectImports": true,
    "libReplacement": false,
    "stableTypeOrdering": true
  }
}

Também existem duas alterações que merecem atenção durante a migração.

A primeira está no rootDir, que passa a utilizar ./ como padrão. Projetos nos quais o código está dentro de src devem declarar o diretório explicitamente:

{
  "compilerOptions": {
    "rootDir": "./src"
  },
  "include": ["./src"]
}

A segunda está na opção types, cujo padrão agora é uma lista vazia. Dependências que adicionam declarações globais precisam ser informadas:

{
  "compilerOptions": {
    "types": ["node", "jest"]
  }
}

A configuração strict ativada por padrão é particularmente relevante. Ela fortalece a verificação de tipos em projetos novos, mas pode revelar problemas até então ignorados em bases mais antigas.

Configurações antigas deixam de ser aceitas

Alguns recursos depreciados no TypeScript 6 passaram a gerar erros definitivos na versão 7.

Entre as remoções mais importantes estão:

• target: "es5";
• downlevelIteration;
• moduleResolution: "node" ou "node10";
• moduleResolution: "classic";
• module: "amd", "umd", "system" ou "none";
• baseUrl;
• esModuleInterop: false;
• allowSyntheticDefaultImports: false;
• alwaysStrict: false.

Para aplicações modernas, a recomendação é utilizar nodenext em projetos Node.js ou bundler em aplicações processadas por ferramentas como Vite, esbuild, Rollup ou webpack.

Um projeto desenvolvido com Vite, por exemplo, pode adotar:

{
  "compilerOptions": {
    "target": "ES2025",
    "module": "ESNext",
    "moduleResolution": "Bundler",
    "strict": true,
    "noEmit": true
  }
}

Como baseUrl deixou de ser suportado, os caminhos configurados em paths devem ser relativos ao diretório do projeto:

{
  "compilerOptions": {
    "paths": {
      "@/*": ["./src/*"]
    }
  }
}

Melhor tratamento de Unicode em template literal types

O TypeScript 7 também corrige um comportamento pouco intuitivo ao trabalhar com caracteres Unicode em tipos baseados em strings.

Antes da atualização, determinados emojis e caracteres representados por pares substitutos em UTF-16 podiam ser divididos em duas partes durante a inferência de template literal types.

Agora, a inferência considera um ponto de código Unicode como uma unidade:

type Separar<S> =
  S extends `${infer Primeiro}${infer Restante}`
    ? [Primeiro, Restante]
    : never;

type Resultado = Separar<"😀abc">;
// TypeScript 7: ["😀", "abc"]

O comportamento se aproxima da maneira como strings são percorridas com for...of ou transformadas por meio do operador spread.

A mudança é mais previsível para a maioria dos projetos, embora possa afetar bibliotecas que manipulam deliberadamente unidades UTF-16 no sistema de tipos.

Atenção aos projetos JavaScript com JSDoc

O suporte a arquivos JavaScript também foi revisado para se aproximar do comportamento aplicado aos arquivos TypeScript.

Algumas construções antigas do JSDoc e padrões herdados do Closure deixam de receber tratamento especial. Entre eles estão:

• uso de valores em locais nos quais um tipo é esperado;
• utilização isolada de ? como tipo;
• funções marcadas com @class;
• sintaxe de funções no estilo Closure;
• reatribuição completa de prototype;
• uso de @enum com o comportamento anterior.

Quando um valor precisar ser utilizado como tipo, será necessário empregar typeof explicitamente.

Essa mudança pode ter impacto maior em projetos JavaScript antigos que dependem extensivamente de JSDoc.

O TypeScript 7 ainda não possui uma API programática estável

Apesar de estar pronto para uso como compilador, o TypeScript 7.0 não oferece uma API programática estável. A nova API está prevista para o TypeScript 7.1 e deverá ser diferente da API existente na versão 6.

Essa limitação afeta ferramentas que importam diretamente o pacote typescript para acessar componentes internos do compilador.

Frameworks e ferramentas que incorporam o TypeScript aos próprios serviços de linguagem — como Vue, Svelte, Astro, MDX, Volar e determinadas partes do Angular — podem precisar continuar utilizando o TypeScript 6 temporariamente. Microsoft — compatibilidade com linguagens incorporadas

Para facilitar essa transição, a Microsoft publicou o pacote de compatibilidade @typescript/typescript6, que disponibiliza o comando tsc6.

Uma instalação paralela pode ser configurada desta forma:

{
  "devDependencies": {
    "@typescript/native": "npm:typescript@^7.0.2",
    "typescript": "npm:@typescript/typescript6@^6.0.2"
  }
}

Com isso, equipes podem utilizar o compilador nativo em verificações de CI enquanto mantêm a versão anterior para ferramentas que ainda dependem de sua API.

Como instalar o TypeScript 7

A versão estável pode ser instalada normalmente pelo npm:

npm install --save-dev typescript

Em seguida, confirme a versão:

npx tsc --version

Antes de atualizar um projeto de produção, é recomendável criar uma branch de migração e executar:

npx tsc --noEmit

Também vale comparar os resultados dos testes, validar a geração dos arquivos .d.ts e revisar ferramentas que possuam o pacote typescript como dependência direta ou peerDependency.

Vale a pena atualizar agora?

Para projetos TypeScript tradicionais, especialmente APIs Node.js, bibliotecas, aplicações React e grandes monorepos, a atualização oferece benefícios imediatos. Compilações mais rápidas, menor uso de memória e respostas quase instantâneas no editor podem reduzir consideravelmente o tempo gasto esperando ferramentas.

A migração exige mais cautela quando o projeto:

• utiliza configurações antigas no tsconfig.json;
• ainda gera JavaScript compatível com ES5;
• depende da API programática do TypeScript;
• possui plugins personalizados para o servidor da linguagem;
• utiliza Vue, Astro, Svelte, MDX ou integrações especializadas;
• contém uma base JavaScript extensa apoiada em padrões antigos de JSDoc.

Nesses casos, executar as versões 6 e 7 lado a lado pode ser a estratégia mais segura até que o ecossistema conclua a adaptação.

Uma atualização de infraestrutura com impacto cotidiano

O TypeScript 7 não tenta conquistar os desenvolvedores com dezenas de novos recursos visíveis na sintaxe. Sua principal inovação acontece nos bastidores — justamente na parte que determina quanto tempo uma equipe perde esperando o compilador, o editor ou a integração contínua.

A migração para Go, o paralelismo e a nova arquitetura baseada em LSP estabelecem uma fundação para os próximos anos da linguagem. Além de resolver gargalos antigos, essa base permitirá que futuras funcionalidades sejam desenvolvidas sem carregar as mesmas limitações de desempenho.

Depois de mais de uma década tornando o JavaScript mais seguro, o TypeScript entra agora em sua era nativa.