Category: TypeScript

satisfies operator: el operador de TypeScript que no estás usando

Tiempo estimado de lectura: 5 min

• Valida sin perder inferencia: El operador satisfies valida que una expresión cumpla un tipo sin cambiar el tipo inferido del valor.
• Mejora la DX en repos grandes: Conserva literales y autocompletado donde las anotaciones tradicionales causan upcast o las aserciones apagan la seguridad.
• Casos de uso claros: Constants, routes, design tokens y mapeos estáticos se benefician más.
• Complemento con as const: Úsalo junto a as const para validación más inmutabilidad absoluta.
• No es para runtime: No reemplaza validación en tiempo de ejecución para datos dinámicos.

Introducción

satisfies operator: el operador de TypeScript que no estás usando es la frase que deberías leer en todos los PRs donde alguien fuerza tipos con as o sacrifica la inferencia de literales. Introducido en TypeScript 4.9, satisfies arregla —sin drama— un problema de tipado que hemos parcheado mal durante años.

Resumen rápido (lectores con prisa)

Qué es: Un operador de TypeScript que valida que un valor cumple un tipo sin cambiar la inferencia del valor.
Cuándo usarlo: Para constantes exportadas, rutas, tokens de diseño y mapeos estáticos donde quieres conservar literales.
Por qué importa: Mantiene autocompletado y seguridad de tipos en grandes bases de código.
Cómo funciona: Verifica el contrato en tiempo de compilación y deja intacta la inferencia literal.

¿Qué hace exactamente el satisfies operator y por qué importa?

El operador satisfies valida que una expresión cumpla con un tipo, pero no cambia el tipo inferido del valor. Es decir: verifica el contrato y deja intacta la inferencia literal del valor. Eso suena pequeño; en equipos con bases de código grandes es una diferencia estructural.

Comparación con anotación y aserción

• La anotación const x: T = ... valida pero hace upcast: pierde literales.
• La aserción const x = ... as T fuerza sin validar: apaga la seguridad.
• const x = ... satisfies T valida y conserva la inferencia.

Ejemplo práctico: tema de colores que no deberías arruinar

Sin satisfies, acabas escribiendo código que obliga al IDE a perder información útil:

type Color = string | [number, number, number];

const theme: Record = {
  primary: "blue",
  secondary: [255, 0, 0]
};

theme.primary.startsWith("b"); // Error: theme.primary es Color, no string literal

Con satisfies:

const theme = {
  primary: "blue",
  secondary: [255, 0, 0]
} satisfies Record;

theme.primary.startsWith("b"); // OK — TypeScript sabe que es string
theme.secondary[0];            // OK — sabe que es number

Validación sin amputación de tipos. Eso es todo.

Casos de uso donde satisfies aporta valor real

– Configuraciones públicas (constants.ts). Valores exportados y consumidos desde varios módulos se benefician de mantener literales.
– Rutas y diccionarios (routing). keyof typeof ROUTES debe devolver claves concretas, no string.
– Design tokens y paletas. Necesitas diferenciar hex strings de tuplas RGB sin perder método de string/array.
– API clients estáticos o mapeos entre endpoints y tipos de respuesta.

Ejemplo de rutas

type RouteConfig = Record;

const ROUTES = {
  home:      { path: "/",    protected: false },
  dashboard: { path: "/app", protected: true  },
} satisfies RouteConfig;

// keyof typeof ROUTES => "home" | "dashboard"

Si hubieras usado : RouteConfig, perderías esas claves y con ellas, seguridad y autocompletado.

Patrón avanzado: satisfies + as const

Úsalos juntos cuando quieras validación + inmutabilidad absoluta:

const ENDPOINTS = {
  users:   "/api/users",
  session: "/api/session",
} satisfies Record as const;

// ENDPOINTS.users es literal "/api/users" y readonly

Esto es ideal para inyectar constantes que se comparten por toda la app sin riesgo de mutación accidental.

Cuándo no usar satisfies

No es una bala de plata. No lo apliques en cada tipo local ni donde el valor no necesite exportarse o conservar literales.

• Definición y consumo inmediato en el mismo scope → anotación clásica puede ser más clara.
• Datos dinámicos desde la red → valida en runtime (Zod, io-ts) y transforma antes de confiar en tipos.

Recuerda: satisfies es para diseño estático y claridad, no para validar payloads de clientes externos en producción.

Cómo adoptarlo en un repo sin romper nada

