const Assertions (as const)

## Why the default is `string[]` When TypeScript infers a type it has to guess how the value will be used. An array literal is a mutable container: you can `push` into it and assign to its indices later. So the compiler *widens* the fresh literal types of the elements to their base types and infers a general array type. ```ts const roles = ['admin', 'user']; // roles: string[] roles.push('guest'); // fine — nothing in the type says otherwise ``` Note that the `const` keyword on the declaration does not help here. `const` pins the *binding* — you cannot reassign `roles` to a different array — but it says nothing about the array's contents, so the contents are still inferred as mutable and widened. The same applies to object literals: ```ts const cfg = { retries: 3 }; // cfg: { retries: number } cfg.retries = 5; // allowed ``` ## What the const assertion changes `as const` is a **const assertion**. Applied to a literal expression, it turns off widening for that whole expression and marks everything it produces as read-only. Three effects, all at once: 1. **Literal types are preserved.** `'admin'` stays `"admin"` instead of becoming `string`; `3` stays `3` instead of becoming `number`; `true` stays `true` instead of `boolean`. 2. **Every property becomes `readonly`.** The checker will reject `cfg.retries = 5`. 3. **Array literals become readonly tuples.** Length and per-position types are fixed. ```ts const roles = ['admin', 'user'] as const; // roles: readonly ["admin", "user"] const cfg = { retries: 3, verbose: true } as const; // cfg: { readonly retries: 3; readonly verbose: true } ``` ## Tuple, not array — why that matters This is the part people miss. `readonly ["admin", "user"]` is a *tuple type*: the compiler knows there are exactly two elements and what each position holds. ```ts const roles = ['admin', 'user'] as const; const first: 'admin' = roles[0]; // index 0 is the literal "admin", not string const n: 2 = roles.length; // length is the literal type 2 ``` Without the assertion, `roles[0]` is `string` and `roles.length` is `number`. That precision is what lets a const-asserted array feed places that demand exact values — argument positions typed as a union of literals, keys of a mapped shape, or a derived union of element types. ## It applies recursively The assertion is not shallow: nested object and array literals inside the asserted expression get the same treatment. ```ts const routes = { home: { path: '/', tags: ['public'] }, } as const; // routes.home.path is "/", routes.home.tags is readonly ["public"] ``` ## Where you are allowed to write it A const assertion may only be applied to a literal expression — a string, number, boolean, array or object literal — or to a reference to an enum member. You cannot write `getRoles() as const` on a function call's result; the compiler rejects it, because there is no literal expression there whose inference it could pin. If you need literal types out of a call, apply the assertion to the literal you pass *in*, or design the function to preserve them. Also worth knowing: a const assertion is an assertion, not a cast that changes the value. It never converts anything and never produces a different runtime object. ## Purely compile-time TypeScript's types are erased. The emitted JavaScript for `const roles = ['admin', 'user'] as const;` is just `const roles = ['admin', 'user'];`. There is no freeze, no proxy, no runtime check and no cost. `readonly` is a promise the checker enforces on code it can see — it is not a runtime guarantee. ## When to reach for it Use `as const` when the *exact values* are part of the meaning: configuration tables, sets of allowed option strings, action-type maps, fixed coordinate or key tuples, and any literal you want to pin so a union can be derived from it later. Skip it when the value is genuinely data that will be mutated or reassigned — you will only fight the `readonly` modifiers for no benefit.