TypeScript 7 y Project Corsa: Todo lo que necesitás saber sobre la reescritura en Go (10x más rápido)

En marzo de 2025, Anders Hejlsberg se sentó frente a una cámara y largó algo que nadie veía venir:

"Estamos portando el compilador de TypeScript a Go."

No a Rust. No a una reescritura gradual. Port completo del compilador, language service y type checker — las tripas del ecosistema TypeScript — de TypeScript a Go. Microsoft lo bautizó Project Corsa y ahora viene como TypeScript 7.0.

Para que dimensiones: el repo de VS Code tiene 1.5 millones de líneas de TypeScript. Con tsc tradicional, compilar tarda unos 78 segundos. Con tsgo, el nuevo compilador en Go: 7.5 segundos. No hablamos de un 2x. Hablamos de 10.4x.

Esto no es un retoque de tooling. Es el cambio más grande en 12 años de TypeScript, y va a transformar cómo construimos, desplegamos y razonamos sobre nuestro código. Desglosemos todo.

¿Por qué reescribir? ¿Por qué ahora?

Para entender Project Corsa, primero hay que entender qué estaba fallando.

El compilador original de TypeScript estaba escrito en TypeScript — self-hosting que funcionó más de una década. Pero a medida que TypeScript se comió la web (en agosto 2025 superó a JavaScript en GitHub), empezó a ahogarse con su propio éxito:

La pared de escalabilidad

• Los codebases corporativos se fueron al carajo de grandes. Google, Microsoft, Stripe manejan millones de líneas de TypeScript. A esa escala, el IDE empezó a andar lento: errores apareciendo con delay, autocompletado tardando 2-3 segundos, renames que se morían por timeout.

• CI/CD como cuello de botella. En monorepos con cientos de paquetes, tsc --build era muchas veces el paso más lento de todo el pipeline — a veces más de 10 minutos para un type check completo.

• El techo del single-thread. JavaScript es single-threaded de nacimiento. Type checking, parsing, inferencia — todo secuencial en un core, mientras los otros 15 del M4 Pro miraban el techo.

¿Por qué Go?

La pregunta del millón.

¿Por qué no Rust? Rust te da máximo performance, pero te cobra caro en velocidad de desarrollo. El código del compilador es muy funcional — closures por todos lados, estructuras recursivas, pattern matching sobre unions discriminadas. El modelo de ownership de Rust choca constantemente con ese estilo. El equipo calculó que un rewrite en Rust iba a tardar 3-5x más y exigir rediseñar la arquitectura completa.

¿Qué tiene Go?

1. Encaje natural. El compilador de TypeScript es sorpresivamente procedural-funcional. El estilo de Go (interfaces, funciones de primera clase, structs sencillos) calza perfecto con los patrones existentes.

2. Goroutines. Paralelismo barato sin la complejidad de manejar threads a mano. Ideal para type-checking en paralelo entre archivos.

3. Performance predecible. El GC de Go está pensado para baja latencia. No hay pausas random como con V8 — justo lo que necesitás para un language service de IDE.

4. Un binario y listo. Go compila a un ejecutable autónomo. Sin Node.js. Sin npm install. Descargás y corrés.

5. Curva de aprendizaje. El equipo se volvió productivo en Go mucho más rápido que lo que hubiera sido con Rust, y aún así lograron el salto de performance.

La arquitectura por dentro

Project Corsa no es "el mismo compilador pero en Go." La arquitectura cambió de raíz.

Antes y Después

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

Archivos → Scanner → Parser → Binder → Type Checker → Emitter
           ↑                                            ↓
      Single-threaded, pipeline secuencial          .js + .d.ts
      V8 vía Node.js
      ~14MB instalado

TypeScript 7.x (Go):

Archivos → Scanner → Parser → Binder → Type Checker → Emitter
           ↑          ↑                    ↑            ↓
        Paralelo   Paralelo        Multi-threaded    .js + .d.ts
        I/O        parsing         type checking
        Binario nativo, ~25MB standalone
        Sin runtime

Los cambios de fondo:

1. Lectura paralela de archivos. Goroutines leyendo y parseando archivos a la vez. En codebases con miles de archivos, esto solo ya da 2-3x.

2. Type checking paralelo. Lo más pesado — el type checking — ahora corre en paralelo entre módulos que no dependen entre sí. De acá sale el grueso del 10x.

3. Memoria compartida. Los worker threads de JS necesitan serializar datos entre threads. Las goroutines de Go comparten memoria directamente. La tabla de símbolos no se copia, se accede.

4. Estructuras de datos nativas. Slices y maps de Go con allocación más predecible que los objetos de V8. Menos presión de GC, mejor uso de cache.

tsgo CLI

El nuevo compilador sale como tsgo, conviviendo con tsc:

# Compilador clásico (sigue andando, TS 6.x)
npx tsc --build

# Compilador en Go
npx tsgo --build

# Binario standalone (sin Node.js)
tsgo --build

Acepta el mismo tsconfig.json y produce la misma salida. Si compila con tsc, debería compilar con tsgo y dar los mismos .js y .d.ts.

TypeScript 6.0: El puente

TS 6.0 es la transición entre la era JS y la era Go:

TS 5.9 (Fines 2025)    → Último release normal
TS 6.0 (Feb 2026)      → Puente: deprecaciones + preparación
TS 7.0 (Mediados 2026) → Compilador Go (Project Corsa)

Lo que cambia en TS 6.0 pensando en 7.0:

• target: "es5" deprecado. TS 7 no emite ES5. Si lo necesitás, usá Babel, SWC o esbuild por fuera.
• moduleResolution viejos deprecados. "node" (la legacy) y "classic" mueren. Usá "node16", "nodenext", o "bundler".
• Defaults nuevos. Target por defecto pasa a "es2025", module a "nodenext".
• Tipos para Temporal API. Tipos built-in para la API Temporal de JavaScript.

