Vale a pena migrar para o TypeScript 7 agora?

Migre para o TypeScript 7 agora se o seu projeto é TypeScript puro e já compila sem erros no 6.0. Se você depende do typescript-eslint ou da verificação de templates do Vue, Svelte, Astro, MDX ou Angular, rode o tsc do 7.0 em paralelo com o 6.0 e espere o 7.1 antes de fazer a troca completa.

Os números de desempenho são tentadores. Mas aí você lembra que o seu pipeline de lint, os seus arquivos .vue e um script personalizado de geração de código importam typescript, e um salto de versão major começa a parecer arriscado.

O TypeScript 7.0 foi lançado em 8 de julho de 2026. Este artigo mostra como é o ganho de velocidade na prática, quais mudanças de configuração vão quebrar o seu build, quais ferramentas ainda não podem usar o 7.0 e como rodar os dois compiladores no mesmo repositório. No final, há uma recomendação para cada tipo de projeto.

Quanto o TypeScript 7 é mais rápido?

O TypeScript 7.0 é um port do compilador TypeScript para Go, e a Microsoft afirma que ele normalmente deixa os builds completos de 8x a 12x mais rápidos que o TypeScript 6.0. A equipe não redesenhou o compilador. A versão em Go espelha a organização e o funcionamento do código original, de modo que os dois compiladores produzem os mesmos resultados. O ganho vem da execução como código nativo e da verificação de tipos em várias threads que compartilham memória.

Estes são os números de build completo do anúncio do TypeScript 7.0 da Microsoft:

A Microsoft executou esses builds com o padrão de quatro workers de verificação de tipos (--checkers 4) em grandes bases de código open source. O anúncio não informa qual hardware foi usado. O menor resultado, o tldraw com 7,7x, fica um pouco abaixo da faixa de “8x a 12x” declarada pela Microsoft.

O tempo que o TypeScript 7 realmente economiza depende do tamanho da sua base de código. Com base nos números da Microsoft, o vscode economiza cerca de 115 segundos por build completo, e o tldraw, menos de 10. Uma aplicação pequena que já faz a verificação de tipos em dois segundos terá um ganho proporcional parecido, mas vai economizar muito pouco tempo.

Três mudanças menores, uma linha cada:

• --checkers e --builders controlam a verificação de tipos em paralelo e os builds com project references. As release notes do 7.0 classificam as duas flags como experimentais.
• O --watch agora roda sobre um port em Go do file watcher do Parcel.
• A verificação de JS e JSDoc foi reformulada para se comportar de forma mais parecida com a análise de arquivos .ts. Os detalhes estão no CHANGES.md do typescript-go.

O que quebra ao migrar do TypeScript 5.x ou 6.0

Código que não tem erros no TypeScript 6.0, com stableTypeOrdering ativado e ignoreDeprecations removido, deve gerar a mesma saída no TypeScript 7.0. Tudo o que quebra vem do 6.0: o 7.0 herda os novos padrões do 6.0, e tudo o que o 6.0 marcou como descontinuado agora interrompe o build. Equipes que vêm direto do 5.x enfrentam os dois conjuntos de mudanças de uma vez.

Novos padrões

Quatro padrões do TypeScript 7.0, herdados do 6.0, causam a maior parte das quebras:

• strict é true. Espere novos erros em código com tipagem frouxa. Helpers bem tipados construídos com utility types do TypeScript facilitam a transição.
• module tem esnext como padrão.
• rootDir tem ./ como padrão. Se o seu tsconfig.json fica acima de src, defina rootDir explicitamente.
• types tem [] como padrão. Liste pelo nome os pacotes de tipos globais, como node ou jest, ou defina ["*"] para restaurar o comportamento antigo.

Outros quatro padrões mudaram: target agora acompanha a edição mais recente finalizada do ECMAScript (um passo atrás de esnext), noUncheckedSideEffectImports é true, libReplacement é false e stableTypeOrdering é true e não pode ser desativado.

Descontinuações que agora são erros fatais

As release notes do TypeScript 7.0 listam doze opções e comportamentos descontinuados que agora geram erro fatal:

• target: es5
• downlevelIteration
• moduleResolution: node / node10 (use nodenext ou bundler)
• moduleResolution: classic (use bundler ou nodenext)
• module: amd, umd, systemjs, none (use esnext ou preserve)
• baseUrl (escreva os paths relativos à raiz do projeto)
• esModuleInterop ou allowSyntheticDefaultImports definidos como false
• alwaysStrict definido como false
• A palavra-chave module em declarações de namespace
• asserts em imports (use with)
• /// <reference no-default-lib /> com skipDefaultLibCheck
• Caminhos de arquivo passados na linha de comando quando o diretório tem um tsconfig.json, a menos que você adicione --ignoreConfig

