In TypeScript, what type does the compiler infer for `const n = 42` compared with `let n = 42`, and why do the two differ?

## What the checker infers When you declare a variable with an initializer and no annotation, TypeScript infers a type from the initializer. For primitives the answer depends on the *declaration form*: ```ts const a = 42; // a: 42 let b = 42; // b: number const c = "ready"; // c: "ready" let d = "ready"; // d: string const e = true; // e: true let f = true; // f: boolean ``` Hover any of these in an editor and that is what you see. Nothing about the *value* differs between the pairs; only the declaration keyword does. ## Why mutability decides it A type is a promise about every value the variable can ever hold. `const` binds a primitive once and forever, so the most precise possible description of it — the exact value — is also a correct one, and precision is free. There is no future assignment that could violate it. `let` has no such guarantee. If the compiler inferred `42` for `let b = 42`, then `b = 43` would be an error, and the declaration would be almost useless. So the compiler applies **widening**: it takes the precise inferred type and replaces it with the general primitive type it belongs to — `number`, `string`, `boolean`, `bigint`, `symbol` — which is what you almost always meant when you wrote a mutable variable. The same widening happens anywhere the value can be reassigned or mutated later, which is why a mutable variable initialised from a `const` still ends up wide: ```ts const a = 42; // 42 let g = a; // number — g is mutable, so the narrow type is widened again ``` ## An annotation always wins Inference only runs when you have not said what you want. An explicit annotation overrides it in either direction: ```ts const wide: number = 42; // number, on purpose let narrow: 42 = 42; // stays 42; narrow = 43 is an error ``` That is the practical control you have. If you need a `const` to be treated as the general primitive — say, because you will pass it somewhere that infers from it and you do not want the precision to propagate — annotate it. If you need a mutable variable pinned to a specific value, annotate that too, and accept that every reassignment must match. ## Where the difference actually bites Most of the time you never notice, because the narrow type is a *subtype* of the primitive: a value of type `42` goes anywhere a `number` is accepted, and `"ready"` goes anywhere a `string` is accepted. The precision is a bonus, not a restriction. It starts to matter when the type is *carried somewhere* — passed to a function that infers from its argument, used to initialise a property, or compared against a fixed set of allowed values. There, a `const` gives the checker exact information and a `let` hands it only "some string". That is the reason the reflex "declare with `const` unless you truly reassign" pays off in TypeScript beyond its usual JavaScript benefits: you keep information the checker can use. The reverse case is worth knowing too. A mutable variable that starts at one value and later holds something else needs an annotation up front, because the initializer alone cannot describe the whole story: ```ts let count = 0; // number — fine, later counts are numbers too let total: number | null = null; // annotate: the initializer alone says only 'null' ``` ## None of it exists at runtime Both the inferred type and the annotation are erased. `const a = 42` and `const a: number = 42` emit the identical JavaScript, and there is no runtime cost or check attached to either. The difference is entirely about what the checker will let you write next — which is the whole point of the type layer, and also why the distinction is invisible until an error message tells you about it. ## The short version `const` keeps the precise inferred type because it cannot change; `let` widens to the primitive because it can. An explicit annotation overrides whichever default you did not want, and nothing about the choice reaches the emitted JavaScript.