Your TypeScript library exports a discriminated union of event types, and consumers switch over it exhaustively so the leftover value in `default` is `never`. Adding one member breaks every consumer's build. How do you weigh keeping that compile-time exhaustiveness against letting consumers absorb unknown members?

## The exhaustiveness check is a contract, not a style choice When a consumer writes a `default` branch that assigns the leftover value into a `never`-typed position, they are asserting: *this union will not grow without me noticing.* That assertion is enormously useful and it is also a coupling. Every member you add invalidates it. Whether that is a feature or a defect depends entirely on who owns the compile step. ## Inside one build, breakage is the point For a union that lives in the same repository as its consumers, forcing the break is close to strictly good. Adding a member and fixing the resulting errors is one change, reviewed together, and the compiler produces the exact list of places that must be updated. The alternative — a permissive default everywhere — means the new member silently takes the fallback path and the gap surfaces as behaviour rather than as a build failure. Here you should encourage exhaustive switches, and you may reasonably enforce them in review. ## Across a package boundary, breakage is a cost you are imposing Once the union is exported and consumers upgrade on their own schedule, the calculus inverts. A new event type is conceptually additive — old consumers do not need to care about it — but the exhaustive switch turns it into a compile error, so the release is semver-major. You now pay for every additive change with a major version, a migration note and a long tail of pinned consumers. Worse, consumers under upgrade pressure will "fix" it by widening their default branch or reaching for an escape hatch, which is a worse outcome than if you had asked for a fallback in the first place. ## The decision: is the union closed or open? **Closed union.** The set of members is finite, semantically complete and owned by you: HTTP method, payment status in a fixed state machine, the arms of a result type. Additions are genuinely rare and genuinely require consumer attention. Publish it as closed, document that additions are major, and let consumers rely on exhaustiveness. **Open union.** The set is expected to grow: event types on a bus, telemetry kinds, plugin messages, anything mirroring a protocol you do not fully control. Publish it as open, document that consumers must handle unrecognised members, and expect the additions to be minor. The failure mode in real codebases is not choosing wrong; it is never deciding, so the type is closed by accident and every addition triggers an argument. ## Making the choice legible A few things make the intent survive contact with consumers: - **Say it in the doc comment on the exported type.** "This union is open — handle unknown members" is the cheapest and most effective control you have. - **Give the open union a real fallback member** rather than expecting consumers to invent one. An explicit member such as `{ kind: 'unknown'; raw: unknown }` that your own parsing produces for unrecognised input turns the fallback into a typed, handled path instead of an unmodelled hole — and keeps consumers' switches exhaustive over a union that no longer needs to grow for every new upstream kind. - **Keep the internal union closed.** Nothing stops you from switching exhaustively over a rich internal union and mapping it onto a narrower, more stable public one. That is the usual way to get both properties: strict checking where you own the build, stability where you do not. - **Version the type with the runtime.** If consumers can install a package version whose types describe more members than the runtime emits, or fewer, the exhaustiveness story is noise anyway. ## Second-order effects worth naming - **Ecosystem size.** Ten internal consumers you can fix in an afternoon is a different problem from an open-source package with unknown adopters. - **Cost of missing a case.** If an unhandled event silently drops a payment, the forced break is cheap insurance. If it merely skips a log line, the major version is poor value. - **Upgrade coupling.** Forced breaks encourage consumers to pin old versions, which is precisely the population you least want stuck on stale code when a security fix ships. - **Deprecation of members.** Removing a member breaks consumers even when the union is open, so the open/closed decision only governs additions. ## What a strong answer sounds like It does not defend one position universally. It separates the same-repository case (break loudly, the compiler is your migration list) from the published-package case (additive should stay minor), names the closed-versus-open decision as the thing that must be written down, and offers the internal-strict/external-stable split as the way to keep both. It also acknowledges the pre-existing consumers: whichever policy you adopt, the first release that changes it is itself a breaking change and needs to be communicated as one.