In TypeScript, `enum Status { Active = 'active' }` rejects `const s: Status = 'active'`, while `type Status = 'active' | 'archived'` accepts it. What rule explains the difference, and why does comparing members of two different enums raise an error?

## Structural by default, nominal on purpose TypeScript's type system is structural. Two object types with the same members are interchangeable regardless of their names, and a value belongs to a type when its shape matches. That is why literal unions feel so natural: `type Status = 'active' | 'archived'` says nothing more than "one of these two strings", and any expression whose type is one of those literals is a `Status`. `enum` breaks that rule on purpose. An enum declaration introduces a type whose members are identified by *where they were declared*. Two enums with byte-identical members are two unrelated types, and a bare literal with the right value is not a member of either. ```ts enum Status { Active = 'active', Archived = 'archived' } const s: Status = 'active'; // Error: Type '"active"' is not assignable to type 'Status' const ok: Status = Status.Active; // the only way in ``` So the enum's member type carries an identity beyond its value. This is TypeScript's one built-in nominal-ish construct. ## Cross-enum comparison The same identity rule produces the comparison error people find surprising: ```ts enum Direction { Up, Down } enum Level { Low, High } declare const d: Direction; declare const l: Level; d === l; // Error: This comparison appears to be unintentional because the types // 'Direction' and 'Level' have no overlap d === 5; // Error: ... types 'Direction' and '5' have no overlap ``` At runtime both `Direction.Up` and `Level.Low` are the number `0`, so the comparison would be `true`. The checker refuses it anyway, because the two types share no members *as types*. Reading that error as "the values can never be equal" is the usual misreading; it means "nothing is a member of both types, so you almost certainly did not mean this". This is genuinely useful. If `Direction` and `Level` were both plain numeric aliases, mixing them would compile silently. The enum catches the category error. ## The other side of the trade Nominality costs you at every place a value is produced from outside the type system. ```ts declare const raw: string; // e.g. from JSON const s: Status = raw; // Error: Type 'string' is not assignable to type 'Status' ``` Here the error is welcome — it forces validation. But you also cannot write `{ status: 'active' }` in a test fixture, a config file, or a mock; you must import `Status` and write `Status.Active`. Every module that merely *mentions* a status now takes a runtime dependency on the enum, which is exactly the coupling the emit-cost argument complains about. With a literal union the same code just works: ```ts type Status2 = 'active' | 'archived'; const a: Status2 = 'active'; // fine const obj = { status: 'active' } as const satisfies { status: Status2 }; ``` And the check that mattered is still there — a value typed `string` is *not* assignable to `Status2`, so external data still has to be narrowed. What you give up is only the protection against mixing two different literal unions that happen to share a member: `type Colour = 'red' | 'green'` and `type Light = 'red' | 'amber'` overlap at `'red'`, and assigning between them where they overlap is allowed. ## Choosing between the two behaviours Prefer the union when the values are data that crosses boundaries — payload fields, query parameters, discriminants in messages you serialise. Ergonomics dominate there, and the values genuinely *are* those strings. Prefer nominality when mixing two sets would be a real bug and the sets never travel as raw literals — internal identifiers, unit-like quantities, keys that must not be confused. Note that an enum is not the only way to get it: TypeScript's branded-type pattern gives you nominal behaviour on top of a structural type without emitting anything, and it is the tool to reach for when you want nominality *and* erasability. Reach for the enum when its declaration-site behaviour is the point and you accept the runtime object that comes with it. ## Answering well Name the rule first — structural everywhere, nominal for enums — then show both symptoms (literal not assignable, cross-enum comparison rejected) as consequences of that one rule. Close on the trade rather than a verdict: nominality is a feature when it prevents mixing and a tax at every boundary where values come from outside your code.