O outFile não está nessa lista, mas também deixou de existir. As release notes do 6.0 dizem que o 6.0 já o havia removido e que todas as opções descontinuadas no 6.0 foram removidas por completo no 7.0. Se você ainda usa outFile, passe essa tarefa para um bundler.

Há também uma mudança no nível dos tipos: a inferência a partir de template literal types não divide mais um caractere, como um emoji, em duas metades. Você só vai notar isso se escreveu helpers de string no nível dos tipos que dependiam da antiga divisão em UTF-16.

Veja uma configuração legada típica e a versão que funciona no 7.0:

// Before: hard errors on 7.0
{
  "compilerOptions": {
    "target": "es5",               // error: es5 unsupported
    "downlevelIteration": true,    // error: removed
    "moduleResolution": "node",    // error: node/node10 unsupported
    "baseUrl": "./src",            // error: baseUrl unsupported
    "paths": { "@/*": ["*"] }
  },
  "include": ["./src"]
}

// After: valid on 7.0
{
  "compilerOptions": {
    "moduleResolution": "bundler",
    "rootDir": "./src",
    "types": ["node", "jest"],
    "paths": { "@/*": ["./src/*"] }
  },
  "include": ["./src"]
}

A nova versão remove o target para que o padrão seja aplicado, faz os paths apontarem a partir da raiz do projeto e define rootDir e types explicitamente.

A Microsoft recomenda migrar primeiro para o 6.0. Atualize para o 6.0, corrija todos os avisos de descontinuação (o anúncio do TypeScript 6.0 explica cada um deles), remova o ignoreDeprecations e só então instale o 7.0.

Quais ferramentas ainda não funcionam com o TypeScript 7?

Ferramentas que importam o compilador TypeScript como biblioteca, e as ferramentas por trás da verificação de templates do Vue, MDX, Astro, Svelte e Angular, ainda não funcionam com o TypeScript 7.0, porque o TypeScript 7.0 não inclui uma API programática. Segundo o anúncio do 7.0 da Microsoft, ferramentas que importam o compilador como biblioteca, como o typescript-eslint, precisam continuar rodando no TypeScript 6.0 por meio do pacote de compatibilidade @typescript/typescript6. Se a sua configuração de linting com reconhecimento de tipos usando typescript-eslint depende de uma peer dependency de typescript, ela precisa da configuração de alias descrita na próxima seção.

Linguagens embutidas também são afetadas. O anúncio do 7.0 da Microsoft diz que projetos Vue, MDX, Astro e Svelte devem continuar no TypeScript 6.0 por enquanto. O Volar e ferramentas semelhantes adicionam suporte a TypeScript nesses formatos de arquivo chamando o compilador diretamente, e o 7.0 não tem uma API para elas chamarem. A verificação de tipos em templates do Angular tem a mesma limitação. Para o Angular, o anúncio sugere uma divisão: use o tsc do 7.0 na linha de comando e no CI para detectar erros em todo o projeto rapidamente, e deixe o 6.0 cuidando do editor para que a verificação de templates continue funcionando.

No VS Code, a extensão dedicada do TypeScript 7 da Microsoft oferece dois comandos na paleta de comandos, “Disable TypeScript 7 Language Server” e “Enable TypeScript 7 Language Server”, para que você possa alternar o editor entre o 6.0 e o 7.0 sempre que precisar. Se o editor começar a se comportar de forma estranha depois da troca, o fluxo habitual de depuração de TypeScript no VS Code continua valendo.

A Microsoft planeja trazer uma API de volta no TypeScript 7.1, embora ela não seja igual à antiga. Essa versão é o momento realista para essas integrações migrarem.

Como rodar o TypeScript 7 e o 6.0 lado a lado

Para rodar as duas versões no mesmo repositório, use aliases do npm. Aponte o nome de pacote typescript para o pacote de compatibilidade do 6.0 e instale o 7.0 com outro nome. Assim, as ferramentas que importam typescript carregam o 6.0. O pacote de compatibilidade fornece a API do 6.0 e um comando do 6.0 chamado tsc6.

Em um projeto npm comum, npx tsc passa a rodar o 7.0. Mas há um porém. O pacote de compatibilidade depende de uma cópia completa do TypeScript 6.0 que declara o próprio tsc, então dois pacotes disputam esse nome de comando. Usuários relataram que o Yarn e o Bun podem vincular o tsc ao 6.0. O script typecheck abaixo chama diretamente o arquivo do 7.0, então não depende de qual pacote fica com o nome tsc. Esta é a configuração que a Microsoft descreve, mostrada aqui com scripts:

