TypeScript Utility Types – Guía completa de principiante a avanzado (con Zod)

Los Utility Types de TypeScript son tipos genéricos predefinidos que facilitan las transformaciones de tipos. Permiten crear nuevos tipos a partir de otros existentes, por ejemplo haciendo que ciertas propiedades sean opcionales o extrayendo el tipo de retorno de una función. Esta guía educativa, en tres niveles (principiante, intermedio, avanzado), presenta todos los principales Utility Types de TypeScript (como Partial, Required, Readonly, Pick, Omit, Record, Exclude, Extract, NonNullable, Parameters, ReturnType, InstanceType, ThisType, etc.), con para cada uno: una explicación de su utilidad, un ejemplo de uso en TypeScript y una comparación con un enfoque equivalente en Zod, una librería de validación en tiempo de ejecución. También discutiremos las diferencias filosóficas entre los Utility Types de TypeScript (sistema de tipos estático) y los esquemas de Zod (validación en tiempo de ejecución).

Configuración del proyecto con Bun

Para probar los fragmentos de código, puedes inicializar un proyecto TypeScript mínimo usando Bun (un ejecutor de JavaScript ultrarrápido que también funciona como gestor de paquetes). Asegúrate de tener Bun instalado y luego, en una carpeta vacía, ejecuta:

shell

Bun creará un package.json y un tsconfig.json por defecto. Luego puedes ejecutar un archivo TypeScript con bun run file.ts (Bun transpila TypeScript al vuelo).

¡Ya estamos listos para explorar los Utility Types!

Nivel principiante: utilidades básicas del sistema de tipos

Partial<T> – Propiedades opcionales

TypeScript: El Utility Type Partial<T> construye un tipo a partir de un tipo existente T haciendo que todas sus propiedades sean opcionales. Es decir, cada propiedad de T se vuelve opcional (añadiendo ?). Esto te permite representar objetos parciales de ese tipo. Por ejemplo, si tienes un tipo User con campos obligatorios, Partial<User> te permite crear una versión donde estos campos pueden omitirse:

typescript

Aquí, Partial<User> tiene el tipo { name?: string; age?: number }. Esto te permite, por ejemplo, implementar una función de actualización parcial sin requerir todos los campos:

typescript

Puedes llamar a updateUser(existingUser, { age: 26 }) con un objeto parcial – TypeScript garantiza estáticamente que fieldsToUpdate solo contiene claves válidas de User.

Equivalente con Zod: Zod ofrece un método equivalente para hacer que un esquema de objeto sea parcial. El método .partial() aplicado a un esquema z.object hace que todas las claves sean opcionales, similar a Partial en TypeScript. Por ejemplo:

typescript

Aquí PartialUserSchema es un esquema que valida objetos que pueden contener solo un subconjunto de claves (name y age se vuelven opcionales). Puedes comprobarlo así:

typescript

Zod también permite hacer opcionales solo ciertas propiedades pasando un objeto como parámetro (UserSchema.partial({ age: true }) solo hace opcional age). Ten en cuenta que .partial() solo actúa en el primer nivel; Zod también ofrece .deepPartial() para hacer opcionales recursivamente los campos anidados.

Required<T> – Propiedades obligatorias

TypeScript: El Utility Type Required<T> es lo opuesto a Partial: crea un tipo a partir de T haciendo que todas sus propiedades sean obligatorias (no opcionales). Es útil para "solidificar" un tipo cuyas propiedades eran opcionales. Por ejemplo:

typescript

En este ejemplo, Required<Settings> es equivalente a { theme: string; fontSize: number } – la omisión de una propiedad se convierte en un error de compilación.

Equivalente con Zod: Para un esquema Zod, el equivalente es el método .required(), que transforma un esquema de objeto haciendo que todas las propiedades sean obligatorias (a diferencia de .partial() que las hace opcionales). Este método es especialmente útil si primero definiste un esquema parcial y luego quieres obtener la versión estricta. Por ejemplo:

typescript

Aquí StrictUserSchema requiere que name y age estén presentes. También puedes especificar solo ciertas propiedades: BaseUserSchema.required({ age: true }) solo hace obligatoria age (y deja name opcional).

