The satisfies Operator & Const Assertions

Two common problems when writing typed object literals: annotate them and you lose their exact inferred shape, don't annotate them and the compiler won't check they match what you meant. satisfies and as const solve both.

The problem with a plain annotation

type Setting = number | string;

const configAnnotated: Record<string, Setting> = {
  retries: 3,
  mode: 'dark',
};

configAnnotated.retries.toFixed(0); // ❌ retries is typed as `number | string`, not number

Annotating with Record<string, Setting> checks that every value is a valid Setting, but then widens every property to the whole union number | string, TypeScript forgets that retries specifically was a number.

satisfies keeps the precise type

const config = {
  retries: 3,
  mode: 'dark',
} satisfies Record<string, Setting>;

config.retries.toFixed(0); // ✅ retries is still known as number
config.mode.toUpperCase(); // ✅ mode is still known as string

satisfies checks the object against Record<string, Setting> the same way the annotation did, rejecting anything that doesn't fit, but it doesn't replace the object's own inferred type afterward. Each property keeps its own specific type.

const assertions

const directions = ['up', 'down', 'left', 'right'];
// inferred as string[], any string could be pushed in later

const fixedDirections = ['up', 'down', 'left', 'right'] as const;
// inferred as readonly ["up", "down", "left", "right"]

type Direction = typeof fixedDirections[number];
// 'up' | 'down' | 'left' | 'right'

as const tells the compiler "infer the narrowest possible type," a literal tuple of exact strings, marked readonly, instead of the general string[]. Combined with typeof ...[number], it's a common way to derive a union type from an array of values you already have, one list instead of a list plus a hand-written union that can drift apart.