In TypeScript, `type Status = 'draft' | 'live' | 'archived'` and someone writes `Exclude<Status, 'archivd'>` with a typo. Why does that compile without any error, what does it evaluate to, and how would you make such a filter fail loudly?

## Why it compiles `Exclude` is an ordinary type alias, not compiler magic: ```ts type Exclude<T, U> = T extends U ? never : T; ``` Neither parameter carries a constraint. `U` is only ever used on the right of `extends`, where its job is to answer an assignability question, and *any* type can answer that question. There is nothing for the compiler to object to when you pass `'archivd'`, `number`, or `{ nope: true }`. `'draft' extends 'archivd'` is simply false — as it is for every member — so every member takes the `else` branch and survives. The result is `'draft' | 'live' | 'archived'`: the untouched union. ## Why that is worse than an error The type still *looks* narrowed everywhere it is used. A function declared `function publish(s: Exclude<Status, 'archivd'>)` accepts `'archived'` happily, and the switch inside it silently loses its exhaustiveness benefit. Nothing fails until run time, when an archived record takes a code path built on the assumption that it could not. The defect has all the properties of the worst class of type bug: no error, no diff-visible symptom, and a type name that reads correct. `Extract` fails in the opposite direction and is usually easier to catch. `Extract<Status, 'archivd'>` is `never`, and `never` accepts no values at all, so the first assignment or call using it errors — but the error points at the *use site*, complaining that `'archived'` is not assignable to `never`, with no hint that a typo three files away is the cause. ## Fix 1: constrain the filter A one-line wrapper reinstates the check the built-in deliberately omits: ```ts type ExcludeStrict<T, U extends T> = Exclude<T, U>; type Editable = ExcludeStrict<Status, 'archived'>; // 'draft' | 'live' // type Oops = ExcludeStrict<Status, 'archivd'>; // Error: Type '"archivd"' does not satisfy the constraint 'Status'. ``` The error now lands exactly on the typo. The same trick works for tag-driven helpers over object unions: constrain the tag parameter to the union of real tags, `K extends Action['type']`, rather than passing a free-form filter object. This is a deliberate trade, not a bug in the standard library. Unconstrained `U` is what lets `Exclude` be used with filters that overlap the union only partly — `Exclude<T, null | undefined>` on a `T` that may contain neither is legitimate and common, and a constraint would reject it. So `ExcludeStrict` is the right tool for a closed, hand-written literal union, and plain `Exclude` for generic plumbing. ## Fix 2: assert the derived type For unions that drive real logic, pin the result with a compile-time assertion rather than trusting the computation: ```ts type Equals<A, B> = (<T>() => T extends A ? 1 : 2) extends (<T>() => T extends B ? 1 : 2) ? true : false; type Assert<T extends true> = T; type _check = Assert<Equals<Editable, 'draft' | 'live'>>; ``` If someone edits `Status`, or a filter stops matching, `_check` fails to compile. Put these in a dedicated types test file so they are cheap to read and obviously not production code; dedicated type-testing libraries offer the same thing with nicer output. ## Fix 3: make the union impossible to mistype The deeper fix is often to stop hand-writing the filter literal at all. Derive both the union and the subsets from one declared source, so the only literal in play is written once: ```ts const STATUSES = ['draft', 'live', 'archived'] as const; type Status2 = (typeof STATUSES)[number]; // 'draft' | 'live' | 'archived' ``` Now a filter still has to name a literal, but the editor autocompletes it from the constrained helper, and the union itself cannot drift from the runtime list. ## What to say in the interview The complete answer has three beats: the mechanism (`U` is unconstrained, so a non-matching filter is a no-op rather than an error), the consequence (silent under-filtering with `Exclude`, a distant `never` error with `Extract`), and the remedy (constrain the filter for closed unions, assert derived types in tests, and prefer autocompleted literals over hand-typed ones). Mentioning that the laxity is intentional — it is what makes the utility usable in generic code — shows you understand the design and are not just complaining about it.