Noticias

TypeScript 7.0 se lanzó el 8 de julio de 2026, y el titular es simple: el compilador ahora está escrito en Go en lugar de en el propio TypeScript, y compila aproximadamente 10 veces más rápido. Para quien mantiene una base de código grande en Vue, Nuxt o React, es el mayor cambio en el día a día de TypeScript en años: no una nueva sintaxis, sino un nuevo motor bajo el mismo comando tsc.

Nada cambia en cómo escribes los tipos. Tus archivos .ts, tu tsconfig.json y tus errores de tipo siguen igual. Lo que cambia es la rapidez con la que el compilador analiza, verifica y emite tu proyecto, y lo ágil que se siente tu editor mientras trabajas. Esta guía cubre qué cambió de verdad, las cifras reales de los benchmarks, cómo probarlo hoy y las contrapartidas honestas antes de migrar.

Qué cambió de verdad

El proyecto, con nombre en clave Corsa, es un port más que una reescritura. El equipo de Microsoft, liderado por el arquitecto principal de TypeScript Anders Hejlsberg, trasladó los algoritmos y estructuras de datos existentes a Go para que el comportamiento de la verificación de tipos siga siendo idéntico: la misma inferencia, los mismos errores. Se eligió Go frente a Rust en gran parte porque los árboles de sintaxis y las tablas de símbolos de TypeScript dependen de referencias cíclicas, que encajan mucho mejor con el recolector de basura y las goroutines de Go que con las reglas de propiedad de Rust.

La velocidad viene de dos cosas. El código nativo compilado es sencillamente más rápido que el antiguo compilador escrito en JavaScript, y el nuevo compilador trabaja en paralelo: el análisis, la verificación de tipos y la emisión pueden ejecutarse en varios hilos en lugar de uno. El uso de memoria cae aproximadamente a la mitad frente al compilador de JavaScript, y el servicio de lenguaje del editor carga los proyectos grandes mucho más rápido.

La velocidad, en cifras reales

Microsoft publicó cifras de antes y después en proyectos reales. Compilar la base de código de VS Code (unos 1,5 millones de líneas) pasó de 77,8 segundos a 7,5 segundos, una mejora de 10,4x. Playwright compiló unas 10x más rápido y TypeORM alrededor de 13,5x. Son compilaciones completas y limpias, las que dominan el tiempo de CI y ralentizan las verificaciones de tipos locales en repositorios grandes.

• TypeScript 7.0 (lanzado el 8 de julio de 2026) reemplaza el compilador escrito en JavaScript por un port nativo escrito en Go: mismos tipos, nuevo motor
• Builds completos unas 10x más rápidos (VS Code 77,8s a 7,5s), carga de proyecto en el editor unas 8x más rápida y alrededor de 50% menos memoria
• Es un port (nombre en clave Corsa) liderado por Anders Hejlsberg: comportamiento de verificación de tipos idéntico, ahora paralelizado en varios hilos
• Se instala y se ejecuta como tsc; las versiones nocturnas siguen usando el nombre tsgo bajo @typescript/native-preview
• Cambios que rompen: target es5, modo de resolución node, baseUrl y AMD/UMD/SystemJS eliminados; algunos valores por defecto (rootDir, types) cambian
• Las herramientas sobre la API programática (typescript-eslint, ts-morph, transformadores) esperan una versión 7.x posterior: adóptalo en paralelo por ahora

Las mejoras en el editor importan igual en el día a día. Cargar un proyecto grande en el servicio de lenguaje bajó de unos 9,6 segundos a 1,2 segundos, aproximadamente 8x. Esa es la diferencia entre esperar a que IntelliSense despierte y tener autocompletado, ir a la definición y subrayado de errores respondiendo casi al instante en una base de código que antes se sentía lenta.

Cómo probarlo hoy

La instalación es deliberadamente aburrida: el compilador nativo se instala desde el paquete habitual y se ejecuta como tsc, así que la mayoría de los proyectos pueden probarlo con una sola actualización de dependencia. Las versiones preliminares anteriores traían un binario tsgo aparte, y las compilaciones nocturnas se siguen publicando bajo @typescript/native-preview con ese nombre, pero la versión estable es simplemente tsc. Nuevos parámetros permiten ajustar el paralelismo, por ejemplo el número de workers de verificación, o desactivarlo con un modo de un solo hilo cuando necesitas una salida serial reproducible.

Una forma segura de adoptarlo es en paralelo. Puedes mantener instalado el compilador 6.x anterior bajo un alias (a menudo invocado como tsc6) mientras apuntas tu build principal a la 7.0. Eso te deja usar el nuevo compilador rápido para builds y edición, mientras cualquier herramienta que aún dependa de la antigua API programática estable sigue funcionando sin tocarla.

Cambios que rompen a vigilar

Hay cambios que rompen compatibilidad reales, así que lee las notas de la versión antes de actualizar en el sitio. Varias opciones obsoletas desde hace tiempo desaparecen, incluidos el target es5, el antiguo modo de resolución de módulos node, baseUrl y los formatos de módulo AMD, UMD y SystemJS. Algunos valores por defecto también cambian, como rootDir y el conjunto por defecto de paquetes de tipos ambientales, lo que puede hacer aflorar nuevos errores en configuraciones que dependían del antiguo comportamiento implícito.

Las contrapartidas honestas

La ganancia de velocidad es real, pero el ecosistema necesita un tiempo para ponerse al día. Las herramientas construidas sobre la API programática de TypeScript (typescript-eslint, ts-morph, transformadores de compilador personalizados) dependen de interfaces que solo se estabilizarán en una versión 7.x posterior. Hasta entonces, los equipos que se apoyan mucho en esas herramientas quizá quieran usar la 7.0 para builds y edición mientras mantienen disponible la línea 6.x para las partes de la cadena de herramientas que aún no están listas.

También conviene mantener las expectativas con los pies en la tierra: TypeScript 7 hace más rápido el compilador, no tu aplicación en producción. La salida sigue siendo el mismo JavaScript ejecutándose en los mismos navegadores y versiones de Node, así que el rendimiento en tiempo de ejecución no cambia. Lo que obtienes son tiempos de build y de CI más cortos y un editor más ágil, que en una base de código front-end grande es justo donde estaba la fricción. Para la mayoría de equipos de Vue, Nuxt y React el paso práctico es probarlo en una rama, vigilar las opciones eliminadas y adoptarlo para el build y el editor una vez que las cifras cuadren.