The `satisfies` Operator (Why It’s a Big Deal)

30‑second interview answer

satisfies lets you check that a value conforms to a type without changing the value’s inferred type. It’s perfect for config objects: you get shape validation plus you keep literal types for autocomplete and safety.

The problem

If you annotate, you can lose literal types:

type Route = { path: string; auth: boolean };
 
const routes: Route[] = [
  { path: '/login', auth: false },
  { path: '/dashboard', auth: true },
];

Now path is just string.

The satisfies solution

type Route = { path: string; auth: boolean };
 
const routes = [
  { path: '/login', auth: false },
  { path: '/dashboard', auth: true },
] satisfies Route[];

Now TS validates shape, but keeps literal types like '/login'.

Why it beats as const sometimes

as const makes everything readonly and literal:

const x = { mode: 'prod' } as const;

satisfies keeps inference more flexible while still validating.

Common interview traps

• Confusing satisfies with type assertions.
• Using as to silence errors (dangerous).

Mini Q&A

Q1: Does satisfies change runtime value?

• No.

Q2: Why use satisfies instead of annotation?

• Keeps literal inference.

Q3: Is it like as?

• No. as can lie; satisfies validates.

Summary checklist

• I can explain the benefit: validation + literal types.
• I can use it for configs.
• I avoid using as to silence errors.