Your TypeScript monorepo models closed value sets inconsistently — some packages use enums, others string-literal unions. How would you decide on a standard, and what would you do about numeric enums whose values are already stored in the database and sent on the wire?

## Treat it as a decision rule, not a ban "No enums" is a rule people route around and argue about. A decision rule survives, because it names the constraints that actually differ between packages. **Does the value cross a serialization boundary?** If it appears in an HTTP payload, a queue message, a database column or a URL, the representation is a contract with systems you do not compile. It must be a stable, self-describing string. A numeric enum is the worst option here: the number carries no meaning in a log or a stored row, and the auto-numbering is positional, so inserting a member in the middle silently renumbers everything after it. That failure mode is not hypothetical and not detectable by the compiler. **Does anything need the members at runtime?** Validation at boundaries, rendering a select, building a lookup — those need a real value, so use an `as const` object with the derived union type. If the set is purely a compile-time constraint, use a bare literal union and emit nothing at all. **Does the build constrain syntax?** Pipelines that strip types instead of transforming them, and the compiler's own `erasableSyntaxOnly` flag, reject `enum` outright. If any target in the repo has that constraint, the answer is decided for every package that might be consumed by that target — this is where the choice stops being style and becomes portability. **Is preventing accidental mixing genuinely valuable here?** That is the one thing enums give you that a union does not. Where it matters — two identifier kinds that must never be confused — a branded type gives the same protection while staying erasable, so even this case rarely argues for an enum. ## The published-package angle An enum exported from a package is part of the *runtime* API surface, not just the type surface. Consumers cannot pull it in with a type-only import and still produce members, so it becomes a real dependency edge. Removing or renaming a member is a runtime breaking change for them, not a type change they can absorb with a version bump of their checker. Literal unions and `as const` objects keep those two surfaces separable, which matters more the more packages you publish. ## Handling values already in the data The governing constraint is that stored data is not yours to reinterpret. So separate two changes that look like one: **Change the type layer, freeze the values.** Replacing an enum with an `as const` object that carries the identical values is invisible outside the compiler: ```ts // before enum Priority { Low = 1, High = 2 } // after — identical runtime values, identical call sites export const Priority = { Low: 1, High: 2 } as const; export type Priority = (typeof Priority)[keyof typeof Priority]; ``` Nothing on the wire moves, no rows change, and `Priority.Low` still reads the same at every call site. As a bonus the numeric-enum assignability hole closes: a value typed `number` is not assignable to `1 | 2`, so the compiler now demands the boundary validation that was previously optional. Expect that to surface real errors — treat them as the point of the exercise, not as breakage. **Change the representation only deliberately.** Turning `1` into `'low'` in stored data is a migration: dual-write or a translation layer at the edge, a backfill, a read path that tolerates both, and a cleanup. Worth doing when the numbers are actively causing incidents or when you are already reshaping that payload; not worth doing as a side effect of a typing convention. Where numbers must stay on the wire, put the translation at the boundary — parse to a named string internally, serialise back to the number on the way out — so exactly one module knows the numeric mapping. ## Rolling it out Sequence by risk, not by package alphabet. Start with internal, non-serialised enums, where the change is invisible. Then shared packages, where the payoff in consumer coupling is largest. Leave enums embedded in wire formats until someone touches that format for another reason. Make the convention mechanical: a lint rule that flags new enum declarations with a documented exception list beats a review habit, because it survives turnover. Codemod the mechanical part — the declaration change is repetitive and the call sites do not move. And write down the exceptions honestly; a standard with no exceptions is a standard people ignore quietly. ## What to measure Define success before you start, or the effort drifts. Reasonable signals: no numeric values in new serialized contracts; every boundary parsing a closed-set field has a validation step; packages consumable by type-stripping builds. Bundle bytes are the weakest justification on its own — real if you are shipping many enums to browsers, but rarely the argument that decides it. ## What a strong answer sounds like Lead with the decision rule and its constraints, be explicit that stored values are frozen and that the type change and the representation change are separate projects, and finish on enforcement and sequencing. Insisting on a repo-wide rewrite, or waving away the persisted numbers, is what makes this answer fail.