Pockit
Back

La Revolución de TypeScript 5.5: Type Predicates Inferidos Explicados

La Revolución de TypeScript 5.5: Type Predicates Inferidos Explicados

Si has escrito TypeScript por algún tiempo, probablemente has escrito código como este:

function isString(value: unknown): value is string {
  return typeof value === 'string';
}

¿Esa parte de value is string? Se llama type predicate. Y durante años, tenías que escribirlo manualmente cada vez que querías que TypeScript entendiera que tu función estrecha tipos.

TypeScript 5.5 lo cambia todo.

Con la nueva característica Inferred Type Predicates, TypeScript ahora puede inferir automáticamente estos type predicates desde el cuerpo de tu función. Sin más anotaciones manuales. Sin olvidar agregarlas. El compilador simplemente... lo descubre.

Esto no es una pequeña mejora de calidad de vida. Es un cambio fundamental en cómo escribimos código type-safe. Vamos a profundizar en qué cambió, cómo funciona, y por qué tu codebase está a punto de volverse mucho más limpia.

El Problema: Los Type Predicates Manuales Eran Tediosos y Propensos a Errores

Antes de TypeScript 5.5, el estrechamiento de tipos solo funcionaba implícitamente dentro del cuerpo de una función. En el momento en que extraías esa lógica a una función separada, la información de tipos se perdía:

// Esto funciona - estrechamiento de tipos inline
const values: (string | number)[] = ['a', 1, 'b', 2];

const strings = values.filter(value => typeof value === 'string');
// TypeScript 5.4: strings es (string | number)[] ❌
// TypeScript 5.5: strings es string[] ✅

En TypeScript 5.4 y anteriores, aunque el callback del filter claramente solo retorna true para strings, TypeScript no podía transportar esa información de tipos. El resultado era tipado como (string | number)[], que es técnicamente correcto pero prácticamente inútil.

Para arreglar esto, tenías que escribir un type predicate explícito:

function isString(value: string | number): value is string {
  return typeof value === 'string';
}

const strings = values.filter(isString);
// strings es string[] ✅

Esto parece bien para un ejemplo simple, pero en codebases reales:

  1. Olvidas agregar type predicates y te preguntas por qué los tipos no se estrechan
  2. Los type predicates pueden mentir - nada te impide escribir value is string mientras retornas typeof value === 'number'
  3. El boilerplate explota cuando tienes docenas de funciones type guard

La Solución: TypeScript 5.5 Infiere Type Predicates Automáticamente

A partir de TypeScript 5.5, el compilador analiza el cuerpo de tu función e infiere automáticamente un type predicate cuando:

  1. La función no tiene tipo de retorno explícito ni anotación de type predicate
  2. La función tiene una sola declaración return (o múltiples returns con la misma lógica de estrechamiento)
  3. La función no muta su parámetro
  4. La función retorna una expresión booleana que estrecha el tipo del parámetro

Veámoslo en acción:

// TypeScript 5.5 - ¡No se necesita anotación!
function isString(value: unknown) {
  return typeof value === 'string';
}

// TypeScript infiere automáticamente: (value: unknown) => value is string

const values: unknown[] = ['hello', 42, 'world', null];
const strings = values.filter(isString);
// strings es string[] ✅

El compilador mira la declaración return, ve typeof value === 'string', y automáticamente genera el type predicate value is string.

Profundizando: ¿Cuándo Se Activa la Inferencia?

La inferencia de TypeScript 5.5 no es magia—sigue reglas específicas. Entender estas reglas te ayuda a escribir código que funcione perfectamente con la nueva característica.

Regla 1: La Función Debe Retornar un Booleano

Los type predicates solo tienen sentido para funciones que retornan booleanos. TypeScript solo inferirá predicates para funciones que retornen boolean:

// ✅ La inferencia funciona
function isNumber(x: unknown) {
  return typeof x === 'number';
}

// ❌ La inferencia no aplica - retorna el valor, no boolean
function getNumber(x: unknown) {
  return typeof x === 'number' ? x : null;
}

Regla 2: Sin Anotación Explícita de Tipo de Retorno

Si anotas explícitamente el tipo de retorno, TypeScript respeta tu anotación y no inferirá un predicate:

// ❌ Sin inferencia - el tipo de retorno explícito la bloquea
function isString(value: unknown): boolean {
  return typeof value === 'string';
}

// ✅ La inferencia funciona - sin anotación de tipo de retorno
function isString(value: unknown) {
  return typeof value === 'string';
}

