NCA Social Media
Aktualisiert:
Autor:
Roland Golla
Grüne Prüfschablone mit gelbem Schriftzug SATISFIES, Würfel passt unverändert hindurch

Was ist der satisfies Operator in TypeScript?

satisfies ist ein TypeScript Operator, der prüft, ob ein Ausdruck zu einem Typ passt, ohne den Typ des Ausdrucks zu verändern. Du bekommst also die volle Fehlerprüfung einer Typannotation und behältst trotzdem die konkreten Literaltypen, die TypeScript von selbst erkannt hat.
Der Operator kam mit TypeScript 4.9 und löst ein altes Dilemma. Wer ein Objekt annotiert, verliert die genauen Werte. Wer nichts annotiert, bekommt genaue Werte, aber keine Prüfung. satisfies gibt dir beides.
Code: 
          
type Colors = "red" | "green" | "blue";
type RGB = [number, number, number];

const palette = {
  red: [255, 0, 0],
  green: "#00ff00",
  blue: [0, 0, 255],
} satisfies Record<Colors, string | RGB>;

// green ist ein string, nicht string | RGB
palette.green.toUpperCase();
Wichtig für das Verständnis: satisfies ist reine Compile Time Prüfung. Im gebauten JavaScript ist der Operator komplett verschwunden. Er kostet zur Laufzeit nichts und ersetzt deshalb auch keine Validierung von Daten, die von außen kommen.

Inhalt

satisfies mit NCA: Schnelle Hilfe vom Experten

Never Code Alone arbeitet seit über 20 Jahren an Softwarequalität. Unser Frontend Stack aus Astro, React und Vue läuft durchgehend typisiert in Production, Type Checking ist Pflichtschritt in jeder Pipeline. satisfies nutzen wir überall dort, wo Konfiguration im Code steht: Routen, Feature Flags, Mappings, Theme Tokens. Dieselbe Strenge kennen wir aus dem Backend, wo PHPStan und Type Coverage die Arbeit machen.

Dieses Wissen bringen wir direkt in dein Projekt. Wir refactoren gewachsene TypeScript Codebasen, führen den strict Mode in bestehenden Projekten ein und machen mit AI Slop Refactoring KI generierten Code produktionsreif. Im Vibe Coding Consulting zeigen wir Teams, wie Typen zum Guardrail werden, die Vibe Coding Best Practices und unsere Quality Gates für KI Code zeigen den Weg vom Prompt zur Pipeline.

TypeScript Projekt absichern

Finde das passende Angebot für dein Projekt

Anfrage-Konfiguration

Starten Sie Ihre Anfrage

Projektart
Infos
Nachricht

Eliminierung technischer Schulden mit PHPStan, Rector PHP und PHPUnit. Über 20 Jahre Praxiserfahrung in skalierbaren Backends.

CORE EXPERTISE

Gesetzliche Konformität & Inklusion. Optimierung von Performance und Conversion durch radikal nutzerzentriertes, universelles Design.

BFSG COMPLIANT

Skalierbare KI-Systeme mit echtem Code Ownership. CI/CD, Backup-Strategien und Infrastruktur, die mit deinem Team wächst.

ENTERPRISE READY

Das Problem: Prüfung oder genauer Typ, aber nie beides

Bevor es satisfies gab, musstest du dich entscheiden. Variante eins: Du schreibst eine Typannotation an die Variable. TypeScript prüft dann jeden Schlüssel und jeden Wert. Der Preis ist hoch. Die Variable hat ab sofort genau den annotierten Typ, alle konkreten Informationen sind weg.
Code: 
          
type Colors = "red" | "green" | "blue";
type RGB = [number, number, number];

const palette: Record<Colors, string | RGB> = {
  red: [255, 0, 0],
  green: "#00ff00",
  blue: [0, 0, 255],
};

// Fehler: Property 'toUpperCase' does not exist on type 'string | RGB'
palette.green.toUpperCase();
Du weißt, dass green ein string ist. TypeScript weiß es nicht mehr. Die Annotation hat den konkreten Typ überschrieben.
Variante zwei: Du lässt die Annotation weg. Jetzt kennt TypeScript die echten Typen und toUpperCase funktioniert. Dafür fällt jeder Tippfehler durch. Ein Schlüssel gren statt green bleibt unbemerkt, ein fehlender Schlüssel ebenso.
Code: 
          
