TypeScript 7.0: el compilador en Go que cambia tu día a día

El año pasado revisé un monorepo Nx de un cliente con más de 600 archivos TypeScript compartiendo tipos entre ocho aplicaciones Angular. Cada vez que alguien tocaba una interfaz común, tsc --noEmit tardaba entre 50 y 90 segundos en confirmar si habíamos roto algo.

Multiplica eso por cada dev, cada commit, cada CI run del día, y tienes horas enteras de tu equipo mirando una terminal en vez de escribir código.

Ayer, 8 de julio de 2026, Microsoft anunció que TypeScript 7 llegó a disponibilidad general. Y no es una release más con un par de utility types nuevos.

Es la primera vez en la historia del lenguaje que el compilador deja de estar escrito en TypeScript y pasa a ser un binario nativo en Go. El proyecto se llamó tsgo durante la beta; en la versión final, tsc ya es ese compilador nativo — no hay que instalar nada aparte.

Llevamos años escuchando la misma queja en cualquier proyecto TypeScript grande: "esto sería instantáneo si estuviera en Rust o en Go, como esbuild o swc". Microsoft por fin le hizo caso a su propia comunidad, y el resultado es el cambio de infraestructura más importante que ha tenido TypeScript desde que existe.

---

Qué cambió realmente en TypeScript 7 (no es un upgrade cosmético)

Hasta la versión 6.0, tsc era un compilador bootstrapped: TypeScript compilando TypeScript, que a su vez corría sobre el motor de JavaScript de Node. Funcional, pero con un techo de rendimiento que ni V8 ni ningún truco de caché podían romper del todo.

TypeScript 7 tira ese techo abajo. Microsoft reescribió el type-checker, el parser y el emitter en Go, un lenguaje compilado con gestión de memoria y concurrencia nativa.

La lógica de chequeo de tipos se mantiene estructuralmente idéntica a la de 6.0 — Microsoft no aprovechó la reescritura para "arreglar" reglas de inferencia. Si tu código compilaba limpio en 6.0 con stableTypeOrdering activado y sin flags deprecados, debería compilar igual en 7.0.

	TypeScript 6.0	TypeScript 7.0
Compilador	Bootstrapped (TS sobre JS/Node)	Nativo en Go (tsgo → tsc)
Velocidad de type-checking	Base	~10x más rápido (16.7x con --checkers 8)
strict	Opcional	Obligatorio
target: es5	Soportado	Eliminado
Módulos amd / umd / systemjs / none	Soportados	Eliminados (CommonJS sigue vivo)
baseUrl	Soportado	Eliminado
API programática estable	Disponible	Llega en TypeScript 7.1

TypeScript 7: los números que sí importan

Microsoft reporta que TypeScript 7.0 es, en promedio, unas 10 veces más rápido que TypeScript 6.0.

Pero el dato que de verdad vale la pena mirar es el de VS Code con el flag --checkers 8 (paralelización del type-checker en varios hilos): pasó de 125.7 segundos a 7.51 segundos. Un speedup de 16.7x en el chequeo de tipos de un codebase real y masivo.

Eso no es "un poco más rápido". Eso es la diferencia entre lanzar un build y perder el foco, versus lanzar un build y ver el resultado antes de levantar la vista de la pantalla.

Si trabajas en un proyecto Angular grande — de esos donde el IntelliSense empieza a tartamudear pasados los 200 componentes, como los que armamos en la guía de Angular Signal Forms — este es el tipo de mejora que se siente en el editor todos los días, no solo en el CI.

Si tu proyecto es de ese tamaño, probablemente ya conoces el dolor de mantener una arquitectura de tipos compartidos entre módulos. En el curso de Angular Moderno trabajamos justo ese tipo de estructura — componentes standalone, signals y una capa de tipos que ahora se va a beneficiar directamente de un compilador que deja de ser el cuello de botella.

¿Rompe mi código? Sí, pero no donde crees

La lógica de inferencia de tipos no cambió. Lo que cambió es que TypeScript 7 convierte en obligatorio todo lo que en 6.0 era opcional o estaba deprecado. Concretamente:

• strict mode ya no es una opción — es el default forzado.
• Desaparecen target: es5, downlevelIteration y, como valores de module, AMD, UMD, SystemJS y none (se recomienda esnext o preserve). CommonJS sigue soportado.
• baseUrl se elimina; los imports relativos tienen que ser explícitos o pasar por paths.
• Los template literals ahora preservan code points Unicode reales, en vez de partir emojis en pares de surrogates UTF-16. Un detalle pequeño que puede romper tests de snapshots si comparas strings a nivel de caracteres.

Si tu proyecto usa validación de esquemas con librerías como Zod, strict obligatorio en realidad juega a tu favor: el compilador ahora exige la misma disciplina de tipos que ya deberías estar aplicando en tus schemas. Si todavía no tienes esa disciplina, este es un buen momento para revisar el curso de Zod para TypeScript antes de que strict te obligue a arreglarlo todo de golpe.

Antes de migrar a TypeScript 7: el checklist que de verdad importa

Actualizar con npm install -D typescript instala el nuevo tsc nativo sin fricción. El problema nunca es la instalación — es lo que descubres después de instalarlo:

1. Revisa tu tsconfig.json. Si el archivo vive fuera del directorio de fuentes (algo común en monorepos), ahora tienes que declarar rootDir de forma explícita. Antes el compilador lo inferías; ahora no.
2. Declara tus @types en el array types. El comportamiento por defecto cambió — si dependes de tipos globales de paquetes como @types/node o @types/jest, sé explícito o vas a ver errores de "no se encuentra el nombre" en símbolos que antes funcionaban solos.

// tsconfig.json — antes (TypeScript 6.0, inferido)
{
  "compilerOptions": {
    // rootDir se infería, types no era obligatorio
  }
}

// tsconfig.json — después (TypeScript 7.0, explícito)
{
  "compilerOptions": {
    "rootDir": "./src",
    "types": ["node", "jest"]
  }
}

3. Si tienes JavaScript con JSDoc, revisa el CHANGES.md del proyecto. Patrones como @enum, el operador postfix ! o sintaxis estilo Closure divergen del comportamiento de 6.0. No es una lista larga, pero si tu proyecto tiene archivos .js documentados con JSDoc, vale la pena los cinco minutos de lectura.
4. Si necesitas convivir con TS 6.0 — por ejemplo, porque una herramienta de tu stack todavía depende de la API interna — instala el paquete @typescript/typescript6, que expone un ejecutable tsc6 en paralelo.

Nada de esto es dramático. Pero tampoco es un "npm install y ya". Trátalo como tratarías cualquier upgrade de compilador mayor — o como el cambio de Karma a Vitest en Angular 22: en una rama aparte, con CI corriendo antes de tocar main.

Lo que todavía no puedes hacer

Aquí está la letra pequeña que casi nadie está mencionando: la API programática estable de TypeScript 7 — la que usan herramientas como ts-morph, plugins de bundlers o el propio Angular Language Service para chequeo de tipos en templates — no llega hasta la versión 7.1. El GA de hoy es para el CLI, para tsc. No para quien construye herramientas sobre el compilador.

Eso significa que, por ahora, puedes usar TypeScript 7 para el chequeo de proyecto completo desde la línea de comandos y sacarle el speedup en CI hoy mismo. Pero el chequeo dentro de templates de Angular en tu editor va a seguir dependiendo de TypeScript 6.0 hasta que esa API se estabilice. Es una convivencia perfectamente normal, no una incompatibilidad — simplemente no esperes que todo tu tooling salte a la vez.

---

Mi consejo, después de quince años viendo migraciones de compiladores salir mal por prisa: no actualices tu proyecto de producción esta semana solo porque salió el anuncio.

Crea una rama, instala TypeScript 7, corre tu build y tu suite de tipos, y mide tú mismo la diferencia de tiempo antes de tocar main. El speedup es real, pero el checklist de arriba es lo que separa una migración de una tarde de una migración de una semana apagando incendios.

Si quieres profundizar en arquitecturas TypeScript grandes y cómo estructurarlas para que este tipo de mejoras de compilador realmente se noten, en Dominicode Labs compartimos los proyectos y patrones que uso en clientes reales, actualizados a medida que el ecosistema cambia.

---

Preguntas frecuentes

¿Debo actualizar mi proyecto a TypeScript 7 ya?

Para probar y medir, sí — en una rama separada, no en producción directamente. Para producción, primero revisa el checklist de breaking changes (strict obligatorio, rootDir explícito, array types, eliminación de targets legacy) y corre tu CI completo antes de mergear.

¿TypeScript 7 rompe mi código actual?

La lógica de type-checking es estructuralmente idéntica a la de TypeScript 6.0. Si tu proyecto ya compilaba limpio en 6.0 con stableTypeOrdering y sin usar flags deprecados, debería compilar igual. Lo que sí rompe son los defaults: strict obligatorio, sin target: es5, sin módulos amd/umd/systemjs/none (CommonJS sigue soportado) y sin baseUrl.

¿Qué es tsgo?

Es el nombre que tuvo el proyecto de reescritura del compilador de TypeScript en Go durante su fase de beta y builds nightly. En el release final de TypeScript 7.0, ese compilador nativo en Go es tsc — no existe un binario separado llamado tsgo que tengas que invocar.

¿Angular ya es compatible con TypeScript 7?

Parcialmente. Puedes usar TypeScript 7 desde la CLI para el chequeo de tipos de proyecto completo y aprovechar el speedup en builds y CI hoy mismo. El propio anuncio de lanzamiento de Microsoft admite que las herramientas que embeben TypeScript en su propio compilador — como las que dan soporte a templates de Angular — "probablemente" seguirán dependiendo de TypeScript 6.0 hasta que la API programática estable llegue en la 7.1. Angular todavía no ha publicado su propia matriz de compatibilidad para TS 7, así que confírmalo en su documentación oficial antes de tocar el editor de tu equipo.

¿Cuándo llega la API programática estable?

Microsoft la tiene planificada para TypeScript 7.1, no para este GA de 7.0. Si construyes herramientas sobre el compilador (ts-morph, plugins de build, integraciones de linters), tu código seguirá dependiendo de la API de TypeScript 6.0 hasta esa siguiente versión.

---

Por Bezael Pérez — Developer senior con más de 15 años de experiencia y fundador de Dominicode.