¿Quieres que tus tipos de TypeScript hagan el trabajo sucio por ti —y de verdad— en vez de darte una falsa sensación de seguridad?

Tiempo estimado de lectura: 4 min

• Los tipos condicionales (T extends U ? X : Y) se evalúan en tiempo de compilación y permiten metaprogramación robusta.
• infer captura partes de tipos para extraer retornos, parámetros y elementos internos sin runtime.
• Patrones clave: Unwrap para Promises, evitar distribución con tuplas, manipular tuples con Head/Tail, y extraer retornos async.
• Precauciones: complejidad excesiva, deuda técnica y necesidad de validación runtime para datos externos.

Bien. Aquí tienes una guía práctica que no promete magia, pero sí te salva de la gimnasia de tipos inútil y de bugs que aparecen a las 2AM.

Resumen rápido (lectores con prisa)

Los condicionales de tipos son ternarios que TypeScript evalúa en tiempo de compilación. infer permite extraer partes de un tipo coincidente. Úsalos para utilidades tipo-level (Unwrap, AsyncReturn, Head/Tail) y evita su abuso: documenta, limita y combina con validación runtime cuando el input viene de la red.

Introducción

Primero, lo obvio: el condicional de tipos es un ternario que vive en el compilador. Sintaxis: T extends U ? X : Y. Se evalúa en tiempo de compilación. No en runtime. Eso lo convierte en una espada afilada: poderosa, pero cortante.

Condicionales de tipos

Sintaxis

Sintaxis: T extends U ? X : Y. Se evalúa en tiempo de compilación.

Ejemplo mínimo

type IsString<T> = T extends string ? true : false;
type A = IsString<'hola'>; // true
type B = IsString<42>;     // false

Sencillo. Útil para construir utilidades.

infer

Qué es

infer captura piezas del tipo que estás inspeccionando. Es la manera de decirle a TS: “si esto encaja, arráncame esto otro”.

Ejemplo clásico — extraer el tipo de retorno

type MyReturn<T> = T extends (...args: any[]) => infer R ? R : never;
type Fn = () => { id: number };
type R = MyReturn<Fn>; // { id: number }

Útil. Limpio. Poderoso.

Patrones

Patrón 1 — Unwrap de Promises (recursivo)

Cuando trabajas con APIs, las promesas anidadas son una plaga. Esto te limpia el resultado:

type Unwrap<T> = T extends Promise<infer U> ? Unwrap<U> : T;
type X = Unwrap<Promise<Promise<{ ok: true }>>>; // { ok: true }

Patrón 2 — Tipos distributivos y el problema que nadie lee

Si T es una unión, el condicional se aplica a cada miembro (distribuye). A veces quieres eso. A veces no.

Distribución:

type ExcludeFunc<T> = T extends Function ? never : T;
type U = ExcludeFunc<string | (() => void)>; // string

Evitar distribución

Envuélvelo en una tupla.

type NoDist<T> = [T] extends [Function] ? never : T;

Memorízalo. Te salvará de errores raros.

Patrón 3 — Extraer elementos de tuples/arrays

infer también domina tuplas. Necesitas sacar head/tail o el último elemento:

type Head<T extends any[]> = T extends [infer H, ...any[]] ? H : never;
type Tail<T extends any[]> = T extends [any, ...infer R] ? R : never;

Esto abre puertas para manipulaciones tipo-level sin hacer trampas.

Patrón 4 — AsyncReturnType para funciones async

type AsyncReturn<T> = T extends (...args: any[]) => Promise<infer R> ? R : never;

Ideal para tipos de efectos y sagas.

Casos reales donde esto brilla

• Clientes HTTP tipados por endpoint (súper seguro, sin as adivinatorio).
• Librerías que exponen utilidades genéricas robustas.
• Metaprogramación de APIs internas (mapea rutas a tipos de response).
• Sistemas de validación y mapeo que dependen de signatures de funciones.

Ejemplo rápido: tipos por endpoint

interface Endpoints {
  '/users': { id: string, name: string }[];
  '/status': { ok: boolean };
}

function fetchApi<T extends keyof Endpoints>(url: T): Promise<Endpoints[T]> {
  return fetch(url).then(r => r.json());
}

No más any. No más guessing.

Pitfalls — Lo que te rompe la vida si no tienes cuidado

• Complexity blowup: tipos gigantes ralentizan el compilador. TS puede confundirse y tirar errores crípticos.
• Abuso: si tu equipo no entiende, se convierte en deuda técnica invisible.
• Debug hard: errores en tipos a veces son opacos; documenta y divide tipos largos.
• Runtime vs compile-time: los tipos no validan data externa. Para eso, runtime schemas (Zod) son tus amigos.

