With `noImplicitAny` enabled, why does the TypeScript declaration `let value;` compile without an implicit-any error, and what type does `value` have after `value = 1;`?

## The exception to noImplicitAny `noImplicitAny` reports an error whenever the compiler would silently fall back to `any` because it cannot infer anything better. A variable with no annotation and no initializer looks like exactly that case, yet it compiles: ```ts let value; // no error, even with noImplicitAny value = 1; value.toFixed(2); // OK — value is number here ``` The reason is that the compiler is not falling back. Instead of fixing the type at the declaration, it gives the variable an **evolving** type: the type at any reference is computed from the assignments that flow into that reference. The variable's type is a function of position, exactly like a narrowed union. ## How the evolution works ```ts let value; // value: undefined here — nothing assigned yet value = "text"; value.toUpperCase(); // string value = 1; value.toFixed(2); // number // value.toUpperCase(); // Error: Property 'toUpperCase' does not exist on type 'number'. ``` At a join point the incoming types are unioned, as with any other flow analysis: ```ts let value; if (flag) { value = "text"; } else { value = 1; } value; // string | number ``` The same treatment applies when the initializer carries no information: ```ts let a = null; // evolving let b = undefined; // evolving ``` and to empty array literals, whose element type grows from the operations performed on them: ```ts const items = []; // evolving array items.push(1); items.push("two"); items; // (string | number)[] ``` ## What ends the evolution **Any annotation.** The moment you write a type, the variable has a declared type and behaves like every other variable — a fixed ceiling with narrowing inside it: ```ts let value: any; // plain any, no evolution, no checking value = 1; value.nonsense(); // no error — any silences everything ``` That is the point worth internalising: `let value;` is *safer* than `let value: any;`, because the untyped form still tracks what was assigned while the annotated form disables checking entirely. **Reading before assignment.** Using the variable on a path where nothing has reached it is an error rather than a silent `any`: ```ts let value; if (flag) value = 1; // value.toFixed(2); // Error — on the other path nothing was assigned ``` ## Why you should still usually annotate The feature exists to make untyped code and gradual migrations behave sensibly, not as a style to adopt. Relying on it has real costs: - The variable's contract is invisible. A reader must trace every assignment in the function to learn what it may hold, which is exactly the work an annotation removes. - Nothing constrains future assignments. Because there is no declared ceiling, a later `value = someUnrelatedThing` is accepted and simply changes the type from that point on — no error tells you the variable's purpose drifted. - It only works for straight-line, single-function flow. Once the variable is used in a position the analysis cannot follow, you are back to a loose type with no annotation to fall back on. The idiomatic form for a value assigned in branches is a declared union plus terminating guards, or a `const` initialised from a conditional expression: ```ts const value = flag ? "text" : 1; // string | number, immutable, obvious ``` ## The interview point The question is really testing whether you know that `noImplicitAny` is about *inference failure*, not about the absence of annotations, and that `any` and "no annotation" are different things in TypeScript. A candidate who answers "it's an error, that's what the flag is for" has the wrong model of what the flag detects.