TypeScript `satisfies` vs `as`: stop silencing the compiler

as isn’t a conversion

When developers write as, they often think they are converting a value. They are not.

as is a promise to the compiler: trust me, stop checking. Nothing changes at runtime. The only thing that changes is whether TypeScript is allowed to complain.

That is why this compiles:

const port = "3000" as number;

…and then fails the moment you treat port like a number.

The bug as hides

Assertions are especially dangerous in config objects, API payloads, and “temporary” escapes that stay forever.

type Config = { port: number };
 
// Compiles. Lies.
const bad = { port: "3000" } as Config;
 
// Errors at compile time, as it should
const good = { port: "3000" } satisfies Config;

satisfies validates the value against Config without forcing the value into a wider or incorrect shape.

as also erases what you know

Even when the assertion is “true enough,” it often widens or flattens the type you just carefully wrote, so you lose autocomplete and exact keys.

type Route = { path: string; auth: boolean };
 
const routesAs = {
  home: { path: "/", auth: false },
  admin: { path: "/admin", auth: true },
} as Record<string, Route>;
// routesAs.home.path is fine… but key autocomplete is gone
 
const routes = {
  home: { path: "/", auth: false },
  admin: { path: "/admin", auth: true },
} satisfies Record<string, Route>;
// Checked against Route *and* keeps exact keys: "home" | "admin"

That combination, validated + precise, is why satisfies belongs in most places teams currently reach for as.

A practical rule set

1. Default to inference, let TypeScript see the literal you wrote
2. Use satisfies when you want a value checked against a contract without widening
3. Use type guards / narrowing when runtime truth matters
4. Use as const for immutable literal collections
5. Use as last, only when you can prove something the checker cannot

Swap one keyword

- const config = { port: "3000" } as Config;
+ const config = { port: 3000 } satisfies Config;

You keep the exact type. You get real validation. You stop shipping “it type-checks, then it crashes.”

If your codebase is full of as, treat every occurrence as a smell until proven otherwise, especially in shared config and domain models.