const palette = {
  red: [255, 0, 0],
  gren: "#00ff00",
  blue: [0, 0, 255],
};

// Kein Fehler. TypeScript kennt Colors hier gar nicht.
// Der Tippfehler landet im Build.
Variante drei ist die schlechteste und trotzdem die häufigste: eine Type Assertion mit as. Sie prüft nichts, sie behauptet. Wer as schreibt, schaltet den Compiler an dieser Stelle ab und übernimmt die Verantwortung selbst.

Die Lösung: satisfies prüft und lässt den Typ in Ruhe

satisfies steht hinter dem Ausdruck, nicht vor der Variable. Genau darin liegt der Unterschied. Der Typ wird als Messlatte angelegt, aber nicht auf die Variable geschrieben.
Code: 
          
const palette = {
  red: [255, 0, 0],
  green: "#00ff00",
  blue: [0, 0, 255],
} satisfies Record<Colors, string | RGB>;

palette.green.toUpperCase(); // green ist string
palette.red[0];              // red ist ein Tuple aus Zahlen
Der Tippfehler von eben fliegt jetzt sofort auf. Ein Schlüssel, den Colors nicht kennt, ist ein Fehler. Ein fehlender Schlüssel ist ein Fehler. Ein Wert vom falschen Typ ist ein Fehler.
Code: 
          
const palette = {
  red: [255, 0, 0],
  gren: "#00ff00",
  blue: [0, 0, 255],
} satisfies Record<Colors, string | RGB>;

// Fehler: Object literal may only specify known properties,
// and 'gren' does not exist in type 'Record<Colors, string | RGB>'.
// Fehler: Property 'green' is missing.
Der Merksatz für Reviews: Annotation überschreibt, as behauptet, satisfies prüft. Nur die dritte Variante gibt dir Sicherheit und Präzision gleichzeitig.

Annotation, as und satisfies im direkten Vergleich

Schreibweise Findet Tippfehler und fehlende Schlüssel Behält den konkreten Typ
const x = { ... } Nein, der Typ ist unbekannt Ja, volle Inferenz
const x: Config = { ... } Ja Nein, der Typ wird überschrieben
const x = { ... } as Config Nein, die Prüfung wird umgangen Nein, der Typ wird behauptet
const x = { ... } satisfies Config Ja Ja

Praxis 1: Schlüssel aus dem Objekt ableiten statt doppelt pflegen

Das ist der Fall, der satisfies im Alltag am häufigsten rechtfertigt. Du hast ein Objekt mit Routen, Icons oder Übersetzungen. Du willst prüfen, dass alle Werte zusammenpassen, und du willst gleichzeitig die Schlüssel als Union weiterverwenden.
Code: 
          
const routes = {
  home: "/",
  blog: "/blog",
  kontakt: "/kontakt",
} satisfies Record<string, string>;

type Route = keyof typeof routes;
// "home" | "blog" | "kontakt"

function navigate(route: Route) {
  window.location.href = routes[route];
}
Mit einer Annotation wäre Route hier einfach string gewesen. Jeder beliebige Text hätte durchgepasst. Mit satisfies bekommst du die drei echten Schlüssel und die Autovervollständigung in der IDE dazu.
Der zweite Gewinn ist Wartung. Kommt eine Route dazu, wächst der Union Type automatisch mit. Es gibt keine zweite Liste, die jemand vergessen kann. Genau diese Redundanz ist in gewachsenen Projekten eine der zuverlässigsten Fehlerquellen.

Praxis 2: as const satisfies für Konfiguration im Code

Die beiden Operatoren lassen sich kombinieren und ergänzen sich gut. as const friert die Werte ein, satisfies prüft sie gegen deinen Typ. Die Reihenfolge ist dabei fest: erst as const, dann satisfies.
Code: 
          
type AppConfig = {
  port: number;
  mode: "development" | "production";
  features: readonly string[];
};

