TypeScript 5.5: tipos avanzados sin rompernos

Actualizado: 2026-05-03

TypeScript 5.5 salió a finales de junio de 2024 y llevo ya un año usándolo en proyectos reales. Un año es suficiente para separar el ruido del anuncio inicial de lo que de verdad ha cambiado la forma en que escribo código tipado. Este post recoge los ajustes que siguen pareciendo relevantes en 2025, cuáles han sido mejoras cosméticas y dónde la versión 5.5 pide cambios en el código existente que conviene calibrar antes de dar el salto.

Para el contexto de stack frontend donde TypeScript opera, el análisis de HTMX en empresa y el post sobre Qwik en producción describen entornos donde la elección de TypeScript tiene implicaciones distintas. El patrón de migración por versiones también aplica al contexto de Rust edición 2024, donde las rutas de actualización son análogas.

Puntos clave

• La inferencia automática de predicados de tipo en funciones de filtrado elimina decenas de anotaciones triviales en código funcional.
• La validación de expresiones regulares en tiempo de compilación atrapa errores de sintaxis antes de que lleguen a producción.
• El modo de declaraciones aisladas reduce el tiempo de build incremental en monorepos grandes, a costa de ser más explícito en los tipos exportados.
• Para equipos en 5.3 o 5.4, actualizar a 5.5 es un ejercicio de tarde sin demasiadas sorpresas.
• Para equipos en 4.x, la recomendación es hacer el salto por etapas, versión a versión.

La inferencia de predicados, el cambio que más se nota

El cambio que más ha afectado el día a día es la inferencia automática de predicados de tipo en funciones de filtrado. Antes de 5.5, un filtro como array.filter(x => x !== null) devolvía un array cuyo tipo seguía incluyendo null, y había que anotar la firma con x is T para que el compilador entendiera la intención. En 5.5 el compilador reconoce patrones sencillos de comparación y estrecha el tipo automáticamente.

El efecto práctico es que desaparecen decenas de anotaciones triviales que arrastrábamos en código funcional. En un proyecto mediano, la migración a 5.5 eliminó alrededor de 40 type guards explícitos que ya no eran necesarios. El código quedó más corto y más legible, y el compilador hace el trabajo silenciosamente.

La limitación es que la inferencia solo funciona para patrones reconocibles: comparaciones con null, undefined o literales. Para filtros más elaborados —comprobar la forma de un objeto o aplicar una lógica compuesta— sigue siendo necesario anotar el predicado a mano. Esto no es una regresión respecto a versiones anteriores, pero conviene entender que el compilador no es mágico y que los casos complejos siguen pidiendo tipado explícito.

Expresiones regulares con validación estructural

La segunda novedad que cambia código real es la validación de expresiones regulares en tiempo de compilación. Antes, una regex con un error de sintaxis pasaba el compilador y fallaba en tiempo de ejecución la primera vez que se evaluaba. En 5.5, el compilador parsea la cadena literal de la regex y emite un error si la sintaxis es inválida o si hay referencias a grupos de captura que no existen.

Esto es más útil de lo que parece. En un proyecto con muchas validaciones de formularios, se encontraron dos o tres regex con errores sutiles que solo se manifestaban al introducir ciertos inputs de usuario. El compilador las detectó al primer build tras la actualización. Cero trabajo, tres bugs menos.

La validación tiene límites. Solo aplica a literales de regex, no a regex construidas dinámicamente con el constructor RegExp desde cadenas. Si el código usa mucho el constructor dinámico, el beneficio será menor. En proyectos donde el 95% de las regex son literales, el impacto es grande.

Aislamiento de declaraciones y compilaciones más rápidas

La tercera novedad es la mejora del modo de declaraciones aisladas, que permite generar archivos .d.ts por módulo sin necesidad de un análisis global. Esto es relevante para bibliotecas que publican declaraciones y para monorepos grandes donde el tiempo de compilación es un cuello de botella.

