Extending string-based enums

Before string based enums, many would fall back to objects. Using objects also allows extending of types. For example:

const BasicEvents = {
    Start: "Start",
    Finish: "Finish"
};

const AdvEvents = {
    ...BasicEvents,
    Pause: "Pause",
    Resume: "Resume"
};

When switching over to string enums, it"s impossible to achieve this without re-defining the enum.

I would be very useful to be able to do something like this:

enum BasicEvents {
    Start = "Start",
    Finish = "Finish"
};

// extend enum using "extends" keyword
enum AdvEvents extends BasicEvents {
    Pause = "Pause",
    Resume = "Resume"
};

Considering that the produced enums are objects, this won"t be too horrible either:

// extend enum using spread
enum AdvEvents {
    ...BasicEvents,
    Pause = "Pause",
    Resume = "Resume"
};

Just played with it a little bit and it is currently possible to do this extension using an object for the extended type, so this should work fine:

enum BasicEvents {
    Start = "Start",
    Finish = "Finish"
};

// extend enum using "extends" keyword
const AdvEvents = {
    ...BasicEvents,
    Pause: "Pause",
    Resume: "Resume"
};

Note, you can get close with

enum E {}

enum BasicEvents {
  Start = 'Start',
  Finish = 'Finish'
}
enum AdvEvents {
  Pause = 'Pause',
  Resume = 'Resume'
}
function enumerate<T1 extends typeof E, T2 extends typeof E>(e1: T1, e2: T2) {
  enum Events {
    Restart = 'Restart'
  }
  return Events as typeof Events & T1 & T2;
}

const e = enumerate(BasicEvents, AdvEvents);

Another option, depending on your needs, is to use a union type:

const enum BasicEvents {
  Start = 'Start',
  Finish = 'Finish'
}
const enum AdvEvents {
  Pause = 'Pause',
  Resume = 'Resume'
}
type Events = BasicEvents | AdvEvents;

let e: Events = AdvEvents.Pause;

Downside is you can't use Events.Pause; you have to use AdvEvents.Pause. If you're using const enums, this is probably ok. Otherwise, it might not be sufficient for your use case.

We need this feature for strongly typed Redux reducers. Please add it in TypeScript.

Another workaround is to not use enums, but use something that looks like an enum:

const BasicEvents = {
  Start: 'Start' as 'Start',
  Finish: 'Finish' as 'Finish'
};
type BasicEvents = (typeof BasicEvents)[keyof typeof BasicEvents];

const AdvEvents = {
  ...BasicEvents,
  Pause: 'Pause' as 'Pause',
  Resume: 'Resume' as 'Resume'
};
type AdvEvents = (typeof AdvEvents)[keyof typeof AdvEvents];

All workarounds are nice but I would like to see the enum inheritance support from typescript itself so that I can use exhaustive checks as simple as possible.

Just use class instead of enum.

I was just trying this out.

const BasicEvents = {
    Start: 'Start' as 'Start',
    Finish: 'Finish' as 'Finish'
};

type BasicEvents = (typeof BasicEvents)[keyof typeof BasicEvents];

const AdvEvents = {
    ...BasicEvents,
    Pause: 'Pause' as 'Pause',
    Resume: 'Resume' as 'Resume'
};

type AdvEvents = (typeof AdvEvents)[keyof typeof AdvEvents];

type sometype<T extends AdvEvents> =
    T extends typeof AdvEvents.Start ? 'Some String' :
    T extends typeof AdvEvents.Finish ? 'Some Other String' :
    T extends typeof AdvEvents.Pause ? 'Abc' :
    T extends typeof AdvEvents.Resume ? 'Xyz' : never;
type r = sometype<typeof AdvEvents.Finish>;

There has got to be a better way of doing this.

Why isn't this a feature already? No breaking changes, intuitive behavior, 80+ people who actively searched for and demand this feature – it seems like a no-brainer.

Even re-exporting enum from a different file in a namespace is really weird without extending enums (and it's impossible to re-export the enum in a way it's still enum and not object and type):

import { Foo as _Foo } from './Foo';

namespace Bar
{
    enum Foo extends _Foo {} // nope, doesn't work

    const Foo = _Foo;
    type Foo = _Foo;
}

Bar.Foo // actually not an enum

+1
Currently using a workaround, but this should be a native enum feature.

I skimmed through this issue to see if anyone has posed the following question. (Seems not.)

From OP:

enum BasicEvents {
    Start = "Start",
    Finish = "Finish"
};

// extend enum using "extends" keyword
enum AdvEvents extends BasicEvents {
    Pause = "Pause",
    Resume = "Resume"
};

Would people expect AdvEvents to be assignable to BasicEvents? (As is, for example, the case with extends for classes.)

If yes, then how well does that mesh with the fact that enum types are meant to be final and not possible to extend?

Carl Mäsak (@masak)