¿Los 10x son posta?

Contexto para el titular:

Build completo

El patrón: la mejora crece con el tamaño. Proyectos grandes tienen más archivos para paralelizar. Un side project con 20 archivos no va a sentir mucho.

Experiencia IDE

Para la mayoría de los devs, esto va a ser más notorio que el build:

Proyecto TypeScript con 500 archivos

TS 6.x:
  Carga inicial:           4-6 segundos
  Primer autocompletado:   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
  Primer autocompletado:   200-400ms
  Go-to-definition:        50-150ms
  Hover tipo:              30-100ms
  Rename global:           1-3 segundos

IntelliSense más rápido = menos espera, menos corte de flow, desarrollo más fluido.

Memoria

Type-checking del codebase de VS Code

TS 6.x (Node.js):
  Peak RSS:  ~4.2 GB
  Promedio:  ~3.1 GB

TS 7.x (tsgo):
  Peak RSS:  ~1.8 GB
  Promedio:  ~1.2 GB

~57% menos memoria

En la práctica: CI runners con menos RAM, dev en laptop sin swapping, containers Docker más ajustados.

¿Qué se rompe?

TS 7 apunta a compatibilidad, pero "apuntar" y "lograr" son cosas distintas.

🔴 Alto riesgo: Plugins del compilador

Si usás la TypeScript Compiler API (ts.createProgram, ts.transform, etc.), es lo más crítico. El compilador Go tiene una API distinta. Los custom transformers escritos para la API de JS no andan con tsgo.

// ❌ Esto no funciona con tsgo
import * as ts from 'typescript';

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

Afecta a:

• ts-morph
• ttypescript
• Cualquier ts.LanguageServicePlugin
• Build tools con uso profundo de Compiler API

TS 7 va a exponer una API cross-language nueva (gRPC/IPC). Pero los plugins actuales hay que reescribirlos.

🟡 Riesgo medio: Strict por defecto

TS 7 activa strict: true por defecto. Si no lo tenés seteado explícitamente, se prende todo:

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

Si tu codebase no usaba strict, el upgrade te va a tirar cientos de errores. Poné "strict": false para mantener el comportamiento actual.

🟢 Riesgo bajo: Output ligeramente distinto

El JS que emite tsgo debería ser idéntico en funcionalidad, pero puede haber diferencias cosméticas (whitespace, source maps, comentarios). Para la mayoría, invisibles.

Cómo prepararte hoy

1. Revisá tu tsconfig.json

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

Chequeá:

• target: "es5" → pasá a "es2020" o superior
• moduleResolution: "node" → pasá a "node16" o "bundler"

2. Probá strict mode

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

Si es manejable, activalo ya. Si no, andá prendiendo flags uno por uno.

3. Corré tsgo en tu proyecto

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

# Compará tiempos
time npx tsc --noEmit
time npx tsgo --noEmit

Impacto en el ecosistema

Bundlers

Vite / Rolldown / esbuild / SWC: Su core no se ve afectado, pero en CI podés usar tsgo para type checking más rápido.

webpack (ts-loader): Usa la Compiler API directamente, así que necesita update para tsgo.

IDEs

VS Code: Va a integrar el language service en Go. IntelliSense notablemente más rápido en workspaces grandes. El equipo de VS Code ya lo usa internamente.

Frameworks

Next.js / Nuxt / Remix / SvelteKit: Reemplazar tsc por tsgo debería ser drop-in, sin tocar código.

Angular: El compilador ngc depende fuerte de la Compiler API. Una de las migraciones más jodidas del ecosistema.

¿TypeScript sigue siendo "TypeScript"?

Hubo debate. Algunos dijeron que un compilador de TypeScript que no está en TypeScript rompe el self-hosting. Otros señalaron la ironía de que una herramienta para devs JavaScript esté en Go.

La realidad: TypeScript como lenguaje no cambia. Tus .ts, tu tsconfig.json, tus type annotations — todo igual. El compilador es un detalle de implementación. Igual que CPython está en C, TypeScript ahora tiene su compilador en un lenguaje más rápido.

Y honestamente? Cuando la gente vio 78 segundos bajar a 7.5, la discusión se terminó bastante rápido.

La tendencia más amplia

TypeScript 7 es parte de un patrón general en el tooling JS:

El ecosistema JS está delegando la infraestructura pesada a lenguajes de sistema, manteniendo las APIs de cara al dev en JS/TS. JavaScript no se está muriendo. Se está especializando.

Qué viene

Corto plazo (Q1-Q2 2026)

• TS 7.0 beta disponible
• tsgo instalable vía npm
• Bundlers y frameworks principales integran tsgo

Mediano plazo (Q3-Q4 2026)

• TS 7.0 stable
• VS Code pasa al language service Go por defecto
• Plugins migran a la nueva API

Largo plazo (2027+)

• TS 6.x entra en maintenance mode
• Features nuevas primero en Go
• Capacidades nuevas imposibles con el compilador JS

Conclusión

TypeScript 7 y Project Corsa son el cambio más grande desde que TypeScript existe. Pasar de un compilador self-hosted en JS a un binario nativo en Go no es solo optimización — es una evolución arquitectónica que habilita cosas nuevas.

Para la mayoría, el upgrade va a ser anticlimático de la mejor manera: tu código queda igual, tu config queda igual, y todo simplemente anda más rápido. Mucho más rápido.

Si tus builds de 78 segundos bajando a 7.5 no te sacan una sonrisa, que Dios te ayude. 😄