1. Audit rápido: busca ficheros constants, theme, routes, tokens.
2. Busca patrones problemáticos: as const seguido de as Type, o const X: Record<...> = {...}.
3. Reemplaza por satisfies donde quieras conservar literales.
4. Añade tests de tipo (tsd) para casos críticos y ejecuta tsc --noEmit en CI.
5. Actualiza guía de estilo y explica el porqué en CONTRIBUTING.md.

Comando grep útil:
grep -R --line-number -E "as const.*as |: Record<|: {[A-Za-z0-9_]+: .*}" src/

Impacto en equipo y mantenimiento

Adoptar satisfies reduce errores sutiles: llamadas a funciones con claves incorrectas, fallos de autocompletado que llevan a as any, y la necesidad de escribir casts defensivos. A nivel de DX, mejora el autocompletado y la intención del código. A nivel de arquitectura, reduce deuda técnica silenciosa: menos as T, menos // @ts-ignore.

Cierre práctico

No es una moda; es una herramienta ergonométrica del tipo system. Si tu repo exporta constantes que consumen otros módulos, haz una pasada hoy mismo y reemplaza las anotaciones que hacen upcast por satisfies. Empieza por constants.ts, theme.ts, routes.ts. Verás menos PRs con as any y más código que documenta intención y comportamiento real.

Implementarlo es simple. Ignorarlo es caro. Esto no acaba aquí: la próxima vez que veas un as en un PR, pregúntate si deberías usar satisfies en su lugar.

Referencia oficial (anuncio): la sección relevante y la documentación general.

FAQ

¿Cansado de que las fechas te arruinen la noche? Bienvenido a Temporal

Tiempo estimado de lectura: 6 min

• Temporal reemplaza a Date para lógica de negocio: menos bugs y contratos más claros.
• Almacena Instants en DB (ISO UTC canonical) y convierte a zonas locales solo en UI.
• Polyfill hoy, tipos con TypeScript 6.0: feature-detect y carga condicional.
• Migración por capas y tests: evita PR monstruo, prioriza fronteras y añade reglas ESLint.

Resumen rápido (lectores con prisa)

Temporal es la API moderna para manejar tiempo en JS. Usa Instant para puntos absolutos (DB/logs), ZonedDateTime para eventos con zona y PlainDate para fechas sin hora. TypeScript 6.0 trae tipos; usa el polyfill donde el runtime no lo implemente.

Configuración y polyfill

TypeScript 6.0 trae los tipos de Temporal, pero el runtime puede no implementarlo aún en todos los motores.

Para usarlo hoy en Node o navegadores, instala el polyfill oficial:

npm install @js-temporal/polyfill

En el punto de entrada (server o client) haz feature-detect y carga el polyfill solo si hace falta:

if (!globalThis.Temporal) {
  await import('@js-temporal/polyfill');
}

Asegura tsconfig:

{
  "compilerOptions": {
    "target": "esnext",
    "lib": ["esnext"],
    "strict": true
  }
}

Qué cambia en tu arquitectura (reglas rápidas)

• No más new Date() para lógica de negocio.
• Almacena timestamps en DB como Instant (ISO) — UTC canonical.
• Muestra/convierte a zonas locales con ZonedDateTime solo donde importe (UI, emails, calendarios).
• En tests y serialización: convierte a strings para persistir; rehidrata con Temporal.from() al cargar.

Casos prácticos y patrones — copia, pega y aplícalo

1) Obtener “ahora” correctamente

// Instant (UTC preciso, para auditoría/logs)
const nowInstant = Temporal.Now.instant();

// ZonedDateTime (evento con zona)
const nowZoned = Temporal.Now.zonedDateTimeISO();

// PlainDate (cumpleaños, sin hora ni zona)
const today = Temporal.Now.plainDateISO();

2) Sumar y restar sin mutar

const hoy = Temporal.Now.plainDateISO();
const dentroDe7Dias = hoy.add({ days: 7 }); // creado nuevo, hoy no cambia

3) Guardar en BD (mejor práctica)

• Guarda Instants como strings: instant.toString() → “2024-05-01T12:00:00Z”.
• Razonamiento: Instant es un punto absoluto; si reconstituyes en otro país, sigues teniendo el mismo momento.

const timestamp = Temporal.Now.instant().toString();
// INSERT INTO events (created_at) VALUES (timestamp);

Recuperación:

const instantFromDb = Temporal.Instant.from(dbValue);
const zonedInMadrid = instantFromDb.toZonedDateTimeISO('Europe/Madrid');

4) Mostrar en UI (zona del usuario)

const instant = Temporal.Instant.from(event.created_at);
const inUserTZ = instant.toZonedDateTimeISO(user.timeZone);
const formatted = inUserTZ.toLocaleString('es-ES', { dateStyle: 'medium', timeStyle: 'short' });

