Decisiones de actualización a TypeScript 7: verificadores en paralelo, modo vigilancia y brechas en la API

TypeScript 7 es una versión importante inusual: el lenguaje que se escribe permanece igual, mientras que el programa encargado de verificarlo y compilarlo ha sido reemplazado. Para la mayoría de los equipos, la actualización supone una gran mejora en velocidad sin necesidad de corregir nada, pero para aquellos cuyas herramientas interactúan directamente con el compilador, puede representar un obstáculo. Esta guía explica qué difiere realmente entre la versión 6 y la 7, cómo utilizar los nuevos controles de paralelismo y cómo decidir si su proyecto debe actualizarse ahora o esperar a una nueva versión.

El blog ya ha abordado en detalle las mejoras de velocidad obtenidas con la reescritura en Go y por qué la adaptación rompió las herramientas de análisis y los componentes de framework; por lo tanto, aquí el enfoque está en la decisión práctica de actualizar.

Mismo lenguaje, nuevo motor

En el momento de escribir esto, TypeScript 7.0 ya se ha lanzado como versión estable (se informó el 8 de julio de 2026; consulte las notas de lanzamiento para conocer el estado actual). Se trata de una reescritura del compilador desde TypeScript a Go, un proyecto que Microsoft anunció en marzo de 2025 bajo el nombre en código Corsa. No se trata de una nueva versión del lenguaje en el sentido habitual: no hay nueva sintaxis, las semánticas del sistema de tipos están destinadas a permanecer inalteradas y no se espera que los archivos .ts existentes dejen de funcionar. Su código sigue siendo el mismo; solo cambia la infraestructura subyacente.

Por qué fue necesario reescribir el compilador

Hasta e incluyendo TypeScript 6, el compilador estaba escrito en TypeScript y se ejecutaba en un motor de JavaScript, lo que en la práctica significaba un único hilo para la verificación de tipos. En los grandes monorepos esto se manifestaba de tres maneras habituales:

• Los editores tardaban tanto en cargar un proyecto que los desarrolladores aprendieron a esperar.
• Las verificaciones de tipo en CI llevaban minutos por ejecución.
• El consumo de memoria era tan alto que hacía que las laptops tuvieran dificultades notables para funcionar.

El equipo optimizó la implementación en JavaScript durante años y concluyó que el cuello de botella era el propio entorno de ejecución y no los algoritmos. Por eso se portó el verificador a Go, manteniendo deliberadamente su estructura lo más cercana posible al código existente. Esa elección es importante: un port fiel en lugar de un rediseño es lo que mantiene la desviación de comportamiento entre 6 y 7 puntos.

¿Qué cambia en la práctica?

Verificaciones de tipo mucho más rápidas

Los resultados de pruebas publicados por Microsoft muestran la magnitud de la mejora: la verificación de tipos en el códigobase de VS Code pasó de 77,8 segundos a 7,5 segundos, es decir, aproximadamente diez veces más rápido, y Playwright pasó de 11,1 segundos a 1,1 segundo. Dos factores contribuyen a esto. El compilador ahora se ejecuta como código máquina nativo en lugar de JavaScript ejecutado por un motor, y puede realizar verificaciones en paralelo mediante goroutines, algo que el antiguo diseño de un solo hilo nunca pudo hacer. Sus propios resultados dependerán de la estructura del proyecto; muchos archivos pequeños e independientes se paralelizan mejor que un enorme conjunto entrelazado de tipos.

Nuevos controles en la línea de comandos para el paralelismo

Su tsconfig.json no cambia, ya que describe el lenguaje y el proyecto, no cómo el compilador programa su trabajo. La configuración a continuación es válida para ambas versiones:

// tsconfig.json — nothing changes here, this is the language, not the compiler
{
  "compilerOptions": {
    "strict": true,
    "target": "ES2022"
  }
}

Los nuevos controles se encuentran en la línea de comandos. --checkers determina cuántos procesos de verificación de tipos se ejecutan en paralelo, --builders controla cuántas compilaciones de referencias del proyecto se realizan al mismo tiempo, y --singleThreaded desactiva por completo el paralelismo:

# But at the CLI level, TypeScript 7 gives you real knobs to turn:
tsc --checkers 4        # number of parallel type-checker workers
tsc --builders 2        # parallel project-reference builds
tsc --singleThreaded    # opt out entirely, useful for reproducible CI logs

