TypeScript Utility Types You Should Use Every Day

Stop Repeating Yourself in the Type System

One of TypeScript's least-celebrated superpowers is its standard library of utility types — generic helpers built into the language that let you transform, compose, and derive new types from existing ones without duplicating a single definition.

Most developers know Partial and Readonly. Fewer reach for ReturnType, Parameters, or Awaited when they should. And almost nobody uses infer directly until they've felt the pain of not having it.

This article is a practical guide to the utility types that should become muscle memory. Each one is explained with the problem it solves, not just what it does — because knowing the syntax is easy. Knowing when to reach for it is what separates TypeScript that ages well from TypeScript that becomes a maintenance nightmare.

The Foundational Four

These four utility types appear in almost every non-trivial TypeScript codebase. If you're not using them, you're probably writing duplicate types.

Partial<T>

Makes all properties of T optional.

The problem it solves: You have a fully defined type for a domain entity, but you need a version for update payloads where the caller only provides the fields they want to change.

interface User {
  id: string;
  name: string;
  email: string;
  role: "admin" | "member" | "viewer";
}

// ❌ Don't do this — duplicated definition, drift risk
interface UpdateUserPayload {
  name?: string;
  email?: string;
  role?: "admin" | "member" | "viewer";
}

// ✅ Do this
type UpdateUserPayload = Partial<User>;

function updateUser(id: string, payload: Partial<User>): Promise<User> {
  // ...
}

Watch out: Partial only shallowly makes properties optional. Nested objects remain as-is. For deep partiality, you'll need a recursive utility type (more on that later).

Required<T>

Makes all properties of T required, stripping any ? modifiers.

The problem it solves: Configuration objects with sensible defaults — you accept a Partial config from the user, merge it with defaults, and then want to guarantee downstream functions receive a fully resolved config.

interface Config {
  timeout?: number;
  retries?: number;
  baseUrl?: string;
  debug?: boolean;
}

const DEFAULT_CONFIG: Required<Config> = {
  timeout: 5000,
  retries: 3,
  baseUrl: "https://api.example.com",
  debug: false,
};

function createClient(userConfig: Config = {}) {
  const config: Required<Config> = { ...DEFAULT_CONFIG, ...userConfig };
  // config is now fully resolved — no undefined checks needed downstream
  return config;
}