Utility Types im Ueberblick: Partial, Pick, Omit und Co.

1. Warum Utility Types den TypeScript-Alltag verändern

Ohne Utility Types landen viele TypeScript-Projekte schnell bei manuell dupliziertem Code: Ein Product-Interface wird für ein Update-Formular kopiert, alle Felder werden händisch auf optional gesetzt, und bei jeder Änderung am Original muss die Kopie manuell nachgezogen werden. Genau dieses Problem lösen die eingebauten Utility Types aus lib.es5.d.ts: Sie transformieren einen bestehenden Typ zur Kompilierzeit in einen neuen, ohne dass eine zweite Quelle der Wahrheit entsteht. Der Compiler erzeugt den abgeleiteten Typ automatisch aus dem Original.

Technisch handelt es sich bei den meisten Utility Types um sogenannte Mapped Types - generische Typen, die über keyof und Indexzugriffe jede Property eines Eingabetyps durchlaufen und transformiert wieder ausgeben. Das passiert vollständig zur Kompilierzeit; zur Laufzeit existiert kein zusätzlicher Code, keine Bundle-Größe wird beeinflusst. Für Teams, die dieselben Domänenmodelle in REST-Clients, GraphQL-Resolvern, Build-Skripten und Frontend-Formularen wiederverwenden, sind Utility Types deshalb kein Nice-to-have, sondern die Grundlage konsistenter Typverträge über das gesamte Projekt hinweg.

2. Partial und Required: Optionalität gezielt steuern

Partial<T> macht jede Property eines Typs optional und ist der Standardfall für Update- oder Patch-Funktionen: Ein Aufrufer soll nur die Felder übergeben, die sich tatsächlich ändern, ohne den kompletten Objektzustand erneut mitschicken zu müssen. Ohne Partial müsste man entweder ein komplett separates Update-Interface pflegen oder mit any arbeiten und damit die Typsicherheit an genau der Stelle verlieren, an der sie am wichtigsten ist: beim Schreibzugriff auf Daten.

Required<T> ist die exakte Umkehrung und entfernt alle optionalen Modifikatoren. Das ist nützlich, wenn ein Entwurfstyp mit vielen optionalen Feldern nach dem Zusammenführen mit Standardwerten garantiert vollständig sein soll - der Compiler erzwingt dann, dass wirklich jedes Feld befüllt wurde, bevor der Wert weiterverarbeitet wird. Beide Utility Types sind flach: Verschachtelte Objekte innerhalb der Property-Werte werden nicht rekursiv transformiert, was bei tief verschachtelten Domänenmodellen zu beachten ist.

interface Product {
  sku: string;
  name: string;
  price: number;
  description: string;
  stockQty: number;
  active: boolean;
}

declare function getProductBySku(sku: string): Product;

// Partial<T>: every field becomes optional - ideal for PATCH-style updates
function updateProduct(sku: string, changes: Partial<Product>): Product {
  const existing = getProductBySku(sku);
  return { ...existing, ...changes };
}

updateProduct('MS-1001', { price: 59.9 }); // only the price field changes

// Required<T>: every field becomes mandatory - useful after merging defaults
interface ProductDraft {
  sku: string;
  name?: string;
  price?: number;
}

const defaults: Required<ProductDraft> = {
  sku: 'MS-0000',
  name: 'Untitled product',
  price: 0,
};

function finalizeProduct(draft: ProductDraft): Required<ProductDraft> {
  return { ...defaults, ...draft };
}

3. Readonly: Unveränderlichkeit auf Typ-Ebene

Readonly<T> markiert jede Top-Level-Property eines Typs als schreibgeschützt. Ein Zuweisungsversuch wie snapshot.total = 0 wird vom Compiler mit einem klaren Fehler abgelehnt, bevor der Code überhaupt läuft. Das ist besonders wertvoll für Funktionsrückgaben, die als unveränderlicher Snapshot gedacht sind - etwa ein einmal geladener Bestellstatus, der von aufrufendem Code nicht versehentlich mutiert werden soll.

