TypeScript 7.0 ha llegado con un cambio que llevaba año y medio gestándose: el compilador ya no está escrito en TypeScript sobre Node.js, sino en Go, compilado a código nativo. Microsoft lo anunció el 3 de agosto de 2026, y el salto no es cosmético: afecta directamente al tiempo que un equipo de desarrollo pierde cada día esperando un build o viendo cómo el editor tarda en marcar un error real. Para quien trabaja con tipado estricto a diario, esto cambia la conversación sobre cuándo actualizar y qué conviene revisar antes de hacerlo.
TypeScript 7.0 es la primera versión estable que sustituye el compilador clásico, escrito en TypeScript, por un puerto nativo en Go: mismo lenguaje, mismas reglas de tipado, pero hasta 12 veces más rápido en builds reales.
TypeScript 7.0 y el compilador escrito en Go
Microsoft no reescribió TypeScript desde cero: portó de forma metódica la lógica existente al nuevo lenguaje, así que el comportamiento de tipado es estructuralmente idéntico al de TypeScript 6.0, según detalla el anuncio oficial. Lo que cambia es el motor que ejecuta esas reglas: código nativo compilado en lugar de JavaScript interpretado, con paralelismo real en memoria compartida en vez del hilo único al que obligaba Node.js.
El nuevo servidor de lenguaje, el proceso que alimenta el autocompletado y el chequeo de tipos del editor, redujo en más de un 80% los comandos que fallaban y en más de un 60% los cierres inesperados respecto a TypeScript 6.0. Para un equipo grande eso significa menos interrupciones por un editor que se queda colgado a mitad de una función, no solo un build más corto al final del día.
Cifras de velocidad de compilación en producción
Los números publicados por Microsoft vienen de proyectos reales, no de bancos de pruebas sintéticos:
- Visual Studio Code: de 125,7 a 10,6 segundos por build completo (11,9 veces más rápido).
- Sentry: de 139,8 a 15,7 segundos (8,9 veces más rápido).
- Slack: el tiempo de comprobación de tipos en su integración continua bajó de 7,5 a 1,25 minutos, con un 40% menos de tiempo total en la cola de fusión de código.
- Uso de memoria: alrededor de un 18% menos en el conjunto de proyectos medidos.
Para una empresa que paga minutos de integración continua por uso, ese recorte se traduce en factura, no solo en comodidad. Y en el editor, un chequeo de tipos que bajaba de 17,5 a 1,3 segundos cambia la sensación de trabajar con el lenguaje: deja de notarse como una capa que frena al desarrollador.
Adopción de TypeScript en el desarrollo profesional
La pregunta de si merece la pena migrar tiene más sentido si se mira cuánta gente ya trabaja en TypeScript. Según la encuesta 2025 de Stack Overflow, el 48,8% de los desarrolladores profesionales lo usa, situándolo como el sexto lenguaje más empleado, por delante de Java y C#, y solo un escalón por debajo de Python.
Ese peso explica por qué un salto de rendimiento en el compilador no es un detalle técnico menor: afecta a una parte muy grande de cualquier equipo de backend o frontend que contrate hoy una empresa. Si tu equipo de desarrollo en Barcelona trabaja ya con tipado estricto, la actualización termina llegando por la vía de las herramientas antes que por decisión propia: los frameworks y editores que uses irán incorporando el compilador nativo como opción por defecto. Planificarlo con tiempo, en vez de sufrirlo cuando una dependencia lo fuerce, es trabajo típico de una consultoría de sistemas IT que ya tenga mapeado el stack del cliente.
Lo que aún falta en el compilador nativo
TypeScript 7.0 no llega completo en todos los frentes. La versión no incluye todavía una API programática estable, la interfaz que usan herramientas externas para conectarse al compilador en lugar de invocarlo por línea de comandos. Sin ella, proyectos como typescript-eslint, o los compiladores de Vue y Svelte, que dependen de esa API para analizar tipos dentro de sus propios archivos, seguirán apoyándose en el compilador clásico hasta la versión 7.1.
Quien use el loader de TypeScript para Webpack tiene la misma espera: no hay soporte del compilador nativo hasta esa siguiente versión. No es un fallo del lanzamiento, es una secuencia deliberada, primero estabilizar el núcleo y después abrir la API a terceros, pero condiciona qué proyectos pueden dar el salto ya y cuáles tienen que esperar sin perder funcionalidad.
Comprobaciones imprescindibles antes de actualizar
Igual que aplazar la salida de una versión de Node.js sin soporte acumula riesgo sin que se note, decidir cuándo mover un proyecto a TypeScript 7.0 exige revisar antes qué depende de la parte que aún no está lista.
Herramientas que aún no soportan la versión nativa
Antes de tocar la versión de TypeScript en un repositorio, conviene listar qué depende de la API programática: reglas de ESLint sobre tipos y plugins propios del editor. Si el proyecto usa Vue o Svelte con su comprobador de tipos integrado, la migración real llegará con la 7.1, no antes: actualizar solo el binario no cambia nada en esos flujos. Lo mismo pasa con cualquier build que dependa del loader de TypeScript para Webpack, que seguirá usando el compilador clásico aunque el resto del equipo trabaje ya con el nativo.
Cómo mantener la compatibilidad mientras migras
Microsoft publica junto a la 7.0 el paquete @typescript/typescript6, con un binario tsc6 que reexporta la API de la 6.0 para que las herramientas que aún la necesitan sigan funcionando sin tocar código. Además, TypeScript 7.0 convierte en errores las funciones que la 6.0 solo marcaba como obsoletas, así que un proyecto con deuda técnica acumulada puede dejar de compilar de golpe. Microsoft recomienda pasar primero por la 6.0, corregir esos avisos con margen, y solo entonces subir a la 7.0.
Preguntas frecuentes sobre TypeScript 7.0
¿Es seguro actualizar ya a TypeScript 7.0?
Para un proyecto sencillo, sin dependencias que usen la API programática, sí: el binario tsc nativo ya es estable y el tipado se comporta igual que en la 6.0. Para proyectos con ESLint sobre tipos, Vue, Svelte o Webpack con loader propio, mejor esperar a la 7.1 o instalar el paquete de compatibilidad mientras tanto.
¿Qué pasa con mi configuración de ESLint?
typescript-eslint sigue apoyándose en la API programática clásica, así que seguirá funcionando con el compilador 6.0 mientras se actualiza para soportar el motor nativo. No hace falta tocar la configuración: basta con mantener instalado el paquete de compatibilidad hasta que el plugin confirme soporte para la 7.1.
¿TypeScript 7.0 cambia la sintaxis del lenguaje?
No. El anuncio oficial es explícito: la lógica de tipos se portó de forma fiel desde la 6.0, sin reescribirla. Lo que cambia es el motor que la ejecuta, no las reglas que un desarrollador tiene que aprender ni la forma de escribir los tipos en el código.
¿Cuánto tarda una migración típica?
Depende de las dependencias, no del tamaño del proyecto: un repositorio sin herramientas atadas a la API antigua puede actualizar el binario en una tarde. Uno con ESLint, Vue o un loader de Webpack necesita antes revisar esas piezas, lo que suele añadir entre unos días y varias semanas de comprobación.