const config = {
  port: 3000,
  mode: "production",
  features: ["auth", "search"],
} as const satisfies AppConfig;

config.mode;     // "production", nicht string
config.features; // readonly ["auth", "search"]
Beachte das readonly im Typ. as const macht aus dem Array ein unveränderliches Tuple. Ein Typ, der ein normales string Array erwartet, passt dann nicht mehr. Das ist keine Schwäche, sondern die ehrliche Ansage: Diese Konfiguration wird nicht mutiert.
Für Werte, die aus der Umgebung kommen, gilt das Gegenteil. Environment Variablen, API Antworten und Nutzereingaben sind zur Laufzeit da und der Compiler sieht sie nie. Dafür brauchst du echte Validierung an der Systemgrenze, nicht satisfies.

Warum satisfies KI generierten Code absichert

KI Coding Agenten schreiben Objekte gerne freihändig. Ein Mapping hier, ein Config Objekt da, alles plausibel formatiert und ohne jede Prüfung. Der Code läuft, bis ein Schlüssel fehlt oder einer zu viel ist.
Noch häufiger ist das andere Muster: Der Agent stößt auf einen Typfehler und löst ihn mit as. Der Fehler ist weg, das Problem bleibt. Genau diese Stellen suchen wir in jedem Codebase Audit für KI generierten Code als erstes.
Deshalb gehört eine einfache Regel in jede AGENTS.md: Objektliterale werden mit satisfies gegen ihren Typ geprüft, as ist nur mit Begründung erlaubt. Das ist eine Zeile Regel, die einer ganzen Klasse von Fehlern den Boden entzieht.
Code: 
          
# Ausschnitt aus AGENTS.md

## TypeScript
- Objektliterale immer mit `satisfies` gegen den Zieltyp pruefen
- `as` nur mit Kommentar und Begruendung
- Keys nie doppelt pflegen, sondern per `keyof typeof` ableiten
- Vor jedem Commit: npx tsc --noEmit
Der Compiler ist im Agentic Coding das ehrlichste Feedback, das ein Agent bekommen kann. Er diskutiert nicht, er hat einfach recht. Wer diesen Kanal offen hält, spart sich später das mühsame Aufräumen. Wie wir das methodisch aufziehen, steht in unseren Quality Gates für KI Code und im Beitrag zu Code Qualität mit KI Agenten.

satisfies in Astro, React und in der CI Pipeline

In Astro Projekten sitzt satisfies überall dort, wo Konfiguration als Objekt im Repository liegt: Navigation, Redirects, Theme Tokens, Metadaten pro Seite. Die Datei bleibt lesbar wie normales JavaScript und ist trotzdem vollständig geprüft.
In React zahlt sich das Muster bei Mappings aus. Ein Objekt, das jeder Variante eine Komponente oder eine Farbe zuordnet, wird mit satisfies gegen den Union Type der Varianten geprüft. Kommt eine Variante dazu, meldet der Compiler die Lücke, statt sie zur Laufzeit als leere Stelle zu zeigen.
Code: 
          
type Variant = "info" | "warning" | "error";

const variantClass = {
  info: "bg-blue-100 text-blue-900",
  warning: "bg-amber-100 text-amber-900",
  error: "bg-red-100 text-red-900",
} satisfies Record<Variant, string>;

export function Alert({ variant }: { variant: Variant }) {
  return <div className={variantClass[variant]} />;
}
Wirksam wird das alles erst in der Pipeline. Ein Type Check, der nur lokal läuft, wird irgendwann übersprungen. Bei uns ist npx tsc --noEmit ein eigener Job, getrennt vom Build. Der Compiler prüft Typen, der Bundler baut das JavaScript.
Code: 
          
# Type Check als eigener Schritt, getrennt vom Build
npx tsc --noEmit

# Build laeuft danach
npm run build
Wer das komplette Setup sucht: In den Vibe Coding CI CD Pipelines steht, wie die Stufen zusammenspielen, und KI Code Review automatisieren zeigt, was danach kommt. Für die Sicht aufs ganze Projekt statt auf einzelne Dateien lohnt ein Blick auf Fallow.

