TypeScript Utility Types You Should Actually Use (And When They Make Code Worse)

TypeScript's utility types are powerful. Pick, Omit, Partial, Required, Record, Exclude, Extract, ReturnType — they transform types without redefining them. But power without restraint creates: type definitions nobody can read, error messages nobody can debug, and abstractions that obscure rather than clarify.

Here are the utility types that genuinely improve code, and the patterns where they make things worse.

The Essential Five

These five utility types solve real problems and belong in every TypeScript developer's toolkit:

Partial: makes all properties optional. Use when: you need to accept a subset of properties for updates. Instead of defining a separate UpdateToolInput type that duplicates ToolInput with optional fields: Partial does it in one word.

Real use case: a function that updates a tool's metadata. It accepts any subset of properties to update: function updateTool(id: string, data: Partial) — the caller can pass { name: "New Name" } or { name: "New", description: "Updated" } or any combination.

Required: makes all properties required. The inverse of Partial. Use when: an interface has optional fields but a specific context requires all of them. Database records from Prisma often have optional fields that are guaranteed to exist after a specific query.

Pick: creates a type with only the specified properties. Use when: you need a subset of properties from a larger type. Instead of creating a new interface: Pick gives you exactly those three fields.

Real use case: API response types. Your database model has 20 fields. Your API response returns 5. Pick defines the response type without duplication.

Omit: creates a type with all properties EXCEPT the specified ones. The inverse of Pick. Use when: you want almost all fields except a few. Omit gives you a public-facing type without internal fields.

Record: creates an object type with specified keys and value type. Use when: you need a dictionary/map type. Record types an object where keys are strings and values are arrays of tools (e.g., tools grouped by category).

When They Improve Code

These utility types improve code when they: reduce duplication (one source of truth for the type, derived types via utilities), express intent clearly (Partial is immediately understood as "some properties of Tool"), and prevent errors (Pick ensures you only access properties that exist in the subset).

Example of genuine improvement: without utility types, creating an API requires defining: the full model, the creation input (no id, no timestamps), the update input (all optional except id), the list response (subset of fields), and the detail response (all fields plus relations). That is 5 type definitions that duplicate information and drift out of sync.

With utility types: the full model is the source of truth. Creation input: Omit. Update input: Partial>. List response: Pick. All derived from one definition. Change the model, and derived types update automatically.

When They Make Code Worse

Pattern 1 — Over-nesting: Pick>, "id">, "name" | "description">. Nobody can read this. Nobody can hover over this in their IDE and understand the resulting type. If you need more than two levels of utility composition: define a named type instead.

Pattern 2 — Using utility types for everything: not every type needs to be derived from another. If a function's parameter type shares 3 fields with a model but has different semantics: define an independent interface. The shared field names are coincidental, not a relationship.

Pattern 3 — Conditional types in application code: type IsArray = T extends any[] ? true : false. Unless you are building a library: conditional types are overkill. They make error messages incomprehensible and types unreadable.

Pattern 4 — Template literal types for business logic: type Route = /api/${string}/${number}. Clever, but: IDE support is limited, error messages are confusing, and a simple string with runtime validation is more maintainable.

The Readability Test

Before using a utility type, ask: "If a new team member hovers over this type in their IDE, will they understand it in 5 seconds?"

If the expanded type is clear: use the utility type. If the expanded type is a wall of nested generics: define a named interface instead.

Named interfaces are self-documenting. Pick, "public fields"> is not self-documenting — even if logically correct.

ReturnType and Parameters: For Libraries, Not Applications

ReturnType extracts the return type of a function. Parameters extracts the parameter types. These are useful when: you consume a function from a library and need its types without importing them separately.

In application code: you control both the function and its callers. Define the types explicitly and use them in both places. ReturnType is less readable than ToolListResponse — and if you rename getTools, the type reference breaks.

Mapped Types: Powerful But Proceed With Caution

Mapped types transform every property of a type: type Readonly = { readonly [K in keyof T]: T[K] }. TypeScript provides built-in mapped types (Readonly, Partial, Required). These are fine to use.

Custom mapped types: powerful for library authors (creating form state types, validation schemas, API response transformers). Dangerous in application code because: they are hard to read, error messages reference the mapped type machinery instead of the resulting type, and maintenance requires understanding generics deeply.

Best Practices

Keep type definitions close to usage: define types in the file or module where they are used. Centralized type files become dump sites for unrelated types.

Prefer explicit over clever: type ToolCreateInput = { name: string; url: string; description: string } is more readable than Omit — even though the latter is DRY.

Use IDE tooling: hover over derived types to see the expanded result. If the expansion is understandable: the type is fine. If you cannot parse the expansion: simplify.

Document complex types: if a utility type composition is necessary but not self-explanatory, add a comment explaining what the resulting type represents and why it is derived rather than defined independently.

The Balance

Utility types are tools. Like any tool: use them when they solve a problem, not because they exist. The best TypeScript codebases use utility types sparingly and intentionally — reducing duplication where it matters while keeping types readable for the humans who maintain them.

The goal is not maximum DRY-ness. The goal is: correct types, readable code, and maintainable definitions. Sometimes a few duplicated fields are the right trade-off for clarity.