5) Schedules y DST (sin manualidades)

const vuelo = Temporal.ZonedDateTime.from('2024-10-15T14:30:00+09:00[Asia/Tokyo]');
const llegadaMadrid = vuelo.withTimeZone('Europe/Madrid');
// Temporal aplica reglas de DST correctamente.

Migración práctica y estrategia (no pegues un PR monstruo)

Plan corto y efectivo:

1. Detecta usos

• grep/rg por new Date(, Date.now(), .toISOString(), getUTC*, setUTC*.
• Haz una lista priorizada: endpoints, parsers de JSON, jobs, filas de cola.

2. Protege el repo

Añade rule de ESLint que prohíba new Date en código nuevo:

// .eslintrc.json
"rules": {
  "no-restricted-syntax": [
    "error",
    {
      "selector": "NewExpression[callee.name='Date']",
      "message": "Usa Temporal en lugar de Date"
    }
  ]
}

3. Cambia en capas

• Fronteras primero: parsers de requests, handlers, webhooks.
• Library layer: utilidades de fecha centralizadas.
• UI: formateadores y locales.

4. Persistencia y API contract

• Define y documenta: “todos los timestamps en la DB son Instant ISO strings”.
• Añade validaciones en los endpoints que aceptan timestamps (Zod / Zod schemas o runtime checks).

5. Tests y CI

• En jest/mocha, añade el polyfill en setupTests: import '@js-temporal/polyfill';
• Añade pruebas para zona horaria, DST y serialización.

Peculiaridades y errores que verás (y cómo arreglarlos)

• Serialización: Temporal types no siempre serializan como esperas en JSON.stringify. Convierte a string explícitamente.
• Redux / Hydration: almacena ISO strings en store si necesitas serialización. Temporal objects son inmutables pero no pensados para serializar automáticamente.
• Comparaciones: usa Temporal.PlainDate.compare o Instant.avoid numeric timezone math.
• Interoperabilidad con libs: elimina gradualmente date-fns/moment; si dependes de ellas, mantén adaptadores hasta reemplazar lógica.

Decisiones de diseño: Instant vs ZonedDateTime vs PlainDate

• Instant → logs, audit, DB primary timestamp.
• ZonedDateTime → eventos programados que dependen de la hora local.
• PlainDate → cumpleaños, fechainterna sin hora.
• Duration → expiraciones, TTLs, duraciones humanas.

Ejemplo real: reserva de vuelo (correcto)

• Guardar en DB: Vuelo.departureInstant (Instant)
• Guardar metadatos: Vuelo.departureTZ = 'Asia/Tokyo'
• Mostrar en UI: instant.toZonedDateTimeISO(tz).toLocaleString(...)

Performance y bundle

El polyfill tiene coste. Si tu app es frontend, lazy-load the polyfill: solo usuarios que lo necesiten (browsers sin Temporal nativo) lo cargarán.

En server (Node), añade polyfill en arranque. No suele ser un problema de perf si lo colocas correctamente.

Checklist rápido antes de mergear cambios de fecha

• Todos los endpoints aceptan/retornan ISO Instant cuando corresponde.
• Tests cubren conversiones entre zonas y casos límites (fin de mes, cambio DST).
• No quedan new Date() en la lógica de negocio.
• Documentación para frontend/backend: cómo serializar y rehidratar.

Metáfora breve: por qué vale la pena

Date era un martillo con un tornillo. Temporal es el juego de herramientas correcto para el tiempo. No es más trabajo: es menos debugging.

Cierre (CTA claro)

¿Quieres el script que escanea tu repo, lista todas las ocurrencias de Date y genera un plan de migración automático por prioridad? Respóndeme con “MIGRAR FECHAS” y te lo entrego: branch de prueba, report con 100 entradas ordenadas, y PR template para cada cambio.

Esto no acaba aquí. La siguiente nota: cómo reescribir utilidades de date-fns a Temporal con transformaciones seguras y codemods semi-automáticos. ¿Lo hacemos?

Si te interesa integrar estas prácticas con flujos de trabajo y automatización de repos, revisa Dominicode Labs para plantillas y herramientas que aceleran migraciones y codemods.

FAQ

¿Tu repo se va a romper cuando actualices a TypeScript 6.0? Probablemente sí. Si no, felicidades: estás en el 10% que ya hacía las cosas bien.

Tiempo estimado de lectura: 7 min

• Strict: true en TS 6.0 es un cambio por defecto que destapará muchos errores latentes.
• Activa banderas gradualmente (noImplicitThis, useUnknownInCatchVariables, noImplicitAny, etc.) y haz PRs pequeños.
• Plan de migración de 6 semanas práctico y enfocado para repos medianos.
• Herramientas y atajos (skipLibCheck, unknown vs any, validadores) para acelerar sin sacrificar seguridad.

Resumen rápido (lectores con prisa)

Strict: true en TS 6.0 activa varias banderas que convierten advertencias silenciosas en errores compilables. Migrar requiere activar banderas por fases, priorizar endpoints/serializadores y usar atajos como skipLibCheck y unknown para avanzar sin bloquear el desarrollo.

Primero, lo obvio (pero que nadie quiere admitir)

• Si ya tienes “strict”: true: no cambia nada.
• Si no lo tenías, al actualizar a TS 6.0 el compilador se pondrá estricto y te lloverán errores.
• Puedes parchear rápido con “strict”: false en tsconfig, pero eso es anestesia. No arregla la enfermedad.

strict no es una única regla. Es un paraguas que enciende varias banderas. Cada una toca piezas distintas del código y cada una duele distinto.

Piensa en strict como un filtro de rayos X: te muestra huesos rotos que antes eran invisibles.

Las banderas, qué hacen y por qué importan (con ejemplos reales)

1) noImplicitAny — El fin de los `any` silenciosos

