TypeScript Utility Types – Kompletter Leitfaden von Anfänger bis Fortgeschritten (mit Zod)

TypeScript Utility Types sind vordefinierte generische Typen, die Typ-Transformationen erleichtern. Sie ermöglichen es, aus bestehenden Typen neue Typen zu erstellen, zum Beispiel indem bestimmte Eigenschaften optional gemacht oder der Rückgabetyp einer Funktion extrahiert wird. Dieser Leitfaden in drei Stufen (Anfänger, Fortgeschritten, Experte) stellt alle Standard-Utility-Types von TypeScript vor (wie Partial, Required, Readonly, Pick, Omit, Record, Exclude, Extract, NonNullable, Parameters, ReturnType, InstanceType, ThisType usw.), jeweils mit einer Erklärung ihres Nutzens, einem Beispiel in TypeScript und einem Vergleich mit einem äquivalenten Ansatz in Zod, einer Laufzeit-Validierungsbibliothek. Außerdem werden die philosophischen Unterschiede zwischen TypeScript Utility Types (statisches Typsystem) und Zod-Schemas (Laufzeitvalidierung) diskutiert.

Projekt mit Bun einrichten

Um die Codebeispiele auszuprobieren, kannst du ein minimales TypeScript-Projekt mit Bun initialisieren (ein extrem schneller JavaScript-Runner, der auch als Paketmanager dient). Stelle sicher, dass Bun installiert ist, und führe dann in einem leeren Ordner aus:

shell

Bun erstellt eine Standard-package.json und tsconfig.json. Du kannst dann eine TypeScript-Datei mit bun run file.ts ausführen (Bun transpiliert TypeScript on the fly).

Jetzt können wir Utility Types erkunden!

Anfänger: Grundlegende Utility Types des Typsystems

Partial<T> – Optionale Eigenschaften

TypeScript: Der Utility Type Partial<T> erstellt aus einem bestehenden Typ T einen Typ, bei dem alle Eigenschaften optional sind. Das heißt, jede Eigenschaft von T wird optional (es wird ein ? hinzugefügt). So kannst du partielle Objekte dieses Typs darstellen. Beispiel: Wenn du einen User-Typ mit Pflichtfeldern hast, erlaubt Partial<User> eine Version, bei der diese Felder weggelassen werden können:

typescript

Hier hat Partial<User> den Typ { name?: string; age?: number }. Das ermöglicht es zum Beispiel, eine partielle Update-Funktion zu implementieren, ohne alle Felder zu verlangen:

typescript

Du rufst updateUser(existingUser, { age: 26 }) mit einem partiellen Objekt auf – TypeScript garantiert statisch, dass fieldsToUpdate nur gültige Schlüssel von User enthält.

Äquivalent mit Zod: Zod bietet eine äquivalente Methode, um ein Objektschema partiell zu machen. Die Methode .partial() auf einem z.object-Schema macht alle Schlüssel optional, ähnlich wie Partial in TypeScript. Beispiel:

typescript

Hier ist PartialUserSchema ein Schema, das Objekte mit nur einer Teilmenge der Schlüssel validiert (name und age werden optional). Du kannst es so testen:

typescript

Zod erlaubt es auch, nur bestimmte Eigenschaften optional zu machen, indem man ein Objekt als Parameter übergibt (UserSchema.partial({ age: true }) macht nur age optional). Beachte, dass .partial() nur auf der ersten Ebene wirkt; Zod bietet auch .deepPartial(), um verschachtelte Felder rekursiv optional zu machen.

Required<T> – Pflicht-Eigenschaften

TypeScript: Der Utility Type Required<T> ist das Gegenteil von Partial: Er erstellt aus T einen Typ, bei dem alle Eigenschaften Pflichtfelder sind (nicht optional). Das ist nützlich, um einen Typ zu "verfestigen", dessen Eigenschaften optional waren. Beispiel:

typescript

In diesem Beispiel ist Required<Settings> äquivalent zu { theme: string; fontSize: number } – das Weglassen einer Eigenschaft wird zum Kompilierfehler.

