In TypeScript, given `let value: string | number = 'a';`, what type does the compiler see for `value` on the next line, what happens if you later write `value = 42`, and what happens if you write `value = true`?

## Two types, not one A TypeScript variable carries two distinct types, and most confusion about narrowing comes from conflating them. - The **declared type** is what the annotation says, or what inference produced at the declaration. It is fixed for the variable's whole life and it is the type every assignment is checked against. - The **narrowed type** is what control-flow analysis believes the variable holds *at one specific point in the code*. It is always the declared type or a subset of it, and it is recomputed for every reference. ```ts let value: string | number = "a"; // declared type: string | number (forever) // narrowed type here: string value.toUpperCase(); // OK — reads use the narrowed type ``` ## Assignment is a narrowing operation An `if (typeof value === "string")` check is not the only thing that narrows. A plain assignment narrows too: after `value = expr`, the compiler narrows the variable to the type of `expr`, intersected with what the declared type permits. ```ts let value: string | number = "a"; value.toUpperCase(); // value: string value = 42; value.toFixed(2); // value: number // value.toUpperCase(); // Error: Property 'toUpperCase' does not exist on type 'number'. ``` The second assignment does not *add* `number` to what the variable might be; it **replaces** the narrowing. Narrowing is a property of a program point, not an accumulating fact about the variable. ## The declared type is the ceiling Assignability is checked against the declared type, always: ```ts let value: string | number = "a"; value = 42; // OK — number is in the declared type // value = true; // Error: Type 'boolean' is not assignable to type 'string | number'. ``` This holds in both directions, which is the part candidates miss. Narrowing to `string` does not *forbid* assigning a number later — the narrowing is not a constraint on writes. And holding a number right now does not *permit* assigning a boolean — the ceiling never moves. A useful consequence: assignment narrowing can make an awkward parameter usable in place. ```ts function normalise(input: string | string[]): string[] { if (typeof input === "string") { input = input.split(","); // narrows input to string[] here } return input; // string[] on both paths } ``` The `then` branch assigns a `string[]`, narrowing `input` to `string[]`; the implicit `else` path already had `string[]`. Where the two paths meet, the compiler unions the narrowed types — `string[] | string[]`, i.e. `string[]` — so the `return` type-checks without a cast. ## When there is no annotation With no annotation, the declared type is the *widened* type of the initializer: ```ts let mode = "fast"; // declared type: string // mode = 3; // Error: Type 'number' is not assignable to type 'string'. ``` So omitting the annotation does not give you a variable that accepts anything — it gives you a ceiling you did not choose. If the variable is meant to hold either shape, say so: `let mode: string | number = "fast"`. ## Reading versus writing The cleanest way to hold the rule: - **Reads** use the narrowed type. That is why `value.toFixed(2)` compiles right after `value = 42`. - **Writes** are checked against the declared type. That is why `value = "a"` is still legal after the variable has become a number. ```ts let value: string | number = 42; value = "back to a string"; // fine — write checked against the ceiling value.toUpperCase(); // fine — read uses the new narrowing ``` ## Why this design The declared type is the contract you wrote; narrowing is an inference the compiler makes *within* that contract to spare you redundant checks. Letting an assignment move the ceiling would mean a variable's contract changes silently as code is edited elsewhere in the function, and every reader would have to simulate the whole body to know what it may hold. Fixing the ceiling keeps the annotation meaningful and localises narrowing to a single flow path. All of this is compile-time only. The emitted JavaScript contains no annotation, no check and no narrowing — a variable at runtime simply holds whatever was last assigned.