as const, satisfies and type assertions

Widening

TypeScript infers the narrowest type it can keep true. A const string can never change, so it keeps its literal type; a let, or an object property, could be reassigned, so it widens:

const a = "GET";             // type "GET"
let b = "GET";               // type string
const req = { method: "GET" };   // { method: string }

That last one is why fetchWith(req) fails against a parameter typed { method: "GET" | "POST" }: string is wider than the union.

as const

as const tells the compiler to infer the narrowest type for the whole expression: every literal stays a literal, every property becomes readonly, and an array becomes a readonly tuple. From such an array you can derive a union type and keep a single source of truth for both the runtime list and the type:

1const ROLES = ["viewer", "editor", "admin"] as const;2 3// The element type of the tuple: "viewer" | "editor" | "admin".4type Role = (typeof ROLES)[number];5 6function isRole(value: string): value is Role {7  return (ROLES as readonly string[]).includes(value);8}9 10function describe(input: string): string {11  return isRole(input) ? `${input} is role #${ROLES.indexOf(input) + 1}` : `${input} is not a role`;12}13 14export function run(): string[] {15  return ["editor", "owner"].map(describe);16}

It is still a compile-time marker. The array is an ordinary, mutable JavaScript array at runtime.

satisfies

An annotation replaces the inferred type with the one you wrote. satisfies (TypeScript 4.9 and later) checks the value against a type and keeps the inferred one. The difference shows up as soon as you read the value back:

1type Route = `/${string}`;2 3// Annotated: the variable's type IS Record<string, Route>. The keys are forgotten.4const annotated: Record<string, Route> = {5  home: "/",6  profile: "/me",7};8 9// satisfies: checked against the same type, but the inferred type keeps its keys.10const checked = {11  home: "/",12  profile: "/me",13} satisfies Record<string, Route>;14 15export function run(): unknown[] {16  const typo = annotated.hoem;          // compiles: any string key is allowed17  // const typo2 = checked.hoem;        // tsc: Property 'hoem' does not exist18  return [String(typo), checked.profile, Object.keys(checked)];19}

With the annotation, the variable's type is Record<string, Route>, so annotated.hoem (a typo) compiles and is undefined at runtime. With satisfies, the compiler still checks every value is a Route, but the type keeps the exact keys, so checked.hoem is a compile error.

as, the assertion

value as T says "treat this as a T". The compiler refuses only an assertion between types that cannot overlap ("x" as number is an error); otherwise it allows it, and from then on it believes you. Nothing is converted and nothing is checked at runtime:

1interface Config {2  port: number;3  host: string;4}5 6export function run(): unknown[] {7  // as is a promise you make to the compiler. Nothing checks it.8  const fromEnv = JSON.parse('{"port":"8080"}') as Config;9  const empty = {} as Config;10 11  return [fromEnv.port + 1, typeof fromEnv.host, String(empty.port)];12}

x as unknown as T forces any assertion through, which is a sign the claim needs a runtime check instead.

Common mistakes

• Using as to "parse". JSON.parse(text) as Config is a promise, not validation: the port above is still the string "8080", and + 1 makes "80801".
• Annotating a config object with a wide type. Record<string, X> forgets which keys exist, so typos compile. Use satisfies to check the values and keep the keys.
• Mutating an as const array through a cast. It works at runtime; the readonly-ness was only in the type.
• Searching an as const tuple with a plain string. ROLES.indexOf(x) wants a Role; widen the array to readonly string[] for the search rather than asserting x as Role — and remember indexOf returns -1 for a miss.

What interviewers ask