Äquivalent mit Zod: Für ein Zod-Schema gibt es die Methode .required(), die ein Objektschema so transformiert, dass alle Eigenschaften Pflichtfelder werden (im Gegensatz zu .partial(), das sie optional macht). Das ist besonders nützlich, wenn man zuerst ein partielles Schema definiert hat und dann die strikte Version möchte. Beispiel:

typescript

Hier verlangt StrictUserSchema, dass name und age vorhanden sind. Du kannst auch gezielt bestimmte Eigenschaften angeben: BaseUserSchema.required({ age: true }) macht nur age zur Pflicht (und lässt name optional).

Beachte, dass Required<T> zur Kompilierzeit wirkt (im ausgegebenen JavaScript-Code existiert es nicht mehr), während schema.required() von Zod zur Laufzeit die Anwesenheit der Schlüssel prüft.

Readonly<T> – Unveränderliche Eigenschaften

TypeScript: Der Utility Type Readonly<T> wandelt einen Typ T so um, dass seine Eigenschaften schreibgeschützt (unveränderlich) sind. Jeder Versuch, diese Eigenschaften neu zuzuweisen, wird beim Kompilieren als Fehler gemeldet. Beispiel:

typescript

Hier ist todo vom Typ Readonly<Todo>, daher können seine Felder nach der Initialisierung nicht mehr verändert werden. Das entspricht oft der Verwendung von Object.freeze in JavaScript, aber TypeScript behandelt dies nur auf Typ-Ebene (es verhindert keine Mutation zur Laufzeit, sondern warnt nur beim Kompilieren).

Äquivalent mit Zod: Zod bietet eine interessante Funktion für Unveränderlichkeit. Die Methode .readonly() auf einem Schema gibt ein neues Schema zurück, das beim Parsen Object.freeze() auf das Ergebnis anwendet und dessen statischer Typ als Readonly<...> markiert ist. Zod kann also das validierte Objekt einfrieren und sicherstellen, dass es einem readonly-Typ entspricht. Beispiel:

typescript

Hier friert FrozenUserSchema das von parse zurückgegebene Objekt ein. Wenn du versuchst, frozenUser zu verändern, wird zur Laufzeit eine Ausnahme ausgelöst, weil das Objekt unveränderlich ist. Zod geht also weiter als TypeScript: Während Readonly<T> rein statisch ist (Eigenschaften könnten in JS verändert werden, wenn man das Typing umgeht), sorgt das Zod .readonly()-Schema für echte Unveränderlichkeit zur Laufzeit und liefert zusätzlich den entsprechenden Readonly<...>-Typ.

Pick<T, Keys> – Auswahl einer Teilmenge von Eigenschaften

TypeScript: Pick<T, Keys> erstellt aus T einen neuen Typ, der nur die Eigenschaften enthält, die durch Keys angegeben sind (typischerweise eine Union von String-Literalen als Eigenschaftsnamen). Das ist nützlich, um aus einem bestehenden Typ einen eingeschränkten Typ zu machen. Beispiel:

typescript

Hier enthält TodoPreview nur title und completed aus FullTodo. Jede nicht aufgeführte Eigenschaft (z.B. description) wird im resultierenden Typ ausgeschlossen.

Äquivalent mit Zod: Zod-Objektschemas haben ebenfalls eine .pick()-Methode, die ein neues Schema mit nur den angegebenen Schlüsseln erstellt, ähnlich wie Pick in TypeScript:

typescript

Du übergibst ein Objekt mit den zu behaltenden Schlüsseln auf true gesetzt. TodoPreviewSchema validiert nur Objekte mit title und completed (andere Eigenschaften von FullTodo werden vom Parser standardmäßig ignoriert). Zum Beispiel gibt TodoPreviewSchema.parse({ title: "Clean", completed: false, description: "..." }) { title: "...", completed: false } zurück, wobei description entfernt wurde (weil Zod standardmäßig nicht spezifizierte Schlüssel ignoriert; dieses Verhalten kann mit .strict() oder .passthrough() angepasst werden).

