TypeScript enums. Why you should stop using them?

What are enums and why do we use them?

How to recognize an inexperienced programmer:

// typo-prone code
if (status !== "active") {
  await sendActivationEmail();
}

We know this is a bad idea. A small typo is enough, and our active users will get flooded with activation emails. Not very professional.

// oops!
if (status !== "activr") {
  await sendActivationEmail();
}

And here comes the enum, saving the day!

enum Status {
  Active = "active",
  Disabled = "disabled",
}

if (status !== Status.Active) {
  await sendActivationEmail();
}

Looks nice. But it introduces unnecessary complexity.

• The “enum footprint” follows us everywhere — we have to import it in every file where we operate on the variable.
• After transpilation (TypeScript → JavaScript), it generates additional JavaScript (extra bundle size).

// this is how enums look in JavaScript
var Status;
(function (Status) {
  Status["Active"] = "active";
  Status["Disabled"] = "disabled";
})(Status || (Status = {}));

• It breaks DRY — for small enums this might sound like a joke, but verbose ones can get truly ugly:

FOREIGN_LINKED_BANK_ACCOUNT_PROFILE = "FOREIGN_LINKED_BANK_ACCOUNT_PROFILE";
PENDING_THIRD_PARTY_PAYMENT_VERIFICATION =
  "PENDING_THIRD_PARTY_PAYMENT_VERIFICATION";
TWO_FACTOR_AUTHENTICATION_BYPASS_ATTEMPT =
  "TWO_FACTOR_AUTHENTICATION_BYPASS_ATTEMPT";

• It reduces readability by making simple comparisons longer than it should:

if (type === InternalWebhookTypes.FOREIGN_LINKED_BANK_ACCOUNT_PROFILE)

Alternatives?

Literal types!

type Status = "active" | "disabled";

if (status !== "active") {
  await sendActivationEmail();
}

Clear and readable, with no JavaScript overhead. The Status type does not exist in the JavaScript value space, so we don’t have to import anything. It does type-checking magic silently in the background. In most cases, this is exactly what we want: clean, quiet, and elegant.

Sometimes, however, you may want access to these values at runtime. For example, if you want to render all options in a UI:

Object.values(Status).map(d => <option value={d}>{d}</option>)

This is not possible because Status does not exist at runtime. Back to enums? Actually, there is a third pattern we can use instead. It combines the simplicity of literal types with runtime availability. The type is derived from the value automatically, so they can never drift apart.

export const Status = ["active", "disabled"] as const;
export type StatusType = (typeof Status)[number];

interface User {
  status: StatusType;
}

// still works!
if (status !== "active") {
  await sendActivationEmail();
}

Rule of thumb

• Literal type → you only need type checking, no runtime iteration. The most common case.
• as const array/object → you need runtime access to all values (validation, UI lists, etc.).
• Enum → mostly when working with external code that already uses them. Generally avoid otherwise.

TL;DR

Enums aren’t inherently bad, but replacing them with literal types or the as const array/object pattern provides the same benefits with greater elegance.