Entscheidend ist die Einschränkung, dass Readonly nur shallow wirkt: Ein Array oder ein verschachteltes Objekt innerhalb der Properties bleibt weiterhin veränderlich, weil die Transformation nicht rekursiv durch die Struktur wandert. Für echte tiefe Unveränderlichkeit braucht es einen eigenen rekursiven Mapped Type nach dem Muster DeepReadonly<T>, der jede Property erneut durch sich selbst schickt, solange sie ein Objekt ist. Kombiniert mit Object.freeze() zur Laufzeit entsteht daraus ein Typsystem, das sowohl beim Kompilieren als auch im laufenden Programm vor versehentlichen Mutationen schützt.

interface OrderItem {
  sku: string;
  qty: number;
}

interface Order {
  id: string;
  customerId: string;
  total: number;
  items: OrderItem[];
}

declare function loadOrder(id: string): Order;

// Readonly<T> is shallow: top-level props cannot be reassigned,
// but nested objects and arrays remain mutable.
function freezeOrderSnapshot(order: Order): Readonly<Order> {
  return Object.freeze({ ...order });
}

const snapshot = freezeOrderSnapshot(loadOrder('ORD-42'));
// snapshot.total = 0;        // Error: read-only property
snapshot.items.push({ sku: 'X', qty: 1 }); // allowed - items array is not frozen

// DeepReadonly via a recursive mapped type, for true nested immutability
type DeepReadonly<T> = {
  readonly [K in keyof T]: T[K] extends object ? DeepReadonly<T[K]> : T[K];
};

const deepSnapshot: DeepReadonly<Order> = freezeOrderSnapshot(loadOrder('ORD-42'));
// deepSnapshot.items.push(...) // Error: items is readonly too

4. Pick und Omit: Teilmengen von Typen extrahieren

Pick<T, K> erzeugt einen neuen Typ, der nur die in K genannten Keys aus T enthält - typischerweise eine Menge von String-Literalen, verbunden über |. Das ist das Werkzeug der Wahl, wenn eine Funktion oder Komponente bewusst nur einen kleinen Ausschnitt eines großen Domänenmodells braucht, etwa ein öffentliches Kundenprofil, das nur Name und ID zeigt, aber niemals interne Felder wie den Passwort-Hash.

Omit<T, K> löst das umgekehrte Problem: Alle Felder bleiben erhalten außer den explizit genannten. Für API-Antworten ist das oft die bessere Wahl, weil man nicht jedes einzelne öffentliche Feld auflisten muss, sondern nur die wenigen, die niemals nach außen dringen dürfen - ein Muster, das robuster gegen künftige, harmlose Erweiterungen des Ursprungstyps ist. Intern ist Omit selbst nichts anderes als eine Kombination aus Pick und Exclude, was zeigt, wie konsequent die Utility Types aufeinander aufbauen.

interface Customer {
  id: string;
  email: string;
  firstName: string;
  lastName: string;
  passwordHash: string;
  newsletterOptIn: boolean;
}

// Pick<T, K>: select only the keys the public profile actually needs
type PublicProfile = Pick<Customer, 'id' | 'firstName' | 'lastName'>;

function toPublicProfile(customer: Customer): PublicProfile {
  const { id, firstName, lastName } = customer;
  return { id, firstName, lastName };
}

// Omit<T, K>: keep everything except the field that must never leave the server
type CustomerApiResponse = Omit<Customer, 'passwordHash'>;

function toApiResponse(customer: Customer): CustomerApiResponse {
  const { passwordHash, ...rest } = customer;
  return rest;
}

// Omit is itself built from Pick and Exclude:
// type Omit<T, K extends keyof any> = Pick<T, Exclude<keyof T, K>>;

5. Record: Typsichere Key-Value-Strukturen

Record<K, V> konstruiert einen Objekttyp, dessen Keys aus K stammen und dessen Werte alle vom Typ V sind. Der entscheidende Vorteil gegenüber einer generischen Index-Signatur wie { [key: string]: number } zeigt sich, sobald K eine Union aus String-Literalen ist: Der Compiler erzwingt dann, dass wirklich jeder mögliche Key in der Union vorhanden ist. Vergisst man beim Anlegen eines Record<CustomerGroup, number>-Literals eine Kundengruppe, meldet TypeScript sofort einen Fehler statt eines stillen Laufzeitfehlers erst bei Zugriff auf den fehlenden Key.

Diese Exhaustivitätsprüfung macht Record zum idealen Werkzeug für Rabattstaffeln, Übersetzungstabellen oder Statusmaps, bei denen jede Ausprägung einer Union explizit behandelt werden muss. Erweitert man die zugrunde liegende Union später um einen neuen Wert, etwa eine zusätzliche Kundengruppe, markiert der Compiler automatisch jede Stelle im Code, an der ein Record-Literal jetzt unvollständig ist - ein Sicherheitsnetz, das reine JavaScript-Objekte oder lose typisierte Maps nicht bieten.

