TypeScript Inheritance: extends, super and override

A TypeScript class inherits from another with extends. The subclass gets every field and method of the parent, calls the parent constructor with super(...), and can override methods, and TypeScript checks that each override stays compatible with the parent's types.

class Animal {
    constructor(public name: string) {}

    speak(): string {
        return `${this.name} makes a sound`;
    }
}

class Dog extends Animal {
    constructor(name: string, public breed: string) {
        super(name); // call the parent constructor first
    }

    override speak(): string {
        return `${super.speak()}: woof`; // call the parent method
    }
}

const rex = new Dog("Rex", "beagle");
console.log(rex.speak());          // Rex makes a sound: woof
console.log(rex);                  // Dog { name: 'Rex', breed: 'beagle' }
console.log(rex instanceof Animal); // true

This is JavaScript class inheritance (see inheritance in JavaScript for the prototype chain behind it). TypeScript adds the type checks: a Dog is assignable anywhere an Animal is expected, and the compiler verifies the override and the super call.

Overriding Methods

A subclass method with the same name replaces the parent's. Its type must be assignable to the parent's: same or compatible parameters, same or narrower return type. Otherwise any code holding an Animal could call the method with arguments the subclass cannot handle.

class Formatter {
    format(value: number): string {
        return value.toString();
    }
}

class CurrencyFormatter extends Formatter {
    // Compatible: accepts more (number | bigint) and returns the same type.
    override format(value: number | bigint): string {
        return `$${value.toLocaleString("en-US")}`;
    }
}

const formatters: Formatter[] = [new Formatter(), new CurrencyFormatter()];
for (const f of formatters) console.log(f.format(1234567));
// 1234567
// $1,234,567

Changing the parameter to value: string would be error TS2416: Property 'format' in type 'CurrencyFormatter' is not assignable to the same property in base type 'Formatter'. The loop shows why: it calls format with a number on every element, without knowing which subclass it has.

There is one hole. Method parameters are compared bivariantly, so an override that accepts a narrower type, such as format(value: 1 | 2), compiles even though the loop could still pass it 1234567. Return types are checked strictly: returning number instead of string is TS2416.

The override Keyword and noImplicitOverride

override says "this member replaces one in the base class", and the compiler holds you to it. If the base has no such member (a typo, or a method someone renamed in the parent), it is an error:

// This does not compile: the parent has no method called 'speek'.
class Animal {
    speak(): string {
        return "...";
    }
}

class Cat extends Animal {
    override speek(): string {
        return "meow";
    }
}

console.log(new Cat().speak());

index.ts(9,14): error TS4117: This member cannot have an 'override' modifier because it is not declared in the base class 'Animal'. Did you mean 'speak'?

Without override, that typo compiles and speak() silently returns "...". The keyword only helps where it is written, so turn on noImplicitOverride in tsconfig.json. Then every method that overrides a base member must say so, and a plain speak() in a subclass is error TS4114 (This member must have an 'override' modifier because it overrides a member in the base class 'Animal').

{
    "compilerOptions": {
        "strict": true,
        "noImplicitOverride": true
    }
}

noImplicitOverride is not part of strict; you have to add it yourself. override is erased from the compiled JavaScript.

protected Members in Subclasses

private members of the parent are invisible in the subclass. protected members are visible, which is the reason protected exists: it is the API a parent class offers to its children.

class Counter {
    protected count = 0;
    private log: string[] = [];

    increment(): void {
        this.count++;
        this.log.push(`now ${this.count}`);
    }
}

class StepCounter extends Counter {
    constructor(private step: number) {
        super();
    }

    override increment(): void {
        this.count += this.step - 1; // protected: allowed
        super.increment();
        // this.log is private to Counter: a compile error here
    }

    get value(): number {
        return this.count;
    }
}

const c = new StepCounter(5);
c.increment();
c.increment();
console.log(c.value); // 10

See access modifiers for the full rules, including why neither private nor protected is enforced at runtime.

Redeclaring a Field with a Narrower Type

A subclass often knows a field holds something more specific than the parent says. Redeclaring it as pet: Dog has a runtime effect with modern class fields: the subclass field is initialized to undefined after super() returns, wiping out what the parent constructor stored. Unless the subclass constructor assigns it again, TypeScript reports this as TS2612 (Property 'pet' will overwrite the base property in 'Home'). Use declare to change only the type:

class Animal {
    name = "pet";
}
class Dog extends Animal {
    bark(): string {
        return "woof";
    }
}

class Home {
    pet: Animal;
    constructor(pet: Animal) {
        this.pet = pet;
    }
}

class Kennel extends Home {
    declare pet: Dog; // type only: no field is emitted

    constructor(dog: Dog) {
        super(dog);
    }
}

console.log(new Kennel(new Dog()).pet.bark()); // woof

declare emits nothing, so the value set by Home's constructor survives. The constructor that only accepts a Dog is what makes the narrower type true.

implements vs extends

The two keywords answer different questions, and a class can use both.

interface Serializable {
    serialize(): string;
}

class Entity {
    constructor(readonly id: number) {}
}

class User extends Entity implements Serializable {
    constructor(id: number, readonly email: string) {
        super(id);
    }

    serialize(): string {
        return JSON.stringify({ id: this.id, email: this.email });
    }
}

const u = new User(1, "ada@example.com");
console.log(u.serialize()); // {"id":1,"email":"ada@example.com"}

A class can extend only one class (TS1174: Classes can only extend a single class). To combine behavior from several places, implement several interfaces and share code through composition (a field holding a helper object) or mixins.

Mixins

A mixin is a function that takes a class and returns a subclass of it. It gives a form of multiple inheritance that type-checks:

type Constructor<T = {}> = new (...args: any[]) => T;

function Timestamped<TBase extends Constructor>(Base: TBase) {
    return class extends Base {
        createdAt = new Date("2024-03-15T10:30:00Z");
    };
}

function Tagged<TBase extends Constructor>(Base: TBase) {
    return class extends Base {
        tags: string[] = [];
        tag(t: string): this {
            this.tags.push(t);
            return this;
        }
    };
}

class Note {
    constructor(public text: string) {}
}

const TaggedNote = Tagged(Timestamped(Note));
const n = new TaggedNote("buy milk").tag("home");
console.log(n.text, n.tags, n.createdAt.toISOString());
// buy milk [ 'home' ] 2024-03-15T10:30:00.000Z

The any[] in Constructor is required: TypeScript only accepts a mixin base whose constructor takes a single rest parameter of type any[]. Mixins work but make types and stack traces harder to read, so reach for composition first.

Common Mistakes

• Calling an overridable method from the base constructor. The base constructor runs before the subclass's fields are initialized, so an override that reads this.items sees undefined, and a call like this.items.push(x) throws a TypeError at runtime. TypeScript does not catch this.
• Forgetting super(...) or calling it late. Errors TS2377 and TS17009; the parent must build the object before the subclass touches this.
• Redeclaring a parent field without declare. The subclass field resets it to undefined.
• Deep hierarchies. Every level couples the child to the parent's internals. Two levels is usually plenty; prefer composition or interfaces beyond that.