In TypeScript, what is the difference between writing `as const` on an object literal and writing `satisfies SomeType` after it, and when would you use both together?

## Three ways to attach a type to a literal Take a routes table and compare what each form gives you. Assume TypeScript 4.9 or later, which is when the `satisfies` operator became available. ```ts type Route = { path: string; auth: boolean }; // A. annotation const a: Record<string, Route> = { home: { path: '/', auth: false } }; // B. const assertion const b = { home: { path: '/', auth: false } } as const; // C. satisfies const c = { home: { path: '/', auth: false } } satisfies Record<string, Route>; ``` **A — the annotation validates and then flattens.** The compiler checks the literal against `Record<string, Route>`, and from then on `a` *is* that type. `a.home` is `Route`, `a.home.path` is `string`, and `keyof typeof a` is just `string` — you have lost the fact that the only key is `home`. Any typo in a key name is also accepted, because the index signature admits every string. **B — the assertion pins and validates nothing.** `b.home.path` is the literal `"/"`, `keyof typeof b` is `"home"`, and everything is `readonly`. But nothing checked that the entries look like a `Route`; misspell `auth` as `athu` and it compiles happily. **C — `satisfies` validates without flattening.** The expression is checked for assignability to `Record<string, Route>` — a missing or misspelled property is an error, and excess-property checking applies to the fresh object literal — yet `c` keeps its inferred type. `keyof typeof c` is still `"home"`. The values are not `readonly` and are still widened (`c.home.path` is `string`), because `satisfies` does not touch widening. ## Combining them The two are orthogonal, which is why they compose: ```ts const routes = { home: { path: '/', auth: false }, admin: { path: '/admin', auth: true }, } as const satisfies Record<string, Route>; type RouteName = keyof typeof routes; // "home" | "admin" const p: '/admin' = routes.admin.path; // literal preserved ``` Now a missing `auth` is a compile error *and* the exact key names and path strings survive for downstream derivation. This is the workhorse form for configuration tables. One subtlety worth understanding: assigning a value whose properties are `readonly` to a target type whose properties are mutable is allowed — TypeScript deliberately ignores `readonly` modifiers when checking property assignability. That is why `as const satisfies Record<string, Route>` passes even though `Route`'s members are not declared `readonly`. ## Choosing between them - **Only `as const`** — a fixed list or tuple whose shape is self-evident and whose exact values you will derive from. A list of allowed option strings, a coordinate pair, an action-type table. - **Only `satisfies`** — you want a contract enforced but the value is genuinely mutable, or the extra precision buys you nothing. Also useful to catch typos in keys of a table that is otherwise open. - **Both** — a constants table that must obey a shape *and* whose keys/values feed derived types. - **Plain annotation** — the flattened type is what you actually want to expose, for instance a public value whose precise contents should not leak into consumers' types. ## Common misconceptions `satisfies` is not a cast. `as T` asserts, suppressing checks and shifting the type by force; `satisfies T` only checks and never changes the type. If the expression is not assignable to `T`, `satisfies` errors where `as` would have silently accepted a wrong assertion. `satisfies` also does not make anything `readonly`, and `as const` does not make anything type-checked. Candidates who describe them as "two ways to type a constant" have missed that each covers exactly the gap the other leaves. ## What is emitted Neither survives compilation. Both are type-layer constructs and are erased, so the runtime value is the plain object literal in all three forms above. The choice affects what the checker knows and what your editor shows — nothing else.