Ebenso bietet Zod .omit() für den gegenteiligen Effekt.

Omit<T, Keys> – Ausschluss von Eigenschaften

TypeScript: Omit<T, Keys> erstellt aus T einen neuen Typ, bei dem bestimmte Eigenschaften (Keys) entfernt werden. Es ist das Gegenstück zu Pick (tatsächlich wird Omit<T, K> oft als Pick<T, Exclude<keyof T, K>> implementiert). Beispiel:

typescript

Hier enthält TaskMeta nur id und title. Die Eigenschaften done und dueDate wurden ausgeschlossen.

Äquivalent mit Zod: Die .omit()-Methode von Zod erzeugt ein Objektschema ohne die angegebenen Schlüssel. Beispiel:

typescript

TaskMetaSchema validiert Objekte, die nur id und title enthalten. Jeder ausgelassene Schlüssel (done, dueDate) wird ignoriert, wenn er im Input vorhanden ist. Pick und Omit erlauben es, ein Zod-Schema auf eine Teilmenge von Feldern zu projizieren, genau wie ihre TypeScript-Äquivalente auf Typ-Ebene.

Record<Keys, Type> – Wörterbuch mit typisierten Schlüsseln

TypeScript: Record<Keys, Type> erstellt einen Objekttyp, dessen Schlüssel vom Typ Keys sind (typischerweise eine Union von String-Literalen oder ein allgemeiner string/number-Typ) und dessen Werte vom Typ Type sind. Damit kannst du z.B. ein Objekt beschreiben, das nach Bezeichnern indiziert ist. Ein klassisches Beispiel:

typescript

Hier stellt Record<CatName, CatInfo> sicher, dass das cats-Objekt genau die Schlüssel "miffy", "boris", "mordred" hat, jeweils mit einem CatInfo verknüpft. Record ist sehr nützlich, um Objekte als Wörterbücher oder Maps zu typisieren.

Äquivalent mit Zod: Zod bietet das Schema z.record(keySchema, valueSchema), um solche Objekte zu validieren. Du kannst es mit einem Schlüssel-Schema (z.B. z.string() oder ein Literal-Schema) und einem Wert-Schema verwenden. Beispiel:

typescript

Hier validiert AgeMapSchema jeden Schlüssel, solange er ein String ist (standardmäßig nimmt z.record ohne erstes Argument string an). Wenn du eine endliche Menge von Schlüsseln hast, ist es oft besser, z.object({ ... }) mit explizit benannten Schlüsseln oder z.enum([...]) zu verwenden, um die Schlüssel einzuschränken. Tatsächlich erlaubt Zod ein strengeres Schlüssel-Schema: Du könntest const CatNameSchema = z.enum(["miffy","boris","mordred"]) definieren und dann z.record(CatNameSchema, CatInfoSchema) verwenden – beachte aber, dass zur Laufzeit JavaScript-Objektschlüssel immer Strings sind. Auch ein numerischer Schlüssel wird zur Laufzeit in einen String umgewandelt (z.B. wird ein Schlüssel 1 zu "1" in einem JS-Objekt). Zod berücksichtigt das und erlaubt kein reines numerisches Schlüssel-Schema ohne Umwandlung in String.

Zusammengefasst: Record<Keys, Type> (TypeScript) und z.record(keySchema, valueSchema) (Zod) erlauben beide die Typisierung von Wörterbüchern. Ersteres wirkt auf Typ-System-Ebene, letzteres validiert die Objektstruktur zur Laufzeit.

Fortgeschritten: Arbeiten mit Unions und optionalen Typen

Exclude<UnionType, ExcludedMembers> – Entfernen von Union-Mitgliedern

TypeScript: Exclude<U, E> erstellt einen Typ, indem aus der Union U alle Mitglieder entfernt werden, die auf den Typ E zuweisbar sind. Anders gesagt: Du schließt bestimmte Typen aus einer Union aus. Beispiel:

typescript

