TypeScript 7: el compilador nativo en Go que lo cambia todo

TypeScript 7 no añade tipos nuevos ni cambia la sintaxis. Reescribe el compilador en Go nativo. La diferencia en proyectos reales: builds que pasan de 30 segundos a 3. Type checking que deja de bloquear el editor. Y un ecosistema que, de golpe, tiene que decidir qué hacer con décadas de herramientas escritas para la API de compilación anterior.

Esta versión es un punto de inflexión, no una mejora incremental. Si tienes TypeScript en producción, necesitas entender qué cambia, qué no cambia y cuándo tiene sentido migrar.

Por qué reescribir el compilador en Go#

El compilador de TypeScript lleva desde 2012 escrito en TypeScript. Ha escalado bien hasta cierto punto, pero tiene un límite estructural: JavaScript es de un solo hilo. Por mucho que optimices el código, el compilador no puede paralelizar trabajo real en proyectos grandes.

Go tiene concurrencia nativa, gestión de memoria eficiente y produce binarios que arrancan en milisegundos. El equipo de TypeScript evaluó Rust y Go durante meses antes de elegir Go, principalmente por la velocidad de iteración del equipo y la facilidad de gestión de concurrencia con goroutines.

Los números del equipo de Microsoft en proyectos internos:

• TypeScript en VSCode: de 7,5s a 1,1s en type checking completo
• Proyecto Next.js mediano (~400 archivos): de 28s a 2,4s en build limpio
• Monorepo enterprise (~2.000 archivos): de 4min a 21s

No son mejoras del 20%. Son órdenes de magnitud.

Qué cambia en el día a día#

El compilador es ahora un binario nativo#

# TypeScript 7 instala un binario nativo, no código JS
npm install typescript@next

# tsc ya no ejecuta Node.js internamente — es un binario directo
which tsc
# /usr/local/bin/tsc  ←  binario Go compilado para tu plataforma

tsc --version
# Version 7.0.0-beta.1 (native)

El arranque frío de tsc pasa de ~300ms (Node.js bootstrapping) a ~5ms. En watch mode se nota inmediatamente.

Type checking sin bloquear el editor#

El servidor de lenguaje (tsserver) también es nativo. En proyectos grandes, el editor dejaba de responder mientras el type checker procesaba cambios en archivos grandes. Con el servidor Go, el checking corre en hilos separados y el editor sigue respondiendo.

// tsconfig.json — nueva opción para controlar paralelismo
{
  "compilerOptions": {
    "target": "ES2022",
    "module": "NodeNext",
    "strict": true,
    "isolatedDeclarations": true,
    "parallelTypeChecking": true  // nuevo en TS7, true por defecto
  }
}

erasableSyntaxOnly: el modo que elimina la fricción con bundlers#

TypeScript 7 añade erasableSyntaxOnly, una opción que restringe el código a sintaxis que puede eliminarse sin transformación. Sin enum, sin namespace, sin experimentalDecorators de la era pre-estándar.

// Con erasableSyntaxOnly: true — esto falla en compilación
enum Direction {
  Up = "UP",
  Down = "DOWN"
}

// Usa const enum o mejor, un objeto literal con 'as const'
const Direction = {
  Up: "UP",
  Down: "DOWN",
} as const;
type Direction = typeof Direction[keyof typeof Direction];

Por qué importa: los bundlers modernos (esbuild, Rollup, Vite) ya hacen strip de tipos con transformaciones simples. erasableSyntaxOnly garantiza que tu código es compatible con esa forma de compilar, eliminando una clase entera de bugs sutiles que aparecen cuando el bundler y tsc discrepan.

isolatedDeclarations se vuelve mainstream#

isolatedDeclarations existía desde TypeScript 5.5 pero era poco conocida. En TypeScript 7 es la opción recomendada para cualquier proyecto que publique tipos o use builds paralelos.

// Sin isolatedDeclarations — esto compila pero es lento de procesar en paralelo
export function procesar(items: Parameters<typeof transformar>[0]) {
  return items.map(transformar);
}

// Con isolatedDeclarations: true — tipos explícitos, procesamiento paralelo
export function procesar(
  items: Array<{ id: number; nombre: string; activo: boolean }>
): Array<{ id: number; nombre: string; slug: string }> {
  return items.map(transformar);
}

El compilador puede procesar cada archivo de forma independiente cuando los tipos son explícitos. Eso es lo que permite la paralelización real.

Lo que NO migra automáticamente#

La Compiler API se rompe#

La parte más disruptiva de TypeScript 7 es que la Compiler API de JavaScript (ts.createProgram, ts.transpileModule, etc.) está deprecada y no existe en el compilador Go.

