TypeScript 7.0 representa una evolución arquitectónica sin precedentes. El núcleo de esta versión gira en torno a la «velocidad extrema y la concurrencia», ya que la infraestructura del compilador se ha reescrito íntegramente desde JavaScript hacia Go. Esta profunda reestructuración dota a TypeScript de un rendimiento de ejecución a nivel de código nativo y procesamiento multihilo con memoria compartida, acelerando las compilaciones completas entre 8 y 12 veces en proyectos reales y reduciendo drásticamente el consumo de memoria. A continuación, exploramos en detalle las características esenciales de TypeScript 7.0 y las pautas clave para una migración sin contratiempos.
Reescritura integral en Go y un salto generacional de rendimiento
El cambio más sustancial en TypeScript 7.0 radica en la transformación de su arquitectura interna. Durante muchos años, TypeScript fue un compilador autohospedado (self-hosting), programado en el propio TypeScript/JavaScript. En la versión 7.0, el equipo de Microsoft completó una migración nativa hacia Go con un altísimo grado de fidelidad.
Esta transición resuelve de raíz los cuellos de botella habituales en proyectos de gran envergadura. En las pruebas de rendimiento oficiales sobre repositorios de código abierto emblemáticos (como VS Code y Sentry), los tiempos de compilación pasaron de varios cientos de segundos a unos pocos segundos, lo que supone una aceleración promedio cercana a 10 veces. Asimismo, se ha reducido el pico de memoria consumida a lo largo de todo el ciclo de compilación, ahorrando cuantiosos recursos en entornos de desarrollo local y en canalizaciones de CI.
Nuevos controles de concurrencia y modo monohilo
Aprovechando las capacidades de Go en materia de concurrencia, TypeScript 7.0 ahora ejecuta de forma paralela las etapas de análisis sintáctico (parsing), comprobación de tipos y generación de código. Como consecuencia, se introducen nuevas opciones de CLI para un control detallado.
Es posible utilizar la bandera --checkers para definir la cantidad de hilos de trabajo (workers) asignados a la comprobación de tipos (el valor predeterminado es 4). Aumentar esta cifra en equipos con procesadores multinúcleo reduce aún más los tiempos de compilación, mientras que en contenedores de CI con recursos limitados conviene moderarla. De igual forma, el parámetro --builders permite gestionar la concurrencia en arquitecturas multiproyecto que emplean Project References.
Por otra parte, para facilitar la depuración o ejecutar el compilador en entornos con severas restricciones, se incorpora la bandera --singleThreaded, que fuerza la ejecución secuencial de todas las tareas en un único hilo.
Renovación del mecanismo de observación en modo Watch
Para los equipos de desarrollo que mantienen activado permanentemente el modo --watch, las versiones anteriores de TypeScript causaban una sobrecarga considerable de CPU por sondeo al vigilar árboles de dependencias masivos en node_modules.
TypeScript 7.0 adopta una arquitectura de monitorización de archivos inspirada en @parcel/watcher. Al portar la lógica principal directamente a Go, se obtiene una capacidad de detección de cambios de archivos multiplataforma de consumo ultrabajo sin necesidad de depender de herramientas de compilación de C++. Gracias a ello, la respuesta del recambio en caliente (hot reload) y del editor en proyectos frontend de gran escala se reduce al orden de los milisegundos.
Compatibilidad del ecosistema: coexistencia mediante el alias de TypeScript 6
Dado que TypeScript 7.0 se basa completamente en Go, en este momento no expone la API programática clásica del compilador (dicha API se rediseñará y presentará en una futura versión 7.1). Esto implica que herramientas del ecosistema como typescript-eslint, con una fuerte dependencia de la API de TypeScript, no pueden interactuar directamente con el motor 7.0.
Con el fin de mitigar esta situación, Microsoft ha preparado una estrategia de coexistencia Side-by-Side. Al instalar el paquete de compatibilidad @typescript/typescript6, un mismo proyecto puede emplear TypeScript 7.0 para las compilaciones de CLI y las funciones del editor, mientras las herramientas basadas en la API continúan ejecutándose sobre el motor 6.0.
{
"devDependencies": {
"typescript": "npm:@typescript/typescript6@^6.0.2",
"@typescript/native": "npm:typescript@^7.0.2"
}
}Soporte nativo de Unicode en tipos literales de plantilla
Al inferir tipos basados en cadenas de texto, las versiones previas de TypeScript replicaban el comportamiento de indexación por unidades UTF-16 de JavaScript. Esto provocaba que los pares sustitutos (surrogate pairs), como los emojis, se fragmentaran por la mitad, generando caracteres truncados sin sentido semántico. En TypeScript 7.0, los tipos literales de plantilla preservan cada carácter Unicode como una unidad lógica completa.
type HeadTail<S> = S extends `${infer Head}${infer Tail}` ? [Head, Tail] : never;
type Result = HeadTail<"😀abc">;
// En 7.0 el resultado inferido es: ["😀", "abc"]
// En versiones anteriores se infería como: ["\ud83d", "\ude00abc"]Esta modificación simplifica enormemente las operaciones de nivel de tipos sobre cadenas complejas, alineando el sistema de tipos con el comportamiento en tiempo de ejecución de las iteraciones for...of y la propagación de arrays.
Ajustes en la compatibilidad con JavaScript y cambios que rompen la compatibilidad
En TypeScript 7.0 se han endurecido las especificaciones de análisis para JSDoc y archivos JavaScript convencionales, eliminando casos atípicos en favor de un análisis mucho más rápido. Por ejemplo, se ha suprimido el comportamiento especial de la etiqueta @enum debiendo emplearse declaraciones estándar, y las anotaciones de funciones al estilo de Closure Compiler (como function(string): void) quedan obsoletas, requiriéndose la sintaxis de flecha estándar de TypeScript (s: string) => void.
Asimismo, 7.0 aplica configuraciones por defecto más rigurosas (heredadas de los estándares introducidos en 6.0 y convertidas ahora en errores estrictos):
strictviene activado por defecto ymoduleapunta por defecto aesnext.rootDirtiene por defecto el valor./, ytypesse establece por defecto en[](ya no se importan tipos globales de forma implícita).- Se elimina por completo el soporte para
target: es5. - Se declaran completamente obsoletos
baseUrlymoduleResolution: node; el equipo oficial recomienda utilizar los modosnodenextobundlerjunto con alias de rutas estándar.
Recomendaciones para la actualización
| Perfil de proyecto | Cuándo actualizar | Consideraciones para la migración |
|---|---|---|
| Proyectos TypeScript puros | Actualizar de inmediato | Comprobar y eliminar el campo obsoleto baseUrl en tsconfig.json; definir explícitamente "rootDir": "./src" para el código fuente fuera de la raíz; declarar los tipos necesarios de forma explícita, como "types": ["node"]. |
| Proyectos JavaScript heredados basados en JSDoc | Esperar / Actualizar con prudencia | El análisis sintáctico de JSDoc es más estricto en 7.0; todos los comentarios basados en Closure Compiler deben reescribirse según la sintaxis estándar de TypeScript. |
| Desarrollo con frameworks (Vue / Astro / Svelte) | Posponer o usar configuración híbrida | Los complementos de plantillas con fuerte dependencia de la API interna aún no están plenamente adaptados a 7.0 en los editores; se aconseja esperar a la versión 7.1 o utilizar el modo de coexistencia mencionado. |
| Mantenedores de librerías y herramientas | Pruebas de compatibilidad | Si tu paquete depende de las API públicas de typescript, orienta a los usuarios para que instalen el paquete con alias de la versión 6.0 a fin de evitar fallos de ejecución. |