El modo de un solo hilo es útil cuando se necesitan registros de CI deterministas y fáciles de leer, o cuando se investiga un posible problema de ordenamiento. En ejecutores de CI compartidos, limitar --checkers al número de núcleos disponibles evita sobrecargar la máquina; además, más procesos significan más memoria en uso al mismo tiempo, por lo que es mejor medir antes que maximizar de forma ciega.

Un modo de monitoreo rediseñado

En proyectos grandes, el antiguo sistema de monitoreo de archivos basado en consultas era un problema conocido, ya que tsc --watch se retrasaba con respecto a los cambios realizados. TypeScript 7 traslada el enfoque de monitoreo de archivos utilizado por el watcher de Parcel a Go, de modo que las reconstrucciones comienzan de inmediato después de guardar los cambios, en lugar de retrasarse.

Empaquetado más sencillo

Durante el período de prueba, probar el compilador nativo requería instalar un paquete separado llamado @typescript/native-preview. Con la versión 7.0, todo vuelve a estar bajo el nombre de paquete estándar, por lo que la instalación es exactamente como siempre ha sido:

npm install -D typescript

Si experimentaste con la versión de prueba, elimina ese paquete adicional y cualquier script que invocara su binario separado, para no terminar ejecutando dos compiladores.

La verdadera deficiencia: la API programática

Esta es la parte que determina muchas actualizaciones. Las herramientas desarrolladas sobre la API del compilador TypeScript, como los complementos language-service, las reglas de lint personalizadas y los codemods, aún no pueden contar con una API programática estable para el compilador Go en la versión 7.0; en el momento de escribir esto, se espera que esté disponible en una versión posterior, con 7.1 como objetivo mencionado. Si su pipeline utiliza algo como ts.createProgram() para analizar el programa, pruebe cuidadosamente ese método antes de pasar a usarlo en producción.

Un escenario realista de migración

Considere un monorepo de tamaño medio con Next.js que contiene unas 40,000 líneas de TypeScript y varias referencias a proyectos. Al pasar a la versión 7.0 en un entorno como este, el comando tsc --noEmit puede pasar de aproximadamente 52 segundos a unos 6. Aunque ahorrar 46 segundos en una sola ejecución parezca poco, esto se aplica a cada tarea de CI, a cada hook pre-commit y a cada verificación manual durante la depuración; en un equipo, eso suma horas semanales.

En los proyectos que solo utilizan tsc para verificar y compilar, la migración en sí suele ser poco significativa: basta con actualizar el paquete, ejecutar el verificador y confirmar que todo funciona sin cambios en el código.

npm install -D typescript@latest
npx tsc --noEmit   # ran clean, zero code changes needed

Una ejecución sin errores es el resultado esperado, pero no una garantía. Guarde los resultados de TypeScript 6 para comparar y analice las errores reportados en la primera ejecución, ya que siempre es posible encontrar casos límite en un proyecto de esta magnitud.

¿Debería actualizar ahora?

• Actualízate ahora si utilizas tsc únicamente para la verificación de tipos y las compilaciones. Se trata, en efecto, de una mejora que se integra sin problemas.
• Espera o divide si dependes de la API programática del compilador a través de herramientas personalizadas, complementos de editor o codemods. Espera a que esté disponible la API estable, o mantén instalado TypeScript 6 para esas herramientas mientras utilizas 7 para las verificaciones.
• Dale prioridad si gestionas un monorepo muy grande donde los minutos de CI representan un costo real. El ahorro de tiempo puede compensar el esfuerzo de migración en cuestión de días.

Puntos clave

• TypeScript 7 modifica el compilador, no el lenguaje; tus archivos tsconfig.json y de código se mantienen intactos.
• La mayor velocidad proviene del código nativo y de la verificación en paralelo, algo que puedes ajustar con --checkers, --builders y --singleThreaded.

El principal riesgo no es su código, sino las herramientas que incorporan el compilador; por lo tanto, haga un inventario de ellas antes de hacer el cambio.

Si la lentitud en las verificaciones era su mayor queja con TypeScript, 7 la elimina en gran medida; si depende de los componentes internos del compilador, espere una versión adicional.