Do Not Use TypeScript Enum?

What is Enum’s fault?

Introduction: The Enum Controversy 🎭

TypeScript enums have been a subject of debate since their inception. Many developers, including seasoned professionals, have voiced concerns about their usage, leading to a “DO NOT USE TypeScript Enum” movement. But are enums really that problematic? Let’s explore the recent developments and alternatives that have sparked this conversation.

The Erasable Syntax Revelation 🧐

With the release of TypeScript 5.8, a new configuration option called --erasableSyntaxOnly was introduced. This option only allows "erasable syntax" in TypeScript files. But what exactly is erasable syntax, and why does it matter?

Erasable vs. Non-Erasable Syntax

• Erasable Syntax: This includes TypeScript-specific constructs that don’t generate additional runtime code, such as type, interface, and type annotations like let n: number.
• Non-Erasable Syntax: These are constructs that generate additional JavaScript code at runtime, including enum, namespace (with runtime code), and class parameter properties.

The Node.js Connection 🔗

The introduction of --erasableSyntaxOnly is closely tied to recent changes in Node.js:

• Node.js 22: Introduced the ability to execute TypeScript files with --experimental-transform-types.
• Node.js 23.6.0: Now supports direct execution of TypeScript files with erasable syntax by default.

TypeScript’s new option aligns with these Node.js changes, allowing developers to ensure their code only uses syntax that Node.js can directly execute.

The Three Sins of Enums 😈

Despite their popularity, enums in TypeScript have several drawbacks that have led to their controversial status:

1. Default Enumeration Values: Enums start from 0 by default, and allow numeric values to be passed where enum types are expected, potentially leading to type safety issues.
2. Lack of Support for Enum Value Literals: You can’t use string literals that match enum…