TypeScript 7 y la versión para Go: construcciones más rápidas, mejor uso de memoria y retroalimentación del editor.

Cualquiera que haya usado TypeScript durante años conoce ese ritmo. Se escribe el código, el editor lo analiza un rato, TypeScript procesa el proyecto, luego se ejecuta tsc y hay que esperar más. En un gran monorepo, esa pausa dura lo suficiente como para ir a por un café. Nada de esto significa que la herramienta esté mal diseñada. Su sistema de tipos y sus herramientas de lenguaje se han vuelto lo suficientemente potentes como para manejar bases de código muy extensas, y ese es precisamente el motivo por el cual se ha vuelto tan fundamental en el mundo de JavaScript. Pero esa fortaleza conllevó un costo: a medida que los proyectos crecían, el compilador y el servidor de lenguaje se convertían en un cuello de botella en cuanto al rendimiento.

TypeScript 7.0 es la respuesta de Microsoft, y lo notable es que el cambio principal no es un nuevo operador, palabra clave ni truco de sintaxis. Se trata del motor subyacente. El compilador de TypeScript solía estar escrito en TypeScript, una estructura recursiva muy eficaz que funcionaba bien, aunque eso significaba que el compilador tenía que operar dentro del modelo de tiempo de ejecución de JavaScript. Para la versión 7, Microsoft trasladó el compilador a Go, creando una implementación nativa diseñada para aprovechar el hardware moderno y el paralelismo.

Eso es lo fundamental que hay que entender de esta versión. TypeScript 7 no es principalmente un nuevo lenguaje, sino un nuevo motor para el lenguaje que ya utilizan las personas, y esa perspectiva explica casi todo lo demás sobre él.

Las cifras de velocidad

La cifra principal indica que es diez veces más rápido. Las pruebas de rendimiento de Microsoft muestran que las compilaciones completas suelen ejecutarse de 8 a 12 veces más rápido, dependiendo del proyecto, y estas pruebas provienen de grandes bases de código reales y no de micropruebas sintéticas.

El tiempo de compilación ni siquiera es el resultado más sorprendente, ya que el servidor de lenguaje también se acelera. En el ejemplo de Microsoft con la base de código de VS Code, abrir un archivo que contenía un error pasó de aproximadamente 17.5 segundos antes de que apareciera el primer error a menos de 1.3 segundos. Eso representa una experiencia de trabajo completamente diferente, y en repositorios grandes es más importante que reducir unos pocos cientos de milisegundos en una compilación en producción.

Uso de todos los núcleos

Las máquinas modernas tienen muchos núcleos, mientras que tsc históricamente funcionaba con uno solo. TypeScript 7 hace un uso mucho mejor de ellos: el análisis, la verificación de tipos y la generación de código pueden ejecutarse en paralelo cuando es posible. También añade algunos parámetros experimentales:

--checkers
--builders
--singleThreaded

Los dos primeros ofrecen un control más preciso sobre cómo se divide el trabajo en paralelo, y --singleThreaded desactiva el paralelismo cuando es necesario, por ejemplo al depurar el comportamiento del compilador o al ejecutarse en un entorno con recursos limitados.

Los monorepos son los que más beneficios obtendrán. Imagine un repositorio con un directorio de aplicaciones:

apps/
  web/
  admin/
  mobile/

y un directorio de paquetes:

packages/
  ui/
  api/
  config/
  utils/
  domain/

TypeScript solía realizar una gran cantidad de tareas secuenciales a través de ese grafo de dependencias. Con la versión 7, es posible realizar más de esas tareas al mismo tiempo. Por lo tanto, el mensaje no es simplemente que el compilador es más rápido, sino que finalmente puede aprovechar el hardware en el que se ejecuta.

Memoria

El rendimiento no se refiere únicamente al tiempo de procesamiento de la CPU. Los proyectos grandes en TypeScript pueden consumir varios gigabytes de RAM, especialmente cuando el servidor del lenguaje funciona junto a un editor, un navegador, Docker y servidores de desarrollo. Las pruebas de rendimiento publicadas por Microsoft muestran que la memoria disminuye entre un 6% y un 26% en varios proyectos grandes:

• Bluesky: alrededor de un 26% menos
• VS Code: alrededor de un 18% menos
• tldraw: alrededor de un 15% menos
• Playwright: alrededor de un 11% menos

Aparte de compilaciones diez veces más rápidas, lo cual puede parecer algo menor, cualquiera que haya visto cómo la memoria de una laptop se agota en un gran monorepo comprende su valor.

Un nuevo servidor de lenguaje