Carl Mäsak (@masak) great point. The feature people want here is definitely not like normal extends. BasicEvents should be assignable to AdvEvents, not the other way around. Normal extends refines another type to be more specific, and in this case we want to broaden the other type to add more values, so any custom syntax for this should probably not use the extends keyword, or at least not use the syntax enum A extends B {.

On that note, I did like the suggestion of spread for this from OP.

// extend enum using spread
enum AdvEvents {
    ...BasicEvents,
    Pause = "Pause",
    Resume = "Resume"
};

Because spreading already carries the expectation of the original being shallow-cloned into an unconnected copy.

Nazario A. Ayala (@nazarioa)

Nazario A. Ayala (@nazarioa)

You can inherit the type from the object, so you don't need to define the values twice.

type ConstEnum<T, V = string> = Extract<T[keyof T], V>

const Gender = {
  Male: 'male',
  Female: 'female'
} as const
type Gender = ConstEnum<typeof Gender>

const gender: Gender = Gender.Female


const ExtendedGender = {
  ...Gender,
  Pansexual: 'pansexual'
} as const
type ExtendedGender = ConstEnum<typeof ExtendedGender>

let extendedGender: ExtendedGender = ExtendedGender.Pansexual
extendedGender = ExtendedGender.Female

Daniel Rosenwasser (@DanielRosenwasser)

So here's the most likely answer at this point - we're probably not going to touch enums for a bit as there's discussion of introducing them to JS; that said, discussion here can help drive the design direction of JS.

Daniel Rosenwasser (@DanielRosenwasser) Ugh, looks like I missed your comment.

For the reference this is probably where the mentioned discussion happens: https://github.com/Jack-Works/proposal-enum

Nazario A. Ayala (@nazarioa)

Please, Nazario A. Ayala (@nazarioa) and freakzlike, refrain from two things:

mixing up sexual orientation with gender. Pansexuality is a sexual orientation.
limiting gender and sexual orientation options. Those are not clear cut and are based on the individual's experiences.

Also, consider if those pieces of data are needed. Most often they're not. If they are, have at least an "Other" option, although an open field would be better.

Patrícia Villela (@patriciavillela)

While Patrícia Villela (@patriciavillela)'s comment might seem like a detour from the main topic, I see a way to connect it to (what I see as) the main important property to preserve in all of this:

The original enum must not be affected by the extension.

We like enums because of their "closed-world" property — that's the one that gives us totality/coverage checking in switch statements, for example. If the implementation of this issue affects that guarantee, we've all lost something valuable.

From a social perspective, there's simply no way to get the original enum author's blessing — the enum is and remains closed. Patrícia Villela (@patriciavillela) was not the original author of the Gender enum, but it's possible to imagine the original author similarly objecting to their enum being extended.

From this point of view, the term "extending" (in the issue topic) is a misnomer; enums simply do not extend. "Inheriting" is half-wrong, half-OK, I guess — you get the original enum's values, but you do not in any sense participate in the original enum's type.

Ryan Cavanaugh (@RyanCavanaugh) wrote:

Option 1: It's Actually Sugar

If spread really means the same as copying down the spreaded enum's members, then there will be a big surprise when people try to use the extending enum's value as if it were the extended enum's value and it doesn't work.

I think the big surprise here is relative to expectations set up by terms like "extending". Since we can't actually deliver on that promise without breaking a fundamental guarantee of enums (that of being closed), I'm fine with Option 1, and I think it can be made much less surprising by avoiding terms like "extending".

Regarding this:

So here's the most likely answer at this point - we're probably not going to touch enums for a bit as there's discussion of introducing them to JS; that said, discussion here can help drive the design direction of JS.

I guess what I should really be doing is head over to the tc39 repository and defend JavaScript enums against the extends keyword. 😄 This seems to be the issue for doing that.

Patrícia Villela (@patriciavillela)

Patrícia Villela (@patriciavillela) I meant no offense. I should not have called it sexual orientation and removed male/female. I was trying to create an example that was relatable -- I did it quickly and sloppy. I think I might have had it on my mind for news reasons. I am willing to update the original content in order to make it more correct.

Per discussion at #51310, we're officially putting this one in "Waiting for TC39" status. There's a proposal that's actively being developed which would potentially bring some sort of enum declaration form to JavaScript, and we'd like this to either proceed, or have the committee informally agree to indefinitely hold off on adding enum to JS in any form.

A good alternative is:

enum X {
  one = "a",
  two = "b"
}
enum Y {
  three = "c",
  four = "d"
}
const XY = { ...X, ...Y } as const;
type XY = (typeof XY)[keyof typeof XY];

which will give you a type/value combination that's effectively indistinguishable from a hypothetical enum XY { ...X, three = "c", four = "d" } declaration

A good alternative is...

I would say this is not a "good" alternative, as much as it is just that, an alternative. It's messy, sloppy and extremely hard if not impossible to remember, unless you're a pure TypeScript pro.

I don't get why:

enum B extends A {}

is not viable. It's simple, elegant, and consistent with the rest of the TypeScript syntax.

Alex (@whatwhywhenandwho)

I don't get why:
enum B extends A {}
is not viable. It's simple, elegant, and consistent with the rest of the TypeScript syntax.

Alex (@whatwhywhenandwho) Well... (and sorry for repeating myself; this is well-covered in the comments above, but I realize there's a lot of them, so maybe repeating the message here might be beneficial)

...using extends as a keyword for enums sets exactly the wrong expectations, which then cannot be upheld with enums. The enum feature implies "these are the enum values, and nothing else" (closed world). The extends keyword implies "we use something as a base, and then add some more stuff" (open world). The exhaustiveness check of switch is also based on the closed-world assumption. Allowing any kind of extends semantics breaks that assumption. (Now consider using extends on an enum, but in a third-party module you neither control or even know about.)

Seeing as how the main reason for having enums is to enforce the closed-world assumption and to allow for the exhaustiveness check in switch, I am vehemently, categorically opposed to using extends in the way you propose.

what about enum B includes A { }? either way, are there plans to implement this functionality?

type IncludesType<T extends {[key: string]: string}, U extends {[key: string]: string}> = T & U;

function includes<T extends {[key: string]: string}, U extends {[key: string]: string}>(first: T, second: U): IncludesType<T, U> {
  return { ...first, ...second };
}

enum X {
  one = "a",
  two = "b",
}

enum Y {
  three = "c",
  four = "d",
}

const XY = includes(X, Y);
/////
function createIncludesFunction<U extends {[key: string]: string}>(baseEnum: U) {
  return <T extends {[key: string]: string}>(superset: T): IncludesType<T, typeof baseEnum> => {
    return includes(superset, baseEnum);
  }
}

const includesY = createIncludesFunction(Y)
const XY = includesY(X)
type XY = ValueOf<typeof Events> // from type-fest

...using extends as a keyword for enums sets exactly the wrong expectations, which then cannot be upheld with enums. The enum feature implies "these are the enum values, and nothing else" (closed world). The extends keyword implies "we use something as a base, and then add some more stuff" (open world). The exhaustiveness check of switch is also based on the closed-world assumption. Allowing any kind of extends semantics breaks that assumption. (Now consider using extends on an enum, but in a third-party module you neither control or even know about.)

Thinking about it a little bit philosophically, inheritance between classes is already a pretty weird feature. 😄 It lets you create instances of your own class which are also instances or someone else's class! Like, what's up with that? 😮

But it's something we expect from classes, and sometimes even use in healthy, well-defined ways. (Like extending base classes provided by a framework.) It works.

With enums, it runs up against the closed-world expectation, which is why enums never allow you to (a) create new instances/values of the enum besides those originally specified, nor (b) create any kind of derived enum/sub-enum with its own new instances.

🔨 (grapher) replace some enum types / TAS-709 (#4170)

Hey guys, it's been a long time since there has been no activity here. I don't want to stir up a hornet's nest, but the problem is still relevant. Are there any plans to solve it?

shArky (@XIshArkIX)

Are there any plans to solve it?

shArky (@XIshArkIX) You can read Ryan Cavanaugh's response above; the tl;dr is that there's now a tc39 proposal for enums in JavaScript/EcmaScript, and it's unlikely that anything will happen with TypeScript's enum feature before that proposal lands. I think that's very reasonable; in a way, TypeScript's original enum feature already somewhat exceeded TypeScript's mission, which includes erasing types and compiling down to JavaScript, but not adding/altering runtime behavior.

I should add that the tc39 proposal is still at Stage 1 ("Under consideration") as of this writing. At a guess, it will not be accepted into the EcmaScript specification anytime soon.

Meanwhile, I recommend Ryan's workaround:

enum X {
  one = "a",
  two = "b"
}
enum Y {
  three = "c",
  four = "d"
}
const XY = { ...X, ...Y } as const;
type XY = (typeof XY)[keyof typeof XY];

...which (a) works today, (b) should satisfy those who want the behavior or "extending" an enum, but (c) doesn't suffer from the problems an extend keyword would have (discussed at length above).

Navigation Menu

Repository navigation

Extending string-based enums #17592

65 remaining items

Option 1: It's Actually Sugar

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Extending string-based enums #17592

Description

Activity

nomaed commented on Aug 3, 2017

aluanhaddad commented on Aug 7, 2017

aj-r commented on Sep 22, 2017

serhiipalash commented on Mar 25, 2018

aj-r commented on Mar 25, 2018

Xenya0815 commented on May 8, 2018

nOstap commented on Sep 4, 2018

guptaamol commented on Oct 19, 2018

cshaa commented on Nov 29, 2018

LukePetruzzi commented on Dec 18, 2018

masak commented on Dec 21, 2018

alangpierce commented on Dec 21, 2018

masak commented on Dec 21, 2018

65 remaining items

freakzlike commented on Feb 17, 2022

whut commented on Feb 22, 2022

patriciaverso commented on Apr 11, 2022

masak commented on Apr 12, 2022

Option 1: It's Actually Sugar

nazarioa commented on Apr 21, 2022

RyanCavanaugh commented on Oct 27, 2022

whatwhywhenandwho commented on Dec 16, 2022

masak commented on Dec 19, 2022

alita-moore commented on Jun 24, 2023

masak commented on Jun 25, 2023

XIshArkIX commented on May 25, 2026

masak commented on May 25, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions