TypeScript 7 e Project Corsa: Tudo sobre a reescrita em Go que acelera 10x

Em março de 2025, Anders Hejlsberg sentou na frente de uma câmera e soltou algo que ninguém esperava:

"Estamos portando o compilador do TypeScript pra Go."

Não pra Rust. Não uma reescrita aos poucos. Port completo do compilador, language service e type checker — o coração do ecossistema TypeScript — de TypeScript pra Go. A Microsoft batizou de Project Corsa, e agora tá saindo como TypeScript 7.0.

Pra ter uma ideia: o repo do VS Code tem 1.5 milhão de linhas de TypeScript. Com tsc compila em uns 78 segundos. Com tsgo, o novo compilador em Go, leva 7.5 segundos. Não é melhoria de 2x. É 10.4x.

Não é ajuste de tooling. É a maior mudança em 12 anos de TypeScript, e vai afetar como a gente constrói, deploya e pensa no nosso código. Bora destrinchar tudo.

Por que reescrever? Por que agora?

Pra entender o Project Corsa, primeiro precisa entender o que tava travando.

O compilador original do TypeScript era escrito em TypeScript mesmo — self-hosting que funcionou por mais de uma década. Mas quando TypeScript virou a linguagem que domina a web (ultrapassou JavaScript no GitHub em agosto de 2025), o compilador começou a engasgar com o próprio sucesso:

Onde a coisa travou

• Codebases empresariais cresceram demais. Google, Microsoft, Stripe rodam milhões de linhas de TypeScript. Nessa escala, o IDE começou a ficar lerdo: erros aparecendo com delay, autocompletar demorando 2-3 segundos, rename de projeto inteiro dando timeout.

• CI/CD virou gargalo. Em monorepos com centenas de pacotes, tsc --build era frequentemente o passo mais pesado do pipeline todo — 10+ minutos de type check em alguns casos.

• Sem saída pro single-thread. JavaScript roda em thread única por natureza. Type checking, parsing, inferência — tudo na fila no mesmo core, enquanto os outros 15 do M4 Pro ficavam parados.

Por que Go?

A pergunta que todo mundo faz.

Por que não Rust? Rust daria máximo desempenho, mas ia custar caro em velocidade de desenvolvimento. O código do compilador é bem funcional — muito closure, estrutura recursiva, pattern matching em union discriminada. O ownership model do Rust vive brigando com esse estilo. O time calculou que reescrever em Rust ia levar 3-5x mais tempo e exigiria refazer a arquitetura toda.

O que o Go tem de bom pra isso:

1. Encaixa natural. O compilador de TypeScript é surpreendentemente procedural/funcional. O jeito do Go (interfaces, functions de primeira classe, structs simples) bate certinho com os padrões existentes.

2. Goroutines. Paralelismo barato sem precisar gerenciar threads na mão. Perfeito pra type-checking em paralelo entre arquivos.

3. Performance previsível. O GC do Go é feito pra baixa latência. Sem aquelas pausas aleatórias do V8 — exatamente o que você quer num language service de IDE.

4. Binário e acabou. Go compila pra um executável autossuficiente. Sem Node.js. Sem npm install. Baixa e roda.

5. Time produtivo rápido. A equipe ficou produtiva em Go muito mais rápido do que seria com Rust, e mesmo assim conseguiu a melhoria de performance necessária.

O que mudou por dentro

Project Corsa não é "mesmo compilador só que em Go." A arquitetura mudou de verdade.

Antes e Depois

TypeScript 5.x/6.x (JavaScript):

Arquivos → Scanner → Parser → Binder → Type Checker → Emitter
           ↑                                            ↓
      Single-threaded, pipeline sequencial          .js + .d.ts
      V8 via Node.js
      ~14MB instalado

TypeScript 7.x (Go):

Arquivos → Scanner → Parser → Binder → Type Checker → Emitter
           ↑          ↑                    ↑            ↓
        Paralelo   Paralelo        Multi-threaded    .js + .d.ts
        I/O        parsing         type checking
        Binário nativo, ~25MB standalone
        Sem runtime