Esto es intencional—te permite optar por no usar la inferencia cuando lo necesites.

Regla 3: El Parámetro No Debe Ser Mutado

TypeScript necesita confiar en que el parámetro es el mismo objeto antes y después del check. Si lo mutas, la inferencia se desactiva:

// ❌ Sin inferencia - el parámetro es mutado
function isNonEmptyArray(arr: unknown[]) {
  arr.push('something'); // ¡Mutación!
  return arr.length > 0;
}

// ✅ La inferencia funciona - sin mutación
function isNonEmptyArray(arr: unknown[]) {
  return arr.length > 0;
}

Regla 4: True Debe Implicar el Tipo Estrechado

El type predicate solo se infiere cuando retornar true genuinamente implica el tipo estrechado:

// ✅ La inferencia funciona: true significa que es un string
function isString(x: unknown) {
  return typeof x === 'string';
}

// ⚠️ La inferencia funciona, pero ten cuidado con la lógica
function isNotNull(x: string | null) {
  return x !== null;
}
// Inferido: x is string (cuando se retorna true)

Regla 5: Los Métodos de Array Reciben Tratamiento Especial

El método .filter() es la estrella de esta característica. TypeScript ahora estrecha correctamente los tipos de arrays filtrados:

const mixed: (string | number | null)[] = ['a', 1, null, 'b', 2];

// Antes de 5.5: (string | number | null)[]
// Después de 5.5: (string | number)[]
const nonNull = mixed.filter(x => x !== null);

// Antes de 5.5: (string | number | null)[]
// Después de 5.5: string[]
const strings = mixed.filter(x => typeof x === 'string');

// ¡El encadenamiento también funciona!
const upperStrings = mixed
  .filter(x => typeof x === 'string')
  .map(s => s.toUpperCase()); // s está correctamente tipado como string

Ejemplos del Mundo Real: Antes y Después

Ejemplo 1: Filtrando Propiedades Opcionales

interface User {
  id: string;
  email?: string;
  phone?: string;
}

const users: User[] = [
  { id: '1', email: '[email protected]' },
  { id: '2', phone: '555-1234' },
  { id: '3', email: '[email protected]', phone: '555-5678' },
];

// Antes de 5.5: Necesitabas esta función helper
function hasEmail(user: User): user is User & { email: string } {
  return user.email !== undefined;
}

// Después de 5.5: Solo escribe el filtro inline
const usersWithEmail = users.filter(u => u.email !== undefined);
// El tipo es correctamente: (User & { email: string })[]

usersWithEmail.forEach(u => {
  console.log(u.email.toUpperCase()); // ¡Sin error! email es string
});

Ejemplo 2: Uniones Discriminadas

type Result<T> = 
  | { success: true; data: T }
  | { success: false; error: string };

const results: Result<number>[] = [
  { success: true, data: 42 },
  { success: false, error: 'Failed' },
  { success: true, data: 100 },
];

// Antes de 5.5
function isSuccess<T>(result: Result<T>): result is { success: true; data: T } {
  return result.success;
}
const successResults = results.filter(isSuccess);

// Después de 5.5 - Solo escríbelo naturalmente
const successResults = results.filter(r => r.success);
// El tipo es { success: true; data: number }[]

const sum = successResults.reduce((acc, r) => acc + r.data, 0); // ¡Funciona!

Ejemplo 3: Validación de Respuesta de API

interface ApiResponse {
  status: number;
  data?: {
    items: string[];
  };
}

const responses: ApiResponse[] = await fetchMultipleEndpoints();

// Antes de 5.5: Predicate manual requerido
function hasData(r: ApiResponse): r is ApiResponse & { data: { items: string[] } } {
  return r.status === 200 && r.data !== undefined;
}

// Después de 5.5: Filtrado natural
const validResponses = responses.filter(
  r => r.status === 200 && r.data !== undefined
);
// El tipo incluye correctamente data no-opcional

const allItems = validResponses.flatMap(r => r.data.items); // ✅ Sin error

Gotchas y Casos Extremos

Gotcha 1: Los Checks de Truthiness No Siempre Estrechan

const values: (string | null | undefined)[] = ['a', null, 'b', undefined];

// ❌ Esto no estrecha como se espera
const truthy = values.filter(x => x);
// Tipo: (string | null | undefined)[]

// ✅ Sé explícito sobre lo que estás comprobando
const defined = values.filter(x => x !== null && x !== undefined);
// Tipo: string[]

