TypeScript enums aren’t the real problem — duplicated UI enum plumbing is

After enough frontend work, the “should we use TypeScript enums?” debate matters less than a more...

After enough frontend work, the “should we use TypeScript enums?” debate matters less than a more practical problem.

The enum itself is rarely the painful part.

The painful part is keeping labels, colors, options, filters, and validation logic in sync.

A status code starts as a simple backend value:

• 0 = draft
• 1 = published
• 2 = archived

Then the UI needs more:

• a human-readable label,
• a translated label,
• a badge color,
• a dropdown option list,
• a table filter list,
• maybe an icon,
• maybe a helper to validate API values.

And suddenly one tiny enum becomes three, four, or five runtime structures spread across your codebase.

That’s the problem this post is really about.

TL;DR

• Native enums and as const objects are both useful.
• Neither one gives you a built-in runtime source of truth for UI metadata.
• enum-plus is most interesting when enum-like values need to drive labels, metadata, i18n, and UI lists from one definition.
• If you only need constants and types, you probably don’t need it.

The usual frontend enum mess

A typical codebase ends up with something like this:

export enum ArticleStatus {
  Draft = 0,
  Published = 1,
  Archived = 2,
}

export const articleStatusLabels: Record<ArticleStatus, string> = {
  [ArticleStatus.Draft]: 'Draft',
  [ArticleStatus.Published]: 'Published',
  [ArticleStatus.Archived]: 'Archived',
};

export const articleStatusColors: Record<ArticleStatus, string> = {
  [ArticleStatus.Draft]: 'gray',
  [ArticleStatus.Published]: 'green',
  [ArticleStatus.Archived]: 'red',
};

export const articleStatusOptions = [
  { value: ArticleStatus.Draft, label: articleStatusLabels[ArticleStatus.Draft] },
  { value: ArticleStatus.Published, label: articleStatusLabels[ArticleStatus.Published] },
  { value: ArticleStatus.Archived, label: articleStatusLabels[ArticleStatus.Archived] },
];

None of this code is wrong.

The problem is that one business concept now lives in multiple runtime structures, and they drift unless someone keeps them aligned.

as const solves one problem — not all of them

A plain as const object is still my default when I only need constants and a union type:

const ArticleStatus = {
  Draft: 0,
  Published: 1,
  Archived: 2,
} as const;

type ArticleStatus = typeof ArticleStatus[keyof typeof ArticleStatus];

That works well for type-level constraints.

It stops being enough when the same values also need labels, i18n, colors, option lists, reverse lookups, or extra metadata at runtime.

What enum-plus is actually good at

enum-plus is easy to describe as “a drop-in replacement for native enum”, but I think that undersells the most useful part.

enum-plus seems most useful when you want one runtime definition to drive both typed values and UI-facing data such as labels, metadata, and option lists.

That means your enum can power:

• application logic,
• display labels,
• localization,
• dropdowns and menus,
• table filters,
• metadata lookups,
• validation and lookup helpers.

And it does this in a package that is:

• zero dependency,
• TypeScript-friendly,
• usable in JavaScript too,
• compatible with frontend frameworks and SSR.

A more useful enum definition

Here’s a practical example:

import { Enum } from 'enum-plus';

const ArticleStatus = Enum({
  Draft: {
    value: 0,
    label: 'Draft',
    color: 'gray',
    icon: 'edit',
  },
  Published: {
    value: 1,
    label: 'Published',
    color: 'green',
    icon: 'check-circle',
  },
  Archived: {
    value: 2,
    label: 'Archived',
    color: 'red',
    icon: 'archive',
  },
});

Now one definition can drive multiple use cases:

ArticleStatus.Published;             // 1
ArticleStatus.label(1);              // 'Published'
ArticleStatus.key(1);                // 'Published'
ArticleStatus.items;                 // UI-friendly iterable items
ArticleStatus.findBy('color', 'red') // enum item lookup
ArticleStatus.named.Published.raw;   // { value: 1, label: 'Published', color: 'green', icon: 'check-circle' }

And if you want direct access to one metadata field:

ArticleStatus.named.Published.raw.color; // 'green'

That may not look dramatic at first glance, but it removes a lot of scattered glue code.

Why this matters in real frontend code

Suppose your backend returns article rows with a numeric status field.

Your UI might need to:

• render a label in a table,
• render a badge color,
• create filter options,
• populate a form select,
• localize the display text.

With the usual approach, these concerns get split across separate maps and helpers.

With a runtime enum definition, they can come from one place.

That doesn’t just save lines of code.

It reduces the number of places where your business vocabulary can silently diverge.

Native enum vs as const vs enum-plus

Here’s the practical tradeoff table I wish more articles included:

So no, enum-plus is not the right answer for every project.

But it is a strong answer for projects where enum-like values need to drive UI and business display behavior.

What changed my mind about this category

A lot of enum discussions in TypeScript are framed around language purity:

• should we use enums at all?
• should we prefer unions?
• should we use as const objects instead?

Those are valid questions.

But in app development, the bigger problem is often operational duplication rather than syntax.

If a single backend code needs to become:

• a readable label,
• a localized label,
• a select option,
• a filter option,
• a badge color,
• a searchable lookup,

then the real design question becomes:

Where does that information live?

That’s the question enum-plus answers better than native enums do.

When I would not use enum-plus

This part matters.

I would not use enum-plus if:

1. I only need a few constants and a union type.
2. I don’t need runtime labels or metadata.
3. I’m writing a tiny module where plain objects are simpler.
4. My team strongly prefers zero abstraction over convenience helpers.
5. I don’t want another runtime dependency.
6. My team already has a stable plain-object pattern that works well.
7. My enum definitions are generated from API types and I don’t want a wrapper layer.

In those cases, as const may be all you need.

But if your codebase keeps rebuilding the same label maps, option arrays, and metadata dictionaries around status-like values, then it’s worth a serious look.

Why this project seems worth watching

A few things make the repo more credible than a random experiment:

• active release history,
• multiple contributors,
• zero dependencies,
• migration docs,
• plugin system,
• support for frontend-oriented use cases that many teams actually hit.

That combination matters more to me than hype.

Final thought

I don’t think the strongest pitch for enum-plus is:

“TypeScript enums, but better.”

I think the stronger pitch is:

“A single runtime source of truth for values your UI needs to display, translate, color, filter, and select.”

I wouldn’t use this everywhere.

But if your frontend repeatedly turns one enum into labels, colors, options, filters, and lookup helpers, then a runtime enum definition can be a reasonable abstraction.

Repo: https://github.com/shijistar/enum-plus