El compilador en Go de TypeScript 7: qué cambia el 10x de velocidad

TypeScript 7 es la reescritura nativa del compilador de TypeScript en Go, y comprueba los tipos de bases de código grandes unas diez veces más rápido que el tsc actual, basado en JavaScript. Mismo lenguaje, mismo sistema de tipos, misma sintaxis. Lo que cambia es la máquina de debajo: la herramienta que lee tu código y avisa de los errores de tipo ahora corre como binario nativo compilado, y no como JavaScript sobre Node.

Si tu equipo espera un tsc --noEmit lento en CI, o el editor se traba un segundo cada vez que reindexa un repo grande, esta es la versión que quita ese coste. Microsoft llama al proyecto Corsa. Salió como preview instalable en 2026 y es el cambio más grande en la cadena de herramientas de TypeScript desde que el lenguaje pasó a compilarse a sí mismo.

La versión de 30 segundos

Microsoft portó el compilador y el servicio de lenguaje de TypeScript a Go. En sus propios benchmarks el compilador nativo comprueba el código de Visual Studio Code (1,5 millones de líneas) en unos 7,5 segundos en lugar de 78, y recorta el tiempo de carga del proyecto en el editor de unos 9,6 segundos a 1,2, con cerca de la mitad de memoria. La cadena nativa lleva el número de versión 7.0. El compilador de JavaScript actual sigue en la línea 6.x mientras los equipos migran. La comprobación de tipos llega lista para producción primero, y la emisión de código y las referencias de proyecto vienen más adelante en el despliegue.

Por qué TypeScript reescribió su compilador en Go

El compilador original está escrito en TypeScript y corre sobre Node. Fue una decisión meditada: así el equipo construía el lenguaje con el propio lenguaje y mantenía todo en una sola base de código. El precio es la velocidad. JavaScript corre en un solo hilo por defecto, tiene recolección de basura y se compila JIT al arrancar, así que una comprobación de tipos en frío paga el parseo y el calentamiento en cada ejecución. A medida que las bases de código pasaron del millón de líneas, esa carga se volvió la queja principal.

Go se eligió por un motivo concreto, no por moda. El compilador actual se apoya en estructuras de datos mutables compartidas y en mucho recorrido de grafos, que encajan bien con el modelo de memoria de Go y con las goroutines. Anders Hejlsberg, arquitecto jefe de TypeScript, explicó que el equipo quería un lenguaje que permitiera portar el código existente de forma estructural en vez de rediseñarlo, y la semántica de Go era la más cercana. Una reescritura en Rust habría supuesto pelearse con el borrow checker para reproducir un compilador construido en torno a punteros compartidos. Con Go el porte quedó fiel al original, y por eso llegó en cerca de un año.

Qué mide de verdad el 10x

La cifra destacada es la velocidad de comprobación de tipos y de build, medida por Microsoft en proyectos reales:

• VS Code (1,5 millones de líneas): de unos 78s a 7,5s, una reducción de 10,4 veces.
• Carga del proyecto en el editor: de unos 9,6s a 1,2s, cerca de 8 veces.
• TypeORM: de 17,5s a 1,3s.
• Memoria: alrededor de la mitad que el compilador de JavaScript en los mismos proyectos.

Dos matices mantienen el cuadro honesto. Las ganancias son mayores en repositorios grandes. Un proyecto pequeño de 5.000 líneas no notará un salto de 10 veces, porque ya era rápido. Y la cifra es velocidad del compilador, no de toda la pipeline: si en CI dominan la instalación de dependencias y los tests, una comprobación de tipos más rápida recorta una parte, no el total.

Qué cambia para un equipo de desarrollo

La CI deja de esperar al comprobador de tipos

En un monorepo grande, un gate tsc --noEmit antes de push o merge puede durar minutos. Los equipos que midieron el compilador nativo cuentan que esa comprobación baja de unos cinco minutos a menos de quince segundos. La comprobación de tipos deja de ser un paso que agrupas y temes, y pasa a ser algo que corres en cada guardado.

Los editores dejan de ir a trompicones en repos grandes

