In TypeScript, what types are inferred for `const mixed = [1, 'a']` and `const tags = ['a', 'b']`, and why is `tags` not inferred as `('a' | 'b')[]`?

## The rule in one line Given an array literal with no contextual type, TypeScript infers `E[]` where `E` is the union of the inferred types of the elements, after each element's literal type has been widened. ```typescript const ids = [1, 2, 3]; // number[] const mixed = [1, 'a']; // (string | number)[] const tags = ['a', 'b']; // string[] const flags = [true]; // boolean[] ``` Two separate mechanisms are at work — union formation and widening — and interviews probe both. ## Union of element types, not a tuple A plain array literal produces an array type, never a tuple type. Length and per-position types are discarded: `[1, 'a']` and `['a', 1]` both infer `(string | number)[]`. That is deliberate. Arrays are mutable and resizable, so a type that pinned index 0 to `number` would be falsified by the very first `push` or reassignment. If you need positional types, you ask for them explicitly — either with an annotation or a `const` assertion — rather than getting them from a bare literal. When the elements share a common supertype the union is still a union of the specific types, not the supertype: ```typescript class Dog { bark() {} } class Cat { meow() {} } const pets = [new Dog(), new Cat()]; // (Dog | Cat)[] ``` This matters because the union preserves what each element can actually do, at the cost of requiring a narrowing check before you call either method. ## Widening: why the literal types disappear A string literal like `'a'` has, momentarily, the literal type `'a'`. Whether that survives depends on where it lands. In a mutable location — a `let` binding, an object property, an array element — the compiler widens it to the base primitive type, because the location can be written to again later: ```typescript let single = 'a'; // string, not 'a' const single2 = 'a'; // 'a' — an immutable binding keeps the literal type const tags = ['a', 'b']; // string[] — the elements are mutable slots ``` Note the asymmetry in the third line: `tags` is a `const` binding, but `const` only freezes the binding, not the array's contents. `tags.push('c')` and `tags[0] = 'c'` are both legal JavaScript, so the element type must be wide enough to accept them. Widening the element type to `string` is what makes the array type honest about its own mutability. ## What overrides the default **A contextual type.** If the literal is checked against an expected type, that type drives inference instead: ```typescript const tags: ('a' | 'b')[] = ['a', 'b']; // element type stays narrow function take(xs: readonly string[]) {} take(['a', 'b']); // literal checked against readonly string[] ``` The same happens for arguments, return positions and object properties with declared types — the annotation is the authority, and inference only fills the gap when there is none. **A `const` assertion.** Writing `['a', 'b'] as const` suppresses widening and produces a readonly tuple of literal types instead of a mutable array — the mechanics of that assertion are a topic of their own, but it is the standard escape hatch when you want the narrow types. ## The empty literal `const xs = []` has no elements to union. Under `noImplicitAny`, rather than erroring immediately, TypeScript treats this specific pattern as an evolving array: the element type is built up from what you subsequently push into the variable, and the type at any use site reflects what has been added so far. ```typescript const xs = []; xs.push(1); xs.push('a'); xs; // (string | number)[] ``` This only applies to a variable initialised with an empty literal; an empty literal in an expression position with no contextual type has nothing to evolve from, which is why library helpers usually annotate it — `const xs: number[] = []`. ## Why interviewers ask this The question separates people who have memorised "TypeScript infers types" from people who know what it infers and why. The useful framing is that inference tries to produce the type that will still be true after the value is used the way its mutability allows. A mutable array with narrow literal elements would not survive that test, so the compiler widens. Once you can state that principle, the `const`-assertion and contextual-type exceptions fall out of it: both are ways of telling the compiler that the mutability assumption does not hold.