Ten en cuenta que Required<T> actúa en tiempo de compilación (ya no existe en el código JavaScript emitido), mientras que schema.required() de Zod actúa en tiempo de ejecución validando la presencia de las claves durante el parseo.

Readonly<T> – Propiedades inmutables

TypeScript: El Utility Type Readonly<T> transforma un tipo T haciendo que sus propiedades sean de solo lectura (inmutables). Cualquier intento de reasignar estas propiedades será reportado como error en compilación. Por ejemplo:

typescript

Aquí, todo es de tipo Readonly<Todo> por lo que sus campos no pueden modificarse después de la inicialización. Esto suele corresponder al uso de Object.freeze en JavaScript, pero TypeScript solo lo gestiona a nivel de tipo (no impide realmente la mutación en tiempo de ejecución, solo avisa en compilación).

Equivalente con Zod: Zod ofrece una funcionalidad interesante para la inmutabilidad. El método .readonly() aplicado a un esquema devuelve un nuevo esquema que, al parsear, llama a Object.freeze() sobre el resultado, y cuyo tipo estático se marca como Readonly<...>. Es decir, Zod puede congelar el objeto validado y asegurar que corresponde a un tipo readonly. Por ejemplo:

typescript

Aquí, FrozenUserSchema congela el objeto devuelto por parse. Si intentas modificar frozenUser, se lanzará una excepción en tiempo de ejecución porque el objeto es inmutable. Así, Zod va más allá que TypeScript: donde Readonly<T> es puramente estático (las propiedades podrían modificarse en JS si se elude el tipado), el esquema .readonly() de Zod asegura inmutabilidad real en tiempo de ejecución además de proporcionar el tipo Readonly<...> correspondiente.

Pick<T, Keys> – Selección de un subconjunto de propiedades

TypeScript: Pick<T, Keys> construye un nuevo tipo a partir de T manteniendo solo ciertas propiedades especificadas por Keys (típicamente una unión de literales de cadena que representan nombres de propiedades). Es útil para crear un tipo más restringido a partir de uno existente. Por ejemplo:

typescript

Aquí, TodoPreview solo mantiene title y completed de FullTodo. Cualquier propiedad no listada (por ejemplo description) se excluye del tipo resultante.

Equivalente con Zod: Los esquemas de objeto de Zod también tienen un método .pick() que crea un nuevo esquema que contiene solo las claves indicadas, de forma similar:

typescript

Pasas un objeto con las claves a mantener puestas en true. TodoPreviewSchema solo validará objetos con title y completed (las otras propiedades de FullTodo serán ignoradas por el parser por defecto). Por ejemplo, TodoPreviewSchema.parse({ title: "Clean", completed: false, description: "..." }) devolverá { title: "...", completed: false } habiendo eliminado description (porque por defecto Zod ignora las claves no especificadas, comportamiento que puede ajustarse con .strict() o .passthrough() si es necesario).

De forma similar, Zod proporciona .omit() para el efecto opuesto.

Omit<T, Keys> – Exclusión de propiedades

TypeScript: Omit<T, Keys> crea un nuevo tipo a partir de T eliminando ciertas propiedades (Keys). Es el complemento de Pick (de hecho Omit<T, K> suele implementarse como Pick<T, Exclude<keyof T, K>>). Ejemplo:

typescript

Aquí TaskMeta solo contiene id y title. Las propiedades done y dueDate han sido excluidas.

Equivalente con Zod: El método .omit() de Zod produce un esquema de objeto sin las claves indicadas. Ejemplo:

typescript

TaskMetaSchema validará objetos que solo contengan id y title. Cualquier clave omitida (done, dueDate) será ignorada si está presente en la entrada. Pick y Omit te permiten proyectar un esquema Zod sobre un subconjunto de campos igual que sus equivalentes de TypeScript a nivel de tipo.

Record<Keys, Type> – Diccionario de claves tipadas

TypeScript: Record<Keys, Type> construye un tipo de objeto cuyas claves son de tipo Keys (típicamente una unión de literales de cadena o un tipo string/number más general) y los valores son de tipo Type. Esto te permite describir, por ejemplo, un objeto indexado por identificadores. Un ejemplo clásico:

typescript

Aquí, Record<CatName, CatInfo> asegura que el objeto cats tenga exactamente las claves "miffy", "boris", "mordred", cada una asociada a un CatInfo. Record es muy útil para tipar objetos usados como diccionarios o mapas.