Grenzen: wo satisfies nicht das richtige Werkzeug ist

satisfies prüft, was im Code steht. Alles, was erst zur Laufzeit entsteht, sieht der Operator nie. Für JSON aus einer API, für Formulareingaben und für Environment Variablen brauchst du eine echte Validierung, die im Browser oder auf dem Server läuft.
Auch als Ersatz für einen sauberen Typ taugt satisfies nicht. Wenn eine Funktion einen bestimmten Parametertyp erwartet, gehört dieser Typ an die Signatur. satisfies ist für Werte da, nicht für Verträge zwischen Modulen.
Und ein letzter Punkt aus dem Review Alltag: satisfies macht Fehler früher sichtbar, es macht Code nicht automatisch sicher. Ein Objekt kann perfekt typisiert sein und trotzdem die falschen Werte enthalten. Für Sicherheit gelten eigene Regeln, die wir unter Vibe Coding Security zusammengefasst haben. Für maschinenprüfbare Verträge zwischen Agenten und Code lohnt Schema Based AI Coding.

satisfies can be used to catch lots of possible errors.

Daniel Rosenwasser, Product Manager TypeScript bei Microsoft – Announcing TypeScript 4.9

Aus der NCA Praxis: ein Operator, der Reviews kürzer macht

satisfies ist kein großes Konzept, sondern ein Handgriff. Genau deshalb setzt es sich in Teams schnell durch. Wir bauen es beim Refactoring als erstes in Konfigurationsdateien ein, weil dort die Fehler am teuersten sind und am spätesten auffallen. Wer tiefer in die Sprache will, findet im NCA TypeScript Glossar die weiteren Bausteine, etwa den never Type für Exhaustive Checks. Die Einordnung der Sprache insgesamt steht im TypeScript Glossareintrag, den Umstieg auf strict Mode mit Astro haben wir separat beschrieben.

Im Backend arbeiten wir mit denselben Prinzipien. PHPStan, Psalm und Rector halten den Symfony Code sauber, Knip räumt im Frontend ungenutzten Code weg. Wer mit KI Agenten arbeitet, findet in den Vibe Coding Modellen die passende Auswahl, etwa OpenCode als offenen Coding Agent. Steckt ein Projekt fest, hilft Vibe Coding Projekt retten, und für Teams, die grundsätzlich umstellen wollen, gibt es das KI Training für Entwicklerteams.

CYPRESS.IO Ambassador und IT Consultant für QA Engenieering und Qualität in PHP Projekten.

Frontend 2025: 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.

Astro JS Frontend E-Mail Kontakt

Häufige Fragen zum satisfies Operator

Die Fragen, die in Trainings und Code Reviews immer wieder kommen, kurz und praxisnah beantwortet.

Was macht der satisfies Operator in TypeScript 2026?

satisfies prüft, ob ein Ausdruck zu einem Typ passt, und lässt den Typ des Ausdrucks dabei unverändert. Du bekommst also die Fehlerprüfung einer Typannotation, behältst aber die konkreten Literaltypen, die TypeScript selbst erkannt hat. Der Operator steht hinter dem Wert, nicht vor der Variable, und verschwindet im gebauten JavaScript vollständig.

Wann nutze ich 2026 satisfies statt einer Typannotation?

Immer dann, wenn du nach der Prüfung noch mit den genauen Werten arbeiten willst. Klassiker sind Routen, Feature Flags, Theme Tokens und Mappings von Varianten auf Komponenten. Die Annotation überschreibt den Typ und macht aus deinen drei Schlüsseln einen beliebigen string. satisfies lässt die Schlüssel stehen und du kannst sie per keyof typeof weiterverwenden.

Was ist 2026 der Unterschied zwischen satisfies und as?

as behauptet, satisfies prüft. Eine Type Assertion mit as schaltet die Prüfung an dieser Stelle ab und übernimmt deine Behauptung ungefragt. satisfies dagegen validiert den Ausdruck gegen den Typ und meldet Tippfehler, fehlende Schlüssel und falsche Werte. Wo im Code ein as steht, lohnt fast immer die Frage, ob satisfies nicht die ehrlichere Lösung wäre.