Qué hace: hace error todo lugar donde TS no pueda inferir el tipo y quedaría any.

Problema típico:

const fn = (payload) => { return payload.name; }

Antes: compila. Después: error.

Arreglo:

const fn = (payload: { name: string }) => payload.name;

Por qué importa: porque any es una mentira que llega a producción sin avisar.

2) strictNullChecks — La regla que evita el “Cannot read properties of undefined”

Qué hace: separa null y undefined de otros tipos.

Problema típico:

function greet(name: string) { return name.toLowerCase(); }
const maybeName: string | null = getName();
greet(maybeName); // Boom si es null

Arreglo:

function greet(name: string) { return name.toLowerCase(); }
const maybeName = getName();
if (maybeName) greet(maybeName);

O escribe la firma:

function greet(name: string | null) { if (!name) return; return name.toLowerCase(); }

Por qué importa: obliga a pensar en ausencia de datos. Nada peor que toLowerCase() explotando en prod.

3) strictFunctionTypes — Contravarianza correcta

Qué hace: comprueba que los tipos de parámetros en funciones sean seguros al asignarlas.

Ejemplo peligroso:

type Handler = (e: Event) => void;
function specificHandler(e: MouseEvent) { /* usa e.clientX */ }
const h: Handler = specificHandler; // antes ok, ahora error

Arreglo: Alinea firmas o usa overloads. No metas handlers con supuestos concretos donde se espera generalidad.

4) strictBindCallApply — Validación de bind/call/apply

Qué hace: valida que los argumentos pasados con call/apply/bind casen con la firma original.

Caso:

function sum(a: number, b: number) { return a + b; }
sum.call(null, "str", 3); // antes pasaba, ahora no

Por qué importa: evita bugs raros cuando se manipula this y argumentos dinámicos.

5) strictPropertyInitialization — Clases más predecibles

Qué hace: exige inicializar propiedades o declararlas como posiblemente undefined.

Antes:

class Foo { value: number; constructor() {} }
const f = new Foo(); console.log(f.value); // undefined

Con la bandera activada: error en compilación. Arreglo:

class Foo { value: number = 0; }

O si la inicialización viene después:

class Foo { value!: number } // use with care
o
class Foo { value?: number }

6) noImplicitThis — Control del “this”

Qué hace: si TS no sabe qué es this en una función, da error.

Ejemplo:

const obj = {
  x: 1,
  getX() { return this.x; }
}
const f = obj.getX;
f(); // this es global — error ahora

Arreglo: tipa this en la función:

getX(this: { x: number }) { return this.x; }

7) useUnknownInCatchVariables — catch seguro

Qué hace: cambia catch (e) de any a unknown.

Ejemplo:

try { ... } catch (e) { console.log(e.message); } // ahora error

Arreglo:

try { ... } catch (e: unknown) {
  if (e instanceof Error) console.log(e.message);
}

Esto fuerza buenos patrones de manejo de errores y evita suposiciones peligrosas.

Estrategia práctica: cómo migrar sin suicidarte

No intentes arreglar 5.000 errores en un PR. Eso no es noble; es destructivo.

Plan de 6 semanas (realista para repos medianos)

Semana 0 — Preparación