Equivalente con Zod: Zod ofrece el esquema z.record(keySchema, valueSchema) para validar objetos de este tipo. Puedes usarlo con un esquema de clave (por ejemplo z.string() o un esquema literal) y un esquema de valor. Ejemplo:

typescript

Aquí, AgeMapSchema valida cualquier clave siempre que sea una cadena (por defecto, z.record sin primer argumento asume string). Si tienes un conjunto finito de claves, a menudo es mejor usar z.object({ ... }) con claves explícitas o z.enum([...]) para limitar las claves. De hecho, Zod permite un esquema de clave más estricto: podrías definir const CatNameSchema = z.enum(["miffy","boris","mordred"]) y luego hacer z.record(CatNameSchema, CatInfoSchema) – sin embargo, en tiempo de ejecución las claves de los objetos JavaScript siempre son cadenas. Incluso una clave numérica se convertirá en cadena en tiempo de ejecución (por ejemplo, una clave 1 se convierte en "1" en un objeto JS). Zod tiene esto en cuenta y no permite definir un esquema de clave puramente numérico sin transformarlo en cadena.

En resumen, Record<Keys, Type> (TypeScript) y z.record(keySchema, valueSchema) (Zod) te permiten tipar diccionarios. El primero actúa a nivel de sistema de tipos, el segundo en tiempo de ejecución para validar la estructura del objeto.

Nivel intermedio: manipulación de uniones y tipos opcionales

Exclude<UnionType, ExcludedMembers> – Eliminación de miembros de una unión

TypeScript: Exclude<U, E> crea un tipo eliminando de la unión U todos los miembros asignables al tipo E. Es decir, excluyes ciertos tipos de una unión. Por ejemplo:

typescript

Aquí, Exclude<Role, "admin"> elimina el literal "admin" de la unión, dejando solo "user" | "guest". Otro ejemplo: Exclude<string | number | boolean, string> daría number | boolean (eliminando todo lo asignable a string). Es útil para refinar una unión eliminando casos no deseados.

Equivalente con Zod: Para restringir las posibilidades de una unión en tiempo de ejecución, normalmente defines un esquema que no incluya los casos a excluir. Por ejemplo, si tienes RoleSchema = z.enum(["admin","user","guest"]) puedes crear un subconjunto no incluyendo "admin". Zod proporciona para enumeraciones el método .exclude([...]) que genera un nuevo esquema enum sin los valores especificados. Por ejemplo:

typescript

Este NonAdminSchema corresponde exactamente al tipo Exclude<Role, "admin"> pero también asegura la validación en tiempo de ejecución. Internamente, RoleSchema.exclude(["admin"]) simplemente elimina "admin" de la lista de literales permitidos. De forma similar, Zod ofrece .extract([...]) para la operación complementaria.

Extract<Type, Union> – Extracción de miembros de una unión

TypeScript: Extract<T, U> crea un tipo manteniendo de T solo los miembros asignables a U. Es básicamente lo opuesto a Exclude. Por ejemplo:

typescript

Otro ejemplo: Extract<"a" | "b" | "c", "a" | "f"> dará "a" (porque solo "a" está en ambos). Este Utility Type se usa para filtrar una unión y extraer solo un subtipo concreto.

Equivalente con Zod: Como con Exclude, Zod permite obtener en tiempo de ejecución un esquema correspondiente a un subconjunto de una enumeración mediante .extract([...]). Tomemos el ejemplo de roles: para extraer solo, por ejemplo, los roles limitados "user" y "guest" de un RoleSchema completo:

typescript

Aquí LimitedRolesSchema corresponde al tipo Extract<Role, "user" | "guest">. En la práctica, podrías obtener el mismo resultado definiendo directamente z.enum(["user","guest"]), pero .extract es útil para derivar un esquema de un enum existente. Ten en cuenta que .exclude y .extract de Zod se aplican a esquemas enum (z.enum o z.nativeEnum), y no a uniones arbitrarias de tipos complejos. Para estos últimos, normalmente construyes manualmente el nuevo esquema de unión deseado.

NonNullable<T> – Exclusión de null y undefined

TypeScript: NonNullable<T> construye un tipo excluyendo null y undefined de T. Es común en TypeScript tener tipos unión que incluyen estos valores "nullish" y querer un tipo que los excluya. Por ejemplo:

typescript

Aquí, DefinitelyString solo contiene string (ni null ni undefined). Este Utility Type se usa a menudo junto con condiciones de presencia (if (value != null) { ... }) para ayudar al compilador a refinar los tipos.

Equivalente con Zod: Con Zod, por defecto los esquemas no aceptan undefined o null a menos que lo especifiques. Por ejemplo, un esquema z.string() solo acepta una cadena, no undefined. Para permitir estos valores, usas explícitamente z.string().optional() (que permite undefined) o z.string().nullable() (que permite null) o incluso .nullish() (que permite ambos). Así, obtener el equivalente de un tipo NonNullable significa simplemente no incluir null/undefined en el esquema. Sin embargo, si partes de un esquema más permisivo y quieres hacerlo más estricto, puedes usar una combinación de técnicas: por ejemplo, el método .unwrap() permite extraer el esquema subyacente de un esquema opcional o nullable.

typescript

Aquí, OptionalName.unwrap() devuelve el esquema z.string() original. Esto te permite "eliminar" el carácter opcional o nullable introducido previamente. Otro enfoque sería usar una validación personalizada para rechazar null/undefined, pero sería redundante dado el comportamiento de los esquemas Zod.

Nivel avanzado: tipos de función y clases

Parameters<Type> – Tipos de parámetros de función

TypeScript: Parameters<T> extrae los tipos de los parámetros de un tipo de función T como una tupla. Es útil para trabajar con firmas de funciones, especialmente cuando quieres crear una función que envuelve a otra. Por ejemplo:

typescript

Aquí, Parameters<typeof greet> extrae la tupla [string, number] que representa los parámetros de greet. Esto permite que safeGreet acepte exactamente los mismos parámetros que greet.

Equivalente con Zod: Zod proporciona z.function() para definir esquemas de función, con métodos para especificar los tipos de parámetros y el tipo de retorno. Aunque no hay un equivalente directo de Parameters<T>, puedes definir un esquema de función y extraer los tipos de parámetros usando Parameters de TypeScript sobre el tipo inferido:

typescript

Aquí, GreetSchema define un esquema de función que acepta una cadena y un número y devuelve una cadena. El método .implement() crea una función envoltorio que valida entradas y salidas según el esquema. Podemos extraer los tipos de parámetros usando Parameters<GreetFn>. Este enfoque combina validación en tiempo de ejecución con tipado estático.

ReturnType<Type> – Tipo de retorno de una función

TypeScript: ReturnType<T> extrae el tipo de retorno de un tipo de función T. Es útil cuando quieres trabajar con el resultado de una función sin tener que redefinir explícitamente el tipo. Por ejemplo:

typescript

Aquí, ReturnType<typeof createUser> extrae el tipo de objeto devuelto por createUser. Esto nos permite definir el tipo User sin duplicar la estructura.

Equivalente con Zod: Como con Parameters, no hay un equivalente directo en Zod para ReturnType, pero puedes combinar el esquema de función de Zod con ReturnType de TypeScript:

typescript

Aquí, definimos un esquema de función con CreateUserSchema, luego extraemos el tipo de retorno de dos maneras: usando ReturnType de TypeScript sobre el tipo de función inferido, o usando el método .returnType() de Zod que devuelve el esquema para el valor de retorno. Ambos enfoques nos dan el tipo User.

InstanceType<Type> – Tipo de instancia de una clase

TypeScript: InstanceType<T> extrae el tipo de instancia de un tipo constructor T. Es útil cuando tienes una referencia a una clase y quieres trabajar con instancias de esa clase. Por ejemplo:

typescript

Aquí, InstanceType<typeof Point> nos da el tipo de una instancia de Point, que incluye sus propiedades y métodos.

Equivalente con Zod: Zod no tiene un equivalente directo para tipos de instancia de clase, ya que se centra en la validación de datos más que en el comportamiento de clases. Sin embargo, puedes definir un esquema para la forma de las instancias de clase:

typescript

Este enfoque define un esquema que corresponde a la forma de una instancia de Point, pero no captura la relación completa de la clase. Para una validación de clase más compleja, podrías combinar Zod con class-validator u otras librerías.

