extends vs Intersection (&)

## Two ways to compose a shape TypeScript gives you two syntactic ways to say "this shape is that shape plus more": ```typescript interface A { id: string } interface B1 extends A { createdAt: Date } type B2 = A & { createdAt: Date }; ``` When the added members do not collide with the inherited ones, the two results are for practical purposes interchangeable — both types have `id: string` and `createdAt: Date`, and each is assignable to the other. The interesting behaviour appears only when a name collides. ## `extends` performs a check; the member is overridden A heritage clause is a *constraint*. The compiler verifies that the derived interface is assignable to each parent, and the derived declaration of a name replaces the inherited one. So the rule is: **a redeclared member must be assignable to the member it hides.** ```typescript interface Wide { id: string | number } interface Narrow extends Wide { id: string } // OK — string is assignable to string | number ``` `Narrow['id']` is exactly `string`. Reverse the relationship and the check fails: ```typescript interface A { id: string } interface B extends A { id: number } // Error: Interface 'B' incorrectly extends interface 'A'. // Types of property 'id' are incompatible. Type 'number' is not assignable to type 'string'. ``` The important property is *where* the error lands: on the declaration of `B`, in the file where the mistake was made, before any value exists. ## `&` performs no check; the member types are intersected An intersection is not inheritance and there is no notion of "the later one wins". `A & { id: number }` has one member `id` whose type is the intersection of the two contributions, `string & number`. Since no value is simultaneously a string and a number, TypeScript reduces that intersection to `never`. ```typescript interface A { id: string } type B = A & { id: number }; declare const b: B; const check: never = b.id; // compiles: b.id really is never ``` Writing the type is legal. Nothing is reported. The type is simply uninhabited in that member, and every later attempt to produce a `B` fails: ```typescript const broken: B = { id: 1 }; // Error here, far from the declaration ``` When the colliding members are *literal* (unit) types acting as discriminants, the reduction can go further and collapse the whole object type to `never`, not just the one member — so `{ kind: "a" } & { kind: "b" }` is an unusable type overall. Either way you learn about it at the call site, which may be in a different package. ## Why one errors and the other does not The asymmetry follows from what each construct *means*. `extends` states a subtype relationship, and a subtype relationship is checkable at the point of declaration, so the compiler checks it. `&` is a type-level operator: it computes a type the way `+` computes a number. An operator has no obligation to be satisfiable — `string & number` is as well-formed as it is useless, exactly like `never` itself. Reporting an error there would break legitimate generic code such as `T & U`, where the operands are unknown at the time the alias is written. ## Multiple parents With several parents the check tightens. `interface C extends A, B` requires any property inherited from both to have **identical** types, not merely compatible ones, unless `C` redeclares it: ```typescript interface A { id: string } interface B { id: number } interface C extends A, B {} // Error: Interface 'C' cannot simultaneously extend types 'A' and 'B'. // Named property 'id' of types 'A' and 'B' are not identical. ``` The intersection `A & B` again stays quiet and hands you `id: never`. ## Practical consequences - Prefer `extends` when composing named object shapes. It is the earlier, louder failure, its hover output is a single named type rather than a chain of `&`, and the TypeScript team's own performance guidance recommends interfaces over large intersections because an interface's member list is computed once and cached, whereas an intersection's members are recomputed during comparisons. - Reach for `&` when the left operand is something an interface cannot extend — a union, a conditional type, or a bare type parameter in generic code. - When you must intersect, treat `never` members as the diagnostic. If a value "should obviously be assignable" and the error is baffling, hover the member: a `never` there means two constituents disagreed and nobody told you. - None of this survives compilation. Both forms are erased entirely; the difference is purely in what the checker says and when it says it.