TypeScript's satisfies Operator: Validate Your Configs Without Losing Their Types

You've written a config object—routes, feature flags, a color palette—and you want two things at once: the compiler should reject typos and wrong shapes, and downstream code should still know exactly which keys exist and what each literal value is. The frustrating truth is that a plain type annotation gives you the first and quietly destroys the second. The satisfies operator, added in TypeScript 4.9, gives you both.

The annotation that helps and hurts at the same time

Annotating a literal widens its inferred type to the annotation:

type Palette = Record<string, string | [number, number, number]>;

const palette: Palette = {
  primary: "#0d9488",
  danger: [220, 38, 38],
};

palette.primary.toUpperCase(); // Error: string | [number, number, number]

The annotation validated the object, but now palette.primary is typed as the union string | [number, number, number], so calling a string method on it fails. You also lose knowledge of which keys exist—palette.doesNotExist type-checks fine because a Record allows any string key. The usual escape hatch, as Palette, is worse: it silences the checker instead of consulting it, so a genuinely malformed object sails through.

What satisfies actually does

satisfies performs a real assignability check against a constraint type without changing the expression's inferred type. It emits no JavaScript—it's purely a compile-time instruction:

const palette = {
  primary: "#0d9488",
  danger: [220, 38, 38] as [number, number, number],
} satisfies Palette;

palette.primary.toUpperCase(); // OK: still inferred as string
palette.danger[0];             // OK: still inferred as a tuple
palette.nonexistent;           // Error: key doesn't exist

Now the compiler catches a missing or malformed entry at the definition site, yet every property keeps its narrow literal type downstream. Hover over palette in your editor and you'll see the exact object type, not Palette. Note the tuple needs as [number, number, number] (or as const) because a bare array literal infers as number[], which doesn't satisfy the tuple type—that's a real check working, not a bug.

The pattern worth adopting: as const satisfies

For route tables, design tokens, and feature flags, combine satisfies with as const to get deep readonly literal types plus validation:

type Route = { path: string; requiresAuth: boolean };

const routes = {
  home: { path: "/", requiresAuth: false },
  dashboard: { path: "/dashboard", requiresAuth: true },
} as const satisfies Record<string, Route>;

type RouteName = keyof typeof routes; // "home" | "dashboard"

Delete a required field or mistype requiresAuth as a string and tsc errors immediately. Meanwhile keyof typeof routes gives you an exact union of route names for free—no parallel enum or union type to keep in sync. This is the single highest-value use of the operator in most codebases: one source of truth that is both validated and fully introspectable at the type level.

Where the trade-offs bite

First, version requirements. You need TypeScript 4.9 or later—check with tsc --version in your project (run it via npx tsc --version so you get the project's compiler, not a global one). Older @typescript-eslint parser versions may also fail to parse the syntax even when the compiler is fine, so verify linting after upgrading. Second, satisfies checks assignability, not exact shape. Excess property checks still apply to the literal itself, but nested optional mismatches can produce errors that point at the constraint rather than your actual mistake, especially with wide constraints. Third—and most important—this is compile-time only. It says nothing about data arriving over the network or from a form. Keep a runtime schema validator (Zod, Valibot, JSON Schema) at system boundaries; satisfies is for literals you wrote yourself.

Try it in five minutes

Pick one hand-written config object in your codebase. Remove its type annotation, append satisfies with the same type, and run npx tsc --noEmit. Then deliberately break it—rename a required key—and confirm the error appears. Finally, hover a property in your editor and compare the inferred type to what the annotation gave you. If the narrow type survives and the broken version fails to compile, you've got the pattern right. You can also inspect the emitted JS to confirm the operator vanishes entirely—zero runtime cost, zero bundle impact.