En un monorepo con unos 80 paquetes internos, activar el modo de aislamiento bajó el tiempo de build incremental en torno al 30%. La mejora no es espectacular pero es consistente, y se nota especialmente en máquinas más lentas y en pipelines de integración continua donde cada segundo se paga en minutos de espera acumulada.

El coste del modo es que obliga a ser más explícito en los tipos exportados. Ya no vale con que el compilador deduzca el tipo de retorno de una función exportada a partir del cuerpo; hay que anotarlo explícitamente. Para código maduro esto es tedioso pero asumible; para código exploratorio donde los tipos cambian rápido, quizá no compense.

Los avisos de ECMAScript que llegan

TypeScript 5.5 también endurece algunos avisos sobre construcciones de ECMAScript que están en proceso de deprecación. El más visible es el aviso sobre la construcción dinámica de funciones mediante el constructor global, en contextos donde el compilador no puede razonar sobre el código generado. Otro es el aviso sobre imports con extensiones que no existen en el sistema de archivos, que en 5.5 se convierte en error por defecto en ciertos modos de módulo.

Estos cambios no rompen código limpio pero pueden sorprender en bases de código antiguas que arrastran patrones no idiomáticos. En la migración de un proyecto con diez años de historia aparecieron 35 avisos de este tipo en el primer build. La mayoría eran fáciles de arreglar, pero hubo dos o tres que requirieron revisar lógica de carga dinámica de módulos que funcionaba por accidente.

Cómo migro en proyectos reales

Mi estrategia de migración es la misma que uso para cada versión menor de TypeScript: primero actualizo en una rama aparte, corro el build, y anoto todos los errores y avisos nuevos. Si hay menos de diez errores, los arreglo inmediatamente. Si hay más, clasifico por categoría y decido cuáles atacar primero.

Para 5.5 en concreto, la mayoría de errores que aparecen en proyectos bien tipados son avisos sobre predicados inferidos que antes estaban anotados a mano. Estos no rompen nada, solo piden limpiar redundancias. Los errores verdaderos suelen venir del endurecimiento de regex y de los avisos de ECMAScript.

En código legacy la historia es otra. Proyectos que han evitado actualizar TypeScript durante dos o tres años se encuentran con decenas de errores acumulados de varias versiones. En estos casos lo mejor es actualizar por escalones, versión a versión, arreglando errores en cada paso, en lugar de saltar directo a 5.5 desde 4.x.

Lo que no ha cambiado

Hay cosas que siguen igual y conviene recordarlo:

• El modelo de decoradores sigue el estándar de stage 3 y no ha absorbido todavía los cambios pendientes de propuestas posteriores.
• El sistema de módulos sigue teniendo las mismas fricciones con CommonJS, especialmente en entornos Node.js con paquetes mixtos.
• El tiempo de compilación, aunque mejora, sigue siendo el punto débil del lenguaje frente a alternativas como esbuild o SWC para transpilación.
• La forma en que TypeScript resuelve tipos genéricos recursivos tampoco ha evolucionado; quien tenga código con mucha manipulación de tipos mapeados complejos seguirá viendo las mismas limitaciones de recursión profunda que en 5.3 y 5.4.

Mi lectura

TypeScript 5.5 no es una versión revolucionaria, pero es una versión que mejora el día a día sin pedir casi esfuerzo de migración. La inferencia de predicados es el cambio que más se agradece porque elimina ruido visual en código funcional, y la validación de regex atrapa bugs reales antes de que lleguen a producción. Las dos son mejoras de calidad de vida, no de potencia.

Para equipos que están en 5.3 o 5.4, actualizar a 5.5 es un ejercicio de tarde sin demasiadas sorpresas. Para equipos que todavía están en 4.x, la recomendación es hacer el salto por etapas, porque los cambios acumulados entre versiones son sustanciales y mezclar problemas de varias versiones complica el diagnóstico.

La dirección general de TypeScript sigue siendo incremental, con foco en la experiencia del desarrollador y compromiso con la compatibilidad. En un ecosistema donde las rupturas son frecuentes y poco avisadas, esta disciplina es un activo que no siempre se valora.