{"id":294,"date":"2026-05-30T13:02:40","date_gmt":"2026-05-30T13:02:40","guid":{"rendered":"https:\/\/abrarqasim.com\/blog\/typescript-satisfies-when-i-stopped-reaching-for-as\/"},"modified":"2026-05-30T13:02:40","modified_gmt":"2026-05-30T13:02:40","slug":"typescript-satisfies-when-i-stopped-reaching-for-as","status":"publish","type":"post","link":"https:\/\/abrarqasim.com\/blog\/typescript-satisfies-when-i-stopped-reaching-for-as\/","title":{"rendered":"TypeScript satisfies: When I Stopped Reaching for as"},"content":{"rendered":"

Short version for the impatient: satisfies<\/code> is the TypeScript keyword I now reach for whenever I want the compiler to check that a value matches a type, without throwing away what the compiler already knows about that value. If you’ve ever typed as SomeType<\/code> and then sighed because you knew you were lying to the compiler a little, this is for you.<\/p>\n

I was reviewing a pull request from someone on my team last week and saw three as Foo<\/code> casts on a config object. The author wasn’t wrong, exactly, but every one of those casts was a tiny bit of trust the compiler was being asked to give up. I left a single comment that just said try satisfies<\/code>. The diff that came back was shorter, safer, and the IDE got smarter about autocomplete inside the object. That’s the post.<\/p>\n

Why as<\/code> always made me a little nervous<\/h2>\n

I’ll start with my honest opinion of as<\/code>. It’s a hammer. It tells the compiler “trust me, I know what this is.” It works. It’s also been the cause of approximately every prod incident I’ve shipped that wasn’t a missing await.<\/p>\n

The usual pattern looks like this:<\/p>\n

type Theme = {\n  light: { bg: string; fg: string };\n  dark: { bg: string; fg: string };\n};\n\nconst theme = {\n  light: { bg: "#fff", fg: "#111" },\n  dark:  { bg: "#0b0b0b", fg: "#eaeaea" },\n} as Theme;\n<\/code><\/pre>\n
This compiles. It also silently allows you to write dark: { bg: \"#0b0b0b\" }<\/code> (missing fg<\/code>) and never hear about it, because as<\/code> widens the assertion. The compiler doesn’t check that your literal actually fits the type. It just nods and walks away.<\/p>\n
The other usual fix is a type annotation:<\/p>\n
const theme: Theme = {\n  light: { bg: "#fff", fg: "#111" },\n  dark:  { bg: "#0b0b0b", fg: "#eaeaea" },\n};\n<\/code><\/pre>\n
Now the compiler will yell if fg<\/code> is missing. But you’ve also told it the type is Theme<\/code>, which means theme.light.bg<\/code> is just string<\/code>, not the literal \"#fff\"<\/code>. If you wanted to derive a union of allowed background colours from this object, you’ve lost that info. Annoying.<\/p>\n
What satisfies<\/code> actually does<\/h2>\n
satisfies<\/code>, introduced in TypeScript 4.9<\/a>, splits those two jobs apart. It checks that the value fits the type. It does not change the inferred type of the value.<\/p>\n
const theme = {\n  light: { bg: "#fff", fg: "#111" },\n  dark:  { bg: "#0b0b0b", fg: "#eaeaea" },\n} satisfies Theme;\n\n\/\/ theme.light.bg is now "#fff", not string\n\/\/ missing fg in dark is now a compile error\n<\/code><\/pre>\n
That’s the whole feature. Read it twice, because it took me a couple of months to internalise that those are different things.<\/p>\n
The TypeScript handbook page on satisfies<\/code><\/a> has the canonical example with palettes and hex codes. It’s fine. But the version that finally got it into my head was config objects, which is what I’ll use here.<\/p>\n
Where it earns its keep in my codebase<\/h2>\n
I now use satisfies<\/code> in three places without thinking, and I want to walk through them quickly because nobody else writes about these as a group.<\/p>\n
Route or feature maps<\/h3>\n
A Next.js app I worked on had a routes map that looked like this:<\/p>\n
const routes = {\n  home: "\/",\n  blog: "\/blog",\n  post: (slug: string) => `\/blog\/${slug}`,\n} as const;\n<\/code><\/pre>\n
This was fine until someone wanted a type that said “the name of any route”. With a Record<string, ...><\/code> annotation we’d have lost the literal keys. With as Record<...><\/code> we’d have lost the function signatures. With satisfies<\/code>, both are preserved:<\/p>\n
type RouteValue = string | ((...args: never[]) => string);\n\nconst routes = {\n  home: "\/",\n  blog: "\/blog",\n  post: (slug: string) => `\/blog\/${slug}`,\n} as const satisfies Record<string, RouteValue>;\n\ntype RouteName = keyof typeof routes; \/\/ "home" | "blog" | "post"\n<\/code><\/pre>\n
Now RouteName<\/code> is the actual union of keys, the function is still callable with (slug: string)<\/code> and not (...args: never[])<\/code>, and the compiler will yell if I add a value that isn’t a string or a function returning a string. That’s three useful things from one keyword.<\/p>\n
API response shape guards in tests<\/h3>\n
When I write a fixture for an API test, I want the fixture to be the real shape of the response, and I want the compiler to scream if the real type changes. satisfies<\/code> makes the fixture self-checking:<\/p>\n
import type { GetUserResponse } from ".\/api-types";\n\nexport const fakeUser = {\n  id: "usr_123",\n  email: "abrar@example.com",\n  roles: ["admin", "editor"],\n} satisfies GetUserResponse;\n<\/code><\/pre>\n
If I later add a required createdAt<\/code> to GetUserResponse<\/code>, the fixture breaks at compile time, not three months later in a flake. I’ve shipped at least two bugs because a test fixture was cast with as<\/code> and silently went out of date. Never again, hopefully.<\/p>\n
Discriminated unions that look obvious but aren’t<\/h3>\n
This one is mine. I had a state object like { status: \"loading\" } | { status: \"ready\", data: T }<\/code>. When I built the initial value, I’d often write as const<\/code> and call it a day. The problem is as const<\/code> doesn’t check anything, it just narrows. So you can produce an initial value that doesn’t fit your union and TypeScript will happily generate a tighter literal type that conflicts with what you actually expect.<\/p>\n
type State = { status: "loading" } | { status: "ready"; data: User };\n\nconst initial = { status: "loading" } as const satisfies State;\n<\/code><\/pre>\n
The as const<\/code> keeps status<\/code> as the literal \"loading\"<\/code>. The satisfies State<\/code> makes sure I haven’t accidentally written something the union doesn’t allow. The two-keyword combo (as const satisfies<\/code>) is now muscle memory for me on every reducer file.<\/p>\n
Where I still don’t bother<\/h2>\n
There are two cases where satisfies<\/code> is overkill and I just don’t use it.<\/p>\n
The first is single-use literals inside function arguments. If I’m calling setOptions({ retries: 3 })<\/code> once, the inline literal already gets contextually typed against the parameter. Adding satisfies<\/code> here is noise.<\/p>\n
The second is when I genuinely need to coerce a value across a type boundary the compiler can’t reason about, usually around external library types or JSON.parse<\/code>. That’s still an as<\/code> cast, and I’d rather have one obvious lie than a satisfies<\/code> that gives me a false sense of safety. I cover that style of “defensive cast” pattern more in my notes on TypeScript generics in production<\/a>.<\/p>\n
A small pitfall I hit twice<\/h2>\n
satisfies<\/code> checks the value against the type, not the other way around. So if your value has extra<\/em> properties, the compiler will complain about excess property checks when you’d rather it didn’t. For library config objects that accept extra forward-compatible keys, you sometimes still want a regular annotation. I keep a \/\/ keep the annotation here, satisfies is too strict<\/code> comment in two spots for this exact reason.<\/p>\n
Also, please don’t go around the codebase replacing every :<\/code> with satisfies<\/code>. The vast majority of typed variables in a normal app are fine with a plain annotation. satisfies<\/code> shines when you care about preserving the exact<\/em> value type, which is mostly true for constants, fixtures, and config maps.<\/p>\n
What I’d do this week<\/h2>\n
If you’re on TypeScript 4.9 or newer, grep your codebase for as<\/code> outside of test files and JSX. Look for the patterns I described, config objects, route maps, fixtures, initial state, and try satisfies<\/code> instead. You’ll probably delete a few quiet casts and gain better autocomplete in the process.<\/p>\n
If you write a lot of typed configs and want a second pair of eyes on a real codebase, that’s the kind of work I take on as a freelancer; you can see some recent client work here<\/a>. And if satisfies<\/code> finally makes a tricky union click for you, I’d love to hear which one.<\/p>\n","protected":false},"excerpt":{"rendered":"
How I actually use TypeScript’s satisfies operator in real code, where it beats type annotations and as casts, and the two places I still don’t bother.<\/p>\n","protected":false},"author":2,"featured_media":293,"comment_status":"","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"rank_math_title":"","rank_math_description":"How I actually use TypeScript's satisfies operator in real code, where it beats type annotations and as casts, and the two places I still don't bother.","rank_math_focus_keyword":"typescript satisfies","rank_math_canonical_url":"","rank_math_robots":"","footnotes":""},"categories":[156],"tags":[98,38,63],"class_list":["post-294","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-typescript","tag-developer-tools","tag-frontend","tag-typescript"],"_links":{"self":[{"href":"https:\/\/abrarqasim.com\/blog\/wp-json\/wp\/v2\/posts\/294","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/abrarqasim.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/abrarqasim.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/abrarqasim.com\/blog\/wp-json\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/abrarqasim.com\/blog\/wp-json\/wp\/v2\/comments?post=294"}],"version-history":[{"count":0,"href":"https:\/\/abrarqasim.com\/blog\/wp-json\/wp\/v2\/posts\/294\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/abrarqasim.com\/blog\/wp-json\/wp\/v2\/media\/293"}],"wp:attachment":[{"href":"https:\/\/abrarqasim.com\/blog\/wp-json\/wp\/v2\/media?parent=294"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/abrarqasim.com\/blog\/wp-json\/wp\/v2\/categories?post=294"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/abrarqasim.com\/blog\/wp-json\/wp\/v2\/tags?post=294"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}