In a TypeScript conditional type, `extends` is often described as "assignable to" rather than "inherits from". What does `type R = { id: number; name: string } extends { id: number } ? 'yes' : 'no'` resolve to, and why?

## The question the checker actually asks When the compiler meets `A extends B ? X : Y`, it runs exactly one test: **is `A` assignable to `B`?** That is, could you pass a value of type `A` into a parameter declared as `B` without an error? If yes, the conditional becomes `X`; if no, it becomes `Y`. The keyword is unfortunate. `extends` also appears on classes (`class Dog extends Animal`) and as a constraint on a type parameter, and those are different jobs. In the conditional position it is neither a declaration nor a restriction — it is a yes/no question about compatibility. ## Structural, not declarative TypeScript's assignability is structural: what matters is the *shape* of the type, not what it was declared to inherit or implement. So the test passes for types that have no declared relationship whatsoever: ```ts type Extends<A, B> = A extends B ? 'yes' : 'no'; type R1 = Extends<Date, { getTime(): number }>; // 'yes' ``` `Date` never says it implements that object type; it simply has a `getTime` method returning a number, and that is enough. Any question of the form "does X extend Y here" is answered by comparing members, not by looking up a declaration. ## Direction: the more specific type goes on the left This is the single most common mistake. Adding members makes a type *more* specific and *more* assignable, not less: ```ts type R2 = Extends<{ id: number; name: string }, { id: number }>; // 'yes' type R3 = Extends<{ id: number }, { id: number; name: string }>; // 'no' ``` In `R2` the left type satisfies every requirement of the right type — it has an `id` of type `number` — and the extra `name` is simply not asked about. In `R3` the left type is missing a required member, so the test fails. The same asymmetry shows up with literals and primitives: ```ts type R4 = Extends<'abc', string>; // 'yes' — a literal is assignable to its primitive type R5 = Extends<string, 'abc'>; // 'no' — string could be any string ``` A useful mental sentence: *the left side must be at least as specific as the right side.* ## Optional members loosen the requirement An optional property is not a requirement, so it does not have to be present: ```ts type R6 = Extends<{ id: number }, { id: number; name?: string }>; // 'yes' ``` The right-hand type only demands `id`; `name` may be absent. This is worth internalising, because it means "has fewer members" and "is not assignable" are not the same statement — it depends which members are required. One related rule does *not* apply here: the excess-property check that rejects `{ id: 1, oops: 2 }` when assigning a fresh object literal to a typed variable is a check on literal expressions in value positions. Type-level assignability, which is what a conditional runs, does not perform it — extra members are simply ignored. ## The `any` special case One result surprises almost everyone: ```ts type R7 = Extends<any, string>; // 'yes' | 'no' ``` When the checked type is `any`, the compiler cannot honestly answer the question either way, so the conditional resolves to the **union of both branches**. This is a documented special rule and a real hazard: a stray `any` leaking into a type-level helper does not pick the convenient branch, it widens the result to everything the helper could ever produce, and the imprecision spreads to whatever consumes it. ## Why this matters beyond trivia Every conditional type you write — and every built-in one — rests on this test. When a conditional "gives the wrong answer", the fix is nearly always to re-read the check as an assignability question and confirm which side is more specific, rather than to reach for an assertion. It also explains a subtlety of writing checks against object types: `T extends { kind: string }` passes for *any* object with a string-typed `kind`, including `{ kind: 'circle'; radius: number }`. A check written to catch one shape will happily catch every richer shape too, which matters as soon as several checks are combined. ## What to say in an interview State the answer (`'yes'`), then the rule (`extends` in a conditional means assignable-to), then the direction (more specific on the left), then one example with no declared relationship at all to prove it is structural. Mentioning the `any` case shows you have actually been surprised by this in practice.