Hier entfernt Exclude<Role, "admin"> das Literal "admin" aus der Union, übrig bleiben "user" | "guest". Ein weiteres Beispiel: Exclude<string | number | boolean, string> ergibt number | boolean (alles, was auf string zuweisbar ist, wird entfernt). Das ist nützlich, um eine Union zu verfeinern und unerwünschte Fälle auszuschließen.

Äquivalent mit Zod: Um die Möglichkeiten einer Union zur Laufzeit einzuschränken, definierst du typischerweise ein Schema, das die auszuschließenden Fälle nicht enthält. Wenn du z.B. ein RoleSchema = z.enum(["admin","user","guest"]) hast, kannst du eine Teilmenge erstellen, indem du "admin" nicht einschließt. Zod bietet für Enums die Methode .exclude([…]), die ein neues Enum-Schema ohne die angegebenen Werte erzeugt. Beispiel:

typescript

Dieses NonAdminSchema entspricht genau dem Typ Exclude<Role, "admin">, stellt aber auch die Validierung zur Laufzeit sicher. Intern entfernt RoleSchema.exclude(["admin"]) einfach "admin" aus der Liste der erlaubten Literale. Ebenso bietet Zod .extract([...]) für die komplementäre Operation.

Extract<Type, Union> – Extrahieren von Union-Mitgliedern

TypeScript: Extract<T, U> erstellt einen Typ, indem aus T nur die Mitglieder behalten werden, die auf U zuweisbar sind. Das ist grob das Gegenteil von Exclude. Beispiel:

typescript

Ein weiteres Beispiel: Extract<"a" | "b" | "c", "a" | "f"> ergibt "a" (weil nur "a" in beiden vorkommt). Dieser Utility Type wird also verwendet, um eine Union zu filtern und nur einen bestimmten Subtyp zu extrahieren.

Äquivalent mit Zod: Wie bei Exclude erlaubt Zod, zur Laufzeit ein Schema zu erhalten, das einer Teilmenge einer Enumeration entspricht, über .extract([...]). Beispiel mit Rollen: Um nur die eingeschränkten Rollen "user" und "guest" aus einem vollständigen RoleSchema zu extrahieren:

typescript

Hier entspricht LimitedRolesSchema dem Typ Extract<Role, "user" | "guest">. Praktisch könntest du das gleiche Ergebnis auch direkt mit z.enum(["user","guest"]) erreichen, aber .extract ist praktisch, um ein Schema aus einem bestehenden Enum abzuleiten. Beachte, dass .exclude und .extract von Zod auf Enum-Schemas (z.enum oder z.nativeEnum) angewendet werden, nicht auf beliebige Unions komplexer Typen. Für letztere baust du das gewünschte neue Union-Schema meist manuell.

NonNullable<T> – Ausschluss von null und undefined

TypeScript: NonNullable<T> erstellt einen Typ, indem null und undefined aus T entfernt werden. Es ist in TypeScript üblich, Union-Typen mit diesen "nullish"-Werten zu haben und einen Typ zu wollen, der davon bereinigt ist. Beispiel:

typescript

Hier enthält DefinitelyString nur string (weder null noch undefined). Dieser Utility Type wird oft in Kombination mit Präsenzbedingungen verwendet (if (value != null) { ... }), um dem Compiler zu helfen, Typen zu verfeinern.

Äquivalent mit Zod: Bei Zod akzeptieren Schemas standardmäßig weder undefined noch null, es sei denn, du gibst es explizit an. Ein z.string()-Schema akzeptiert also nur einen String, kein undefined. Um diese Werte zuzulassen, verwendest du explizit z.string().optional() (erlaubt undefined) oder z.string().nullable() (erlaubt null) oder .nullish() (erlaubt beides). Das Äquivalent zu einem NonNullable-Typ erhältst du also einfach, indem du null/undefined nicht im Schema zulässt. Wenn du von einem großzügigeren Schema ausgehst und es strikter machen willst, kannst du verschiedene Techniken kombinieren: Die Methode .unwrap() erlaubt es, das zugrundeliegende Schema aus einem optionalen oder nullable-Schema zu extrahieren.

