# A More Idiomatic Enum for JavaScript
**URL:** https://es.discourse.group/t/a-more-idiomatic-enum-for-javascript/2566
**Category:** đź’ˇ Ideas
**Created:** [May 13, 2026, 9:10am UTC](https://es.discourse.group/t/a-more-idiomatic-enum-for-javascript/2566 "2026-05-13T09:10:04Z")
**Posts on this page:** 5
**Page:** 1
### Author:  [@yxdtg](https://es.discourse.group/u/yxdtg)
#### Post date: [May 13, 2026, 9:10am UTC](https://es.discourse.group/t/a-more-idiomatic-enum-for-javascript/2566/1 "2026-05-13T09:10:04Z")
## A More Idiomatic Enum for JavaScript
- Idiomatic to JavaScript
- Semantic
- Progressive
- Arbitrary value types
- Mergeable
- Straightforward desugaring
- Straightforward TypeScript typing
## Basic Syntax
```javascript
enum STATUS {
Ready: 0,
Pending: 1,
Done: 2
};
```
## Desugaring: Object + (1. Pure syntactic sugar OR 2. Frozen object)
```javascript
// Option 1: Pure syntactic sugar (for readability)
const STATUS = {
Ready: 0,
Pending: 1,
Done: 2,
};
// Option 2: Frozen object (with runtime immutability)
const STATUS = Object.freeze({
Ready: 0,
Pending: 1,
Done: 2,
});
```
## Arbitrary Value Types
```javascript
enum STATUS {
Ready: 0,
Pending: "pending",
Done: true,
Error: null,
Warn: {}
}
```
## Merging: {...enum, ...object}
```javascript
enum APP_STATUS {
Ready: "ready",
Pending: "pending",
Done: "done"
}
enum USER_STATUS {
LoggedIn: "logged-in",
LoggedOut: "logged-out"
}
const TEST_STATUS = {
Success: "success",
Error: "error"
};
enum STATUS {
...APP_STATUS,
...USER_STATUS,
...TEST_STATUS
}
```
## Design Rationale: No Reverse Mapping
The decision to omit reverse mapping is a deliberate choice to keep the feature idiomatic to JavaScript.
- **Idiomatic & Predictable** : JS developers are accustomed to standard object semantics. Adding reverse mapping introduces hidden complexity that breaks the “what you see is what you get” intuition.
- **Rarely Used** : In practice, the need for `STATUS[1]` is extremely rare compared to `STATUS.Ready`.
- **Ambiguity with Shared Values** : Reverse mapping is fundamentally broken when different keys map to the same value. For example, if `Ready: 1` and `Success: 1` both exist, a reverse mapping like `STATUS[1]` is ambiguous. Plain objects naturally handle this by just retaining the key-value structure.
For cases where reverse lookup is strictly necessary, developers can easily and explicitly use `Object.entries()` or `Object.keys()` to build a reverse map, paying only for what they actually use.
---
### Author:  [@aclaymore](https://es.discourse.group/u/aclaymore)
#### Post date: [May 13, 2026, 10:14am UTC](https://es.discourse.group/t/a-more-idiomatic-enum-for-javascript/2566/2 "2026-05-13T10:14:07Z")
Hi @yxdtg
There is an existing proposal for enums. If this is an idea on how that proposal could change it would be best to discuss there.
> **[GitHub - tc39/proposal-enum: Proposal for ECMAScript enums](https://github.com/tc39/proposal-enum)**
>
> Proposal for ECMAScript enums
---
### Author:  [@yxdtg](https://es.discourse.group/u/yxdtg)
#### Post date: [May 13, 2026, 10:33am UTC](https://es.discourse.group/t/a-more-idiomatic-enum-for-javascript/2566/3 "2026-05-13T10:33:38Z")
Sure, thanks for the reminder
---
### Author:  [@yxdtg](https://es.discourse.group/u/yxdtg)
#### Post date: [May 20, 2026, 8:03am UTC](https://es.discourse.group/t/a-more-idiomatic-enum-for-javascript/2566/4 "2026-05-20T08:03:23Z")
[https://www.npmjs.com/package/@jiaozi-dev/kit](https://www.npmjs.com/package/@jiaozi-dev/kit)
---
### Author:  [@David263](https://es.discourse.group/u/David263)
#### Post date: [June 13, 2026, 11:47am UTC](https://es.discourse.group/t/a-more-idiomatic-enum-for-javascript/2566/5 "2026-06-13T11:47:46Z")
Is a new result type string from typeof desired, or do you propose Enum.isEnum()? Why is the Array add-on solution using Object (that is, just defining a new Prototype) not okay for Enum? Should Enums be only integers, or other datatypes as well? What is lacking in the existing syntax for enumerations as constant object literals declared using {}? Why is a new idiomatic syntax useful? Are you trying to eliminate the need for the awful Object.freeze?
Perhaps my questions are not needed. I see that the existing proposal (link above) answers most of them similarly to TypeScript.