TypeScript enums: use cases and alternatives

One thing I'm missing in the comments here is that enums are a very early TypeScript feature. They were in there nearly from the start, when the project was still trying to find clarity on its goals and principles.

Since then:

- TypeScript added string literals and unions, eg `type Status = "Active" | "Inactive"`

- TypeScript added `as const`, eg `const Status = { Active: 0, Inactive: 1 } as const`

- TypeScript adopted a stance that features should only generate runtime code when it's on a standards track

Enums made some sense back when TS didn't have any of these. They don't really make a lot of sense now. I think they're effectively deprecated, to the point that I wonder why they don't document them as deprecated.

After almost a decade of TypeScript my recommendation is to not use TypeScript enums.

Enums is going to make your TypeScript code not work in a future where TypeScript code can be run with Node.js or in browser when typings are added to JavaScript[1]

Enums results in runtime code and in most cases you really want type enums. Use `type State = "Active" | "Inactive"` and so on instead. And if you really want an closed-ended object use `const State = { Active: 1, Inactive: 0 } as const`

All of the examples in the article can be achieved without enums. See https://www.typescriptlang.org/play/?#code/PTAEFEA8EMFsAcA2B...

[1] https://github.com/tc39/proposal-type-annotations

I use TypeScript in a way that leaves no TS traces in compiled JS. It means no enums, no namespaces, no private properties, etc.

Great list of such features: https://www.totaltypescript.com/books/total-typescript-essen...

TS has a great type system, the rest of the language is runtime overhead.

The suggested alternative looks overly complex to me. Moreover, it uses the `__proto__` property that is deprecated [0] and never was standardized. I could write something like this instead:

  type MyEnum = typeof MyEnum[keyof typeof MyEnum];
  const MyEnum = {
    A: 0,
    B: 1,
  } as const;

  enum MyEnum {
    A = 0,
    B = 1,
  }

This is why I'm still using TypeScript enum, even if I really dislike the generated code and the provided features (enum extensions, value bindings `MyEnum[0] == 0`).

Also, some bundlers such as ESbuil are able to inline some TypeScript enum. This makes TypeScript enum superior on this regard.

In a parallel world, I could like the latter to be a syntaxic sugar to the former. There were some discussions [1] for adopting a new syntax like:

  const MyEnum = {
    A: 0,
    A: 1,
  } as enum;

[1] https://github.com/microsoft/TypeScript/issues/59658

After several iterations (some of which older than TS native enums if I remember well), this is the Enum code I ended up with. It creates type, "accessors" (`MyEnum.value`), type guard (`isMyENum(...)`) and set of values (`for(const value of MyEnum)`), and have 2 constructor to allow easier transition from TS native enum.

https://gist.github.com/forty/ac392b0413c711eb2d8c628b3e7698...

I think type-level string unions are the way to go. They're concise, efficient (the strings are interned anyway), and when you're debugging you know what the values are rather than getting mysterious integers.

I personally see TS enums as an anti-pattern.

One big reason: you can't name it interfaces.d.ts, or import as type, which has widespread implications:

Your types are now affecting your shipped bundles.

Sure that's a small bit of size - but it can actually lead to things like server side code getting shipped to the client.

Whereas if it's all .d.ts stuff you know there's no risk of chained dependencies.

I'd go so far as to say default eslint rules should disallow enums.

I like how this article demystifies TypeScript enums—especially around numeric vs. string values and all the weird runtime quirks. Personally, I mostly steer clear of numeric enums because of that dual key/value mapping, which can be as confusing as Scala’s old-school Enumeration type (where numeric IDs can shift if you reorder entries). In Scala, it’s often better to use sealed traits and case objects for exhaustiveness checks and more explicit naming—kind of like TS’s union-of-literal types.

If you just need a fixed set of constants, union types with never-based exhaustiveness checks feel simpler and more “ADT–style.” That approach avoids generating the extra JS code of enums and plays nicer with certain “strip-only” TypeScript setups. In other words, if you’ve ever regretted using Enumeration in Scala because pattern matching turned messy or IDs moved around, then you’ll probably want to keep TypeScript enums at arm’s length too—or at least stick to string enums for clarity.

I don’t understand all these comments. I use TS enums like I use Java enums and I literally never have issues. What are y’all doing with these?

This article could be an unintentional case study in why letting patterns emerge beats designing them upfront. Java devs insisted on enum classes while JS devs gravitated towards plain objects tells us something about language evolution.

Makes me wonder if it was a mistake to include them at all instead of letting the community converge on patterns naturally, like we did with so many other JS patterns.

For someone who writes TS only occasionally and mostly doesn't care about the JS ecosystem, this is a great article. I picked up a few tricks. That said, normalization of warts is a common thing in JS, and people tend to just live with it rather than fix it. This feels like another example of that.

In Go, if something is discouraged (unsafe, runtime, reflection shenanigans), you immediately know why. The language is mostly free of things that exist but you shouldn’t use.

TS was a breath of fresh air when it came out. I never took Node seriously for backend work—it was always something I reluctantly touched for client-side stuff. But TS made some of JS’s warts bearable. Over time, though, it’s added so many crufts and features that these days, I shudder at the thought of reading a TS expert’s type sludge.

Had a quick look but I was surprised to see using a Set.

Personally I use a plain string union. If I need to lookup a value based on that I’ll usually create a record (which is just a stricter object). Typescript will error if I tried to add a duplicate.

This is all enforced at build time, whereas using a Set only happens at runtime.

    type Fruit = ‘apple’ | ‘banana’;

    const lookup: Record<Fruit, string> = { ‘apple’: ‘OK’, ‘banana’: ‘Meh’ }

It isn’t forced to be a 1:1 map of string to string; I’ll often use string to React components which is really nice for lots of conditional rendering.

On a slightly related topic, I also feel that the ‘type’ keyword is far more useful and preferable than ‘interface’. [1]

[1]: https://www.lloydatkinson.net/posts/2023/favour-typescript-t...