typescript

Hier gibt OptionalName.unwrap() das ursprüngliche z.string()-Schema zurück. So kannst du das optionale oder nullable-Charakteristikum wieder "entfernen". Ein anderer Ansatz wäre ein Custom Refinement, um null/undefined abzulehnen, aber das wäre redundant, da Zod-Schemas dies ohnehin standardmäßig tun.

Experte: Funktionstypen und Klassen

Parameters<Type> – Funktion-Parameter-Typen

TypeScript: Parameters<T> extrahiert die Parametertypen eines Funktionstyps T als Tupel. Das ist nützlich, um mit Funktionssignaturen zu arbeiten, besonders wenn du eine Funktion erstellen willst, die eine andere Funktion umschließt. Beispiel:

typescript

Hier extrahiert Parameters<typeof greet> das Tupel [string, number], das die Parameter von greet repräsentiert. So kann safeGreet genau die gleichen Parameter wie greet akzeptieren.

Äquivalent mit Zod: Zod bietet z.function(), um Funktionsschemas zu definieren, mit Methoden zur Angabe von Parametertypen und Rückgabetyp. Es gibt zwar kein direktes Äquivalent zu Parameters<T>, aber du kannst ein Funktionsschema definieren und die Parametertypen mit TypeScripts eigenem Parameters-Utility auf dem abgeleiteten Typ extrahieren:

typescript

Hier definiert GreetSchema ein Funktionsschema, das einen String und eine Zahl nimmt und einen String zurückgibt. Die Methode .implement() erstellt eine Wrapper-Funktion, die Eingaben und Ausgaben gemäß dem Schema validiert. Wir können die Parametertypen mit Parameters<GreetFn> extrahieren. Dieser Ansatz kombiniert Laufzeitvalidierung mit statischer Typisierung.

ReturnType<Type> – Rückgabetyp einer Funktion

TypeScript: ReturnType<T> extrahiert den Rückgabetyp eines Funktionstyps T. Das ist nützlich, wenn du mit dem Ergebnis einer Funktion arbeiten willst, ohne den Typ explizit neu zu definieren. Beispiel:

typescript

Hier extrahiert ReturnType<typeof createUser> den Objekttyp, der von createUser zurückgegeben wird. So können wir den User-Typ definieren, ohne die Struktur zu duplizieren.

Äquivalent mit Zod: Wie bei Parameters gibt es kein direktes Zod-Äquivalent zu ReturnType, aber du kannst das Funktionsschema von Zod mit TypeScripts ReturnType-Utility kombinieren:

typescript

Hier definieren wir ein Funktionsschema mit CreateUserSchema und extrahieren dann den Rückgabetyp auf zwei Arten: mit TypeScripts ReturnType auf dem abgeleiteten Funktionstyp oder mit Zods .returnType(), das das Schema für den Rückgabewert liefert. Beide Ansätze ergeben den User-Typ.

InstanceType<Type> – Instanztyp einer Klasse

TypeScript: InstanceType<T> extrahiert den Instanztyp eines Konstruktortyps T. Das ist nützlich, wenn du eine Klassenreferenz hast und mit Instanzen dieser Klasse arbeiten willst. Beispiel:

typescript

Hier gibt InstanceType<typeof Point> uns den Typ einer Point-Instanz, der ihre Eigenschaften und Methoden enthält.

Äquivalent mit Zod: Zod hat kein direktes Äquivalent für Klasseninstanzen, da es sich auf Datenvalidierung und nicht auf Klassenverhalten konzentriert. Du kannst aber ein Schema für die Form von Klasseninstanzen definieren:

typescript

Dieser Ansatz definiert ein Schema, das der Form einer Point-Instanz entspricht, aber nicht die vollständige Klassenbeziehung abbildet. Für komplexere Klassenvalidierung musst du ggf. Zod mit class-validator oder ähnlichen Bibliotheken kombinieren.

Philosophische Unterschiede zwischen TypeScript Utility Types und Zod-Schemas

