Type Inference

1What Inference Means

TypeScript can figure out a value's type from how it's written or used, without an explicit annotation. Most real-world TypeScript code relies on inference far more than explicit annotations — annotating every single variable is noisy and considered bad style once inference already gets it right.

let count = 5;          // inferred: number
let name = "Ana";        // inferred: string
let items = [1, 2, 3];    // inferred: number[]

2let vs const — Widening and Literal Types

let a = "hello";     // inferred as the WIDER type: string
const b = "hello";    // inferred as the NARROWER literal type: "hello"

Because let allows reassignment, TypeScript widens the inferred type to the general string — a could later hold any string. const can never be reassigned, so TypeScript keeps the most precise type possible: the exact literal "hello".

function greet(role: "admin" | "guest") {}

const role = "admin";
greet(role); // ✅ role's type is the literal "admin", assignable to "admin" | "guest"

let mutableRole = "admin";
greet(mutableRole); // ❌ mutableRole's type widened to `string` — NOT assignable to "admin" | "guest"

3Contextual Typing — Inference Flowing Into an Expression

Inference doesn't only flow outward from a value to its variable — it can flow inward from an expected type into an expression, filling in parameter types you never wrote.

const numbers = [1, 2, 3];

numbers.map((n) => n * 2);
//           ^ n is inferred as `number`, WITHOUT you annotating it —
//             TypeScript already knows .map's callback receives the array's element type

TypeScript knows .map's signature expects (value: number, index: number, array: number[]) => U, and propagates the number type from that expected signature into your arrow function's parameter — this is called contextual typing.

4Best Common Type for Arrays

const mixed = [1, "two", 3]; // inferred: (string | number)[]

const points = [{ x: 1 }, { x: 2, y: 3 }]; // inferred: { x: number; y?: number }[]

When array elements have different (but related) types, TypeScript computes the best common type — a union broad enough to describe every element, or a merged shape for objects.

5Return Type Inference

function add(a: number, b: number) {
  return a + b; // return type inferred as `number` — no explicit `: number` needed
}

TypeScript infers a function's return type by analyzing every return statement in its body. For recursive functions or complex conditional logic, explicit return type annotations are still recommended — inference can be slow or ambiguous on deeply recursive code, and an explicit return type also documents intent and catches accidental changes.

6Inference Across Destructuring

function getUser() {
  return { id: 1, name: "Ana", active: true };
}

const { id, name } = getUser(); // id: number, name: string — inferred from the return type

7as const — Requesting Maximum Narrowing

let point = { x: 1, y: 2 };            // { x: number; y: number }
let pointConst = { x: 1, y: 2 } as const; // { readonly x: 1; readonly y: 2 }

as const tells the inference engine to widen as little as possible: object properties become readonly, and literal values keep their exact literal type instead of widening to number/string. Commonly used for configuration objects, Redux-style action types, and anywhere exact literal types matter.

numbers.map((n) => n * 2)
              ▲
              │ expected type "number" is pushed in from .map's own signature
              │ BEFORE the arrow function's body is even checked

⚠️ Common Pitfalls

1. Relying on inference for public function signatures — inferred return types can change unexpectedly when the implementation changes, silently breaking callers; explicit return types on exported/public functions are safer.
2. Expecting a let variable to keep a literal type — it always widens; use const or an explicit literal type/as const if you need the narrow type to persist.
3. Assuming contextual typing always applies — it only flows in when TypeScript can already determine an expected type from context (an annotated parameter, a typed array, an assignment target); a genuinely standalone expression has nothing to receive from.
4. Overusing as const — it makes every nested property readonly, which can fight with code that legitimately needs to mutate the object later.

📋 Quick Reference

let x = "hi"        → widened: string
const x = "hi"        → literal: "hi"
{ x: 1 } as const       → { readonly x: 1 }
callback params         → often inferred via contextual typing, no annotation needed

🎤 Interview Q&A

🛠️ Practice exercises

Each exercise is a file in this topic folder. Code exercises are self-checking: run them and make the checks pass.

Source: ts_type_inference_theory.md · generated by tools/build_lessons.py