TypeScript 6 y el camino a TypeScript 7: la guía de la migración al compilador nativo

Durante casi diez años, cada mejora de rendimiento en TypeScript llegaba en forma de optimización quirúrgica: un algoritmo de inferencia más listo, una caché mejor gestionada, menos pasadas sobre el árbol sintáctico. El compilador seguía siendo, en el fondo, un programa TypeScript compilado a JavaScript y ejecutado sobre un motor de JavaScript. Eso ya no es así. TypeScript 7 sustituye ese compilador por uno escrito en Go, y el salto de rendimiento no se mide en porcentajes sino en múltiplos.

Si trabajas con TypeScript a diario, hay dos preguntas que importan de verdad: qué cambia en el día a día con TypeScript 6, que ya está instalado en la mayoría de proyectos activos, y qué tienes que revisar antes de saltar a la 7. Vamos con las dos, sin relleno.

TypeScript 6.0: la última versión escrita en TypeScript

TypeScript 6.0 se planteó explícitamente como una versión bisagra: la última construida sobre la base de código clásica (la que el equipo llama internamente “Corsa” es ya la 7, así que a la 6 a veces se la nombra por descarte, “la JS-based”). Su función no es traer funcionalidades nuevas vistosas, sino homogeneizar los valores por defecto para que el salto posterior no rompa nada por sorpresa.

Los cambios de configuración por defecto son los que de verdad afectan a un proyecto existente:

