Crash Course Overview

JavaScript is the language of the web, but it has a well-known weakness: it lets you make mistakes that you won't discover until your code is running in front of users. TypeScript was created to fix that. It adds a layer of static type checking on top of JavaScript, so the compiler can catch entire categories of bugs before your code ever runs. Every valid JavaScript file is already valid TypeScript — TypeScript just adds optional type annotations that the compiler uses to verify your code is correct.

TypeScript is never executed directly. Instead, the TypeScript compiler (tsc) reads your .ts files, checks them for type errors, and then strips away all the type annotations to produce plain JavaScript. That JavaScript is what actually runs in Node.js or the browser. Think of it as a spell-checker for your code — it runs before you "publish," catches problems, and the final output is clean JavaScript.

One of the most important things to understand about TypeScript is that you do not have to annotate every single variable. TypeScript has a powerful type inference engine that looks at the value you assign and figures out the type automatically. When you write let age = 20, TypeScript knows that is a number. When you use const, TypeScript goes even further — it infers a literal type, because a const can never change. The rule of thumb is simple: let TypeScript infer when it can, and annotate when it cannot or when you want to be explicit for clarity.

TypeScript has two types that accept any value: any and unknown. They look similar but behave very differently. Using any is like turning off the type checker — you can do anything with the value and TypeScript will not complain. Using unknown is the safe alternative — TypeScript forces you to check what type the value actually is before you can use it. Prefer unknown over any whenever you are dealing with values whose type you do not know at compile time. It keeps the safety net intact.

Here is the most important pattern in this module. A discriminated union is a union of object types that all share a common "tag" field — a literal-typed property like kind or status or type. When you switch on that tag field, TypeScript knows exactly which variant you're dealing with inside each case. It narrows the type automatically. This pattern shows up everywhere: shapes, API responses, event systems, state machines, Redux actions. Learn it once and you'll recognize it constantly.

Extension is the reason many teams reach for interface first. With extends, you build a hierarchy of shapes: define the common fields once in BaseEntity, then let User inherit them, then let AdminUser add permissions on top. Each layer adds only what is new. And you can extend multiple interfaces at once — AuditedUser below pulls fields from both User and Auditable. This is how real codebases stay DRY. When you change a base interface, every descendant inherits the change and TypeScript tells you immediately about any object literal that needs updating. That is a refactor you can make with confidence.

Here's the core problem generics solve. Without generics, a function that returns the first element of an array either has to be written separately for numbers, strings, and every other type -- or it uses any, which means TypeScript forgets the type completely. With a generic type parameter T, you write the function once. When you call it with a number array, TypeScript knows the return type is number. When you call it with a string array, TypeScript knows the return type is string. You get full type safety and full reuse.

When you have a variable whose type is a union — say, string or number — TypeScript does not know which one it is. But the moment you write an if-check like typeof value equals string, TypeScript narrows the type inside that block to just string. The broad union gets refined into a specific type. This is called type narrowing, and it happens automatically based on your control flow. Every if, switch, and conditional you write is not just runtime logic — it is also a proof to the compiler about what type the data must be.

When you handle every case in a union with a switch or if-else chain, the remaining type becomes never — a type that represents something that should be impossible. You can assign the value to a variable of type never in the default branch. If you ever add a new variant to the union and forget to handle it, the compiler will refuse to assign it to never and give you a compile error. This is called an exhaustive check, and it is your guarantee that you have covered every case.

There are two ways to consume Promises. The original way is chaining with dot-then: you call dot-then on the Promise and pass a callback that receives the resolved value. Each dot-then returns a new Promise, so you can chain them. The modern way is async/await: you mark a function as async, then use the await keyword to pause execution until the Promise resolves. The result is the same, but async/await reads like synchronous code, which makes it much easier to follow. Both approaches handle errors — dot-then uses dot-catch, while async/await uses try/catch.

When you have multiple async operations that do not depend on each other, you should run them in parallel rather than one after another. Promise.all takes an array of Promises and returns a single Promise that resolves with an array of all the results — but only if every Promise succeeds. If any one fails, the entire Promise.all rejects. TypeScript preserves the tuple types, so if you pass three different Promise types, you get a tuple of three different result types back.

Exceptions have a problem: they are invisible in your type signatures. A function that says it returns a number might actually throw three different kinds of errors, and the caller has no way to know that from the type alone. The Result type pattern solves this. Instead of throwing, your function returns a discriminated union: either an Ok variant with a value, or an Err variant with an error. The caller must check which variant they got before they can access the data. This makes error paths explicit and impossible to ignore.

Here is the core problem: when data comes from an API, a file, or any external source, it arrives as an unknown blob. A type assertion like "as User" silences the compiler, but if the data does not actually match the User shape, your code will crash later in a confusing way — accessing a property that does not exist, calling a method on undefined. The solution is type guard functions that check the data at runtime and narrow it to the expected type only if it actually matches. This is the boundary between the untyped outside world and your typed code.

In a real application, you call fetch to get data from an API. The response dot json method returns a Promise of any — completely untyped. A typed fetch wrapper combines the HTTP request with schema validation in a single function. You pass the URL and a validator, and it handles the request, checks the HTTP status, parses the JSON, validates the shape, and returns a typed value. If anything goes wrong at any step, you get a clear error. This is the boundary defense pattern in action: external data enters untyped and exits fully validated.

In this capstone, you will build a Task Tracker command-line application from scratch. This is not a toy example -- it has the same structure as a real production TypeScript project. There is a types file that defines all the data shapes. There is a store module that handles the core business logic. There is a CLI module that parses commands and formats output. There is an entry point that ties it all together. And there are tests that verify everything works. The project includes proper npm scripts, a tsconfig.json, and a .gitignore. When you finish this module, you will have built something you can point to and say: I know how to structure a TypeScript project.

You have completed all 20 modules of TypeScript Fundamentals. You started with a single hello.ts file and built your way up to a complete, tested, well-structured CLI application. Along the way, you learned type annotations, interfaces, classes, generics, utility types, type narrowing, modules, async/await, error handling, JSON and APIs, npm, tsconfig, testing with Vitest, and advanced patterns including decorators, mapped types, and template literal types. These are not just academic concepts -- they are the tools that professional TypeScript developers use every day. The next step is to build something of your own. Pick a project, set up the structure you learned here, and start writing TypeScript with confidence.