TypeScript Utility Types und Zod-Schemas dienen beide der Datensicherheit, aber auf unterschiedlichen Ebenen: einer zur Kompilierzeit, der andere zur Laufzeit.

• TypeScript: statische Sicherheit (Kompilierzeit) – Utility Types (und das Typsystem allgemein) wirken während der Entwicklung. TypeScript analysiert den Code und verhindert Typinkonsistenzen, bevor der Code überhaupt ausgeführt wird. Zum Beispiel stellt Partial<T> sicher, dass eine Funktion keine Fälle vergisst, in denen Eigenschaften fehlen, ReturnType<Fn> gibt die erwartete Form von Funktionsrückgaben an usw. Diese Prüfungen existieren jedoch nicht mehr, sobald die Anwendung läuft: TypeScript entfernt die Typen beim Transpilieren zu JavaScript. Nichts verhindert, dass zur Laufzeit fehlerhafte Daten zirkulieren (z.B. aus JSON, Benutzerformularen, externen APIs ...). Das Typsystem allein schützt nicht vor unerwarteten Werten zur Laufzeit.
• Zod: dynamische Validierung (Laufzeit) – Zod-Schemas füllen diese Lücke zur Laufzeit. Durch die Definition eines Schemas für deine Daten erstellst du einen Laufzeit-Guard, der prüft, ob empfangene Daten dem erwarteten Format entsprechen. Ein PartialUserSchema prüft tatsächlich, ob das empfangene Objekt nur gültige Schlüssel und Werte des richtigen Typs enthält, während Partial<T> nur eine Zusicherung zur Kompilierzeit ist. Zod und TypeScript ergänzen sich also: TypeScript sorgt für die interne Konsistenz deines Codes (was du manipulierst, entspricht den angekündigten Typen), während Zod sicherstellt, dass externe Daten deinen Typen entsprechen.

Zusammengefasst:

• TypeScript ist ein Kompilierzeit-Guard, der Fehler früh im Entwicklungszyklus abfängt und viele typische Fehler vermeidet, bevor der Code überhaupt läuft.
• Zod ist ein Laufzeit-Guard, der sicherstellt, dass keine nicht-konformen Daten "durch die Tür" deiner Anwendung gelangen (Benutzereingaben, API-Antworten, Konfigurationsinhalte usw.).

Philosophisch gesehen drücken Utility Types Transformationen oder Einschränkungen auf Typ-System-Ebene aus (sie helfen dem Entwickler, haben aber keinen direkten Einfluss auf den ausgegebenen Code), während Zod zur Laufzeit Verträge bereitstellt (sie ermöglichen die konkrete Implementierung von Datenvalidierungen und -transformationen zur Ausführung). Beide Ansätze adressieren unterschiedliche, aber verwandte Bedürfnisse: die Robustheit des Codes. Zod ist zudem so konzipiert, dass es sich harmonisch in TypeScript integriert: Es leitet automatisch statische Typen aus deinen Schemas ab, sodass du keine Definitionen duplizieren musst. Oft kannst du ein Zod-Schema (für die Validierung) definieren und mit z.infer den entsprechenden statischen TypeScript-Typ ableiten, statt ein TypeScript-Interface und ein separates Schema zu definieren – so hast du eine einzige Quelle der Wahrheit für deine Datentypen.

Fazit: Wer TypeScript Utility Types kennt, kann das Typsystem optimal nutzen, um sicheren und ausdrucksstarken Code zu schreiben. Wer Zod beherrscht, hat die Werkzeuge, um diese Typverträge zur Laufzeit durchzusetzen. Zusammen stärken sie die Zuverlässigkeit deiner TypeScript-Anwendungen erheblich: TypeScript schützt vor Programmierfehlern, Zod schützt deine Anwendung vor unerwarteten Daten von außen. Definiere deine Typen, validiere deine Daten und programmiere mit ruhigem Gewissen 🎉!

1bun init
2bun add zod             # fügt Zod als Abhängigkeit hinzu

