Classes & Enums

A TypeScript class is a JavaScript class with types written on it. Everything that runs — the constructor, methods, fields, extends, super, #private, static — is plain JavaScript and behaves exactly as it does there. TypeScript adds two kinds of things on top: checks (every field must be declared and initialised, method calls are type-checked, overrides must be compatible) and a handful of TypeScript-only keywords (private, protected, public, readonly, abstract, override, implements, parameter properties). Most of those keywords are erased; a couple (parameter properties) generate code. The topics below go through each one and show what's left at runtime.

The one idea that makes classes "interesting" in TypeScript, as my notes put it: a class declaration creates two things with one name. class Point {} creates a value — the constructor function you call with new — and a type — the shape of the instances it creates. When you write Point after a colon, you mean the instance type; when you write new Point() or typeof Point, you mean the constructor.

And because TypeScript is structurally typed (see What TypeScript is (and isn't)), that instance type is just a shape. Any object with the same members is accepted where a Point is expected, whether or not it came from the class.

class Person {
  name: string;
  age = 0;                 // type inferred from the initialiser: number
  nickname?: string;       // optional: string | undefined, no initialiser needed

  constructor(name: string) {
    this.name = name;
  }

  greet(): string {
    return `Hi, I'm ${this.name}`;
  }
}

class Broken {
  title: string; // ❌ Property 'title' has no initializer and is not definitely assigned in the constructor.

  setUp() {
    this.label = "x"; // ❌ Property 'label' does not exist on type 'Broken'.
  }
}

class Point {
  x = 0;
  y = 0;
}

const p: Point = { x: 1, y: 2 }; // fine: it has the right shape
console.log(p instanceof Point);  // false — it never went through the constructor

function create(ctor: typeof Point): Point {
  return new ctor();
}
const q = create(Point); // Point { x: 0, y: 0 }

class Animal {
  move(): string {
    return "moving";
  }
}

class Dog extends Animal {
  override move(): string {
    return "running";
  }
  override mvoe(): string { // ❌ This member cannot have an 'override' modifier because it is not declared in the base class 'Animal'.
    return "typo";
  }
}

TypeScript has had public, private and protected since long before JavaScript had any privacy. JavaScript later added #private fields (ES2022). They look like they do the same job, but they live in different worlds: the TypeScript modifiers are compile-time only and are erased, while #private is enforced by the JavaScript engine at runtime.

• public (the default) — accessible everywhere. Writing it is just documentation.
• protected — accessible inside the class and its subclasses.
• private — accessible only inside the class that declares it, as far as the type checker is concerned.
• #name — accessible only inside the class body, enforced at runtime; nothing outside can read it, write it, or even see that it exists.

Mental model: private is a "Staff only" sign on a door — it stops people who read signs (the type checker), but the door isn't locked. #private is a locked door — it doesn't matter who you are or what tool you used to get there.

class BankAccount {
  public owner: string;
  private balance = 0;
  protected currency = "CAD";
  #pin: string;

  constructor(owner: string, pin: string) {
    this.owner = owner;
    this.#pin = pin;
  }

  deposit(amount: number): void {
    this.balance += amount;
  }

  checkPin(pin: string): boolean {
    return this.#pin === pin;
  }
}

const acc = new BankAccount("Ada", "1234");
acc.deposit(100);
acc.owner;      // fine
acc.balance;    // ❌ Property 'balance' is private and only accessible within class 'BankAccount'.
acc.currency;   // ❌ Property 'currency' is protected and only accessible within class 'BankAccount' and its subclasses.
acc.#pin;       // ❌ Property '#pin' is not accessible outside class 'BankAccount' because it has a private identifier.
acc["balance"]; // compiles! bracket access is an escape hatch for private

class BankAccount {
    owner;
    balance = 0;
    currency = "CAD";
    #pin;
    constructor(owner, pin) {
        this.owner = owner;
        this.#pin = pin;
    }
    deposit(amount) {
        this.balance += amount;
    }
    checkPin(pin) {
        return this.#pin === pin;
    }
}
const acc = new BankAccount("Ada", "1234");
acc.deposit(100);
console.log(Object.keys(acc));    // [ 'owner', 'balance', 'currency' ]
console.log(JSON.stringify(acc)); // {"owner":"Ada","balance":100,"currency":"CAD"}
console.log(acc.balance);         // 100

class Celsius {
  private value: number;
  constructor(value: number) {
    this.value = value;
  }
}
class Fahrenheit {
  private value: number;
  constructor(value: number) {
    this.value = value;
  }
}
const t: Celsius = new Fahrenheit(70); // ❌ Type 'Fahrenheit' is not assignable to type 'Celsius'.

class Token {
  #brand = true;
  static isToken(value: unknown): value is Token {
    return typeof value === "object" && value !== null && #brand in value;
  }
}
const fake: Token = {}; // ❌ Property '#brand' is missing in type '{}' but required in type 'Token'.

class Session {
  private token = "secret-123";
  #userId = 42;
}

const s = new Session();
console.log(JSON.stringify(s));
console.log(Object.keys(s).length);

Parameter properties are a TypeScript shorthand: put an access modifier (public, private, protected) or readonly in front of a constructor parameter, and TypeScript both declares a property of that name and assigns the argument to it. It's the most common piece of TypeScript syntax that generates real JavaScript code.

readonly marks a property as "assign once": it can be set where it's declared or in the constructor, and never again. Like the access modifiers it's compile-time only — and it's shallow: a readonly property holding an array stops you replacing the array, not pushing into it.

From my notes, a class implementing an interface with parameter properties:

interface User {
  id: number;
  name: string;
  email: string;
}

class Person implements User {
  constructor(public id: number, public name: string, public email: string) {}
}

const ada = new Person(1, "Ada", "ada@example.com");
console.log(ada.name); // "Ada"

class Order {
  readonly createdAt = new Date();

  constructor(public readonly id: string, private readonly items: string[]) {}

  addItem(item: string): void {
    this.items.push(item);  // fine — the array itself isn't readonly
    this.items = [];        // ❌ Cannot assign to 'items' because it is a read-only property.
  }
}

const order = new Order("A1", []);
order.addItem("book");
order.id = "B2"; // ❌ Cannot assign to 'id' because it is a read-only property.

class Order {
    id;
    items;
    createdAt = new Date();
    constructor(id, items) {
        this.id = id;
        this.items = items;
    }
    addItem(item) {
        this.items.push(item);
    }
}

class Price {
  withTax = this.amount * 1.13; // ❌ Property 'amount' is used before its initialization.

  constructor(public amount: number) {}
}

An abstract class is a base class that is incomplete on purpose. It can't be instantiated with new; it exists to be extended. It can contain real, shared implementation and abstract members — methods or properties that are declared but not implemented, which every concrete subclass must provide.

It sits between an interface and a normal class. An interface is a pure contract with no code. A normal base class is complete and instantiable. An abstract class says "here's the shared skeleton and some ready-made behaviour; you fill in these specific holes." That's the template method pattern: the base class's describe() calls this.area(), and each subclass decides what area() means.

abstract class Shape {
  constructor(public readonly name: string) {}

  abstract area(): number;

  describe(): string {
    return `${this.name} with area ${this.area().toFixed(2)}`;
  }
}

class Circle extends Shape {
  constructor(private radius: number) {
    super("circle");
  }

  area(): number {
    return Math.PI * this.radius ** 2;
  }
}

console.log(new Circle(1).describe()); // "circle with area 3.14"

new Shape("blob");                 // ❌ Cannot create an instance of an abstract class.
class Square extends Shape {}      // ❌ Non-abstract class 'Square' does not implement inherited abstract member area from class 'Shape'.

class Shape {
    name;
    constructor(name) {
        this.name = name;
    }
    describe() {
        return `${this.name} with area ${this.area().toFixed(2)}`;
    }
}
class Circle extends Shape {
    radius;
    constructor(radius) {
        super("circle");
        this.radius = radius;
    }
    area() {
        return Math.PI * this.radius ** 2;
    }
}

abstract class Repository {
  abstract find(id: string): string | undefined;
}

const make: new () => Repository = Repository; // ❌ Type 'typeof Repository' is not assignable to type 'new () => Repository'.
const base: abstract new () => Repository = Repository; // fine

function withLogging<T extends abstract new (...args: any[]) => object>(Base: T) {
  abstract class Logged extends Base {
    log(message: string) {
      console.log(`[${this.constructor.name}] ${message}`);
    }
  }
  return Logged;
}

From my notes: "using — used to do automatic cleanup once the object goes out of scope." It's the JavaScript explicit resource management proposal: TypeScript 5.2 added the syntax and types, and engines now run it natively (V8 13.x; it works in Node 24+ and Chrome 134+). It's no longer experimental in the engines that matter, but for older runtimes TypeScript downlevels it.

The problem it solves is cleanup code that's easy to forget or get wrong: closing files, releasing locks, ending database transactions, removing listeners. The old answer is try/finally, which gets ugly with several resources (nested try blocks, cleanup in reverse order, what if a cleanup throws?). using x = value declares a constant whose [Symbol.dispose]() method is called automatically when the enclosing block exits — normally, by return, or by an exception. Think of it as C#'s using, Python's with, or Go's defer, attached to a variable.

The rules:

• The value must have a [Symbol.dispose]() method (the Disposable interface), or be null/undefined (skipped).
• Resources are disposed in reverse order of declaration — last acquired, first released, like a stack.
• await using works with [Symbol.asyncDispose]() (the AsyncDisposable interface) and awaits each cleanup; it's only allowed in async functions and at the top level of modules.

class TempFile implements Disposable {
  constructor(public readonly path: string) {
    console.log(`open ${path}`);
  }
  [Symbol.dispose]() {
    console.log(`close ${this.path}`);
  }
}

function work() {
  using a = new TempFile("a.txt");
  using b = new TempFile("b.txt");
  console.log("working");
  return "done";
}
console.log(work());
// open a.txt
// open b.txt
// working
// close b.txt
// close a.txt
// done

function failing() {
  using c = new TempFile("c.txt");
  throw new Error("boom");
}
try {
  failing();
} catch (e) {
  console.log("caught", (e as Error).message);
}
// open c.txt
// close c.txt
// caught boom

function work() {
    const env_1 = { stack: [], error: void 0, hasError: false };
    try {
        const a = __addDisposableResource(env_1, new TempFile("a.txt"), false);
        const b = __addDisposableResource(env_1, new TempFile("b.txt"), false);
        console.log("working");
        return "done";
    }
    catch (e_1) {
        env_1.error = e_1;
        env_1.hasError = true;
    }
    finally {
        __disposeResources(env_1);
    }
}

class Connection implements AsyncDisposable {
  constructor(public name: string) {
    console.log(`connect ${name}`);
  }
  async [Symbol.asyncDispose]() {
    await new Promise((resolve) => setTimeout(resolve, 10));
    console.log(`disconnect ${this.name}`);
  }
}

async function main() {
  await using db = new Connection("db");
  {
    using stack = new DisposableStack();
    stack.defer(() => console.log("deferred 1"));
    stack.defer(() => console.log("deferred 2"));
    console.log("in block");
  }
  console.log("after block");
}

await main();
console.log("main finished");
// connect db
// in block
// deferred 2
// deferred 1
// after block
// disconnect db
// main finished

An enum is a named set of constants. enum Color { Red, Green, Blue } gives you Color.Red, Color.Green, Color.Blue instead of magic numbers, and a type Color that only accepts those members. It's one of the few TypeScript features that is not just types: an enum declaration generates a real JavaScript object.

In a numeric enum each member is a number. If you don't give a value, members are numbered from 0, each one more than the previous. If you set a member explicitly, counting continues from that value — the "notice the indexes" point in my notes.

enum Color {
  Red,         // 0
  Green,       // 1
  Yellow = 18, // 18 — set explicitly instead of 2
  Blue,        // 19 — continues from the last explicit value
}

console.log(Color.Red, Color.Green, Color.Yellow, Color.Blue); // 0 1 18 19

function paint(color: Color) {}
paint(Color.Green); // fine
paint(1);           // fine — 1 is the value of Color.Green
paint(2);           // ❌ Argument of type '2' is not assignable to parameter of type 'Color'.

var Color;
(function (Color) {
    Color[Color["Red"] = 0] = "Red";
    Color[Color["Green"] = 1] = "Green";
    Color[Color["Yellow"] = 18] = "Yellow";
    Color[Color["Blue"] = 19] = "Blue";
})(Color || (Color = {}));

Numeric enums map both ways: name → value (Color.Blue is 19) and value → name (Color[19] is "Blue"). That's what the double assignment in the emitted IIFE builds. It's useful for logging and debugging — turning a numeric status code from an API back into a readable name.

From my notes: "Reverse mapping for ENUM is also possible!!!! (Output would be Blue and Yellow)" — with the Color enum from Numeric enums:

enum Color {
  Red,
  Green,
  Yellow = 18,
  Blue,
}

console.log(Color[19], Color[18]);   // Blue Yellow
console.log(Color[Color.Green]);     // Green
console.log(Color[7]);               // undefined — but typed as string
console.log(Object.keys(Color));
// [ '0', '1', '18', '19', 'Red', 'Green', 'Yellow', 'Blue' ]
console.log(Object.values(Color).filter((v) => typeof v === "number"));
// [ 0, 1, 18, 19 ]

enum Level {
  Low = 1,
  Medium,
  High = 10,
  Critical,
}

console.log(Level.Medium, Level.Critical, Level[11], Level["High"]);

In a string enum every member is initialised with a string literal. There's no auto-increment (the compiler can't guess the "next" string), so every member needs a value. The pay-off is readability at runtime: logs, JSON and network payloads contain "UP" instead of 0, and the values don't shift when someone inserts a member in the middle — a real risk with auto-numbered enums that are stored in a database.

String enums are also stricter than numeric ones. A string enum type accepts only its members, not the equivalent string literal. That makes them nominal — unusual in a structural type system.

enum Direction {
  Up = "UP",
  Down = "DOWN",
  Left = "LEFT",
  Right = "RIGHT",
}

function move(direction: Direction) {
  console.log(`moving ${direction}`);
}

move(Direction.Up); // "moving UP"
move("UP");         // ❌ Argument of type '"UP"' is not assignable to parameter of type 'Direction'.

function parseDirection(input: string): Direction | undefined {
  return (Object.values(Direction) as string[]).includes(input) ? (input as Direction) : undefined;
}

var Direction;
(function (Direction) {
    Direction["Up"] = "UP";
    Direction["Down"] = "DOWN";
    Direction["Left"] = "LEFT";
    Direction["Right"] = "RIGHT";
})(Direction || (Direction = {}));

An enum name lives in both the value world and the type world, just like a class name:

• As a value, Color is the runtime object ({ Red: 0, …, "0": "Red", … }). You can pass it around, iterate it, and index it.
• As a type, Color means "any member of this enum" — effectively the union Color.Red | Color.Green | Color.Yellow | Color.Blue.
• Each member is also a type: Color.Red in a type position is the type of just that member.

To talk about the object at the type level (its keys, for instance), you go through typeof: typeof Color is the type of the object, and keyof typeof Color is the union of member names. Mixing these up is the most common enum confusion.

enum Color {
  Red,
  Green,
  Blue,
}

let c: Color = Color.Red;          // type position: any member
let onlyRed: Color.Red = Color.Red; // member type: just Red
onlyRed = Color.Green;              // ❌ Type 'Color.Green' is not assignable to type 'Color.Red'.

type ColorName = keyof typeof Color; // "Red" | "Green" | "Blue"

function fromName(name: ColorName): Color {
  return Color[name];
}
fromName("Green"); // 1
fromName("Pink");  // ❌ Argument of type '"Pink"' is not assignable to parameter of type '"Blue" | "Green" | "Red"'.

function label(color: Color): string {
  switch (color) {
    case Color.Red:
      return "warm";
    case Color.Green:
    case Color.Blue:
      return "cool";
    default: {
      const unreachable: never = color;
      return unreachable;
    }
  }
}

A const enum is an enum that exists only at compile time. Every use like Direction.Down is replaced with its literal value (1), and no enum object is emitted at all. My notes say "const enum to improve performance" — the gain is one less object and one less property lookup per use, and smaller bundles. In modern engines that lookup is rarely measurable; the bigger reasons to know about const enum today are the restrictions and the build-tool problems.

const enum Direction {
  Up,
  Down,
}

const move = Direction.Down;
console.log(move); // 1

const all = Object.values(Direction); // ❌ 'const' enums can only be used in property or index access expressions or the right hand side of an import declaration or export assignment or type query.
const name = Direction[0];            // ❌ A const enum member can only be accessed using a string literal.

const move = 1 /* Direction.Down */;
console.log(move);

Most enums can be replaced by one of two plain-TypeScript patterns, and many teams now do exactly that:

• A string literal union: type Direction = "up" | "down" | "left" | "right". Pure type, fully erased, no runtime object. Callers pass plain strings and get autocomplete and checking.
• An as const object plus a derived union, when you also want a runtime object (to iterate values, or to write Direction.Up in code). See as const and [Getting every value type with T[keyof T]](#getting-every-value-type-with-t-keyof-t).

The modern push away from enums is about erasability. Tools that strip types without type-checking — Node's built-in TypeScript support, and bundlers running in isolatedModules mode — want TypeScript to be "JavaScript plus annotations you can delete". Enums aren't: they generate code. Node 26 refuses to run a file containing an enum (ERR_UNSUPPORTED_TYPESCRIPT_SYNTAX: TypeScript enum is not supported in strip-only mode), and TypeScript 5.8 added the erasableSyntaxOnly option that turns enums, namespaces with code and parameter properties into compile errors.

From my notes, "enum vs union types" — here are the three side by side:

// 1. enum
enum DirectionEnum {
  Up = "UP",
  Down = "DOWN",
}

// 2. literal union
type DirectionUnion = "UP" | "DOWN";

// 3. as const object + derived union
const Direction = {
  Up: "UP",
  Down: "DOWN",
} as const;
type Direction = (typeof Direction)[keyof typeof Direction]; // "UP" | "DOWN"

function moveEnum(d: DirectionEnum) {}
function moveUnion(d: DirectionUnion) {}
function move(d: Direction) {}

moveEnum(DirectionEnum.Up);
moveEnum("UP"); // ❌ Argument of type '"UP"' is not assignable to parameter of type 'DirectionEnum'.

moveUnion("UP");
moveUnion("SIDEWAYS"); // ❌ Argument of type '"SIDEWAYS"' is not assignable to parameter of type 'DirectionUnion'.

move(Direction.Up); // named access, like an enum
move("DOWN");       // and plain strings work too
const values = Object.values(Direction); // ("DOWN" | "UP")[]

enum Status {
  Active = "ACTIVE",
  Inactive = "INACTIVE",
}
type StatusUnion = "ACTIVE" | "INACTIVE";

const a: StatusUnion = Status.Active;
const b: Status = "ACTIVE";

enum Status {
  Active = "ACTIVE",
  Inactive = "INACTIVE",
}
type StatusUnion = "ACTIVE" | "INACTIVE";

const a: StatusUnion = Status.Active; // fine: an enum member is a subtype of its literal
const b: Status = "ACTIVE";           // ❌ Type '"ACTIVE"' is not assignable to type 'Status'. Did you mean 'Status.Inactive'?