NCA Social Media
Aktualisiert:
Autor:
Roland Golla
Grüner Werkzeugkoffer mit gelbem Schild UTILITY TYPES und Werkzeugen

Was sind Utility Types in TypeScript?

Utility Types sind eingebaute Hilfstypen in TypeScript, die aus einem vorhandenen Typ einen neuen erzeugen. Sie stehen ohne Import überall bereit. Damit leitest du Varianten ab, statt dieselben Felder ein zweites Mal aufzuschreiben.
Code: 
          
type Nutzer = {
  id: string;
  name: string;
  email: string;
};

type NutzerUpdate = Partial<Nutzer>;      // alle Felder optional
type NutzerVorschau = Pick<Nutzer, "id" | "name">;
type NeuerNutzer = Omit<Nutzer, "id">;
Kommt bei Nutzer ein Feld dazu, ziehen die abgeleiteten Typen automatisch mit. Genau das spart im Alltag die meisten Fehler.
Inhalt
NCA KI Workshop für Developer

Agentic Coding im Team, nicht nur im Glossar

Ein Tag inhouse mit Benjamin Klein für Developer, Tester und Admins. Context Engineering, Harness, ADRs und zwei Hands on Blöcke mit KI Agenten in eurem Setup.

  1. 1
    Kostenloses Vorgespräch
    Stand, Rollen und Ziele klären
  2. 2
    Workshoptag bei euch
    Praxis am Vormittag, Hands on danach
  3. 3
    Praxistag optional
    Agenten im eigenen Projekt
Benjamin Klein
Benjamin Klein
Senior Consultant
Zum Workshop für Developer arrow_forward

Wir räumen doppelte Typen aus deiner Codebasis

Vor allem KI generierter Code legt für jede Aufgabe gern einen neuen Typ an. Nach einigen Monaten gibt es dann mehrere Fassungen desselben Nutzers. Mit AI Slop Refactoring führen wir sie wieder zusammen und leiten Varianten sauber ab.

Im Team verankern wir das über die AI Coding Guidelines für TypeScript. Mehr zu unserer Arbeit steht unter Frontend Development, das gemeinsame Üben im KI Training für Entwicklerteams.

Diese Utility Types brauchst du am häufigsten

Utility Type Ergebnis Typischer Einsatz
Partial Alle Felder optional Teilweise Updates
Required Alle Felder Pflicht Konfiguration nach dem Auffüllen
Readonly Felder nicht neu zuweisbar Unveränderliche Daten
Pick Nur die genannten Felder Listenansicht, Vorschau
Omit Alle Felder außer den genannten Eingabedaten ohne id
Record Objekt aus Schlüsseln und Werttyp Mappings und Lookups
ReturnType Rückgabetyp einer Funktion Typ aus vorhandenem Code ableiten
Parameters Parameter als Tupel Funktionen umhüllen
Awaited Inhalt eines Promise Ergebnis asynchroner Funktionen

Record und Awaited sparen dir den Abgleich von Hand

Record zwingt dich zur Vollständigkeit, wenn die Schlüssel aus einer Union kommen. Fehlt eine Variante, meldet der Compiler sie.
Code: 
          
type Rolle = "admin" | "redaktion" | "gast";

const rechte: Record<Rolle, string[]> = {
  admin: ["lesen", "schreiben", "löschen"],
  redaktion: ["lesen", "schreiben"],
  gast: ["lesen"],
};
Bei vorhandenen Funktionen musst du den Typ nicht neu beschreiben. ReturnType und Awaited holen ihn direkt aus dem Code.
Code: 
          
async function ladeNutzer(id: string) {
  return { id, name: "Ada", aktiv: true };
}

type Nutzer = Awaited<ReturnType<typeof ladeNutzer>>;
// { id: string; name: string; aktiv: boolean }

Wie sich solche Typen kombinieren lassen und was dahinter steckt, zeigt der never Eintrag am Beispiel von Exclude und NonNullable.

Diese drei Fallen sieht man im Review immer wieder

Omit prüft keine Schlüssel. Ein Tippfehler im zweiten Parameter ist kein Fehler. Das Feld bleibt einfach im Typ, und niemand merkt es.
Code: 
          
type Fehler = Omit<Nutzer, "emial">; // kein Compilerfehler, email bleibt drin
type Sicher = Pick<Nutzer, "id" | "name">; // Pick meldet falsche Schlüssel
Readonly wirkt nur auf der ersten Ebene. Verschachtelte Objekte und Arrays bleiben veränderbar. Zur Laufzeit schützt Readonly ohnehin nichts.
Code: 
          
const nutzer: Readonly<{ profil: { name: string } }> = {
  profil: { name: "Ada" },
};

nutzer.profil = { name: "Linus" }; // Fehler
nutzer.profil.name = "Linus";      // erlaubt
Partial ist schnell zu großzügig. Bei einem Update ist oft nur ein Teil der Felder wirklich änderbar. Dann beschreibt Partial<Pick<Nutzer, "name" | "email">> die Absicht genauer, und die id kann nicht versehentlich überschrieben werden.

TypeScript provides several utility types to facilitate common type transformations.

