Literal types and const assertions

"pending" here isn't just the value "pending" — it's also a type, one that only that exact string satisfies. This looks like a strange, overly-narrow thing to want on its own, but literal types become genuinely useful the moment several of them are combined into a union — "pending" | "confirmed" | "cancelled" is exactly how the union-types lesson expressed "one of these three specific strings," built entirely out of individual literal types.

This is the sharp edge nearly everyone hits first: TypeScript infers let status = "pending" as the general string type, not the literal "pending" — because let means the variable could be reassigned to any other string later, so TypeScript widens to the type that actually reflects what's really possible. const, by contrast, can never be reassigned, so TypeScript keeps the narrow literal type inferred from the single value it will ever hold.

This is the genuinely confusing case: config itself is a const, but the property status inside the object literal still widens to string — const only prevents reassigning config itself, it says nothing about the mutability of config's own properties, so TypeScript can't assume config.status will stay "pending" forever the same way it can for a bare const variable. This is exactly the situation as const (below) exists to fix properly, without reaching for a type assertion that silences the check instead of actually solving it.

as const tells TypeScript: "infer the narrowest possible type for this value, and treat every property as readonly." It's the direct, deliberate fix for exactly the object-literal-widening problem above — every property keeps its specific literal type instead of widening to the general type, and the whole structure becomes immutable at the type level (attempting config.status = "confirmed" afterward is a compile error, readonly is enforced).

This is one of the most common real uses of as const: define the actual list of valid values once, as data (useful for iterating over at runtime — rendering a dropdown, say), then derive a matching union type from that same array with typeof ROLES[number], instead of writing the union out separately and risking the two falling out of sync. Without as const, ROLES would widen to string[], and typeof ROLES[number] would just be string — losing all the specificity that made this worth doing.