Herramientas que dependen de esta API y que necesitan actualización:

• ts-jest: usa ts.transpileModule internamente
• ts-node: depende de la Compiler API para ejecutar TypeScript directamente
• ts-morph: librería de manipulación de AST basada en la API anterior
• tsup: usa ts.createProgram para builds
• Cualquier transform personalizado en tsconfig.json

El ecosistema está actualizando activamente. Para mayo de 2026, ts-node ya tiene una versión compatible y ts-jest tiene una beta. Pero si tu proyecto usa transforms de compilación personalizados, la migración requerirá trabajo.

experimentalDecorators no está en el compilador nativo#

Los decoradores estándar de TC39 (Stage 3) están soportados. Los experimentalDecorators del compilador anterior no. Si usas NestJS, TypeORM o class-validator con la configuración clásica, necesitas migrar a los decoradores estándar antes de saltar a TypeScript 7.

// experimentalDecorators (no soportado en TS7 nativo)
@Injectable()
class ServicioUsuarios {
  @Inject(REPOSITORIO_TOKEN)
  private repositorio: RepositorioUsuarios;
}

// Decoradores estándar TC39 (soportado en TS7)
@injectable()
class ServicioUsuarios {
  constructor(
    @inject(REPOSITORIO_TOKEN) private repositorio: RepositorioUsuarios
  ) {}
}

NestJS v11 añade soporte a decoradores estándar manteniendo compatibilidad con los experimentales durante el período de transición.

Estrategia de migración por tipo de proyecto#

Proyecto nuevo#

Empieza directamente con TypeScript 7. Activa erasableSyntaxOnly, isolatedDeclarations y strict. No hay nada que migrar.

{
  "compilerOptions": {
    "target": "ES2022",
    "module": "NodeNext",
    "moduleResolution": "bundler",
    "strict": true,
    "erasableSyntaxOnly": true,
    "isolatedDeclarations": true,
    "parallelTypeChecking": true
  }
}

Proyecto existente sin decoradores ni Compiler API#

La migración es relativamente directa. Actualiza TypeScript, ejecuta tsc y resuelve los errores que aparezcan, que probablemente sean enum que necesitas convertir a const objects.

npm install typescript@latest
npx tsc --noEmit  # ver qué rompe sin generar archivos

Proyecto con NestJS o TypeORM#

Espera a NestJS v11 estable y TypeORM 0.4 antes de migrar. La transición de experimentalDecorators a decoradores estándar requiere cambios en toda la base de código. Hazlo en una rama separada con tiempo suficiente para testear.

Monorepo con tools personalizadas#

Audita primero qué herramientas del build usan la Compiler API. Para cada una, busca si tiene versión compatible con TS7 o si necesitas una alternativa. No migres hasta tener el camino claro.

Errores comunes al migrar a TypeScript 7#

Migrar antes de que el ecosistema esté listo. TypeScript 7 está en beta. Para proyectos en producción con dependencias complejas, espera a la versión estable y a que las herramientas clave (ts-jest, ts-node, NestJS) tengan releases oficiales.

Ignorar `erasableSyntaxOnly` por comodidad. Los enum son fáciles de usar y difíciles de querer migrar. Pero el modo erasableSyntaxOnly existe por razones de rendimiento y compatibilidad reales. Migrando enum a const objects ahora reduces la deuda técnica para cuando TS7 sea estable.

Asumir que todos los tipos van a ser más rápidos. El compilador nativo es más rápido en builds completos y en watch mode. Pero si tienes tipos inferidos muy complejos con cientos de niveles de recursión, el cuello de botella sigue siendo la complejidad del sistema de tipos, no la velocidad del compilador.

No actualizar las extensiones del editor. El servidor de lenguaje nuevo requiere extensiones actualizadas. Asegúrate de tener la versión compatible de la extensión de TypeScript para VSCode o tu editor antes de cambiar la versión del compilador en el proyecto.

Conclusión#

TypeScript 7 es la mayor revisión de la herramienta en diez años. No porque cambie el lenguaje, sino porque cambia la herramienta que lo compila. Builds 10x más rápidos, editor que no se congela en proyectos grandes y un modelo de compilación que permite el paralelismo real son mejoras que se notan en el día a día desde el primer build.

El coste es real: la Compiler API se rompe, los decoradores experimentales desaparecen y parte del ecosistema necesita tiempo para adaptarse. Para proyectos nuevos y proyectos sin dependencias de la Compiler API, la migración es ya. Para proyectos con NestJS, TypeORM o transforms personalizados, da un par de meses más al ecosistema. La dirección es clara y el destino vale el viaje.