Ab welcher TypeScript Version gibt es satisfies 2026?

Der Operator kam mit TypeScript 4.9 und ist seitdem fester Bestandteil der Sprache. In allen aktuellen Versionen ist er ohne zusätzliche Konfiguration verfügbar, ein Compiler Flag brauchst du nicht. Wer noch auf einer älteren Version arbeitet, hat mit dem Upgrade ohnehin größere Baustellen als diesen einen Operator.

Hilft satisfies 2026 gegen Fehler in KI generiertem Code?

Ja, an einer sehr konkreten Stelle. KI Agenten schreiben Objektliterale gern freihändig und lösen aufkommende Typfehler mit as auf. Beides führt zu Code, der läuft und trotzdem falsch ist. Eine Regel in der AGENTS.md, die satisfies vorschreibt und as begründungspflichtig macht, entzieht dieser Fehlerklasse den Boden. Der Compiler wird damit zum ehrlichsten Feedback für den Agenten.

Kann ich satisfies mit as const kombinieren?

Ja, und die Kombination ist ausgesprochen nützlich. Die Reihenfolge ist dabei fest: erst as const, dann satisfies. as const friert die Werte auf ihre Literaltypen ein, satisfies prüft sie anschließend gegen deinen Zieltyp. So bekommst du unveränderliche Konfiguration, die trotzdem vollständig validiert ist.

Warum meldet TypeScript bei as const satisfies plötzlich einen Fehler?

Meistens liegt es an Arrays. as const macht aus einem Array ein readonly Tuple. Ein Zieltyp, der ein normales Array erwartet, akzeptiert das nicht mehr. Die Lösung ist kein Workaround, sondern eine Korrektur am Typ: Schreibe readonly string[] statt string[]. Damit sagst du auch aus, dass diese Werte nicht mutiert werden.

Ersetzt satisfies eine Validierung mit einer Schema Library?

Nein. satisfies ist reine Compile Time Prüfung und sieht nur, was im Code steht. Daten aus einer API, aus Formularen oder aus Environment Variablen entstehen erst zur Laufzeit. Dafür brauchst du echte Validierung an der Systemgrenze. Beides ergänzt sich: satisfies sichert deine Konfiguration im Repository, die Schema Prüfung sichert alles, was von außen hereinkommt.

Funktioniert satisfies auch mit Arrays und Funktionen?

Ja, der Operator arbeitet mit beliebigen Ausdrücken. Du kannst ein Array gegen einen Elementtyp prüfen und eine Funktion gegen eine Signatur. Der Nutzen ist derselbe wie bei Objekten: Die Prüfung greift, ohne dass der genaue Typ des Ausdrucks verloren geht. In der Praxis liegt der Schwerpunkt trotzdem klar bei Objektliteralen.

Kostet satisfies zur Laufzeit Performance?

Nein. Der Operator existiert nur im Typsystem und wird beim Kompilieren entfernt. Im ausgelieferten JavaScript ist keine Spur davon übrig, weder ein Funktionsaufruf noch eine Prüfung. Die einzigen Kosten entstehen beim Type Checking selbst und fallen bei normalen Projektgrößen nicht ins Gewicht.

Wie finde ich Stellen im Projekt, an denen satisfies fehlt?

Suche zuerst nach as im Code. Jede Type Assertion ist ein Kandidat. Danach schaust du in Konfigurationsdateien, Konstantendateien und Mappings, also überall dort, wo größere Objektliterale liegen. Ein Linter mit Type Awareness und ein Blick auf den gesamten Modulgraph helfen dabei, diese Stellen systematisch statt zufällig zu finden.

Gehört satisfies in die Coding Guidelines?

Aus unserer Sicht ja, und zwar als kurze, überprüfbare Regel. Objektliterale werden gegen ihren Zieltyp geprüft, as ist nur mit Begründung erlaubt, Schlüssel werden per keyof typeof abgeleitet statt doppelt gepflegt. Drei Zeilen, die in jedem Review sofort anwendbar sind und in Teams mit KI Agenten besonders viel Wirkung entfalten.