TypeScript

The type system: structural, not nominal

TypeScript uses structural typing: two types are compatible if they have the same shape, regardless of their declared names. If Duck has a quack() method and RubberDuck also has a quack() method, they are mutually assignable — even though they're declared separately. This is the opposite of nominal typing (Java, C#) where two classes are only compatible if one explicitly extends the other.

Structural typing integrates naturally with JavaScript's duck-typing culture but requires understanding: a function that accepts User will also accept any object with the required fields — even objects that have extra fields.

Advanced types: mapped, conditional, template literal

TypeScript's type system is Turing-complete — capable of expressing complex type transformations. Key advanced features:

// Mapped types — transform every property in a type
type Readonly<T> = { readonly [K in keyof T]: T[K] };
type Partial<T>  = { [K in keyof T]?: T[K] };
type Required<T> = { [K in keyof T]-?: T[K] };
type Record<K extends string, V> = { [P in K]: V };

// Conditional types
type IsString<T> = T extends string ? "yes" : "no";
type A = IsString<string>;  // "yes"
type B = IsString<number>;  // "no"

// Utility types (built into TypeScript)
interface User { id: number; name: string; email: string; }
type UserPreview = Pick<User, "id" | "name">;     // { id; name }
type WithoutEmail = Omit<User, "email">;           // { id; name }
type MaybeUser   = Partial<User>;                 // all optional

// Template literal types
type EventName = "click" | "focus" | "blur";
type Handler = `on${Capitalize<EventName>}`;     // "onClick" | "onFocus" | "onBlur"

null, undefined, and strictNullChecks

With strictNullChecks: true (required in strict mode), null and undefined are their own types and are not assignable to other types. A function that might return null must declare string | null as its return type. This forces callers to handle the null case explicitly — eliminating entire categories of null-pointer runtime errors. Without strict null checks, TypeScript behaves like JavaScript — nulls hide everywhere.

function findUser(id: number): User | null {
  const user = db.find(u => u.id === id);
  return user ?? null;
}

const user = findUser(1);
// user.name                  // ERROR: Object is possibly null
if (user !== null) {
  user.name;                  // OK: narrowed to User
}
user?.name;                   // optional chaining: undefined if null
user?.name ?? "Anonymous";    // nullish coalescing: fallback

// Non-null assertion — use only when you KNOW it's not null
const u = findUser(1)!;       // tells TypeScript: "trust me"
u.name;                       // OK — but crashes if actually null

Enums, as const, and string literals

TypeScript has runtime enum objects, but for most use cases as const on an object is preferred — it creates a constant object whose values are inferred as literal types, with no runtime overhead beyond a plain JavaScript object.

// Runtime enum — generates a JS object at runtime
enum Direction { Up = "UP", Down = "DOWN", Left = "LEFT", Right = "RIGHT" }

// Preferred: const object with as const — zero runtime overhead
const DIRECTION = { Up: "UP", Down: "DOWN", Left: "LEFT", Right: "RIGHT" } as const;
type Direction2 = typeof DIRECTION[keyof typeof DIRECTION]; // "UP" | "DOWN" | "LEFT" | "RIGHT"

// String literal union — simplest
type Status = "active" | "inactive" | "pending";
function setStatus(status: Status): void { /* ... */ }
// setStatus("unknown");  // ERROR: Argument of type "unknown" is not assignable

The TypeScript type system is Turing-complete

TypeScript's type system, through conditional types, mapped types, and recursive type aliases, is Turing-complete — it can express any computation. This was demonstrated by Henning Hess (2019) who implemented a sorting algorithm entirely in TypeScript's type system. While this is an academic curiosity, it underpins why TypeScript can express types like DeepReadonly<T>, DeepPartial<T>, or route parameter extraction from URL strings: RouteParams<"/users/:id/posts/:postId"> = { id: string; postId: string }.

Variance, covariance, and contravariance

TypeScript's type compatibility follows structural subtyping rules with variance annotations (added in TypeScript 4.7): in (contravariant), out (covariant), in out (invariant). Intuitively: a type used only as a function return is covariant (you can return a more specific type); a type used only as a function parameter is contravariant (you can accept a less specific type). TypeScript infers variance but in/out modifiers make it explicit and allow the compiler to skip expensive structural compatibility checks.

tsc vs. esbuild vs. SWC vs. Babel

tsc (TypeScript compiler): the official compiler — performs full type checking + code emission. Slowest for large projects due to type checking. esbuild: written in Go, strips TypeScript types without type checking, ~100× faster than tsc. Used in Vite. SWC: written in Rust, strips types without type checking, used in Next.js 12+. Babel with @babel/preset-typescript: strips types without checking. The modern pattern: use tsc --noEmit for type checking (in CI) and esbuild/SWC for fast compilation during development and production builds. This separates type checking from transpilation.