El problema es que x siendo truthy no estrecha definitivamente el tipo—los strings vacíos son falsy pero siguen siendo strings.

Gotcha 2: El Constructor Boolean No Funciona

const values: (string | null)[] = ['a', null, 'b'];

// ❌ No estrecha - Boolean se trata como una función que retorna boolean
const filtered = values.filter(Boolean);
// Tipo: (string | null)[]

// ✅ Usa arrow function en su lugar
const filtered = values.filter(x => x !== null);
// Tipo: string[]

Esto es porque Boolean está tipado como (value?: unknown) => boolean, no como un type predicate.

Gotcha 3: Condiciones Complejas Pueden No Inferir

function isSpecialString(x: unknown) {
  if (typeof x !== 'string') return false;
  if (x.length < 5) return false;
  if (!x.startsWith('prefix')) return false;
  return true;
}

// TypeScript puede o no inferir un type predicate aquí
// dependiendo de la complejidad del flujo de control

Para lógica de validación compleja, los type predicates explícitos siguen siendo tus amigos.

Consideraciones de Rendimiento

Podrías preguntarte: ¿esta inferencia agrega sobrecarga en tiempo de compilación?

La respuesta es: mínima. El motor de inferencia de tipos de TypeScript ya analiza los cuerpos de las funciones para el estrechamiento de tipos dentro de funciones. Extender esto para inferir type predicates de retorno reutiliza la mayoría de esa maquinaria.

En pruebas del mundo real, el impacto en tiempo de compilación es insignificante—usualmente dentro del ruido de medición.

Guía de Migración: Actualizando a TypeScript 5.5

Paso 1: Actualizar TypeScript

npm install [email protected] --save-dev
# o
yarn add [email protected] --dev
# o
pnpm add [email protected] --save-dev

Paso 2: Eliminar Type Predicates Redundantes

Una vez actualizado, puedes empezar a eliminar type predicates explícitos que TypeScript ahora infiere:

// Antes: Predicate explícito
function isNumber(x: unknown): x is number {
  return typeof x === 'number';
}

// Después: Deja que TypeScript lo infiera
function isNumber(x: unknown) {
  return typeof x === 'number';
}

Precaución: No elimines predicates a ciegas. Mantenlos cuando:

  • La función tiene lógica compleja que TypeScript podría no inferir correctamente
  • Quieres documentar explícitamente el comportamiento de estrechamiento
  • La función es parte de una API pública donde los tipos explícitos mejoran la documentación

Paso 3: Revisar Tus Llamadas a .filter()

Aquí es donde verás las mayores ganancias. Busca en tu codebase:

  • Usos de Array.prototype.filter() con predicates inline
  • Funciones helper usadas solo para filtrar

Muchas de estas ahora pueden simplificarse.

La Visión General: La Filosofía de TypeScript

Esta característica se alinea con la filosofía central de TypeScript: inferir lo que puede ser inferido, requerir tipos explícitos solo cuando es necesario.

TypeScript ha mejorado progresivamente en inferencia:

  • TS 2.1: Análisis de flujo de control para estrechamiento de tipos
  • TS 4.4: Análisis de flujo de control para condiciones con alias
  • TS 4.9: El operador satisfies para mejor inferencia
  • TS 5.5: Type predicates inferidos

Cada versión reduce el boilerplate que necesitas escribir mientras mantiene—y frecuentemente mejora—la seguridad de tipos.

Conclusión: Escribe Menos, Tipea Más Seguro

Los Inferred Type Predicates de TypeScript 5.5 representan una mejora significativa en la calidad de vida para desarrolladores TypeScript. Al generar automáticamente type predicates desde los cuerpos de las funciones, el compilador:

  1. Reduce boilerplate - No más anotaciones manuales value is Type para checks simples
  2. Mejora la corrección - Los predicates inferidos no pueden mentir como los manuales pueden
  3. Hace que .filter() sea un placer - El filtrado de arrays finalmente funciona como siempre esperaste

El camino de actualización es suave, el impacto de rendimiento es insignificante, y los beneficios son inmediatos. Si aún no estás en TypeScript 5.5, esta característica sola es razón suficiente para actualizar.

Tu codebase está a punto de volverse más limpia. Tu seguridad de tipos está a punto de fortalecerse. Y vas a dejar de escribir value is string por centésima vez.

Bienvenido al futuro de TypeScript.

typescriptjavascripttype-safetyprogrammingweb-developmenttype-guardstypescript-5