TypeScript Types and Type Inference: A Practical Introduction

A bike-share app has a function that prints a status line for each station: describe(station, bikes). It has run for months. Then one night a station goes offline, the feed stops sending the bike count, the function receives undefined, calls .toFixed() on it, and the dashboard page crashes. In JavaScript nothing warned anyone because nothing could. TypeScript's whole value proposition is that this class of mistake, a value being something other than you assumed, is reported while you type instead of at 3 a.m.

What TypeScript is, and what it is not

TypeScript is JavaScript plus a static type system. You write .ts files, the compiler (tsc) checks them, and the types are then erased: the output is plain JavaScript with no trace of them. That has two consequences worth memorising. First, types cost nothing at runtime. Second, types also protect nothing at runtime: if data arrives from a network call or a form, TypeScript cannot verify it is the shape you claimed. We return to that in the last lesson.

Turn on strict mode ("strict": true in tsconfig.json) from day one. Without it, TypeScript quietly allows null anywhere and treats missing annotations as any, which removes most of the benefit. Everything in this course assumes strict mode.

Annotations and inference working together

You can annotate a value with a colon and a type: let freeDocks: number = 12. Usually you should not, because TypeScript infers the type from the initial value. Annotate where inference cannot reach: function parameters, return types of exported functions, and variables declared without a value. Notice also that const infers the narrowest possible type: const stationName = "Riverside" has the literal type "Riverside", whereas let widens to string, since a let may be reassigned.

// docks.ts - a bike-share station
const stationName = "Riverside";          // inferred: "Riverside" (a literal type)
let freeDocks = 12;                       // inferred: number
let isOpen = true;                        // inferred: boolean

freeDocks = freeDocks - 1;

const bikeIds: number[] = [301, 302, 305];
const lastCheck: [string, number] = ["08:15", 4];   // tuple: fixed length and order

function docksLeft(total: number, bikes: number): number {
  return total - bikes;
}

function describe(station: string, bikes?: number): string {
  return bikes === undefined ? `${station}: unknown` : `${station}: ${bikes} bikes`;
}

const logLine = (msg: string): void => console.log(msg);

console.log(docksLeft(20, bikeIds.length));
logLine(describe(stationName));
logLine(describe(stationName, bikeIds.length));
console.log(lastCheck[0], isOpen);

17
Riverside: unknown
Riverside: 3 bikes
08:15 true

This file contains only type syntax, so you can run it directly on recent Node versions with node --experimental-strip-types docks.ts (the flag is needed on some Node 22 releases) or compile it with npx tsc. The bikes?: number parameter is optional and has the type number | undefined, and the function handles that case explicitly, which is precisely the bug from the opening story, now fixed by design. void marks a function that returns nothing useful.

Letting the compiler tell you what is wrong

The next file is wrong on purpose. It will not compile, and each comment shows the real TypeScript 5.9 error for the line beside it. Reading these messages is a skill: they are long but they always say what the compiler expected and what it found.

let freeDocks = 12;
freeDocks = "none";                          // (1)

function describe(station: string, bikes?: number): string {
  return `${station}: ${bikes.toFixed(0)} bikes`;   // (2)
}

function findStation(id: number): string | undefined {
  return id === 1 ? "Riverside" : undefined;
}
const name = findStation(2);
console.log(name.toUpperCase());             // (3)

function parse(raw: unknown) {
  return raw.length;                         // (4)
}

const trip: [string, number] = ["08:15", 4, 9];   // (5)

(1) Type 'string' is not assignable to type 'number'.
(2) 'bikes' is possibly 'undefined'.
(3) 'name' is possibly 'undefined'.
(4) 'raw' is of type 'unknown'.
(5) Type '[string, number, number]' is not assignable to type '[string, number]'.
      Source has 3 element(s) but target allows only 2.

Errors (2) and (3) come from strict null checking: a value typed string | undefined cannot be used as a string until you have handled the undefined case. Error (4) shows why unknown is the safe way to say "I do not know what this is". You must check it before using it. Its dangerous cousin any switches the checker off for that value, so anything.toFixed() compiles even when anything is a string and then throws at runtime. Treat every any as a debt you are choosing to take on.

Common mistakes and the errors they produce

• Leaving strict mode off. Nothing complains about null, so the runtime error TypeError: Cannot read properties of undefined still reaches production. Enable strict.
• Parameters without types. Under noImplicitAny (part of strict), function f(x) {} gives Parameter 'x' implicitly has an 'any' type. Annotate it.
• Silencing errors with `any` or `as`. The red squiggle disappears but the crash remains. Fix the model, or use unknown and narrow.
• Annotating everything. const count: number = 0 adds noise and no safety. Annotate where inference cannot reach.
• Believing types validate data. const trip = JSON.parse(text) as Trip compiles whatever the text contains. Validate data at runtime when it crosses a trust boundary.
• Expecting `let x = "a"` to be a literal. It widens to string, so let mode = "open" cannot be passed where "open" | "closed" is required. Use const, an annotation, or as const.

How this shows up in real projects and interviews

Most teams adopt TypeScript for editor support as much as for error catching: autocomplete that knows what is in an object, safe renames across a codebase, and function signatures that document themselves. Reviewers expect strict on and are suspicious of any. In interviews, a common question is "what is the difference between any and unknown", and another is "are TypeScript types checked at runtime", which you can now answer with a clear no. Next you will learn to model real data shapes with interfaces, type aliases and unions, and if you build UIs, React pairs naturally with this.