"Pure" Replacement for Enums (Erasable Constants)

[Boukeng-rochinel]

🔍 Search Terms

The Problem: Traditional enum in TypeScript generates an IIFE (Immediately Invoked Function Expression) at runtime, which breaks "type-stripping".
The Proposal: Introduce a new syntax, such as const enum type Name { ... }, that behaves exactly like an as const object but provides the dedicated ergonomics of an enum. It should be 100% erasable, leaving only a simple object literal in the emitted JavaScript.

✅ Viability Checklist

• This wouldn't be a breaking change in existing TypeScript/JavaScript code
• This wouldn't change the runtime behavior of existing JavaScript code
• This could be implemented without emitting different JS based on the types of the expressions
• This isn't a runtime feature (e.g. library functionality, non-ECMAScript syntax with JavaScript output, new syntax sugar for JS, etc.)
• This isn't a request to add a new utility type: https://github.com/microsoft/TypeScript/wiki/No-New-Utility-Types
• This feature would agree with the rest of our Design Goals: https://github.com/Microsoft/TypeScript/wiki/TypeScript-Design-Goals

⭐ Suggestion

I propose a new, fully erasable version of enum that aligns with modern Type Stripping standards. This would provide the developer experience of an Enum (autocompletion, grouping, and type safety) but compile to a simple, standard JavaScript object literal—or be erased entirely if used only for types.

📃 Motivating Example

The Problem: "The Enum Tax"
Today, if you want a set of named constants in TypeScript, you have to choose between clean syntax (Enums) or clean output (Objects).
Standard Enums generate a "magic" IIFE (Immediately Invoked Function Expression) that is difficult for modern bundlers to tree-shake and impossible for "Type-Stripping" runtimes (like Node.js 23+) to handle without a heavy transpilation step.
typescript
// ❌ Current Enum: Generates 7+ lines of complex JS
enum Status {
Pending,
Active
}

// Resulting JS (Hard to optimize):
var Status;
(function (Status) {
Status[Status["Pending"] = 0] = "Pending";
Status[Status["Active"] = 1] = "Active";
})(Status || (Status = {}));

💻 Use Cases

1. What do you want to use this for? for my personal projects
2. What shortcomings exist with current approaches?
3. What workarounds are you using in the meantime?

[MartinJohns]

https://www.typescriptlang.org/docs/handbook/enums.html#const-enums

[nmain]

Search terms: ...

The Github search engine can't do anything useful with all of that! Try something simpler. When I search for enum iife, I get #62883. Based on "compile to a simple, standard JavaScript object literal", I think this is what you're looking for?

[jcalz]

It's not obvious to me what the actual proposal is, since the examples above are either examples of what already happens, or a sketch of a syntax with an ellipsis where code should be. You can't have something 100% erasable that also leaves an object literal; that's a contradiction... unless the object literal is present in the TS code as an object literal, but I don't see that here.

To make it actually erasable it would need to look something like

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

where as enum is simply erased on transpilation... and where the type checker behaves somewhat as if you had written enum X { A, B } (but lacks reverse mappings, and note you have to explicitly write out 0 and 1 there).

But now it feels like I'm actually writing the feature proposal instead of just trying to comprehend it.
EDIT: My interpretation looks like #60790

[Boukeng-rochinel]

https://www.typescriptlang.org/docs/handbook/enums.html#const-enums

I'm aware of const enums, but they don't actually solve the problem for modern Type-Stripping runtimes.
Currently, const enums are removed entirely during compilation. This means if you use them in a project that doesn't use a heavy build step (like Node's new --experimental-strip-types or Deno), the code crashes at runtime because the object is missing.
My proposal is for an enum that emits a plain JavaScript object instead of an IIFE. This would allow the code to run in 'Type-Stripping' mode while keeping the clean Enum syntax.

[MartinJohns]

My proposal is for an enum that emits a plain JavaScript object instead of an IIFE.

This would clearly go against the Viability Checklist and the language Design Goals.

[RyanCavanaugh]

This seems to lack an actual proposal. #60790 is the spirit of what's being implied here.