{
“frontmatter”: {
“title”: “TypeScript satisfies: 3 Patterns That Fix What Type Annotations Break”,
“date”: “2026-05-28”,
“author”: “Nico Brandt”,
“category”: “tutorials”,
“slug”: “typescript-satisfies-operator-patterns”,
“description”: “Three production patterns where the TypeScript satisfies operator fixes what type annotations break: config objects, discriminated unions, and as const combos — with before/after code you’d actually ship.”,
“keywords”: [
“typescript satisfies operator”,
“typescript satisfies vs type annotation”,
“typescript satisfies examples 2026”,
“typescript type widening fix”,
“typescript satisfies const assertion”,
“typescript strict type patterns”
],
“meta_description”: “Three patterns where the TypeScript satisfies operator fixes what type annotations break: config objects, discriminated unions, and as const.”,
“og_title”: “Your Type Annotation Is Breaking Autocomplete. satisfies Fixes It.”,
“primary_keyword”: “typescript satisfies operator”,
“secondary_keywords”: [
“typescript satisfies vs type annotation”,
“typescript satisfies examples 2026”,
“typescript type widening fix”,
“typescript satisfies const assertion”,
“typescript strict type patterns”
],
“schema_type”: “Article”
},
“markdown”: “—\ntitle: "TypeScript satisfies: 3 Patterns That Fix What Type Annotations Break"\ndate: "2026-05-28"\nauthor: "Nico Brandt"\ncategory: "tutorials"\nslug: "typescript-satisfies-operator-patterns"\ndescription: "Three production patterns where the TypeScript satisfies operator fixes what type annotations break: config objects, discriminated unions, and as const combos — with before/after code you’d actually ship."\nkeywords: ["typescript satisfies operator", "typescript satisfies vs type annotation", "typescript satisfies examples 2026", "typescript type widening fix", "typescript satisfies const assertion", "typescript strict type patterns"]\nmeta_description: "Three patterns where the TypeScript satisfies operator fixes what type annotations break: config objects, discriminated unions, and as const."\nog_title: "Your Type Annotation Is Breaking Autocomplete. satisfies Fixes It."\nprimary_keyword: "typescript satisfies operator"\nsecondary_keywords: ["typescript satisfies vs type annotation", "typescript satisfies examples 2026", "typescript type widening fix", "typescript satisfies const assertion", "typescript strict type patterns"]\nschema_type: "Article"\n—\n\nYou annotated your config object with : Record<string, Handler>, and it compiled. That’s the problem.\n\nThe annotation didn’t check your object against the type. It replaced your object’s types with it. Every key just lost its specific value, and autocomplete went with it. You won’t notice until you reach for .method() on a value the compiler now swears doesn’t have one.\n\nYou already know what the TypeScript satisfies operator is. The real question is where it earns its place. Short version: use satisfies when you want TypeScript to validate an object against a broader type but keep the narrow inferred type for autocomplete and method calls — it fixes type widening in config objects, discriminated unions, and pairs with as const for immutable registries.\n\nThree patterns, before/after code you’d actually ship. Here’s the first thing to understand about why the annotation betrayed you.\n\n## Why Your Type Annotation Is Quietly Breaking Autocomplete\n\nA colon annotation is a command, not a check. When you write const config: SomeType = {...}, you’re telling TypeScript to treat the value as SomeType — full stop. The narrow type it inferred from your literal gets thrown away. You get the wide type back: string instead of \"GET\", the whole union instead of the one member you wrote.\n\nsatisfies runs the two steps in the opposite order. TypeScript infers the narrow type from your literal first, then checks that it conforms to the target. Validation without widening. Your object stays exactly as specific as you wrote it.\n\nThe difference is easiest to see in one line. This is the typescript satisfies vs type annotation split in miniature:\n\nts\n// Annotation: each value widens to string | number\nconst a: Record<string, string | number> = { id: 1, name: \"nico\" };\na.id; // string | number ← you lost the number\n\n// satisfies: validated, but each key keeps its real type\nconst b = { id: 1, name: \"nico\" } satisfies Record<string, string | number>;\nb.id; // number ← preserved\n\n\nThat’s the typescript type widening fix in nine characters. It looks academic until your object has keys that each need a different specific type — which is exactly what a config object is.\n\n## Pattern 1: Config Objects That Keep Their Specific Types\n\nEvery app has one: a map of routes, events, or commands where each key points at a handler. Type it the obvious way and watch the per-key information evaporate.\n\nHere’s the broken version. A typed event-handler map, annotated:\n\nts\ntype Handler = (payload: unknown) => void;\n\nconst handlers: Record<string, Handler> = {\n login: (p: { userId: string }) => log(p.userId),\n purchase: (p: { amount: number }) => charge(p.amount),\n};\n\n// payload is `unknown` everywhere — you've thrown away the real shapes\nhandlers.login; // (payload: unknown) => void\n\n\nThe annotation flattened every handler to (payload: unknown) => void. Autocomplete on the payload is gone. Worse, handlers.logn (typo) compiles fine, because Record<string, Handler> accepts any string key.\n\nNow the same object with satisfies:\n\nts\nconst handlers = {\n login: (p: { userId: string }) => log(p.userId),\n purchase: (p: { amount: number }) => charge(p.amount),\n} satisfies Record<string, Handler>;\n\nhandlers.login; // (p: { userId: string }) => void ← real type back\nhandlers.purchase; // (p: { amount: number }) => void\n\n\nTwo wins from one keyword. Each key keeps its specific handler signature, so handlers.login autocompletes userId. And because satisfies still validates against Record<string, Handler>, a handler that returns the wrong shape gets flagged at the definition site, not three files away.\n\nThe typo protection is the part people miss. Want a key typo caught too? Constrain the keys with a union — Record<\"login\" | \"purchase\", Handler> — and satisfies rejects any key outside it while still preserving each value’s type. That’s the move that makes these typescript satisfies examples 2026-grade instead of toy code.\n\nConfig keys are flat, though. Each value is independent. What happens when the entire shape of the value changes depending on one field?\n\n## Pattern 2: Discriminated Unions That Stay Narrowed\n\nThis is where annotations do real damage, and where almost no tutorial follows you. Take a standard discriminated union:\n\nts\ntype Shape =\n | { kind: \"circle\"; radius: number }\n | { kind: \"rect\"; width: number; height: number }\n | { kind: \"triangle\"; base: number; height: number };\n\n\nAnnotate a value with it, and TypeScript stops knowing which member you wrote:\n\nts\nconst c: Shape = { kind: \"circle\", radius: 10 };\nc.radius; // ok, but c is the FULL union now\n// reach for c.width and TS won't stop you mid-edit until you narrow again\n\n\nYou wrote a circle. The compiler sees Shape. Every access has to re-narrow through the kind check, and your editor can’t autocomplete radius without help. The specific variant — the thing you actually have — got widened to the union.\n\nSwap in satisfies:\n\nts\nconst c = { kind: \"circle\", radius: 10 } satisfies Shape;\nc.radius; // number — c is still the circle member\nc.kind; // \"circle\" — the discriminant stays literal\n\n\nNow c is the circle, validated as a legal Shape. The discriminant stays narrowed to \"circle\", which is what makes exhaustive checking actually work downstream:\n\nts\nfunction area(s: Shape) {\n switch (s.kind) {\n case \"circle\": return Math.PI * s.radius ** 2;\n case \"rect\": return s.width * s.height;\n case \"triangle\": return (s.base * s.height) / 2;\n default: {\n const _exhaustive: never = s; // add a 4th variant, this line errors\n return _exhaustive;\n }\n }\n}\n\n\nValidate the member, keep the variant. That combination is the whole reason these typescript strict type patterns hold up as a codebase grows. Add a \"square\" to Shape and the never line lights up red — the compiler routes you to every switch you forgot.\n\nThese patterns all share one limitation, though. Each time, you’re typing the object fresh and it’s still mutable. What if you want validation and immutability and literal types — all at once?\n\n## Pattern 3: as const satisfies for Immutable Registries\n\nThis is the combo that earns the operator a permanent spot in your toolbox. The order matters: as const runs first, freezing the value and inferring the narrowest possible literal types. Then satisfies Type checks that frozen, literal-typed value against a contract. Neither step widens the other.\n\nWatch what each tool gives you alone, and what the pair gives you together:\n\nts\ntype FlagConfig = { enabled: boolean; rollout: number };\n\n// Annotation alone: loses the literals, can't index by exact key\nconst a: Record<string, FlagConfig> = {\n newCheckout: { enabled: true, rollout: 0.5 },\n};\n\n// as const alone: literals, but NOTHING validates the shape\nconst b = {\n newCheckout: { enabled: true, rollout: 0.5 },\n} as const;\n\n// The combo: frozen literals AND a validated contract\nconst flags = {\n newCheckout: { enabled: true, rollout: 0.5 },\n betaDashboard: { enabled: false, rollout: 0 },\n} as const satisfies Record<string, FlagConfig>;\n\n\nWith flags, a typo in enabled or a rollout: \"half\" gets caught — that’s the satisfies half. And because of as const, the keys stay literal, which unlocks the payoff most people are actually after: deriving types straight from the data.\n\nts\ntype FlagName = keyof typeof flags;\n// \"newCheckout\" | \"betaDashboard\" — auto-derived, never drifts from the config\n\nfunction isEnabled(flag: FlagName) {\n return flags[flag].enabled; // indexed by exact key, fully type-safe\n}\n\n\nYour union type is now generated from your registry. Add a flag, the union updates itself. No second list to keep in sync. This typescript satisfies const assertion pattern is the one I reach for on anything that’s both a source of truth and immutable — feature flags, status maps, route tables, theme tokens.\n\nWhich raises the obvious question. If satisfies is this good, can you just put it on everything?\n\n## The One Mistake: satisfies on a Mutable Variable\n\nNo. And here’s the gotcha that’ll cost you a confusing debugging session if nobody warns you.\n\nsatisfies locks onto the initial value’s inferred type. Use it on a let you plan to reassign, and the inferred type can be too narrow for a later — perfectly valid — assignment:\n\nts\nlet shape = { kind: \"circle\", radius: 10 } satisfies Shape;\nshape = { kind: \"rect\", width: 4, height: 8 };\n// Error: 'rect' is not assignable to the inferred circle type\n\n\nYou wanted "any valid Shape." satisfies gave you "this specific circle, validated." That’s the right behavior for a config literal and the wrong behavior for a variable you mutate.\n\nThe rule is clean: use satisfies on const objects and config literals, not on variables you intend to reassign. If you need the wide type for reassignment, that’s the one place a plain annotation still earns its keep.\n\nSo: three patterns and one trap. Which do you actually reach for?\n\n## Which One Do You Reach For?\n\nThe rule fits on a sticky note. Use a type annotation when you want the wide type — when the broad type is the public contract a function signature promises. Use satisfies when you want that same validation but need to keep the narrow inferred type for autocomplete, indexing, and exhaustive checks. Reach for as only as an escape hatch, when you genuinely know more than the compiler and accept the risk.\n\nRemember the autocomplete the annotation quietly broke back at the top? satisfies is what hands it back. Same validation, none of the widening.\n\nIf you’re typing config objects or building a registry, default to satisfies. The moment that thing is immutable, upgrade to as const satisfies and let your union types derive themselves. That single habit removes a whole category of "why is this string instead of the literal I wrote" bugs from your week. If you’re still warming up to the language’s sharper edges, how to actually use TypeScript without hating it is the right next stop.\n”
}