Buenas prácticas — rápido y aplicable

• Usa tipos condicionales en librerías y núcleos infra. No en cada componente.
• Nombra aliases: type AsyncReturn<T> = ... — no pongas 10 ternarios directos.
• Comenta. Sí, los tipos necesitan comentarios.
• Mantén límites: si un tipo tiene más de 30–40 líneas, replantea.
• Combina con validación runtime donde el input viene de la red.
• Testea tipos con tsd o expect-type para evitar regresiones.

Trucos avanzados en dos líneas

• Forzar no-distribución: [T] extends [U] ? X : Y.
• Obtener parámetros de una función: type Params<T> = T extends (...a: infer A) => any ? A : never;
• Extraer propiedades no-función: usa mapped types con condicionales para filtrar claves.

Metáfora rápida para que no lo olvides

Los tipos condicionales son el sistema inmunitario del código. Te protegen si los pones en el lugar correcto. Si los usas por todos lados sin control, te provocan una reacción autoinmune: complejidad que te derriba.

¿Quieres algo práctico que puedas pegar ya?

Puedo mandarte:

• Un cheat-sheet con 25 utilidades (Unwrap, AsyncReturn, Head, Tail, PickByValue, etc.).
• Un pequeño repo con ejemplos y tests de tsd.
• Un snippet para un cliente HTTP tipado por endpoints + validación Zod integrada.

Responde “Envíame el cheat-sheet” y te lo paso listo para copiar. No es teoría. Es la diferencia entre escribir tipos y dejar que los tipos te salven. Esto no acaba aquí.

FAQ

• ¿Qué es un condicional de tipos en TypeScript?
• ¿Qué hace infer?
• ¿Cómo evito que un condicional distribuya sobre una unión?
• ¿Los tipos garantizan que los datos externos sean válidos?
• ¿Cuándo debo usar estos patrones vs validación runtime?
• ¿Qué herramientas recomiendas para testear tipos?

TypeScript 7.0 en Go: qué está pasando y por qué es histórico

Tiempo estimado de lectura: 3 min

• Reescritura en Go: Microsoft está migrando el compilador oficial de TypeScript a Go, buscando binarios nativos, paralelismo real y un GC con latencias más predecibles.
• Rendimiento práctico: Benchmarks internos muestran mejoras de orden de magnitud que reducen compilaciones de minutos a segundos, con impacto directo en CI/CD y experiencia de editor.
• Compatibilidad y fricción: Integraciones que consumen la API interna de tsc requerirán adaptación (RPC, bindings, WASM) y pruebas exhaustivas en casos límite.
• Acción inmediata: Estabilizar en TypeScript 6.0, automatizar chequeos de tipos en CI y mapear dependencias que usan la API interna de tsc.

Tabla de contenidos

• TypeScript 7.0 en Go: qué está pasando y por qué es histórico
• Introducción
• Resumen rápido (lectores con prisa)
• TypeScript 7.0 en Go: qué está pasando y por qué es histórico (resumen técnico)
• Por qué importa para proyectos grandes y monorepos
• Impacto en Angular y React: matices prácticos
• Impacto — Angular
• Impacto — React/Next.js/Vite
• Riesgos y fricciones en el ecosistema
• Qué hacer hoy: plan de preparación para equipos técnicos
• Perspectiva: por qué es histórico
• Fuentes y lecturas
• FAQ

TypeScript 7.0 en Go: qué está pasando y por qué es histórico — la frase debería ser familiar para cualquier Tech Lead que haya sufrido compilaciones lentas en monorepos. Microsoft está reescribiendo el compilador de TypeScript en Go, un movimiento que cambia la base de rendimiento y operacionalidad de todo el ecosistema. Esto no es una mejora incremental: es una rearquitectura que hace viable un análisis tipo‑a‑gran escala sin renunciar a la precisión semántica que define a TypeScript.

Resumen rápido (lectores con prisa)

TypeScript 7.0 es la reescritura del compilador oficial en Go, orientada a rendimiento y paralelismo. Ofrece binarios nativos, mejor paralelización y un GC con latencias más predecibles. Es relevante para monorepos, CI y experiencia de editor. Prepara la migración estabilizando en TypeScript 6.0 y automatizando chequeos de tipos en CI.

TypeScript 7.0 en Go: qué está pasando y por qué es histórico (resumen técnico)

El compilador actual está escrito en TypeScript y corre sobre Node/V8. Esa decisión fue pragmática en 2012, pero hoy limita la paralelización y sufre del JIT/GC de V8 en cargas largas. Reescribir tsc en Go aporta tres ventajas concretas:

