Type Annotations & Inference

TypeScript can usually figure out a variable's type from the value you give it — this is type inference, and it runs constantly, whether or not you write an annotation. let count = 5 is inferred as number just as surely as if you had written let count: number = 5. The rule of thumb: let inference handle variables with an initial value, and write an explicit annotation only when there is nothing for the compiler to infer from — a variable declared before it is assigned, or one that needs to be wider than its first value suggests.

let count = 5
count = "ten"

app.ts:2:1 - error TS2322: Type 'string' is not assignable to type 'number'.

2 count = "ten"
  ~~~~~

let count: number | string = 5
count = "ten"

Type inference

TypeScript deducing a type from context — an initial value, a return expression, a usage — without an explicit annotation.

Widening

Inference generalising a specific value to the type family it belongs to: 5 becomes number, not the literal type 5, when declared with let.

Function parameters almost always need an explicit annotation — TypeScript has no value to infer a parameter's type from until the function is actually called, so an unannotated parameter is treated as an implicit any and flagged under the compiler's noImplicitAny setting, which almost every project enables. Return types, on the other hand, are usually left to inference: TypeScript reads the function body and works out what it returns. Writing the return type explicitly on public, exported functions is still good practice — it documents the contract and catches a mistake inside the function instead of at every call site.

Contextual typing is why nums.map(x => x * 2) never needs x: number written out. TypeScript already knows nums is number[], so it knows .map expects a callback whose parameter is a number — it works backwards from that expected function shape to infer the type of x inside the arrow function, without you annotating anything. This is the same mechanism behind untyped-looking callbacks for .filter, .forEach, .reduce, event handlers, and a Promise executor.

const nums: number[] = [1, 2, 3]
nums.forEach((x: string) => console.log(x))

app.ts:2:16 - error TS2345: Argument of type '(x: string) => void' is not assignable to parameter of type '(value: number, index: number, array: number[]) => void'.
  Types of parameters 'x' and 'value' are incompatible.
    Type 'number' is not assignable to type 'string'.

2 nums.forEach((x: string) => console.log(x))
                 ~~~~~~~~

const nums: number[] = [1, 2, 3]
nums.forEach(x => console.log(x))

• Array methods: .map, .filter, .reduce, .forEach, .sort
• Event handlers: button.addEventListener("click", e => ...) — e is inferred as the right event type
• A Promise executor: new Promise((resolve, reject) => ...)
• Any place you pass a function into another function whose parameter type is already known

as const is a type assertion that tells TypeScript "infer the narrowest possible type for this, and make it read-only". A plain object literal infers widened property types ({ x: number }, not { x: 10 }); the same literal with as const infers the exact literal types for every property, and makes the object and any nested arrays readonly. It has zero effect at runtime — the values are identical — it only changes what the type checker will let you do afterward.

const point = { x: 10, y: 20 } as const
point.x = 99

app.ts:2:1 - error TS2540: Cannot assign to 'x' because it is a read-only property.

2 point.x = 99
  ~~~~~~~

const point = { x: 10, y: 20 } as const
const moved = { ...point, x: 99 }
console.log(moved.x)

as const

A type assertion that narrows a value to its exact literal type and, for objects and arrays, marks every property/element readonly.

Readonly array/tuple

An array or tuple type whose elements cannot be reassigned by index and that has no mutating methods like push or pop in its type.

When you write an array literal with elements of different types, TypeScript infers a type that covers every element — this is the "best common type" algorithm. For elements of unrelated types it falls back to a union of every distinct type it saw: [1, "two", 3] infers as (string | number)[]. When every element shares a common supertype, it uses that instead — an array of a base class and subclass instances infers as an array of the base class.