• Crea branch “ts-migration/strict”.
• Añade CI que compile en strict y que no bloquee master todavía.
• Si la migración debe ser suave, temporalmente coloca “strict”: false para que CI siga pasando mientras trabajas.

Semana 1 — Protección inmediata

• Activa noImplicitThis y useUnknownInCatchVariables.
• Razon: cambios pequeños, refactors simples, impacto bajo.
• Haz PRs pequeños. Revisa con atención en code owners.

Semana 2 — Sanear `any`

• Activa noImplicitAny.
• Prioriza endpoints y parsers: handlers de API, converters, deserializadores.
• Empieza a reemplazar any por tipos concretos o unknown + validación.

Semana 3-4 — Funciones y propiedades

• Activa strictFunctionTypes.
• Refactoriza callbacks y firmas exportadas.
• Activa strictPropertyInitialization y arregla inicializaciones en clases públicas.

Semana 5 — El gran salto

• Activa strictNullChecks.
• Este es el más complicado. Reescribe funciones que asumían no-null implícito.
• Amplía tests unitarios. Añade pruebas para casos nulos/undefined.

Semana 6 — Finalización

• Ejecuta npx tsc --noEmit en todo el repo.
• Revisa errores residuales; limpia // @ts-ignore que se usó como parche.
• Mueve strict a true en tsconfig principal y mergea.

Comandos útiles que vas a repetir hasta odiarlos

• Inicializar config: npx tsc --init
• Compilar sin emitir: npx tsc --noEmit
• Compilar un proyecto con build mode: npx tsc -b
• Detectar errores en workspace monorepo: npx lerna exec -- npx tsc --noEmit (o tu equivalente)

Trucos y atajos para acelerar la migración

• Usa skipLibCheck: true mientras migras para no pelear con tipos de dependencias.
• Introduce types o index.d.ts temporales sólo para las partes que bloquean.
• Prefiere unknown a any y escribe validadores pequeños si es necesario.
• Añade eslint rule para prohibir // @ts-ignore excepto con razón y ticket.

Checklist mínimo antes de mergear a master

• CI compila con strict: true.
• Tests cubren entradas nulas y errores.
• No any sin ticket que lo justifique.
• Documentación de breaking changes en PR.
• Plan de rollback (tag + branch) por si algo explota en prod.

Errores comunes que vas a ver (y cómo solucionarlos rápido)

• "Object is possibly 'null'." → Optional chaining o comprobación previa.
• "Parameter implicitly has an 'any' type." → Añade tipo explícito o infiere con generics.
• "Property has no initializer and is not definitely assigned in the constructor." → Inicializa o marca como optional.

Metáfora corta: ¿por qué todo esto vale la pena?

Poner strict por defecto es como obligar a instalar cinturón de seguridad en todos los coches nuevos. Al principio fastidia, pero salva vidas y reduce reclamaciones. Te obliga a pensar, a documentar y a dejar menos trampas para producción.

Argumentos para convencer a la gerencia

• Menos bugs en producción = menos on-call nocturno.
• Código más legible = onboarding más rápido.
• Mejores contratos = menos regresiones en refactors.

Cuando NO migrar ahora

• Repos monolíticos gigantes sin tests.
• Sistemas que requieren compatibilidad inmediata con CommonJS profundo.
• Migraciones sincronizadas de múltiples equipos donde el riesgo de romper pipelines es alto.

Si caes en estos casos, planifica la migración, no la improvises.

Cierre agresivo pero útil

No es una moda. Es una obligación técnica. Si tu equipo no puede permitirse el tiempo de migrar, al menos que lo documente y tenga roadmap. No dejes el problema para “cuando tengamos tiempo” — ese cuando nunca llega.

¿Quieres una ayuda real y directa?

Respóndeme con “MIGRAR MI REPO” y te envío:

• Un script que crea el branch de migración,
• Activa strict en un tsconfig de prueba,
• Ejecuta npx tsc --noEmit,
• Genera un reporte con los 100 errores más comunes ordenados por archivo y tipo.

Esto no acaba aquí. Si lo ejecutas, empezaremos la siguiente nota: cómo redactar PRs pequeños para migraciones de types (plantillas incluidas). ¿Lo quieres?

FAQ

• ¿Qué es “strict: true” en TypeScript 6.0?
• ¿Por qué voy a ver tantos errores al actualizar?
• ¿Puedo parchear temporalmente la migración?
• ¿Cuál es la bandera que menos impacto tiene al principio?
• ¿UseUnknownInCatchVariables romperá mi manejo de errores actual?
• ¿Qué hacer con librerías de terceros con tipos rotos?
• ¿Cómo evitar PRs enormes durante la migración?

¿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?