TypeScript — Cradle to Mastery

TypeScript was created at Microsoft under Anders Hejlsberg — the architect of C# and, before that, Turbo Pascal and Delphi — and it is deliberately a *superset* of JavaScript: every valid JavaScript file is already valid TypeScript. Understanding that framing explains why TypeScript never changes runtime behaviour and why its types vanish entirely when compiled.

Installing TypeScript is one npm command; the part that actually matters is <code>tsconfig.json</code>, which decides how strictly your code is checked and what JavaScript it compiles down to. This lesson gets both in place so every later lesson can be typed and compiled, not just read.

TypeScript's primitives map straight onto JavaScript's, but two of its types are unusual: <code>unknown</code> (a value whose type you must narrow before using) and <code>never</code> (a value that can never exist, used for exhaustiveness checks). Both become important later, so meet them now.

Beginners over-annotate. TypeScript infers the type of nearly every variable, return value and callback parameter from context, and the inferred type is often *more* precise than what you would write by hand. Knowing where inference works is what keeps TypeScript code readable instead of noisy.

Function signatures are where types pay off most immediately — a wrong argument is caught as you type rather than at runtime. This lesson also covers overloads: one function name with several valid signatures, which is common in library code you will read long before you write it.

A tuple is an array whose length and per-position types are both fixed — <code>[string, number]</code> rather than <code>(string | number)[]</code>. React's <code>useState</code> returns one, which is why destructuring it gives you correctly-typed values instead of a union.

Enums are one of the few TypeScript features that emit real JavaScript rather than vanishing at compile time, which is exactly why the official handbook now recommends most new code use union types or <code>as const</code> objects instead. Worth learning because you will meet them in existing code.

TypeScript adds compile-time access modifiers to JavaScript's classes, plus parameter properties that cut constructor boilerplate considerably. Note the distinction that trips people up: TypeScript's <code>private</code> is checked at compile time only, while JavaScript's own <code>#field</code> syntax is genuinely private at runtime.

This is among the most-asked TypeScript questions, and the honest answer is that the two are nearly interchangeable for object shapes. The one real difference is declaration merging: interfaces can be reopened and extended by later declarations, type aliases cannot.

A union type says a value is one of several types; an intersection says it satisfies all of them simultaneously. Unions are how TypeScript models the messy reality of JavaScript values, and they set up everything in the next three lessons — you cannot narrow what you have not first expressed as a union.

This lesson is the synthesis for the shape half of this stage: seeing type aliases, interfaces, unions, discriminated unions and structural typing combined into one realistic data model, rather than each feature in isolation. Structural typing is the key idea to take away — TypeScript cares what a type's shape *is*, not what it is *named*.

<code>strict: true</code> switches on roughly a dozen individual checks at once. The most consequential by far is <code>strictNullChecks</code>, which stops <code>null</code> and <code>undefined</code> from being assignable to every type — turning JavaScript's most common crash into a compile error.

This is TypeScript's signature move. Write <code>if (typeof x === "string")</code> and inside that block TypeScript *knows* x is a string — it reads your ordinary JavaScript control flow and narrows the type accordingly. No other mainstream type system tracks plain runtime checks this closely.

When a check is too custom for TypeScript to follow on its own, a type guard — a function returning <code>value is Type</code> — tells the compiler what a <code>true</code> result proves. This is the escape hatch that keeps narrowing working at the edges of a real codebase, especially around data arriving from a network.

An unconstrained type parameter tells TypeScript almost nothing — you cannot access any property on it, because it could be anything. <code>extends</code> is how you say “this can be any type, as long as it has at least this shape,” which is what makes generic code actually usable.

A conditional type branches at the type level, letting one type definition produce different results depending on its input. With <code>infer</code>, it can also extract a type out of another type — the mechanism behind almost every clever type in the standard library.

A mapped type walks over the keys of an existing type and produces a new one, so <code>Readonly&lt;T&gt;</code> or “make every field optional” becomes a single line instead of a duplicated interface that will drift out of sync.

Template literal types let the type system construct and pattern-match string types — so <code>`on${Capitalize&lt;K&gt;}`</code> can generate <code>onClick</code>, <code>onChange</code> and so on from a set of keys. Unusual among type systems, and the reason some TypeScript APIs feel almost magical.

TypeScript ships a set of ready-made mapped and conditional types that cover the transformations you need most: making fields optional, picking or omitting keys, building record types. This lesson also covers <code>satisfies</code> and <code>as const</code>, two modern additions that change how object literals get typed.

The patterns library authors rely on: several interacting type parameters, sensible defaults so callers rarely specify them, and generic classes that carry their type through every method. This is the point where reading a library's type definitions stops being intimidating.

This lesson is the synthesis for this stage: the individual type-level features you just met, combined the way real library code combines them — a generic function whose return type is computed from its input via a conditional type and a mapped type. Read it once the pieces are familiar, not before.

The single most clarifying fact about TypeScript: <code>tsc</code> type-checks your code and then deletes every type, emitting plain JavaScript. Nothing is checked at runtime. As of 2026 there is also a Go-based rewrite of the compiler that runs roughly ten times faster — a historic change for a project that had always been written in TypeScript itself.

Most “TypeScript is broken” moments are really a <code>tsconfig.json</code> set up wrong. This lesson covers the options that actually matter day to day, including the <code>target</code> vs <code>lib</code> distinction most people conflate: one sets the JavaScript version you emit, the other declares which built-in APIs exist.

TypeScript predates the ES module standard, so it invented namespaces to solve the same problem. Today <code>import</code>/<code>export</code> is simply the right answer, and namespaces mainly appear in older code and in declaration files. Knowing which one you are looking at saves real confusion.

A declaration file is types without code: it tells TypeScript the shape of a JavaScript library that has no types of its own. Understanding them explains where <code>@types/*</code> packages come from and how to type a dependency that ships none.

An important distinction: your test runner executing TypeScript is not the same as your types being checked. Most setups transpile tests without type-checking them for speed, which means <code>tsc --noEmit</code> belongs in your pipeline as its own step alongside the test run.

An <code>async</code> function always returns a <code>Promise&lt;T&gt;</code>, and <code>await</code> simply unwraps it back to <code>T</code>. The genuinely important part is typing failure: a rejected promise is typed as <code>unknown</code> in a catch block under modern settings, which forces you to narrow before assuming you caught an <code>Error</code>.

React is where most people meet TypeScript in earnest. Typed props turn a component's contract into something the compiler enforces, and typed hooks — especially <code>useState</code>, which returns a tuple — are where the tuple lesson from Stage 1 pays off directly.

Decorators are now a real JavaScript standard, and TypeScript's modern implementation follows it. Critically, the older <code>experimentalDecorators</code> version is a different, incompatible design — so a tutorial or library written for one will not work under the other. Knowing which you are looking at is the whole battle.