As mudanças de verdade:

1. Leitura paralela de arquivos. Goroutines lendo e parseando arquivos ao mesmo tempo. Num codebase com milhares de arquivos, isso sozinho já dá 2-3x.

2. Type checking paralelo. A parte mais pesada — type checking — agora roda em paralelo entre módulos independentes. Daqui que sai o grosso do 10x.

3. Memória compartilhada. Worker threads do JS precisam serializar dados. Goroutines do Go compartilham memória direto. A tabela de símbolos não precisa ser copiada.

4. Estruturas de dados nativas. Slices e maps do Go com alocação mais previsível que objetos do heap V8. Menos pressão no GC e melhor uso de cache.

tsgo CLI

O novo compilador sai como tsgo, convivendo com tsc:

# Compilador clássico (continua funcionando, TS 6.x)
npx tsc --build

# Compilador Go
npx tsgo --build

# Binário standalone (sem Node.js)
tsgo --build

Aceita o mesmo tsconfig.json e gera a mesma saída. Se compila com tsc, deve compilar com tsgo e dar os mesmos .js e .d.ts.

TypeScript 6.0: A ponte

TS 6.0 é a transição entre a era JS e a era Go:

TS 5.9 (Final 2025)    → Último release normal
TS 6.0 (Fev 2026)      → Ponte: deprecações + preparação
TS 7.0 (Meados 2026)   → Compilador Go (Project Corsa)

O que muda no TS 6.0 pensando no 7.0:

• target: "es5" depreciado. TS 7 não emite ES5. Se precisa, use Babel, SWC ou esbuild separado.
• moduleResolution antigos depreciados. "node" (a legacy) e "classic" morrem. Use "node16", "nodenext", ou "bundler".
• Defaults novos. Target padrão vira "es2025", module vira "nodenext".
• Tipos pra Temporal API. Tipos built-in da API Temporal do JavaScript.

Os 10x são de verdade?

Contexto pro número da manchete:

Build completo

O padrão: melhoria cresce com o tamanho. Projetos grandes têm mais arquivos pra paralelizar. Side project com 20 arquivos não vai notar tanto.

Experiência no IDE

Pra maioria dos devs, isso vai impactar mais que a velocidade de build:

Projeto TypeScript com 500 arquivos

TS 6.x:
  Carga inicial:          4-6 segundos
  Primeiro autocompletar: 2-3 segundos
  Go-to-definition:       500ms-1s
  Hover tipo:             200-500ms
  Rename global:          5-15 segundos

TS 7.x (tsgo):
  Carga inicial:          0.5-1 segundo
  Primeiro autocompletar: 200-400ms
  Go-to-definition:       50-150ms
  Hover tipo:             30-100ms
  Rename global:          1-3 segundos

IntelliSense mais rápido = menos espera, menos perda de flow, dev mais fluido.

Memória

Type-checking do codebase VS Code

TS 6.x (Node.js):
  Peak RSS:  ~4.2 GB
  Média:     ~3.1 GB

TS 7.x (tsgo):
  Peak RSS:  ~1.8 GB
  Média:     ~1.2 GB

~57% menos memória

Na prática: CI runners com menos RAM, dev em notebook sem swap, containers Docker mais enxutos.

O que quebra?

TS 7 mira compatibilidade, mas "mirar" e "acertar" são coisas diferentes.

🔴 Alto risco: Plugins do compilador

Se usa TypeScript Compiler API (ts.createProgram, ts.transform, etc.), é o ponto mais crítico. O compilador Go tem API diferente. Custom transformers escritos pra API JS não rodam com tsgo.

// ❌ Não funciona com tsgo
import * as ts from 'typescript';

const transformer: ts.TransformerFactory<ts.SourceFile> = (context) => {
  return (sourceFile) => {
    return ts.visitEachChild(sourceFile, visitor, context);
  };
};

Afeta:

• ts-morph
• ttypescript
• Qualquer ts.LanguageServicePlugin
• Build tools com uso pesado da Compiler API