{
  "devDependencies": {
    "@typescript/native": "npm:typescript@^7.0.2",
    "typescript": "npm:@typescript/typescript6@^6.0.2"
  },
  "scripts": {
    "typecheck": "node node_modules/@typescript/native/bin/tsc --noEmit",
    "typecheck:6": "tsc6 --noEmit",
    "lint": "eslint ."
  }
}

O typecheck roda o 7.0. O typecheck:6 roda o 6.0, o que é útil para confirmar que os dois compiladores concordam durante a migração. O lint resolve typescript para o 6.0 por meio do alias. Para configurar o alias do 6.0 pelo terminal, execute npm install -D typescript@npm:@typescript/typescript6. Se fizer só isso, você terá apenas o tsc6, então adicione também o alias do 7.0.

Execute npx tsc --version para ver qual compilador um tsc simples chama. A Microsoft documenta essa configuração apenas para o npm, então confira o resultado por conta própria se você usa pnpm, Yarn ou Bun.

Vale a pena migrar? A recomendação para cada situação

Migrar ou não para o TypeScript 7 depende de duas coisas: o quanto o seu build no 6.0 está limpo e se alguma ferramenta da sua toolchain importa o compilador.

Projeto novo: comece no 7.0. Se você está migrando de Flow para TypeScript, adote os padrões do 7.0 desde o início para não precisar migrar uma segunda vez.

Base de código pequena em TS puro: passe para o 6.0, corrija todas as descontinuações e depois faça a troca. O tempo economizado será pequeno, mas você estará na linha com manutenção ativa.

Monorepo grande: configure o alias, mova a verificação de tipos do CI para o tsc do 7.0 agora e mantenha o linting, a geração de código e o editor no 6.0 até que o 7.1 traga sua API.

Conclusão

O TypeScript 7.0 verifica os tipos do seu código quase exatamente como o 6.0, só que mais rápido. Praticamente tudo o que quebra vem das descontinuações do 6.0 ou de ferramentas que precisam de uma API do compilador. Comece garantindo um build limpo no 6.0, sem ignoreDeprecations. Depois disso, faça a troca completa ou adicione o alias do npm e deixe o CI rodar o tsc do 7.0 enquanto as suas ferramentas permanecem no 6.0 até o 7.1.

Perguntas frequentes

O tsgo ou o @typescript/native-preview são a mesma coisa que o TypeScript 7?

Não mais. Antes do lançamento do 7.0, o compilador em Go era disponibilizado em prévia no pacote @typescript/native-preview, e seu comando era tsgo. A última versão desse pacote é a 7.0.0-dev.20260707.2, publicada um dia antes da versão estável. No TypeScript 7.0, o compilador nativo fica no pacote typescript comum e roda como tsc. Os builds nightly agora vêm de typescript@next, então troque tsgo por tsc nos seus scripts de CI.

O TypeScript 7 deixa os builds com Vite, esbuild ou SWC mais rápidos?

Não. Vite, esbuild e SWC transformam TypeScript em JavaScript removendo os tipos sem verificá-los, então nunca chamam o tsc, e seus tempos de transpilação continuam os mesmos. O TypeScript 7 acelera a etapa separada de verificação de tipos, geralmente o tsc --noEmit no CI ou em um hook de pre-commit, além do language server do editor. Se a verificação de tipos não é a etapa mais lenta do seu pipeline, a migração não vai encurtar os builds de forma perceptível.

O ts-node funciona com o TypeScript 7?

Não diretamente. O ts-node compila arquivos por meio da API do compilador TypeScript, e o 7.0 não inclui essa API. Com a configuração de alias do npm, o import de typescript feito pelo ts-node é resolvido para o pacote de compatibilidade do 6.0, então ele continua rodando no 6.0 enquanto o tsc roda o 7.0. Para código que usa apenas sintaxe apagável, o type stripping das versões recentes do Node.js consegue executar arquivos .ts sem nenhum compilador, mas não faz verificação de tipos.

O TypeScript 7 ainda consegue compilar para ES5 para navegadores antigos?

Não. O TypeScript 6.0 elevou o target mínimo suportado para ES2015 e descontinuou o target es5. No 7.0, target es5 gera erro fatal. Se você ainda precisa de saída em ES5, faça o tsc emitir ES2015 ou posterior e pós-processe o resultado com o Babel ou outro compilador. Outra opção é compilar o código-fonte TypeScript diretamente com essa ferramenta externa.