En realidad, gran parte del atractivo de TypeScript no proviene de tsc. Proviene del editor: completado automático, información de tipo al pasar el cursor, acceso directo a la definición, lista de todas las referencias, cambio de nombre de un símbolo en todas partes, errores mostrados directamente en el código y correcciones con un solo clic. Una gran parte de lo que se considera desarrollo moderno en JavaScript se basa en esto.

TypeScript 7 incluye un nuevo servidor de lenguaje desarrollado sobre el Language Server Protocol, que utiliza la implementación nativa y el multihilo. El equipo sigue mejorando sus funcionalidades: ya están disponibles lentes de código, sugerencias integradas, resaltado semántico, ordenación de importaciones y eliminación de importaciones no utilizadas, además de importaciones automáticas, acceso directo a la definición en el código fuente, edición vinculada de JSX y completado de etiquetas. El objetivo va más allá de un tsc más rápido: todo el proceso, desde escribir código hasta recibir retroalimentación, se vuelve más rápido, y eso es, sin duda, la mayor ventaja.

Salida determinista bajo paralelismo

Un cambio menos llamativo pero técnicamente interesante es que TypeScript realiza una gran cantidad de tareas internas relacionadas con tipos, símbolos, uniones y declaraciones. Cuando varios procesos se ejecutan simultáneamente, el orden en el que se crean los objetos internos puede variar, lo que podría cambiar los IDs internos y, por ende, alterar el orden de las declaraciones generadas.

TypeScript 7 lo aborda ordenando los elementos de manera determinista a partir del contenido de los objetos internos, en lugar de depender del orden en el que se encuentren. Tomemos esta función:

function foo(condition: boolean) {
  return condition ? 100 : 500;
}

Puede generar una declaración como esta:

export declare function foo(
  condition: boolean
): 100 | 500;

Y el orden de la unión se mantiene estable sin importar cómo se realice el trabajo en paralelo. La mayoría de los desarrolladores no se darán cuenta, pero esto es precisamente la ingeniería que hace que un compilador altamente paralelo sea fiable.

No es una versión con nuevas funciones

Cualquiera que espere algo así:

type NewSuperPower<T> = ...

O bien, debido a la gran cantidad de nuevas características del lenguaje, TypeScript 7 podría parecer poco impresionante al principio. La mayor parte del esfuerzo se destinó a la infraestructura en lugar de a nuevas capacidades del sistema de tipos. El equipo pasó años sentando las bases para la próxima generación de TypeScript, y ahora ella ya existe. La hoja de ruta apunta hacia el desarrollo de nuevas funciones, mejoras en la ergonomía, mayores ganancias de rendimiento y una nueva API del compilador después de la versión 7.0. Esta versión se percibe mejor como el inicio de una nueva era que como el final de la anterior.

Consideraciones para los creadores de herramientas

Aquí es donde las cosas se vuelven interesantes para quienes desarrollan herramientas. TypeScript 7.0 no incluye la antigua API del compilador, y el equipo espera que la versión 7.1 introduzca una nueva. Esto es importante porque gran parte del ecosistema no se limita a ejecutar tsc; los linters, los compiladores de frameworks, los servicios de lenguaje y las herramientas de compilación interactúan con TypeScript de forma programática.

Esa es una de las razones por las cuales TypeScript 6 y 7 podrían tener que coexistir por el momento. Microsoft introdujo @typescript/typescript6 para facilitar la transición, de modo que un proyecto pueda seguir utilizando la versión 6 en las herramientas que aún necesitan su API, al mismo tiempo que emplea el compilador de la versión 7 por separado. Una actualización del compilador no siempre es tan sencilla como editar una sola línea:

{
  "devDependencies": {
    "typescript": "^7.0.0"
  }
}

En los ecosistemas grandes, el compilador es la infraestructura, y la infraestructura tiene dependencias.

Otra limitación afecta a los frameworks y herramientas que integran TypeScript dentro de sus propios pipelines de compilación o de servicio de lenguaje. El equipo denomina a Vue, MDX, Astro, Svelte y Angular como entornos en los que el soporte para el nuevo diseño de servicio de lenguaje aún está en proceso de implementación, y nuevamente la ausencia de una API programática estable explica por qué. Una aplicación sencilla de React y TypeScript puede migrar sin muchos problemas. En cambio, una integración compleja con un framework, un complemento de compilador o un complemento de servicio de lenguaje enfrenta un camino más difícil. Vale la pena verificarlo antes de actualizar cualquier repositorio de producción a gran escala.

TypeScript 6 como peldaño intermedio

TypeScript 6 nunca fue simplemente la versión anterior a 7. Fue creado deliberadamente como un puente. Varias opciones antiguas del compilador fueron marcadas como obsoletas en esa versión y desaparecieron por completo en 7, por lo que el equipo recomienda eliminarlas antes de hacer el salto. Utilizar la versión intermedia, como se muestra a continuación, es mejor que tratar a 7 como una actualización independiente:

TypeScript 5.x
      ↓
TypeScript 6
      ↓
TypeScript 7

Todos los avisos de obsolescencia que genera un proyecto con TypeScript 6 merecen atención. En esencia, son notificaciones de migración enviadas desde el futuro.

Por qué es importante el ciclo de retroalimentación

TypeScript desaparece después de la compilación, por lo que los desarrolladores front-end rara vez lo consideran parte del tiempo de ejecución de la aplicación. Sin embargo, influye significativamente en él. Cada vez que un editor atraviesa un ciclo como este:

type something
↓
autocomplete appears
↓
you navigate to a definition
↓
you rename a symbol
↓
you save
↓
CI runs
↓
the project gets type-checked

TypeScript participa en cada ocasión, y su papel crece a medida que las aplicaciones se vuelven más complejas. Un retraso de 100 ms no tiene importancia, pero uno de 10 segundos sí la tiene; una espera de 30 segundos altera la forma en que una persona trabaja, mientras que una verificación de tipo en CI de cinco minutos afecta el trabajo de todo un equipo. Por lo tanto, la principal característica de TypeScript 7 no es una compilación diez veces más rápida, sino un intervalo más corto entre escribir código y saber si está correcto.

Probándolo

Para un proyecto nuevo, claramente vale la pena evaluar TypeScript 7. En el caso de uno ya existente, es mejor adoptar un enfoque más cauteloso. Comience instalándolo como dependencia de desarrollo:

npm install -D typescript@7

Luego ejecute una verificación de tipo sin emitir:

npx tsc --noEmit

Y examine los resultados, revisando estas áreas:

1. Errores del compilador
2. Configuración obsoleta
3. Compatibilidad de las herramientas de compilación
4. Integración con ESLint
5. Integración con el framework
6. Comportamiento del IDE
7. Rendimiento de CI
8. Consumo de memoria

En un monorepo grande, realice pruebas de rendimiento antes y después, utilizando algo como:

time npx tsc --build

Y compare el resultado con la versión actual de TypeScript. El número final no debería ser el único foco; lo que realmente importa es toda la experiencia del desarrollador.

Reconstruyendo las bases

TypeScript 7 destaca en las herramientas para frontend porque el equipo evitó el paso habitual de añadir más funcionalidades a la arquitectura existente y, en su lugar, reconstruyó las bases del lenguaje. El lenguaje en sí no necesitaba una reevaluación, pero sí la infraestructura. El momento elegido también tiene sentido, dado que existen proyectos JavaScript más grandes, monorepos comunes, APIs seguras desde el punto de vista tipológico en todas partes, editores más inteligentes, herramientas de programación basadas en IA que buscan datos semánticos, y desarrolladores que esperan respuestas casi instantáneas. Un compilador lo suficientemente rápido para una aplicación de 2015 no necesariamente podrá mantenerse al día con un monorepo de 2026.

En pocas palabras, esta versión reconoce que el diseño anterior funcionaba, pero el software moderno ya lo superó. En lugar de descartar un sistema de tipos que los desarrolladores ya aprecian, el equipo reconstruyó lo que hay en su base. Por esa razón, esta versión es más importante de lo que sugiere su lista de características visibles. Constituye la base para lo que será TypeScript en el futuro, además de un tsc más rápido. Si las mejoras prometidas se extienden a todo el ecosistema, las características más interesantes de TypeScript podrían no aparecer ni siquiera en la versión 7; podrían ser aquellas que solo se vuelven prácticas porque la versión 7 es lo suficientemente rápida para desarrollarlas.

“Diez veces” es el titular. Lo que hay detrás de ello es el paralelismo, la ejecución nativa, un uso reducido de memoria, un nuevo servidor de lenguaje, resultados de compilación deterministas y las bases para herramientas futuras. Para quienes mantienen aplicaciones grandes en TypeScript, esto es sin duda más valioso que otra utilidad de tipos más.

Leer más

• RAG-Anything en 65 libros sobre vino: dónde triunfa y falla la recuperación de grafos — Una prueba práctica del grafo de conocimientos de RAG-Anything en 65 PDFs sobre vino: elección del analizador, costos, respuestas basadas en grafos frente a vectores, y el punto ciego relacionado con los vinos espumosos.
• Comparación de 16 arquitecturas RAG: qué patrón se adapta a qué problema — Un recorrido por dieciséis patrones RAG en cuatro niveles, desde recuperación estándar e híbrida hasta diseños basados en agentes, grafos y federados, con un orden de construcción mes a mes.