type CustomerGroup = 'retail' | 'wholesale' | 'vip';

// Record<K, V>: exhaustive, type-checked map - a missing key is a compile error
const groupDiscounts: Record<CustomerGroup, number> = {
  retail: 0,
  wholesale: 0.15,
  vip: 0.25,
};

interface Product {
  sku: string;
  name: string;
  categoryCode: string;
}

// Record<string, T[]> for dynamic, non-exhaustive grouping keys
function groupProductsByCategory(products: Product[]): Record<string, Product[]> {
  return products.reduce<Record<string, Product[]>>((acc, product) => {
    const category = product.categoryCode ?? 'uncategorized';
    (acc[category] ??= []).push(product);
    return acc;
  }, {});
}

// Adding a new CustomerGroup member later forces every Record<CustomerGroup, ...>
// literal in the codebase to be updated - the compiler will not let it slide.

6. Exclude und Extract: Union Types gezielt filtern

Exclude<T, U> und Extract<T, U> arbeiten anders als Pick und Omit: Sie operieren nicht auf den Keys eines Objekttyps, sondern auf den Mitgliedern eines Union Types. Exclude entfernt aus T alle Mitglieder, die sich U zuweisen lassen, Extract behält genau diese Mitglieder und verwirft den Rest. Beide sind damit spiegelbildlich zueinander, ähnlich wie Pick und Omit es auf Objektebene sind - nur eine Ebene tiefer, auf der Ebene einzelner Typwerte innerhalb einer Union.

In der Praxis eignen sich Exclude und Extract hervorragend, um aus einer breiten Status-Union wie einem Bestellstatus gezielt Teilmengen abzuleiten: eine Gruppe abgeschlossener Zustände für Reporting-Zwecke, eine Gruppe offener Zustände für Follow-up-Benachrichtigungen. Statt diese Teilmengen als separate, redundante String-Literal-Unions zu pflegen, leitet man sie direkt aus der einen kanonischen Union ab - ändert sich die Ursprungs-Union, propagiert sich die Änderung automatisch in alle abgeleiteten Teilmengen, und der Compiler markiert jede Stelle, die dadurch inkonsistent wird.

7. NonNullable: null und undefined zuverlässig ausschließen

NonNullable<T> entfernt null und undefined aus einem Typ und ist besonders in Projekten mit aktiviertem strictNullChecks relevant, wo diese beiden Werte explizit im Typsystem sichtbar sind statt implizit überall erlaubt zu sein. Typische Anwendung: Ein API-Response-Feld ist als Order | null | undefined typisiert, weil es optional in der Datenbank ist - nach einer expliziten Prüfung im Code soll der resultierende Typ aber garantiert nicht mehr null oder undefined enthalten, damit nachfolgender Code ohne ständige Optional-Chaining-Operatoren auskommt.

Wichtig ist, dass NonNullable allein keine Laufzeitprüfung ersetzt - der Typ beschreibt nur, was der Compiler nach einer bereits erfolgten Prüfung annehmen darf. Die eigentliche Absicherung übernimmt weiterhin ein if-Guard, ein throw bei fehlendem Wert oder ein Array-Filter mit einem benutzerdefinierten Type Guard. NonNullable macht dabei lediglich den Rückgabetyp dieser Prüfung präzise, statt pauschal mit einem !-Non-Null-Assertion-Operator zu arbeiten, der jede tatsächliche Prüfung durch den Compiler umgeht.

8. Utility Types kombinieren: verschachtelte Muster

Die eigentliche Stärke der eingebauten Utility Types zeigt sich erst in der Kombination. Partial<Pick<T, K>> etwa wählt zunächst eine bestimmte Teilmenge von Feldern aus und macht anschließend genau diese Teilmenge optional - das perfekte Muster für ein Patch-DTO, das nur wenige, klar benannte Felder überhaupt verändern darf, alle davon aber optional. Ein generisches Partial<T> wäre hier zu großzügig, weil es versehentlich auch sensible Felder wie eine SKU oder eine ID änderbar machen würde.

