Proposal: Add \`enum const\` modifier to auto-generate union types for constant objects

[yxdtg]

A type-only, fully erasable modifier with zero runtime overhead.

enum const Status = {
    Success: "success",
    Failure: "failure",
    Pending: "pending",
};

Desugared TypeScript Equivalent

The compiler desugars this internally to standard TS. No manual boilerplate required.

The const value and type share the same name, leveraging TypeScript's separate value/type namespaces.

const Status = {
    Success: "success",
    Failure: "failure",
    Pending: "pending",
} as const;
type Status = (typeof Status)[keyof typeof Status];

Compiled JavaScript Output

The enum modifier is stripped entirely. Output is a native JS object with no extra generated code.

const Status = {
    Success: "success",
    Failure: "failure",
    Pending: "pending",
};

✅ 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

Compatibility

• Fully backward compatible: this is a new additive syntax, no breaking changes to existing code
• Compatible with isolatedDeclarations and isolatedModules
• Aligns with erasableSyntaxOnly: no runtime code is generated
• No conflict with existing const enum, as the keyword order and semantics are clearly distinct

📃 Motivating Example

Current approaches for type-safe constant collections in TypeScript all have notable tradeoffs:

1. Standard enum generates extra runtime code
   It produces bidirectional mapping IIFE in JavaScript output, adding bundle overhead. It conflicts with the erasableSyntaxOnly principle and cannot be extended via object spread.
2. const enum has severe compatibility limits
   Values are inlined at compile time and break across file/package boundaries. It is incompatible with isolatedModules and isolatedDeclarations, making it unusable for libraries and monorepos.
3. as const objects require heavy boilerplate
   The de facto standard pattern forces developers to manually derive union types with type T = typeof Obj[keyof typeof Obj]. This becomes even more verbose under isolatedDeclarations, where every cross-file usage requires explicit typeof annotations to avoid cross-file type inference.

This proposal introduces a lightweight, type-only erasable modifier that solves all the above issues: it retains native JavaScript object semantics, produces zero runtime overhead, and is natively compatible with single-file compilation architectures.

💻 Use Cases

• Shared status codes, state constants and configuration values in application code
• Enum-like public APIs in component libraries and SDKs
• Cross-package constant definitions in monorepos, where const enum cannot be used
• Constant objects that need to be extended, merged or spread while preserving type safety

[MartinJohns]

Essentially a duplicate of #60790.

[yxdtg]

Essentially a duplicate of #60790.

Hi there, thanks for pointing out that issue! I’ve gone through #60790, and while both proposals relate to object-literal enums, they are fundamentally different in design goals and implementation logic, and not duplicates.

The core of #60790 (as enum) is to add nominal typing capabilities to object literals. It introduces new type-system semantics to emulate native enum type isolation, and also extends to discussions around symbol support, __proto__ handling and other type-level features — it is essentially a type system enhancement.

This proposal, by contrast, is pure syntactic sugar with zero new type semantics. It desugars 100% into the widely used standard pattern: const Obj = {...} as const plus a manually derived union type. The enum keyword here acts purely as a type-level marker that gets fully erased at compile time. No extra syntax transformation is required, and the final output is just a plain native JavaScript object.

The syntax also stays very close to native JavaScript: it’s just a standard const object declaration with a lightweight type modifier in front. You can immediately recognize it as a native JS object with enum-level type safety, without introducing any non-standard runtime constructs.

They address different pain points and follow distinct design paths, so they are not the same proposal.