1interface User {
2  name: string;
3  age: number;
4}
5
6const partialUser: Partial<User> = { name: 'Alice' };
7// 'partialUser' kann nur den Namen enthalten, die Eigenschaft 'age' ist optional
8partialUser.age = 30; // OK, später hinzufügbar, da 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 ist vom Typ { name?: string; age?: number }

1PartialUserSchema.parse({ name: 'Alice' }); // OK (fehlendes age erlaubt)
2PartialUserSchema.parse({}); // OK (darf leer sein)
3PartialUserSchema.parse({ age: ' thirty ' }); // Fehler: age ist keine Zahl

1interface Settings {
2  theme?: string;
3  fontSize?: number;
4}
5const s1: Settings = { theme: 'dark' }; // OK, fontSize fehlt
6const s2: Required<Settings> = { theme: 'dark' }; // Fehler – fontSize ist Pflicht
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// Fehler 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'; // Laufzeitfehler: Das Objekt ist eingefroren (TypeError im Strict Mode)

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/* Entspricht:
8type Cats = {
9  miffy: CatInfo;
10  boris: CatInfo;
11  mordred: CatInfo;
12}
13*/
14const cats: Cats = {
15  miffy: { age: 10, breed: 'Persian' },
16  boris: { age: 5, breed: 'Maine Coon' },
17  mordred: { age: 16, breed: 'British Shorthair' },
18};

1// Wir wollen ein Objekt, dessen Schlüssel Namen (string) und Werte Alter (number) sind
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' }); // Fehler: "25" ist keine Zahl

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'); // Fehler: "admin" ist ausgeschlossen

1type Mixed = string | number | boolean;
2type NumbersOnly = Extract<Mixed, number | boolean>;
3// NumbersOnly: number | boolean (nur was auf number | boolean zuweisbar ist, bleibt)

1const LimitedRolesSchema = RoleSchema.extract(['user', 'guest']);
2type LimitedRoles = z.infer<typeof LimitedRolesSchema>;
3// LimitedRoles: "user" | "guest"
4LimitedRolesSchema.parse('guest'); // OK
5LimitedRolesSchema.parse('admin'); // Fehler, "admin" ist nicht extrahiert

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

1const OptionalName = z.string().optional(); // Typ: string | undefined
2const Name = OptionalName.unwrap(); // gibt das zugrundeliegende z.string()-Schema zurück (Typ: string)
3Name.parse('Alice'); // "Alice"
4Name.parse(undefined); // Fehler: undefined nicht erlaubt

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// Wir können diesen Typ verwenden, um eine Funktion zu erstellen, die greet aufruft
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()) // definiert Parameter: string, number
4  .returns(z.string()); // definiert Rückgabetyp: string
5
6type GreetFn = z.infer<typeof GreetSchema>; // Typ: (name: string, age: number) => string
7type GreetParams = Parameters<GreetFn>; // Typ: [string, number]
8
9// Wir können dieses Schema verwenden, um eine Funktion zu validieren
10const greet = GreetSchema.implement((name, age) => {
11  return `Hello ${name}, you are ${age} years old`;
12});
13// greet ist jetzt eine validierte Funktion, die bei falschen Typen eine Exception wirft

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// Wir können diesen Typ jetzt anderswo verwenden
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// Typ: (name: string) => { id: number; name: string; createdAt: Date }
14type User = ReturnType<CreateUserFn>;
15// Typ: { id: number; name: string; createdAt: Date }
16
17// Wir können auch direkt das Rückgabeschema extrahieren
18const UserSchema = CreateUserSchema.returnType();
19// UserSchema ist das Objektschema für den Rückgabewert
20type User2 = z.infer<typeof UserSchema>; // Gleich wie 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 (der Instanztyp, mit x, y und distanceFromOrigin)
17
18// Wir können diesen Typ verwenden, ohne eine Instanz zu haben
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// Typ: { x: number; y: number; distanceFromOrigin: () => number }
9
10// Wir können prüfen, ob ein Objekt der Point-Schnittstelle entspricht
11function isPoint(obj: unknown): obj is PointLike {
12  return PointSchema.safeParse(obj).success;
13}