Diferencias filosóficas entre los Utility Types de TypeScript y los esquemas de Zod

Los Utility Types de TypeScript y los esquemas de Zod sirven ambos para garantizar la fiabilidad de los datos, pero a diferentes niveles: uno en tiempo de compilación, el otro en tiempo de ejecución.

• TypeScript: seguridad estática (compile-time) – Los Utility Types (y el sistema de tipos en general) operan durante el desarrollo. TypeScript analiza el código y previene incoherencias de tipo antes de que el código se ejecute. Por ejemplo, Partial<T> asegura que una función no olvide manejar casos donde faltan propiedades, ReturnType<Fn> da la forma esperada de los retornos de función, etc. Sin embargo, estos chequeos ya no existen una vez que la aplicación está en ejecución: TypeScript elimina los tipos al transpilar a JavaScript. Nada impide que datos erróneos circulen en tiempo de ejecución (provenientes de JSON, formularios de usuario, APIs externas...). El sistema de tipos por sí solo no puede proteger contra valores inesperados en tiempo de ejecución.
• Zod: validación dinámica (runtime) – Los esquemas de Zod intervienen en tiempo de ejecución para llenar ese vacío. Al definir un esquema para tus datos, creas una protección en tiempo de ejecución que verifica que los datos recibidos coincidan con el formato esperado. Por ejemplo, un PartialUserSchema realmente verificará que el objeto recibido contenga solo claves válidas y que sus valores sean del tipo correcto, mientras que Partial<T> es solo una garantía en tiempo de compilación. Así, Zod y TypeScript son complementarios: TypeScript asegura la coherencia interna de tu código (lo que manipulas corresponde a los tipos declarados), mientras que Zod asegura que los datos externos se ajusten a tus tipos.

En resumen:

• TypeScript es una protección en tiempo de compilación que detecta errores temprano en el ciclo de desarrollo y te ayuda a evitar muchos errores comunes antes incluso de ejecutar el código.
• Zod es una protección en tiempo de ejecución que asegura que ningún dato no conforme "pase la puerta" de tu aplicación (entradas de usuario, respuestas de API, contenido de configuración, etc.).

Filosóficamente, los utility types expresan transformaciones o restricciones a nivel de sistema de tipos (ayudan al desarrollador, sin impacto directo en el código emitido), mientras que Zod proporciona contratos a nivel de ejecución (permiten la implementación concreta de validaciones y transformaciones de datos en ejecución). Ambos enfoques responden a necesidades diferentes pero relacionadas: mantener la robustez del código. Además, Zod está diseñado para integrarse armoniosamente con TypeScript: infiere automáticamente los tipos estáticos de tus esquemas, evitando la duplicación de definiciones. Esto significa que a menudo puedes definir un esquema Zod (para validación) y usar z.infer para derivar el tipo estático correspondiente de TypeScript, en lugar de definir una interfaz TypeScript y un esquema separado – teniendo así una sola fuente de verdad para tus tipos de datos.

En conclusión, conocer los Utility Types de TypeScript te permite aprovechar el sistema de tipos para escribir código seguro y expresivo, mientras que dominar Zod te da las herramientas para hacer cumplir estos contratos de tipo en tiempo de ejecución. Usados juntos, refuerzan enormemente la fiabilidad de tus aplicaciones TypeScript: TypeScript te protege de errores de programación, Zod protege tu aplicación de datos inesperados del exterior. ¡Crea tus tipos, valida tus datos y programa con tranquilidad 🎉!

1bun init
2bun add zod             # añade Zod como dependencia

1interface User {
2  name: string;
3  age: number;
4}
5
6const partialUser: Partial<User> = { name: 'Alice' };
7// 'partialUser' puede contener solo el nombre, la propiedad 'age' es opcional
8partialUser.age = 30; // OK añadir después porque age: number | undefined

1function updateUser(user: User, fieldsToUpdate: Partial<User>): User {
2  return { ...user, ...fieldsToUpdate };
3}

1import { z } from 'zod';
2
3const UserSchema = z.object({
4  name: z.string(),
5  age: z.number(),
6});
7const PartialUserSchema = UserSchema.partial();
8type PartialUser = z.infer<typeof PartialUserSchema>;
9// PartialUser es de tipo { name?: string; age?: number }

