Introduction to TypeScript

Why TypeScript?

JavaScript is dynamically typed. That's flexible — and dangerous. Every undefined is not a function, every typo in an object key, every "oh I forgot this field can be null" is a runtime crash.

TypeScript adds a layer of static analysis on top of JS. You annotate (or let it infer) the shape of your data, and the compiler tells you — *before* you ship — when something doesn't line up.

Key ideas:

• It's a superset of JS. Every valid JS file is a valid TS file. You can adopt it gradually.
• Types are erased at compile time. They exist for the developer + tooling, not at runtime. Browsers and Node.js still run plain JavaScript.
• Structural typing. Two types are compatible if they have the same *shape*, not because they share a name. (Different from Java/C#'s nominal typing.)
• Editor superpowers. VS Code (built in TS!) gives you autocomplete, jump-to-definition, rename-symbol, inline docs, and red squigglies — all powered by the TS language service.

The TypeScript ecosystem

Installing TypeScript

Globally is fine for playing, but in real projects always install it as a dev dependency so the version is pinned:

npm install --save-dev typescript
npx tsc --init        # creates tsconfig.json with sensible defaults
npx tsc               # compile every .ts file in the project

If you're inside Next.js / Vite / Create React App, TypeScript is supported out of the box — just rename a file to .tsx.

tsconfig.json — the minimum you should know

{
  "compilerOptions": {
    "target": "ES2022",
    "module": "ESNext",
    "moduleResolution": "Bundler",
    "strict": true,
    "esModuleInterop": true,
    "skipLibCheck": true,
    "noEmit": true,
    "jsx": "preserve"
  },
  "include": ["src"]
}

The single most important flag is strict: true. It turns on noImplicitAny, strictNullChecks, and a handful of other checks that turn TS from "linter" into "actual type system". Always start a new project with strict on.

Your first .ts file

// greet.ts
function greet(name: string, age: number): string {
  return Hello ${name}, you are ${age};
}
console.log(greet("Rahul", 21));
// console.log(greet("Rahul", "21")); // ❌ Argument of type 'string' is not assignable to parameter of type 'number'.

Run it:

npx tsc greet.ts        # produces greet.js
node greet.js
# or, in one step:
npx tsx greet.ts

Type inference — let TS do the work

You don't have to annotate everything. TypeScript infers types from initial values:

let count = 0;          // inferred as number
count = "hello";        // ❌ Type 'string' is not assignable to type 'number'.
const items = [1, 2, 3]; // number[]
items.push("four");      // ❌

Rule of thumb: annotate function *parameters* and public APIs. Let TS infer everything else.

The mental model

Think of TS as a *separate program* that runs alongside your JS:

1. You write .ts source. 2. The TS compiler builds a graph of all your types and checks them. 3. It either errors out, or strips the type annotations and outputs .js. 4. Node / the browser runs the JS — it knows nothing about TypeScript.

That separation is why TS can never affect runtime behaviour. typeof at runtime is still JS typeof. There are no classes-from-types or runtime type checks. (Libraries like Zod fill that gap when you need it.)

What's next

In the next topic we'll go through every primitive type, the difference between any, unknown, and never, and how literal types let TS narrow values down to a single string.