So I know this has been discussed many times before but I feel like this is becoming a bigger issue recently as of https://github.com/discordjs/discord.js/pull/7313 so I'd like to bring back this discussion and get Vlad's opinion mainly as this mostly concerns discord-api-types
So the library is currently using const enums, which prevents us from using any methods on these objects like Object.keys(), which is used for BitField#toArray, which is being removed on the PR I mentioned above. I understand you're trying to remove string types from the library and use enums only and that's not what I'm discussing here. I feel like most users, myself included, use BitField#toArray in order to display the bits in a user-friendly way and not as an actual way to check for presence or absence of a bit. The TypeScript documentation itself recommends the usage of enums over const enums for exported types (see https://www.typescriptlang.org/docs/handbook/enums.html#const-enum-pitfalls) and linters like typescript-eslint have rules (https://github.com/typescript-eslint/typescript-eslint/blob/main/docs/linting/TROUBLESHOOTING.md#how-can-i-ban-specific-language-feature) that can be used to ban const enums completely.
In summary I feel like removing perfectly valid and useful features for a simple burden than can be easily fixed is avoidable, so I'd like to propose the switch to regular enums in discord-api-types, and would like to use this thread as a way to discuss that if needed. Please let me know what you think!
#Const enums vs regular enums and possible switch
mint marsh
toxic flare
Most likely won't happen. They'll stay as const enums until I have to change them to objects due to the flags moving to bigints (like how Permissions is a const enum)
Another crucial issue is Object.keys on a number enum will yield both the string and number keys, which is not something we want, plus it'd be pascal case and not UPPER_SNAKE_CASE, so either way discord.js would need to adapt to it
supple ferry
What about the fact that it seems that const enums cannot be used with --isolatedModules ?
mind, I'm not sure I really know what I'm talking about but I literally just ran into this issue and the bit of googling I did indicated as such
the fact you guys are talking about it right now was a happy coincidence
mint marsh
Most likely won't happen. They'll stay as const enums until I have to change the...
If everything on discord.js is moving to PascalCase (with the enums from discord-api-types) I don't see why we'd need to adapt.
Also
Another crucial issue is Object.keys on a number enum will yield both the string and number keys, which is not something we want
This can be easily avoided when creating the array with a simple filter with an isNaN check
Eventually pretty much all types will need to be changed to bigints so might as well do that now and solve this issue. Otherwise, what solution do you have for the methods that are being removed in that PR? I don't think it makes any sense for them to be removed without any reasonable replacement as that will break a ton of bots with no easy way of fixing them
toxic flare
Nothing is moving to PascalCase
Afaik
That move was temporary before nuking it in a subsequent PR
The added resolvers check UPPER_SNAKE_CASE too
mint marsh
yeah but the keys in the enums are still pascal cased, just the strings aren't
because there are no more strings
but if you changed the enum keys to PascalCase I wouldn't see an issue in having an array of bit strings in PascalCase
mint marsh
So what other solutions are there to these methods other than changing to regular enums? And why would we not change to regular enums?
toxic flare
Making your own?
mint marsh
Making your own?
how is that a reasonable answer? The point of a library is to make things like these easier not remove every single utility you guys have made over the years
there's no real advantage to exporting const enums unless you can show me some
And yes some removals make sense and have logical and easy alternatives to them, but this one doesn't and not everyone is familiar with bitshifting, which is the hardest part of this
and it's not as easy as the Collection#toArray() change
supple ferry
Chill, @mint marsh these people are volunteers
That being said, maybe this will help convince them?
https://ncjamieson.com/dont-export-const-enums/
I'll be honest, I'm seriously stuck because of this and am going to have to roll up my own....
I'm getting a
Cannot access ambient const enums when the '--isolatedModules' flag is provided.ts(2748)
when trying to use InteractionType in my code... so I tried to re-create the enum locally, but then I get
Type 'InteractionType.Ping' is not comparable to type 'InteractionType'.ts(2678) ,
which in retrospect I should have realized would happen. Is there any workaround for this considering I need to use isolated modules?
perhaps I can extract the value of my enum somehow I'm unaware of?
I'd prefer not to case 1: as that defeats the purpose....
toxic flare
Again, you're tied up to the fact they're const enums when thats not the issue. PascalCased strings are hell to work with compared to UPPER_SNAKE_CASE ones. For TS users, they get inlined values. For JS users, they still work because I enabled preserveConstEnum.
@tiny forge has brought up the same concerns internally and if memory serves it was agreed that the const enums weren't the issue in the end. Thats why we also return the full class now instead of the raw number.
Now, sure there could be other issues related to const enums, as shown above with --isolatedModules (which was one of the reason deno gets its own script alongside fixing imports) and I might change them all at some point to just an Object (like PermissionBitFlags) rather than an enum. 
supple ferry
I'm not so much "tied up" with that as much as that is literally the title of this sidebar 🙂 ... which aligns with my current issue
so case 1: it is, then? I'm not enough familiar with the internals of typescript to come up with a different workaround for my issue
mint marsh
Again, you're tied up to the fact they're const enums when thats not the issue. ...
Well I don't know what concerns were brought up internally but when I asked him why he removed those methods he said it was because of the eventual TS rewrite which wouldn't allow for the usage of Object.keys with those enums, isn't that right?
tiny forge
I mean that is the reason we’ve been removing reverse lookups of const enums
But I prefer numbers/enums only anyways since they’re easier to work with