1PartialUserSchema.parse({ name: 'Alice' }); // OK (age faltante permitido)
2PartialUserSchema.parse({}); // OK (puede estar vacío)
3PartialUserSchema.parse({ age: ' thirty ' }); // Error: age no es un número

1interface Settings {
2  theme?: string;
3  fontSize?: number;
4}
5const s1: Settings = { theme: 'dark' }; // OK, fontSize faltante
6const s2: Required<Settings> = { theme: 'dark' }; // Error – fontSize es obligatorio
7// TypeScript: Property 'fontSize' is missing in type ... but required in type 'Required<Settings>'

1const BaseUserSchema = z.object({
2  name: z.string().optional(),
3  age: z.number().optional(),
4});
5// BaseUserSchema: { name?: string; age?: number }
6const StrictUserSchema = BaseUserSchema.required();
7// StrictUserSchema: { name: string; age: number }

1interface Todo {
2  title: string;
3  done: boolean;
4}
5const todo: Readonly<Todo> = { title: 'Init project', done: false };
6todo.done = true;
7// Error TS: Cannot assign to 'done' because it is a read-only property.

1const FrozenUserSchema = z.object({ name: z.string() }).readonly();
2type FrozenUser = z.infer<typeof FrozenUserSchema>;
3// FrozenUser: Readonly<{ name: string }>
4const frozenUser = FrozenUserSchema.parse({ name: 'Bob' });
5frozenUser.name; // "Bob"
6frozenUser.name = 'Eve'; // Error en tiempo de ejecución: el objeto está congelado (TypeError en modo estricto)

1interface FullTodo {
2  title: string;
3  description: string;
4  completed: boolean;
5}
6type TodoPreview = Pick<FullTodo, 'title' | 'completed'>;
7// TodoPreview: { title: string; completed: boolean }
8const t: TodoPreview = { title: 'Clean', completed: false }; // OK

1const FullTodoSchema = z.object({
2  title: z.string(),
3  description: z.string(),
4  completed: z.boolean(),
5});
6const TodoPreviewSchema = FullTodoSchema.pick({ title: true, completed: true });
7type TodoPreview = z.infer<typeof TodoPreviewSchema>;
8// { title: string; completed: boolean }

1interface Task {
2  id: string;
3  title: string;
4  done: boolean;
5  dueDate: string;
6}
7type TaskMeta = Omit<Task, 'done' | 'dueDate'>;
8// TaskMeta: { id: string; title: string }

1const TaskSchema = z.object({
2  id: z.string(),
3  title: z.string(),
4  done: z.boolean(),
5  dueDate: z.string(),
6});
7const TaskMetaSchema = TaskSchema.omit({ done: true, dueDate: true });
8type TaskMeta = z.infer<typeof TaskMetaSchema>;
9// { id: string; title: string }

1type CatName = 'miffy' | 'boris' | 'mordred';
2interface CatInfo {
3  age: number;
4  breed: string;
5}
6type Cats = Record<CatName, CatInfo>;
7/* Equivalente a:
8type Cats = {
9  miffy: CatInfo;
10  boris: CatInfo;
11  mordred: CatInfo;
12}
13*/
14const cats: Cats = {
15  miffy: { age: 10, breed: 'Persa' },
16  boris: { age: 5, breed: 'Maine Coon' },
17  mordred: { age: 16, breed: 'British Shorthair' },
18};

1// Queremos un objeto cuyas claves sean nombres (string) y los valores edades (number)
2const AgeMapSchema = z.record(z.string(), z.number());
3type AgeMap = z.infer<typeof AgeMapSchema>;
4// AgeMap: Record<string, number>
5AgeMapSchema.parse({ Alice: 30, Bob: 25 }); // OK
6AgeMapSchema.parse({ Alice: 30, Bob: '25' }); // Error: "25" no es un número

1type Role = 'admin' | 'user' | 'guest';
2type NonAdmin = Exclude<Role, 'admin'>;
3// NonAdmin: "user" | "guest"

1const RoleSchema = z.enum(['admin', 'user', 'guest']);
2const NonAdminSchema = RoleSchema.exclude(['admin']);
3type NonAdmin = z.infer<typeof NonAdminSchema>;
4// NonAdmin: "user" | "guest"
5NonAdminSchema.parse('user'); // OK
6NonAdminSchema.parse('admin'); // Error: "admin" está excluido

