TypeScript's enum predates the wide adoption of literal union types and still shows up in real code, especially in codebases with a C#/Java background:
enum Direction {
Up,
Down,
Left,
Right,
}
function move(dir: Direction) { /* ... */ }
move(Direction.Up);
A numeric enum compiles to a real runtime object (unlike almost everything else in TypeScript's type system, it is not erased) and, unless given explicit values, its numbering starts at 0 and can shift unexpectedly if members are reordered. A const enum avoids emitting that object by inlining values at every use site, but has compatibility caveats with some build tools (notably isolated-file transpilers like Babel, which can't safely inline it without full type information).
type Direction2 = "up" | "down" | "left" | "right"; // no runtime object at all — pure type-erased
function move2(dir: Direction2) { /* ... */ }
move2("up");
enum | Union of string literals | |
|---|---|---|
| Runtime footprint | Real object emitted (unless const enum) | None — fully erased |
| Refactoring safety | Renaming a member updates all usages via the compiler | Same, via find-and-replace on the literal string |
| Serializes cleanly to JSON | Numeric enums serialize as numbers, easy to misread | String literals are self-describing in JSON payloads |
| Common modern preference | Less common in new code | The more idiomatic modern default for most codebases |
Most current style guides (including TypeScript's own team, in various public statements) lean toward plain union literal types for new code, reserving enum for cases where you specifically want the extra runtime object (e.g. iterating over all values).