{"id":508,"date":"2026-03-09T20:19:42","date_gmt":"2026-03-09T20:19:42","guid":{"rendered":"https:\/\/blog.rebalai.com\/es\/2026\/03\/09\/typescript-5x-in-2026-features-that-actually-matte\/"},"modified":"2026-03-18T22:31:10","modified_gmt":"2026-03-18T22:31:10","slug":"typescript-5x-in-2026-features-that-actually-matte","status":"publish","type":"post","link":"https:\/\/blog.rebalai.com\/es\/2026\/03\/09\/typescript-5x-in-2026-features-that-actually-matte\/","title":{"rendered":"TypeScript 5.x en 2026: Las Funcionalidades que Realmente Importan en Producci\u00f3n"},"content":{"rendered":"

Llevo casi dos a\u00f1os usando TypeScript 5.x activamente \u2014 primero en un proyecto personal, luego en producci\u00f3n con<\/a> un equipo de seis personas construyendo una plataforma SaaS B2B. No he probado cada feature de cada minor release, pero s\u00ed he ido adoptando las que ten\u00edan sentido para nuestro stack: Next.js en el<\/a> frontend, NestJS en la API principal, un par de workers con Bun corriendo tareas de procesamiento en background.<\/p>\n

Este art\u00edculo no es una lista de todo lo que<\/a> sali\u00f3. Es sobre lo que realmente<\/a> us\u00e9, lo que<\/a> me funcion\u00f3, y honestamente, lo que<\/a> me decepcion\u00f3 un poco.<\/p>\n

Decoradores Estables: La Historia de Nunca Acabar que Por Fin Acab\u00f3<\/h2>\n

Si llevas tiempo en el<\/a> ecosistema TypeScript, sabes que los decoradores experimentales de experimentalDecorators: true<\/code> estuvieron rondando durante demasiado tiempo. TypeScript 5.0, lanzado en marzo de 2023, finalmente implement\u00f3 el est\u00e1ndar ECMAScript de decoradores. No son los mismos decoradores de antes. Son mejores, pero implican una migraci\u00f3n real que nadie te<\/a> avisa que va a doler un poco.<\/p>\n

Migramos nuestros controladores de NestJS a los nuevos decoradores durante el primer trimestre de 2024. Fue m\u00e1s suave de lo que<\/a> esperaba \u2014 la mayor\u00eda de librer\u00edas ya hab\u00edan a\u00f1adido soporte \u2014 pero encontr\u00e9 un par de casos raros con decoradores en propiedades de clase donde el comportamiento difer\u00eda del sistema legacy. Uno de esos casos me tuvo depurando durante una tarde entera porque el error en runtime no mencionaba los decoradores para nada.<\/p>\n

\/\/ Decorador de clase con el nuevo est\u00e1ndar ECMAScript\nfunction singleton<T extends { new(...args: any[]): {} }>(\n  target: T,\n  context: ClassDecoratorContext\n) {\n  let instance: InstanceType<T> | undefined;\n\n  return class extends target {\n    constructor(...args: any[]) {\n      if (instance) return instance;\n      super(...args);\n      instance = this as unknown as InstanceType<T>;\n    }\n  } as T;\n}\n\n@singleton\nclass DatabasePool {\n  connection = createConnection();\n}\n<\/code><\/pre>\n
El nuevo par\u00e1metro context<\/code> es lo que<\/a> m\u00e1s me gust\u00f3. Tienes acceso al nombre, al tipo del decorador, y a addInitializer<\/code> para ejecutar l\u00f3gica post-construcci\u00f3n. Es mucho m\u00e1s expl\u00edcito que el sistema anterior, donde b\u00e1sicamente estabas adivinando el orden de ejecuci\u00f3n en algunos casos edge.<\/p>\n
Lo que me decepcion\u00f3: no hay compatibilidad autom\u00e1tica con el c\u00f3digo legacy. Si tienes decoradores propios escritos para el sistema experimental, los tienes que reescribir desde cero. En nuestro caso fueron cuatro decoradores internos \u2014 un par de horas de trabajo \u2014 pero conozco equipos con docenas de decoradores propios que tardaron semanas en la migraci\u00f3n completa. Haz el inventario de decoradores propios antes<\/em> de comprometerte con una fecha. Y no hagas la migraci\u00f3n el viernes por la tarde. Yo aprend\u00ed eso de la manera dif\u00edcil.<\/p>\n
const<\/code> en Gen\u00e9ricos y NoInfer<\/code>: Dos Cambios Peque\u00f1os, Mucho Menos Ruido<\/h2>\n
\u00bfCu\u00e1ntas veces terminaste con un tipo m\u00e1s ancho de lo que<\/a> quer\u00edas, el c\u00f3digo compil\u00f3, los tests pasaron, y seis semanas despu\u00e9s alguien pas\u00f3 un valor inv\u00e1lido que el tipo deber\u00eda haber rechazado? Eso es exactamente lo que resuelven estos dos \u2014 const<\/code> type parameters en 5.0 y NoInfer<\/code> en 5.4 \u2014 aunque llegaron en versiones distintas.<\/p>\n
const<\/code> en gen\u00e9ricos es simple pero resuelve algo que antes requer\u00eda un as const<\/code> en cada callsite:<\/p>\n
\/\/ Sin const: T se infiere como string[]\nfunction createRoute<T extends string[]>(paths: T): T {\n  return paths;\n}\nconst routes = createRoute(['\/', '\/about', '\/contact']);\n\/\/ tipo inferido: string[] \u2014 demasiado amplio\n\n\/\/ Con const: T se infiere como el tuple literal exacto\nfunction createRoute<const T extends string[]>(paths: T): T {\n  return paths;\n}\nconst routes = createRoute(['\/', '\/about', '\/contact']);\n\/\/ tipo inferido: readonly ['\/', '\/about', '\/contact'] \u2014 perfecto\n<\/code><\/pre>\n
Llevaba a\u00f1os escribiendo as const<\/code> en cada callsite de funciones similares. Esto lo elimina. En nuestro sistema de configuraci\u00f3n de<\/a> rutas, donde necesitamos los tipos literales para generar breadcrumbs y validaciones, fue un cambio de calidad de vida enorme.<\/p>\n
NoInfer<\/code> es m\u00e1s sutil \u2014 tard\u00e9 tiempo en ver cu\u00e1ndo usarlo, pens\u00e9 que era un caso edge raro, y resulta que no. El caso principal: tienes un gen\u00e9rico T<\/code> que se infiere desde un argumento, pero no quieres que otro argumento influya en esa inferencia y la ampl\u00ede inadvertidamente.<\/p>\n
function setDefault<T>(\n  values: T[],\n  defaultValue: NoInfer<T>\n): T[] {\n  return values.length ? values : [defaultValue];\n}\n\nsetDefault(['a', 'b'], 'c'); \/\/ OK\nsetDefault(['a', 'b'], 42);  \/\/ Error: number no es asignable a string\n<\/code><\/pre>\n
Antes de NoInfer<\/code>, ten\u00edamos que recurrir a t\u00e9cnicas como T & {}<\/code> o reestructurar la firma entera. Uno de los desarrolladores del equipo lo us\u00f3 en una funci\u00f3n de validaci\u00f3n de feature flags y cerr\u00f3 dos bugs de runtime que llevaban meses en<\/a> el backlog. Los bugs exist\u00edan porque TypeScript aceptaba valores inv\u00e1lidos por c\u00f3mo estaban estructuradas las firmas gen\u00e9ricas. Peque\u00f1o cambio, impacto real.<\/p>\n
using<\/code> para la Gesti\u00f3n de Recursos: M\u00e1s \u00datil de lo que Pens\u00e9<\/h2>\n
TypeScript 5.2 implement\u00f3 using<\/code> y await using<\/code>, basados en la propuesta de Explicit Resource Management de TC39. Cuando lo vi por primera vez pens\u00e9 “interesante, pero cu\u00e1ndo lo uso realmente en mi d\u00eda a d\u00eda”. La respuesta: m\u00e1s seguido de lo que esperaba.<\/p>\n
Funciona as\u00ed: cualquier objeto que implemente Symbol.dispose<\/code> (o Symbol.asyncDispose<\/code>) se limpia autom\u00e1ticamente al salir del scope. Como el using<\/code> de C# o los context managers de Python:<\/p>\n
class DatabaseTransaction {\n  private committed = false;\n\n  constructor(private db: Database) {}\n\n  commit() {\n    this.db.commit();\n    this.committed = true;\n  }\n\n  [Symbol.dispose]() {\n    if (!this.committed) {\n      this.db.rollback();\n    }\n  }\n}\n\nasync function transferFunds(from: string, to: string, amount: number) {\n  using transaction = new DatabaseTransaction(db);\n\n  await db.debit(from, amount);\n  await db.credit(to, amount);\n  transaction.commit();\n  \/\/ Si algo lanza antes del commit, el rollback ocurre autom\u00e1ticamente al salir del scope\n}\n<\/code><\/pre>\n
Lo que me sorprendi\u00f3 genuinamente fue empezar a ver cu\u00e1ntos lugares en nuestra codebase ten\u00edamos bloques try\/finally<\/code> para cleanup que se pod\u00edan simplificar con using<\/code>. Conexiones a caches temporales, file handles en workers de procesamiento de CSV, clients de APIs externas que necesitan un .close()<\/code> expl\u00edcito. No es que el c\u00f3digo fuera incorrecto antes \u2014 pero era m\u00e1s verboso y, lo que es peor, m\u00e1s f\u00e1cil de olvidar el cleanup en paths de error que nadie<\/a> testea.<\/p>\n
En un proyecto de frontend puro probablemente no lo uses mucho. Pero si tienes workers, scripts de migraci\u00f3n de datos<\/a>, o c\u00f3digo de servidor con gesti\u00f3n expl\u00edcita de recursos, vale la pena<\/a> adoptarlo.<\/p>\n
isolatedDeclarations<\/code> en Monorepos: El Antes y el Despu\u00e9s de<\/a> Nuestros Builds<\/h2>\n
Esta es, para nuestro equipo espec\u00edfico, la funcionalidad m\u00e1s impactante de toda la serie 5.x. Lleg\u00f3 en TypeScript 5.5 y resolvi\u00f3 un problema que yo ni sab\u00eda que ten\u00eda nombre.<\/p>\n
El problema: en un monorepo con m\u00faltiples paquetes TypeScript, el compilador necesita procesar todos los archivos de un paquete para generar sus .d.ts<\/code> de declaraciones de tipos. Esto hace que el build sea inherentemente secuencial en ciertos puntos \u2014 un paquete no puede emitir sus tipos hasta que<\/a> termina de compilar completamente, y los paquetes que dependen de \u00e9l tienen que esperar.<\/p>\n
isolatedDeclarations: true<\/code> en el<\/a> tsconfig a\u00f1ade una restricci\u00f3n: todas las exportaciones p\u00fablicas deben tener tipos expl\u00edcitos anotados, no pueden depender solo de inferencia. A cambio, herramientas como tsc<\/code>, esbuild y otras pueden generar los .d.ts<\/code> en paralelo sin necesitar procesar los archivos de dependencias primero.<\/p>\n
Nuestro monorepo tiene doce paquetes. Con el setup anterior, el build completo en CI \u2014 incluyendo generaci\u00f3n de tipos \u2014 tardaba entre 3 minutos 45 segundos y 4 minutos 10 segundos dependiendo del runner. Despu\u00e9s de<\/a> habilitar isolatedDeclarations<\/code> y ajustar nuestro pipeline de Turborepo para aprovechar la paralelizaci\u00f3n, bajamos a 2 minutos 20 segundos de forma consistente. No es lineal con el n\u00famero de paquetes \u2014 el beneficio depende mucho de la topolog\u00eda de dependencias \u2014 pero el impacto en nuestro caso fue muy tangible.<\/p>\n
El coste es real: tienes que a\u00f1adir anotaciones de tipo expl\u00edcitas donde antes te apoyabas en inferencia para las exportaciones p\u00fablicas. Nuestro linter marca autom\u00e1ticamente las violaciones con una regla propia, as\u00ed que el burden en el d\u00eda a d\u00eda no es grande. El setup inicial requiri\u00f3 medio d\u00eda de limpieza. Si tienes un monorepo TypeScript y no est\u00e1s mirando esto, empieza por aqu\u00ed antes de mirar cualquier otra optimizaci\u00f3n de build.<\/p>\n
Predicados de Tipo Inferidos: El Bug que Llevaba Tres Meses en<\/a> el Radar<\/h2>\n
TypeScript 5.5 tambi\u00e9n trajo algo que parece menor pero que tiene una elegancia conceptual que me gusta: el compilador ahora puede inferir que una funci\u00f3n es un type predicate sin que t\u00fa lo declares expl\u00edcitamente, siempre que la l\u00f3gica sea clara.<\/p>\n
Antes, si quer\u00edas narrowing autom\u00e1tico en el callsite, ten\u00edas que anotar el return type manualmente:<\/p>\n
\/\/ Antes de 5.5: anotaci\u00f3n expl\u00edcita obligatoria para que funcione el narrowing\nfunction isString(value: unknown): value is string {\n  return typeof value === 'string';\n}\n\n\/\/ TypeScript 5.5+: inferencia autom\u00e1tica del type predicate\nconst isDefinedString = (v: string | undefined) => v !== undefined && v.length > 0;\n\nconst items = ['hello', undefined, 'world', undefined, ''];\nconst definedItems = items.filter(isDefinedString);\n\/\/ definedItems ahora es string[], no (string | undefined)[]\n\/\/ antes necesitabas el as string[] o anotar isDefinedString expl\u00edcitamente\n<\/code><\/pre>\n
Ten\u00eda un bug \u2014 o m\u00e1s bien, un \/\/ @ts-ignore<\/code> vergonzoso \u2014 en nuestro pipeline de procesamiento de eventos donde hac\u00edamos .filter(Boolean)<\/code> y luego ten\u00edamos que castear manualmente porque TS no infer\u00eda el narrowing. Era de esos parches que vives con durante semanas hasta que<\/a> te molesta lo suficiente como para investigarlo de verdad<\/a>. Cuando actualic\u00e9 a 5.5, desapareci\u00f3 solo. No tuve que tocar el c\u00f3digo.<\/p>\n
Una advertencia: si tienes predicados con l\u00f3gica muy compleja, el compilador puede no inferirlo autom\u00e1ticamente y necesitar\u00e1s la anotaci\u00f3n expl\u00edcita. Para los casos comunes de filtrado y narrowing b\u00e1sico, funciona sorprendentemente bien.<\/p>\n
\n
Despu\u00e9s de dos<\/a> a\u00f1os con TypeScript 5.x en producci\u00f3n:<\/a> no actualices en bloque esperando una transformaci\u00f3n m\u00e1gica. Actualiza de forma incremental y adopta activamente isolatedDeclarations<\/code> si tienes un monorepo, using<\/code> si manejas recursos con cleanup expl\u00edcito, y los const<\/code> gen\u00e9ricos si tienes APIs que se benefician de inferencia m\u00e1s precisa. Los decoradores estables merecen la migraci\u00f3n, pero planif\u00edcala \u2014 no la hagas el viernes por la tarde.<\/p>\n
TypeScript 5.x no reinvent\u00f3 el lenguaje. Lo que hizo fue cerrar brechas que llevaban a\u00f1os abiertas, y en producci\u00f3n<\/a> eso vale m\u00e1s que cualquier feature nueva que suene impresionante en un changelog pero que rara vez tocas en el trabajo<\/a> real.<\/p>\n
<\/p>\n","protected":false},"excerpt":{"rendered":"
Llevo casi dos a\u00f1os usando TypeScript 5.x activamente \u2014 primero en un proyecto personal, luego en producci\u00f3n con un equipo de seis personas construyendo un<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"site-sidebar-layout":"default","site-content-layout":"","ast-site-content-layout":"default","site-content-style":"default","site-sidebar-style":"default","ast-global-header-display":"","ast-banner-title-visibility":"","ast-main-header-display":"","ast-hfb-above-header-display":"","ast-hfb-below-header-display":"","ast-hfb-mobile-header-display":"","site-post-title":"","ast-breadcrumbs-content":"","ast-featured-img":"","footer-sml-layout":"","ast-disable-related-posts":"","theme-transparent-header-meta":"","adv-header-id-meta":"","stick-header-meta":"","header-above-stick-meta":"","header-main-stick-meta":"","header-below-stick-meta":"","astra-migrate-meta-layouts":"default","ast-page-background-enabled":"default","ast-page-background-meta":{"desktop":{"background-color":"var(--ast-global-color-5)","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""},"tablet":{"background-color":"","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""},"mobile":{"background-color":"","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""}},"ast-content-background-meta":{"desktop":{"background-color":"var(--ast-global-color-4)","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""},"tablet":{"background-color":"var(--ast-global-color-4)","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""},"mobile":{"background-color":"var(--ast-global-color-4)","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""}},"footnotes":""},"categories":[1],"tags":[],"class_list":["post-508","post","type-post","status-publish","format-standard","hentry","category-general"],"_links":{"self":[{"href":"https:\/\/blog.rebalai.com\/es\/wp-json\/wp\/v2\/posts\/508","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/blog.rebalai.com\/es\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/blog.rebalai.com\/es\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/blog.rebalai.com\/es\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/blog.rebalai.com\/es\/wp-json\/wp\/v2\/comments?post=508"}],"version-history":[{"count":11,"href":"https:\/\/blog.rebalai.com\/es\/wp-json\/wp\/v2\/posts\/508\/revisions"}],"predecessor-version":[{"id":761,"href":"https:\/\/blog.rebalai.com\/es\/wp-json\/wp\/v2\/posts\/508\/revisions\/761"}],"wp:attachment":[{"href":"https:\/\/blog.rebalai.com\/es\/wp-json\/wp\/v2\/media?parent=508"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/blog.rebalai.com\/es\/wp-json\/wp\/v2\/categories?post=508"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/blog.rebalai.com\/es\/wp-json\/wp\/v2\/tags?post=508"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}