1type Mixed = string | number | boolean;
2type NumbersOnly = Extract<Mixed, number | boolean>;
3// NumbersOnly: number | boolean (solo mantenemos lo asignable a number | boolean)

1const LimitedRolesSchema = RoleSchema.extract(['user', 'guest']);
2type LimitedRoles = z.infer<typeof LimitedRolesSchema>;
3// LimitedRoles: "user" | "guest"
4LimitedRolesSchema.parse('guest'); // OK
5LimitedRolesSchema.parse('admin'); // Error, "admin" no está extraído

1type MaybeString = string | null | undefined;
2type DefinitelyString = NonNullable<MaybeString>;
3// DefinitelyString: string

1const OptionalName = z.string().optional(); // tipo: string | undefined
2const Name = OptionalName.unwrap(); // recupera el z.string() subyacente (tipo: string)
3Name.parse('Alice'); // "Alice"
4Name.parse(undefined); // Error: undefined no aceptado

1function greet(name: string, age: number): string {
2  return `Hello ${name}, you are ${age} years old`;
3}
4type GreetParams = Parameters<typeof greet>;
5// GreetParams: [name: string, age: number]
6
7// Podemos usar este tipo para crear una función que llama a greet
8function safeGreet(...args: GreetParams): string {
9  try {
10    return greet(...args);
11  } catch (e) {
12    return 'Greeting failed';
13  }
14}

1const GreetSchema = z
2  .function()
3  .args(z.string(), z.number())
4  .returns(z.string());
5
6type GreetFn = z.infer<typeof GreetSchema>; // tipo: (name: string, age: number) => string
7type GreetParams = Parameters<GreetFn>; // tipo: [string, number]
8
9// Podemos usar este esquema para validar una función
10const greet = GreetSchema.implement((name, age) => {
11  return `Hello ${name}, you are ${age} years old`;
12});
13// greet es ahora una función validada que lanzará un error si se llama con tipos incorrectos

1function createUser(name: string) {
2  return { id: Date.now(), name, createdAt: new Date() };
3}
4type User = ReturnType<typeof createUser>;
5// User: { id: number; name: string; createdAt: Date }
6
7// Podemos usar este tipo en otros lugares
8function processUser(user: User) {
9  console.log(`Processing user ${user.name} created at ${user.createdAt}`);
10}

1const CreateUserSchema = z
2  .function()
3  .args(z.string())
4  .returns(
5    z.object({
6      id: z.number(),
7      name: z.string(),
8      createdAt: z.date(),
9    }),
10  );
11
12type CreateUserFn = z.infer<typeof CreateUserSchema>;
13// tipo: (name: string) => { id: number; name: string; createdAt: Date }
14type User = ReturnType<CreateUserFn>;
15// tipo: { id: number; name: string; createdAt: Date }
16
17// También podemos extraer directamente el esquema de retorno
18const UserSchema = CreateUserSchema.returnType();
19// UserSchema es el esquema de objeto para el valor de retorno
20type User2 = z.infer<typeof UserSchema>; // Igual que User

1class Point {
2  x: number;
3  y: number;
4
5  constructor(x: number, y: number) {
6    this.x = x;
7    this.y = y;
8  }
9
10  distanceFromOrigin(): number {
11    return Math.sqrt(this.x * this.x + this.y * this.y);
12  }
13}
14
15type PointInstance = InstanceType<typeof Point>;
16// PointInstance: Point (el tipo de instancia, con x, y y distanceFromOrigin)
17
18// Podemos usar este tipo sin tener una instancia real
19function processPoint(p: PointInstance) {
20  console.log(
21    `Point at (${p.x}, ${p.y}) is ${p.distanceFromOrigin()} from origin`,
22  );
23}

1const PointSchema = z.object({
2  x: z.number(),
3  y: z.number(),
4  distanceFromOrigin: z.function().args().returns(z.number()),
5});
6
7type PointLike = z.infer<typeof PointSchema>;
8// tipo: { x: number; y: number; distanceFromOrigin: () => number }
9
10// Podemos validar si un objeto corresponde a la interfaz Point
11function isPoint(obj: unknown): obj is PointLike {
12  return PointSchema.safeParse(obj).success;
13}