La parte más lenta al trabajar con mucho TypeScript no es la compilación, es el servicio de lenguaje: el autocompletado, el ir a la definición y los subrayados de error que se atascan mientras el servidor reindexa. El servicio de lenguaje nativo recorta los tiempos de carga y de respuesta en un factor parecido, así que un repo grande empieza a comportarse como uno pequeño.

Menos motivos para partir una base de código por velocidad

Muchos equipos parten un monorepo en paquetes solo para que la comprobación de tipos sea tolerable. Cuando una sola comprobación de más de un millón de líneas termina en segundos, esa presión afloja. La decisión de arquitectura vuelve a ser sobre propiedad y límites, no sobre el rendimiento del compilador.

Qué no cambia

El sistema de tipos es idéntico. TypeScript 7 es una reimplementación, no un rediseño: la misma inferencia, los mismos errores, el mismo tsconfig.json. Microsoft informa de una compatibilidad en la comprobación de tipos por encima del 98% frente al compilador actual, con un puñado de casos límite seguidos de forma abierta. Los ajustes de strict mode y la configuración actual pasan sin cambios.

Lo que quedó por detrás del comprobador de tipos durante el despliegue fue el resto de la cadena: la emisión de JavaScript y de archivos de declaración, el modo --build con referencias de proyecto y el conjunto completo de funciones del servicio de lenguaje. Por eso el punto de entrada práctico es tsgo --noEmit como comprobación de tipos rápida junto al tsc actual para la emisión, en vez de un cambio total desde el primer día.

Parte de un giro hacia las herramientas nativas

TypeScript 7 es un caso de un patrón que recorre las herramientas frontend en 2026: las herramientas de JavaScript críticas para el rendimiento reescritas en un lenguaje compilado. Los bundlers y los linters pasaron a Rust y Go por la misma razón que el compilador, porque las cargas de trabajo son grandes, repetitivas y paralelizables. Para un equipo, la lectura es esta: los pasos de build que antes justificaban partir proyectos o cachear a lo bruto se están volviendo un orden de magnitud más rápidos por sí solos. Lo tenemos en cuenta al elegir stack para proyectos nuevos: un comprobador de tipos nativo cambia cuánto cuesta de verdad mantener una superficie grande de TypeScript. Y se combina con la disciplina de mantener ligero el grafo de dependencias, porque un comprobador rápido igual tiene que leer todo lo que importas.

Cuándo adoptarlo y cuándo esperar

Adóptalo ya como comprobador de tipos si tienes una base de código grande y los tiempos de comprobación en CI se miden en minutos. Corre tsgo --noEmit en paralelo con tu build actual y compara los dos. El riesgo es bajo, porque no produce la salida que entregas. Espera antes de convertirlo en tu único compilador si dependes de la emisión de declaraciones para un paquete publicado, de las referencias de proyecto para orquestar el build, o de una extensión de editor que aún no se ha portado. Toma 2026 como el año en que lo añades como comprobación rápida, y el ciclo siguiente como el año en que pasa a ser el valor por defecto.

Cómo probarlo hoy

El compilador nativo sale como @typescript/native-preview y expone un binario tsgo. Instálalo como dependencia de desarrollo y luego corre tsgo --noEmit sobre un proyecto con un tsconfig.json existente. Como lee la misma configuración, puedes engancharlo a la CI como un job extra y mantener tu paso tsc actual hasta que la emisión y las referencias de proyecto sean estables en tu caso. Hay una extensión experimental de editor para el servicio de lenguaje nativo, si quieres notar el cambio de respuesta en directo.

Dónde encaja en tus decisiones de stack

Un comprobador de tipos nativo cambia las cuentas de varias decisiones cercanas. La strict mode sale más barata de correr, así que los motivos para aplazarla se reducen. Los límites de un monorepo dejan de ser un apaño de rendimiento y vuelven a ser una cuestión de propiedad. Y la idea de partir una app grande en servicios solo para que los builds locales sigan siendo rápidos pierde fuerza. Nada de esto es razón para rediseñar hoy. Es una razón para dejar de tratar el tiempo de comprobación de tipos como un coste fijo al planear la próxima base de código, porque en 2026 dejó de serlo.