The satisfies operator

The three tools on one value

When you find yourself choosing between type safety and type precision, pause — you may not have to choose. The question to ask is: do I need the target type to flow in and drive inference, or do I need a check from outside that leaves the inferred type intact?

Put the same object through each tool and watch what happens to its type.

type Routes = Record<string, `/${string}`>;

// 1) Annotation — validates, but WIDENS to the annotated type
const a: Routes = { home: "/", profile: "/u/:id" };
a.home;
// ^? `/${string}`   — lost the literal "/"; a.home is just "a path string"
// a.dashboard;      // no error — keys are Record<string, ...>, completeness not enforced

// 2) as — keeps a type you assert, but does NO real check
const b = { home: "/", dashboard: "oops" } as Routes;
//                     ^^^^^^^^ typo + invalid path, but `as` silences it
b.home;
// ^? `/${string}`   — also widened, and the bug slipped through

// 3) satisfies — validates AND keeps the precise inferred type
const c = { home: "/", profile: "/u/:id" } satisfies Routes;
c.home;
// ^? "/"            — exact literal preserved
c.profile;
// ^? "/u/:id"
// const d = { home: "x" } satisfies Routes;
// Error: Type 'string' is not assignable to type `/${string}` — invalid path caught

The annotation widens: the variable’s type becomes Routes, so a.home forgets it was "/". The cast lies: as performs an assignability check in one direction only and suppresses excess-property and value errors — dashboard: "oops" sails through. satisfies validates without widening: the value is checked against Routes, but the variable keeps its inferred type { home: "/"; profile: "/u/:id" }, so each literal survives.

Both completeness checking and precise per-key types

The canonical win is a record where you want the key set checked and the per-key value types kept precise. Use a constraint type to enforce shape, and satisfies to keep the inference:

type Color = "red" | "green" | "blue";

const palette = {
  red: [255, 0, 0],
  green: [0, 255, 0],
  blue: [0, 0, 255],
} satisfies Record<Color, [number, number, number]>;

// Completeness: drop a key and you get an error
// const p2 = { red: [255,0,0], green: [0,255,0] } satisfies Record<Color, [number,number,number]>;
// Error: Property 'blue' is missing.

palette.red;
// ^? [number, number, number]   — kept as a tuple, not number[]
palette.red[0].toFixed(2);
// ok — element is `number`, available because the tuple type survived
const keys = Object.keys(palette);
// the value still has exact keys, so downstream code can rely on them

With a plain annotation const palette: Record<Color, ...>, palette.red would be widened and you’d lose the tuple-vs-array precision and the exact key set. satisfies keeps both: the constraint validates completeness and value shape; the inferred type keeps the literals and tuples.

The trap: satisfies does not provide a contextual type

The one place satisfies cannot replace an annotation is contextual typing. An annotation on a variable flows its type inward to give un-annotated function parameters their types. satisfies only checks outward after the value is already inferred, so it does not seed parameters.

type Handlers = { onClick: (e: MouseEvent) => void };

// Annotation: the type flows in, so `e` is contextually typed
const h1: Handlers = {
  onClick: (e) => { e.clientX; },   // e: MouseEvent — inferred from the annotation
};

// satisfies: checked AFTER inference, so `e` gets no contextual type
const h2 = {
  onClick: (e) => { e.clientX; },
  //         ^ Error: Parameter 'e' implicitly has an 'any' type.
} satisfies Handlers;

In h2, the arrow’s parameter e is inferred before satisfies runs its check, so there is nothing to contextually type it — under noImplicitAny it’s an error; you must annotate e: MouseEvent yourself. The rule: reach for an annotation when you need the target type to drive inference of callback parameters; reach for satisfies when you want to validate a value while preserving its precise inferred type. They are complementary, not interchangeable.