TS 7 vai expor uma API cross-language nova (gRPC/IPC). Mas plugins atuais precisam ser reescritos.

🟡 Risco médio: Strict por padrão

TS 7 liga strict: true por padrão. Se não tá definido no tsconfig, liga tudo:

{
  "compilerOptions": {
    "strict": true,
    "strictNullChecks": true,
    "strictFunctionTypes": true,
    "strictBindCallApply": true,
    "strictPropertyInitialization": true,
    "noImplicitAny": true,
    "noImplicitThis": true,
    "alwaysStrict": true,
    "useUnknownInCatchVariables": true
  }
}

Se o codebase não usava strict, o upgrade vai soltar centenas de erros. Coloque "strict": false pra manter o comportamento atual.

🟢 Risco baixo: Output levemente diferente

O JS do tsgo deve ser funcionalmente igual ao do tsc, mas pode ter diferenças cosméticas. Pra maioria, invisível.

Como se preparar agora

1. Revise o tsconfig.json

npx tsgo --build --noEmit 2>&1 | grep -i "deprecated"

Cheque:

• target: "es5" → mude pra "es2020" ou superior
• moduleResolution: "node" → mude pra "node16" ou "bundler"

2. Teste strict mode

npx tsc --strict --noEmit 2>&1 | wc -l

Dá pra gerenciar? Ativa agora. Se forem milhares, vai ligando flag por flag.

3. Rode tsgo no projeto

npm install -D [email protected]
npx tsgo --noEmit

# Compare velocidade
time npx tsc --noEmit
time npx tsgo --noEmit

Impacto no ecossistema

Bundlers

Vite / Rolldown / esbuild / SWC: Core não é afetado. Em CI pode trocar o type check pra tsgo e ganhar velocidade.

webpack (ts-loader): Usa Compiler API direto, precisa de update pra tsgo.

IDEs

VS Code: Vai integrar o language service Go. IntelliSense sensivelmente mais rápido em workspaces grandes. O time do VS Code já usa internamente.

Frameworks

Next.js / Nuxt / Remix / SvelteKit: Trocar tsc por tsgo deve ser drop-in, sem mexer no código.

Angular: O compilador ngc depende pesado da Compiler API. Uma das migrações mais trabalhosas do ecossistema.

TypeScript ainda é "TypeScript"?

Teve debate. Uns falaram que compilador de TypeScript em Go quebra o self-hosting. Outros apontaram a ironia de uma ferramenta pra devs JS ser escrita em Go.

A real: TypeScript como linguagem não muda. Seus .ts, seu tsconfig.json, suas annotations — tudo igual. O compilador é detalhe de implementação. Assim como CPython é em C, TypeScript agora tem seu compilador numa linguagem mais rápida.

E sinceramente? Quando a galera viu 78 segundos virando 7.5, a discussão acabou rápido.

A tendência maior

TypeScript 7 faz parte de um padrão no tooling JS:

O ecossistema JS tá delegando infraestrutura pesada pra linguagens de sistema, mantendo as APIs de cara pro dev em JS/TS. JavaScript não tá morrendo. Tá se especializando.

O que vem

Curto prazo (Q1-Q2 2026)

• TS 7.0 beta disponível
• tsgo instalável via npm
• Bundlers e frameworks integram tsgo

Médio prazo (Q3-Q4 2026)

• TS 7.0 stable
• VS Code troca pro language service Go por padrão
• Plugins migram pra nova API

Longo prazo (2027+)

• TS 6.x em maintenance mode
• Features novas primeiro em Go
• Capacidades novas impossíveis no compilador JS

Conclusão

TypeScript 7 e Project Corsa são a maior mudança desde que TypeScript existe. Sair de um compilador self-hosted em JS pra um binário nativo em Go não é só otimização — é evolução arquitetural que abre portas novas.

Pra maioria, o upgrade vai ser anticlimático da melhor forma: código fica igual, config fica igual, tudo só fica mais rápido. Muito mais rápido.

Se seus builds de 78 segundos caindo pra 7.5 não te arrancam um sorriso, não sei o que arranca. 😄