discordjs / discord-api-types

Up to date Discord API Typings, versioned by the API version
https://discord-api-types.dev
MIT License
536 stars 118 forks source link

GuildFeature is not a two-way enum #583

Open MattIPv4 opened 2 years ago

MattIPv4 commented 2 years ago

Please describe the problem you are having in as much detail as possible:

Many of the enums exported from discord-api-types are two-way enums, meaning that you can pass a key into the enum, and than that result back into the enum again to get the original key. This is true of the ChannelType enum for example, which has both the integer and string values as keys.

However, the GuildFeature enum only has the PascalCase values as keys, with the SCREAMING_SNAKE_CASE values missing from the keys. This means that you cannot convert the snake case values back to the pascal case values using the enum.

Include a reproducible code sample here, if possible:

import { ChannelType, GuildFeature } from 'discord-api-types';

console.log(ChannelType[ChannelType[0]]); // 0
console.log(GuildFeature[GuildFeature['Banner']]); // undefined

Further details:

Jiralite commented 2 years ago

Isn't that just how enumerations work? String-valued enumerations do not return numbers in the first place.

vladfrangu commented 2 years ago

This is outside of my power / control, this is how TS turns string enums into objects. So, sadly, can't easily add these without doing it manually. But there should be modules to easily convert snake_case to PascalCase

MattIPv4 commented 2 years ago

I'm just running this to patch it locally, rather annoying that TS is inconsistent with how enums get exported w/ strings vs numbers:

Object.entries(GuildFeature).forEach(([key, value]) => {
  GuildFeature[value] = key;
});
vladfrangu commented 1 year ago

I doubt we'd change the enums themselves but I'd be willing to merge a utility method for getting the PascalCase name šŸ‘

Renegade334 commented 1 year ago

I'm just running this to patch it locally, rather annoying that TS is inconsistent with how enums get exported w/ strings vs numbers:

This is the way it has to be. There's nothing to stop you having an enum like

enum StringEnum {
  Foo = 'Bar',
  Bar = 'Baz',
  Baz = 'Foo'
}

and there's no way of creating a bidirectional key-to-value map when the keys and values are allowed to overlap.

I doubt we'd change the enums themselves but I'd be willing to merge a utility method for getting the PascalCase name šŸ‘

Is there a significant usage case for this? Besides users wanting to use PascalCase strings for logging purposes or whatnot, but there are plenty of case converter packages in the npm ecosystem that they can use.