Interfaces and type aliases

Both of these describe the same object:

interface User {
  id: string;
  email: string;
  name?: string;          // may be absent
  readonly createdAt: Date;
}

type UserAlias = {
  id: string;
  email: string;
  name?: string;
  readonly createdAt: Date;
};

name? means the property may be missing, so its type is string | undefined and you have to handle that. readonly stops assignment after construction — at compile time only; nothing prevents it at runtime.

The difference that matters

An interface is open: declaring it twice merges the declarations.

interface Window { myThing: string }   // adds to the existing Window

(That line merges with the DOM's Window only where it is declared in the global scope: a script file, or inside declare global in a module.)

A type alias is closed: declaring it twice is an error. It can, however, name things an interface cannot — a union, a tuple, a mapped or conditional type:

type Status = "draft" | "live";              // interface cannot
type Pair = [string, number];                // interface cannot

So: interface for an object shape others may need to extend, especially a public API or a global. type for everything else. Beyond that the two are interchangeable, and a codebase that picks one and sticks to it is easier to read than one that agonises.

Try it

Structural typing

TypeScript does not care what you called a type. If a value has the right shape, it fits:

function greet(u: { name: string }) { return `Hi ${u.name}`; }

const nino = { name: "Nino", extra: 1 };
greet(nino);                        // fine: it has a name, extra is ignored
greet({ name: "Nino", extra: 1 });  // error: excess property 'extra'

Passing an object literal directly is the exception: excess property checking rejects extra there, on the grounds that you probably made a typo. A later lesson shows what the extra property costs once it gets through.

readonly is a compile-time promise

readonly stops you assigning through that type. It does not freeze the object, and a readonly object may be assigned to a type without readonly, which can then write to it:

When you need the object itself to refuse writes, that is Object.freeze, a runtime call.

Common mistakes

• Interpolating an optional property. A template string accepts undefined without complaint, so removing the ?? u.email from the first example still compiles and prints "undefined (since 2024-01-01)". The optional type protects you only where undefined cannot be used, such as calling a method on it.
• Expecting readonly to protect the object. As above: one assignment to a mutable alias and the "readonly" total is 0.
• Declaring an interface twice by accident. It does not fail; the two merge, and the shape now requires both sets of properties.
• Relying on excess property checks. They only apply to a fresh object literal. Any variable with the right properties gets through, extras and all.

What interviewers ask

• interface or type — how do you choose? An interface can be merged and extended, which suits public object shapes; unions, tuples, mapped and conditional types need type. Otherwise consistency matters more.
• What does structural typing mean in practice? Compatibility is decided by shape, not by name: anything with the required properties fits.
• No. It is checked at compile time only and can be bypassed through a mutable alias; use (shallow) for runtime immutability.