• Binarios nativos sin warm‑up de JIT.
• Paralelismo real con goroutines y memoria compartida para analizar módulos en paralelo.
• Un GC con latencias más predecibles, mejorando la experiencia de tsserver.

Las herramientas que demostraron el valor del código nativo ya probaron que compilar fuera de Node puede multiplicar la velocidad. SWC, esbuild, Biome y Turbopack ya marcaron esa tendencia. Ahora el compilador oficial entra en esa categoría, pero manteniendo la verificación de tipos completa que esas herramientas no cubren.

Por qué importa para proyectos grandes y monorepos

Los beneficios no son teóricos. Microsoft reporta mejoras de orden de magnitud en benchmarks internos, reduciendo compilaciones que tardaban minutos a segundos. Traducido a la vida real:

• CI/CD: menos minutos por ejecución ⇒ menos coste y despliegues más rápidos.
• tsserver: indexado y respuestas en el editor que no degradan con el tiempo.
• Compilaciones incrementales: casi instantáneas en repositorios con cientos de paquetes.

Si tu pipeline actual dedica gran parte del tiempo a tsc --noEmit, esto cambia la economía del desarrollo.

Impacto en Angular y React: matices prácticos

Angular

Angular está fuertemente integrado con el pipeline de TypeScript (Angular Compiler y Language Service). Proyectos enterprise con workspaces (Nx, monorepos) verán una mejora directa en ng build, ng serve y en la reactividad de las herramientas de plantilla.

React/Next.js/Vite

La cadena de transpilación de React/Next.js/Vite ya utiliza SWC o esbuild para velocidad, pero sigue ejecutando tsc para verificación de tipos en CI. Ahí la ganancia será ostensible: los chequeos de tipos dejarán de ser el cuello de botella de los pipelines.

En ambos casos, el resultado es práctico: menos tiempo en loops edit→build→test y más capacidad para ejecutar validaciones costosas (análisis estático adicional) sin penalizar al equipo.

Riesgos y fricciones en el ecosistema

El cambio es histórico, no indoloro. Puntos a vigilar:

• Herramientas que consumen la API del compilador (por ejemplo ts-morph) necesitarán adaptaciones para interoperar con el nuevo binario o exponer puentes (RPC, bindings, WASM).
• Integraciones internas que dependen de detalles de implementación de tsc pueden requerir trabajo de migración.
• Compatibility testing: aunque el lenguaje no debería cambiar, diferencias sutiles en corner cases exigen pruebas exhaustivas.

La recomendación es seguir la guía oficial del repositorio de TypeScript y monitorizar los anuncios de Microsoft para migraciones y tooling.

Qué hacer hoy: plan de preparación para equipos técnicos

1. Estabiliza tu base de código en TypeScript 6.0: activa strict: true y corrige errores. TypeScript 6.0 actúa como puente hacia 7.0.
2. Automatiza chequeos de tipos en CI: ejecuta tsc --noEmit y añade cobertura para casos límite de tipos.
3. Identifica dependencias: detecta librerías y herramientas que usan la API interna de tsc y marca tickets de migración.
4. Mide: registra tiempos actuales de compilación y coste de CI para cuantificar mejoras futuras.
5. Mantén pruebas: pruebas end‑to‑end y contract tests; cualquier cambio del compilador debe validar el comportamiento real del producto.

Perspectiva: por qué es histórico

La convergencia de herramientas nativas (Rust/Go) con el ecosistema JavaScript es una tendencia clara: mayor velocidad sin perder integridad semántica. TypeScript 7.0 no es solo rendimiento; es la posibilidad de escalar el análisis estático a organizaciones enteras sin sacrificar productividad. Para equipos que priorizan calidad y velocidad operativa, esto reconfigura las decisiones de arquitectura y la inversión en tipado.

Fuentes y lecturas

• TypeScript (repositorio oficial)
• SWC
• esbuild
• Biome
• Turbopack
• ts-morph

Adoptar TypeScript 6.0 y preparar tu infraestructura ahora es la mejor forma de capitalizar la promesa de TypeScript 7.0 en Go cuando el binario esté listo para producción.

FAQ

• ¿Qué cambia exactamente al reescribir tsc en Go?
• ¿Debo migrar mis repositorios ahora mismo?
• ¿Cómo afectará esto a mi CI/CD?
• ¿Qué pasa con herramientas que usan la API de tsc?
• ¿Cambiará el lenguaje TypeScript?
• ¿Cómo puedo medir el beneficio esperado?