TypeScript Handbook, Offizielle TypeScript Dokumentation von Microsoft – typescriptlang.org, Kapitel Utility Types

Eine Quelle für jeden Typ erleichtert auch dem Agent die Arbeit

Eine kurze Regel in der AGENTS.md hilft: Vor einem neuen Typ prüft der Agent, ob er sich aus einem vorhandenen ableiten lässt. Doppelte Dateien und ungenutzte Typen findet danach Fallow. In den Quality Gates für KI Code läuft das gemeinsam mit dem Type Check.

Technisch bauen Utility Types auf Generics auf. Typen aus Konfigurationsobjekten liefert satisfies, Typen aus Schemas liefert Zod. Der TypeScript Eintrag gibt den Überblick zur Sprache.

CYPRESS.IO Ambassador und IT Consultant für QA Engenieering und Qualität in PHP Projekten.
Frontend: Optimieren Sie Ihre Webseite mit Astro JS und nutzen Sie die Vorteile der Barrierefreiheit

Optimieren Sie Ihre Webseite mit Astro JS und nutzen Sie die Vorteile einer schnellen, sicheren und barrierefreien Webseite. Erfüllen Sie die gesetzlichen Anforderungen und verbessern Sie die Benutzererfahrung Ihrer Webseite. Mit Astro JS können Sie die Ladezeit reduzieren, die Sicherheit maximieren und die SEO-Optimierung verbessern. Kontaktieren Sie uns, um mehr zu erfahren und um Ihre Webseite auf ein neues Level zu heben.

E-Mail Kontakt

Häufige Fragen zu TypeScript Utility Types

Kurze Antworten für den Alltag.
Was sind Utility Types in TypeScript 2026?

Eingebaute generische Typen, die aus einem vorhandenen Typ einen neuen erzeugen. Bekannte Beispiele sind Partial, Pick, Omit und Record. Du musst nichts importieren oder installieren. Sie existieren nur beim Kompilieren und erzeugen kein JavaScript.

Wann nutze ich 2026 Pick und wann Omit?

Pick passt, wenn du wenige Felder aus einem großen Typ brauchst. Omit passt, wenn fast alle Felder bleiben sollen. Pick prüft dabei die Schlüssel und meldet Tippfehler, Omit nicht. Im Zweifel ist Pick deshalb die sicherere Wahl.

Was ist 2026 der Unterschied zwischen Record und Map?

Record ist nur ein Typ für ein normales Objekt und verschwindet beim Kompilieren. Map ist eine echte JavaScript Struktur zur Laufzeit. Für feste Schlüssel aus einer Union passt Record. Für häufig wechselnde Einträge oder Schlüssel, die keine Texte sind, passt Map.

Macht Readonly 2026 ein Objekt wirklich unveränderlich?

Nein. Readonly wirkt nur beim Kompilieren und nur auf der ersten Ebene. Verschachtelte Objekte bleiben änderbar, und zur Laufzeit gibt es keinen Schutz. Dafür brauchst du Object.freeze, das seinerseits ebenfalls nur die erste Ebene einfriert.

Helfen Utility Types 2026 gegen doppelten KI Code?

Ja, wenn der Agent dazu angehalten wird. Ohne Regel legt er für neue Aufgaben schnell eigene Typen an. Eine Vorgabe in der Regeldatei und ein Review, das auf Ableitungen achtet, halten die Zahl der Definitionen klein und das Datenmodell an einer Stelle.

Kann ich Utility Types kombinieren?

Ja, sie lassen sich ineinander schachteln, etwa Partial und Pick für änderbare Felder oder Awaited und ReturnType für Ergebnisse asynchroner Funktionen. Bei mehr als zwei oder drei Ebenen wird es schwer lesbar. Dann hilft ein benannter Zwischentyp.

Warum meldet Omit keinen Fehler bei falschen Schlüsseln?

Der zweite Parameter von Omit ist bewusst nicht auf die Schlüssel des Typs beschränkt. Ein Tippfehler entfernt also einfach nichts. Wenn dich das stört, nimm Pick oder schreibe einen eigenen strengeren Typ für dein Projekt.

Wie mache ich Readonly für verschachtelte Objekte?

Ein eingebautes DeepReadonly gibt es nicht. Für feste Werte reicht oft as const, das auch verschachtelte Strukturen schreibgeschützt typisiert. Alternativ schreibst du einen eigenen rekursiven Typ oder nutzt eine erprobte Bibliothek. Das ist für die meisten Projekte selten nötig.

Sollte ich Typen ableiten oder neu schreiben?

Ableiten, solange die Typen fachlich zusammengehören. Ein Update hängt am Nutzer und soll mitwachsen. Haben zwei Typen nur zufällig dieselben Felder, schreibst du sie besser getrennt. Sonst koppelst du Dinge, die sich später unabhängig ändern müssen.

Kann ich eigene Utility Types schreiben?

Ja, mit Generics, Mapped Types und Conditional Types. Die eingebauten sind genauso aufgebaut. Für Anwendungscode reichen sie meist aus. Eigene lohnen sich, wenn ein Muster im Projekt oft vorkommt und der Name den Code wirklich lesbarer macht.