Ein zweites häufiges Muster ist die Intersection aus Omit und Partial<Pick<...>>: Omit<T, K> & Partial<Pick<T, K>> beschreibt einen Typ, bei dem die meisten Felder wie im Original verpflichtend bleiben, eine klar benannte Teilmenge aber ausdrücklich optional wird - etwa ein Create-Input, bei dem die generierte SKU beim Anlegen fehlt, eine Beschreibung aber optional nachgereicht werden darf. Bei mehr als zwei verschachtelten Utility Types lohnt es sich, einen benannten Zwischentyp zu extrahieren; sonst leidet die Lesbarkeit spürbar, ohne dass die Typsicherheit dadurch steigt.

interface Product {
  sku: string;
  name: string;
  price: number;
  description: string;
  stockQty: number;
  active: boolean;
}

// Combining utility types: only price, stockQty and active are editable, and optional
type ProductPatch = Partial<Pick<Product, 'price' | 'stockQty' | 'active'>>;

function patchProduct(sku: string, patch: ProductPatch): void {
  // sku and name can never be touched through this function's signature
  applyPatch(sku, patch);
}

declare function applyPatch(sku: string, patch: ProductPatch): void;

// Combining with an intersection: most fields required, one explicitly optional
type ProductCreateInput = Omit<Product, 'sku'> & Partial<Pick<Product, 'description'>>;

function createProduct(sku: string, input: ProductCreateInput): Product {
  return { sku, description: '', ...input };
}

// Exclude/Extract narrow a union, NonNullable strips null/undefined after a guard
type OrderStatus = 'pending' | 'processing' | 'shipped' | 'delivered' | 'cancelled' | 'refunded';
type ClosedStatus = Extract<OrderStatus, 'delivered' | 'cancelled' | 'refunded'>;
type OpenStatus = Exclude<OrderStatus, ClosedStatus>;

interface CustomerWithOrder {
  id: string;
  lastOrder: Product | null | undefined;
}

function requireLastOrder(customer: CustomerWithOrder): NonNullable<CustomerWithOrder['lastOrder']> {
  if (!customer.lastOrder) {
    throw new Error(`Customer ${customer.id} has no orders yet`);
  }
  return customer.lastOrder;
}

9. Utility Types im direkten Vergleich

Die neun wichtigsten eingebauten Utility Types lösen unterschiedliche Probleme und lassen sich anhand von drei Fragen einordnen: Wirkt die Transformation auf Objekt-Keys oder auf Union-Mitglieder? Verändert sie Optionalität oder Veränderlichkeit? Und erzeugt sie eine Teilmenge oder eine strukturelle Neuabbildung? Die folgende Tabelle fasst die praktische Anwendung jedes Typs zusammen.

Die Tabelle zeigt auch, wo sich Typen kombinieren lassen: Pick und Partial ergänzen sich zu Patch-DTOs, Exclude und Extract ergänzen sich zu vollständigen Union-Zerlegungen, und Omit ist letztlich nur eine vordefinierte Kombination aus Pick und Exclude. Wer diese Bausteine versteht, muss selten eigene Mapped Types von Grund auf schreiben.

10. Zusammenfassung

Die eingebauten Utility Types von TypeScript lösen ein wiederkehrendes Problem: Domänenmodelle sollen in unterschiedlichen Kontexten leicht unterschiedliche Formen annehmen, ohne dass daraus mehrere manuell gepflegte Interfaces entstehen. Partial und Required steuern Optionalität, Readonly schützt vor versehentlicher Mutation zur Kompilierzeit, Pick und Omit extrahieren beziehungsweise entfernen Teilmengen von Feldern, Record erzwingt vollständige Key-Value-Abdeckung, Exclude und Extract filtern Union Types, und NonNullable präzisiert einen Typ nach einer Existenzprüfung.

Der größte Hebel liegt in der Kombination dieser Bausteine: Partial<Pick<T, K>> und Omit<T, K> & Partial<Pick<T, K>> decken die meisten Patch- und Create-DTO-Szenarien ab, ohne dass ein einziges zusätzliches Interface von Hand geschrieben werden muss. Wer diese Muster konsequent statt punktueller any-Workarounds einsetzt, bekommt ein Typsystem, das mit dem Domänenmodell mitwächst, statt bei jeder Änderung an mehreren Stellen gleichzeitig gepflegt werden zu müssen.

11. FAQ: Utility Types im Ueberblick