• strict pasa a true por defecto. Si tu tsconfig.json no fijaba strict explícitamente, antes obtenías el modo permisivo sin darte cuenta. Ahora, si quieres seguir sin él, tienes que declararlo: "strict": false. Cualquier proyecto que empezó hace años sin fijar esta opción puede llevarse una buena cantidad de errores nuevos al actualizar.
• module pasa a esnext. Antes el valor por defecto dependía de target de una forma que confundía a casi todo el mundo. Ahora se asume, con razón, que ESM es el formato dominante.
• target deja de ser un valor fijo y pasa a seguir el año de ECMAScript en curso (en la práctica, ES2025 en el momento de escribir esto). Es un cambio conceptual: el compilador ya no apunta a una versión congelada, sino a “lo último que la especificación considera estable”.
• noUncheckedSideEffectImports se activa por defecto, lo que atrapa en tiempo de compilación un error muy habitual: importar un módulo por sus efectos secundarios (import './setup') cuando en realidad el path está mal escrito y el módulo no existe.
• rootDir ya no se infiere: por defecto es el directorio donde vive el tsconfig.json. Si tu estructura de carpetas dependía de la inferencia antigua, puedes encontrarte rutas de salida distintas a las que esperabas.
• types pasa a ser [] en vez de cargar automáticamente todos los paquetes @types/* instalados. Este cambio, en proyectos grandes con muchas dependencias de tipos, ha llegado a recortar entre un 20% y un 50% el tiempo de arranque del compilador, porque deja de leer declaraciones que nunca se usan. La contrapartida es que ahora tienes que declarar explícitamente qué paquetes de tipos necesitas en el array types.

Y en el otro extremo, lo que desaparece: target: es5 queda descartado por completo (el mínimo pasa a ser ES2015, porque no hay navegador relevante que no lo soporte desde hace años) y los formatos de módulo amd, umd y systemjs dejan de estar soportados. Si tu build todavía depende de alguno de ellos, necesitas un bundler que lo genere a partir de ESM, no esperar que lo haga tsc.

TypeScript 7.0: el compilador nativo

TypeScript 7.0 llegó el 8 de julio de 2026, tras una release candidate publicada semanas antes. La diferencia de fondo no es una API nueva ni una función de lenguaje: es que tsc ha dejado de ser un programa TypeScript y ha pasado a ser un binario nativo escrito en Go, con las mismas estructuras de datos y la misma lógica que el compilador clásico, pero compilado a código máquina y con soporte real de multihilo mediante memoria compartida.

Los números, publicados por el propio equipo de TypeScript sobre proyectos open source reales, son estos:

En conjunto, el equipo habla de builds completos entre 8x y 12x más rápidos, con una reducción de memoria de entre el 6% y el 26% según el proyecto. En VS Code, el tiempo de carga inicial de un proyecto TypeScript pasó de rondar el minuto a apenas diez segundos, algo que cualquiera que haya esperado a que el servidor de lenguaje “despierte” en un monorepo grande sabrá apreciar.

graph LR
subgraph "TypeScript 6.x y anteriores"
  A[Código TS] --> B[Compilador escrito en TS]
  B --> C[Ejecutado sobre V8 / Node]
  C --> D[JS + tipos verificados]
end
subgraph "TypeScript 7.0"
  E[Código TS] --> F[Compilador nativo en Go]
  F --> G[Binario compilado, multihilo real]
  G --> H[JS + tipos verificados]
end

Lo que rompe de verdad

No es una actualización transparente. Hay tres frentes en los que TypeScript 7 exige trabajo real:

1. Los valores por defecto de TypeScript 6 se vuelven obligatorios. strict: true, module: esnext, el mínimo target: es2015, la desaparición de AMD/UMD/SystemJS: todo lo que en la 6 era “el nuevo default, pero puedes desactivarlo” en la 7 deja de ser opcional en varios casos.
2. La API del compilador (conocida como Strada) no existe en el compilador nativo. TypeScript 7.0 se publica sin una API programática equivalente; el equipo ha confirmado que una nueva API llegará en la 7.1, no antes. Esto afecta directamente a cualquier herramienta que recorra el AST de TypeScript en tiempo de ejecución para generar código o analizar tipos: ts-morph es el caso más citado, pero cualquier linter, generador de esquemas o plugin de framework que dependa de typescript como librería (no solo como CLI) necesita comprobar si ya tiene una versión compatible.
3. El soporte de plantillas de frameworks va con retraso. Vue, Svelte, Angular y Astro necesitan una API programática estable para analizar tipos dentro de sus plantillas (.vue, .svelte, .astro), así que de momento siguen apoyándose en TypeScript 6.0 para esa parte, incluso en proyectos que ya usan 7.0 para el resto del código. Si tu stack incluye alguno de estos frameworks, comprueba el estado de su integración antes de forzar la actualización en todo el monorepo.

Para mitigar el golpe, el equipo publica @typescript/typescript6, un paquete que expone el comando tsc6 y la API clásica, pensado como puente para herramientas que todavía no han migrado.

Probarlo sin comprometer el proyecto

Antes de migrar de verdad, puedes validar compatibilidad instalando la preview nativa junto a tu compilador actual:

npm install -D @typescript/native-preview@beta
npx tsgo --noEmit

tsgo es el binario nativo expuesto por ese paquete. Ejecutarlo con --noEmit contra tu base de código te da una lista de discrepancias sin tocar tu instalación de typescript en producción. Si el resultado coincide con lo que ya obtienes con tsc, puedes empezar a introducir tsgo en CI como verificación adicional mientras esperas a que el resto del ecosistema (editor, framework, herramientas de build) confirme soporte estable.

Un detalle práctico que ahorra tiempo al comparar ambos compiladores: TypeScript 6.0 incluye la flag --stableTypeOrdering, pensada específicamente para que el orden en que se listan los tipos coincida con el que usará el compilador nativo, evitando falsos positivos al diferenciar los dos outputs.

Checklist de migración

Si gestionas un proyecto de tamaño medio o grande, este es el orden que minimiza sorpresas:

1. Actualiza a TypeScript 6.0 en una rama aislada y compila con "ignoreDeprecations": "6.0" activado.
2. Retira ignoreDeprecations y corrige, uno a uno, los avisos de deprecación que aparecen. No los silencies de forma permanente: cada uno es un cambio real que la 7.0 exigirá.
3. Fija explícitamente rootDir y el array types con los paquetes de @types que necesitas realmente; no dependas de la carga automática.
4. Audita tus dependencias de build: si usas ts-morph, algún linter con AST propio o un plugin de framework, comprueba su hoja de ruta hacia TypeScript 7 antes de continuar.
5. Instala @typescript/native-preview y compara tsgo --noEmit contra tu tsc actual.
6. Cuando el proyecto compile limpio en 6.0 y tsgo no reporte diferencias relevantes, actualiza el paquete typescript a la versión 7 en una rama de prueba y ejecuta toda tu batería de tests, no solo la compilación.

Qué hacer con esto hoy

Si tu equipo ya vive en strict: true y ESM, la actualización a TypeScript 6 apenas se nota más allá de revisar types y rootDir. Si vienes de una configuración antigua sin strict, es el momento de abordarlo por partes —módulo a módulo, no de golpe— antes de que la 7.0 te obligue a hacerlo sin margen.

La reescritura en Go no es un capricho de rendimiento: es la respuesta de Microsoft a que los proyectos TypeScript han crecido mucho más rápido de lo que su compilador clásico podía escalar, sobre todo en monorepos con decenas de miles de archivos. Para un proyecto pequeño, la diferencia de velocidad es agradable pero no cambia la vida. Para un monorepo donde el tsc --noEmit de CI tarda minutos, es la diferencia entre esperar y no esperar, y eso sí cambia cómo trabaja un equipo entero.

Vale la pena revisar también qué funciones del lenguaje merece la pena adoptar ahora que el compilador ya no es el cuello de botella: lo repasamos en JavaScript moderno en 2026: las funciones que deberías dominar. Y si tu equipo evalúa un cambio de runtime a la vez que de compilador, conviene leer antes Bun vs Node.js vs Deno en 2026: son decisiones independientes, pero conviene no tomarlas a ciegas una de la otra.