I tried to clarify that I was not talking about enum usage in the original message, so let me rephrase. By converting all types into numbers, if we're trying to see what type a structure has, we'd be looking directly at the structure, and not comparing it with anything else, meaning that if we have type: 20 in it, we will have to check the docs, whereas before we could simply read the string and understand what the type was. This is for situations when you are not using an enum, and just looking at the type property of a structure.

Is till don't understand what you're getting at. The type marked on the structures and methods is the enum type not the number. We have all recommended multiple times that people stay away from magic numbers.

I understand it made type checking harder, which is why typeguards were implemented in most cases. What I'm saying is that having a "magic number" is harder for someone not familiar with Discord's types to figure out what it means, which didn't happen before, forcing the developer to go hunt for the enum on the docs.

Magic numbers were possible in v13 nothing was stopping anyone from using them. And I'll reiterate we don't recommend using magic numbers as a replacement for enums. You summarized the issues with using magic numbers pretty well.

Me being the only person bringing this up surely isn't an argument as there aren't nearly enough people using the dev versions to have an idea of the impact of any change so far, so I'm sure this will become a more evident issue once public release comes. I still don't understand why you call this "mixing and matching" as this saves performance by avoiding the totally unnecessary checks builders has (yes I know an option is coming, but still setting all data at once is better than calling functions over and over) and this is the way that the library implements these builders. I don't think you should offer support for passing an object in the constructor and then have that be the only thing that accepts snake_cased properties only. My goal is not to use a plain object, as I still want to take advantage of the functions, but only in the situations where they make sense, and not when declaring the variable for the first time, as that would be a waste of time, specially in bigger bots like you mentioned.

Ok fair, the one-person argument is a bit of a stretch.

I say mix and match, because you're mixing the builder syntax with the json syntax. You also questioned why have the option in the constructor if it only accepts snake_case. In another conversation I had exclusively with you I stated that the main use of the constructor for the builders was so djs could serialize incoming API data, it was never built for around the user providing varying user json inputs. In addition, we would like to avoid builders depending on djs types, as that would cause a circular dependency.

By converting all types into numbers, if we're trying to see what type a structure has, we'd be looking directly at the structure, and not comparing it with anything else, meaning that if we have type: 20 in it, we will have to check the docs, whereas before we could simply read the string and understand what the type was.

I can't quite imagine a use case where someone has no idea what type a structure is, but also doesn't know what type they want to check it to be. Are you able to provide an example?

Even then, assuming you're doing something like console.log(structure.type); // 20 and seeing the number, console.log(StructureType[structure.type]) will give you a string - pending a discord-api-types release I'm told, doesn't work with the current const enums.

I say mix and match, because you're mixing the builder syntax with the json syntax. You also questioned why have the option in the constructor if it only accepts snake_case. In another conversation I had exclusively with you I stated that the main use of the constructor for the builders was so djs could serialize incoming API data, it was never built for around the user providing varying user json inputs. In addition, we would like to avoid builders depending on djs types, as that would cause a circular dependency.

I know the constructor is there to allow for serialization of API data, however you have to take into account that people will use that given the possibility. Despite all the guides doing it in one way, doesn't mean other people, like myself, won't find another way they prefer and use. And it's not like the constructor is private so it is meant to be used and should work just like it did in v13, otherwise you'd be simply breaking for the sake of breaking without any advantage (and I'd even argue there are way more disadvantages to using builders as opposed to discord.js's classes).
As for the DJs types, we don't need to use them, we can declare them in /builders itself and use them there, no need to re-export. Either that or discord.js could export a class that extends builders and adds support for camelCasing, that way we could use discord.js's types freely.

I can't quite imagine a use case where someone has no idea what type a structure is, but also doesn't know what type they want to check it to be. Are you able to provide an example?

When I say structure I'm referring to any structure in general. Of course you know if it's a Message or a Channel, what I'm trying to describe is a scenario where you want to find out the type of Message or type of Channel.

Even then, assuming you're doing something like console.log(structure.type); // 20 and seeing the number, console.log(StructureType[structure.type]) will give you a string - pending a discord-api-types release I'm told, doesn't work with the current const enums.

While that is true now, that's another thing developers have to keep in mind when debugging, when it could be done in discord.js through the use of a getter that converts the type to a string and passes it to the user when accessing it, while also keeping it stored as a number internally. This way you'd only use strings for output, never input.

While that is true now, that's another thing developers have to keep in mind when debugging, when it could be done in discord.js through the use of a getter that converts the type to a string and passes it to the user when accessing it, while also keeping it stored as a number internally. This way you'd only use strings for output, never input.

Any half-decent developer should know that the type is an enum and convert it or look it up while debugging, however they choose to translate it.

I'm guessing the getter would be something like get type() { return StructureType[this._type]; } or something, which hey, I think conceptually is probably fine, if a little added bloat. I don't think it helps the level of developer who wouldn't already know how to lookup an enum though, since they're probably just going to console.log the whole object. Which of course, wont show any getters.

I feel like this is getting into fairly unrealistic examples or is simply another case of subjective opinions on what "cleaner" code is. As I've said before, if the bot developer's code being shorter is "cleaner" then by that same measure, we must have made discord.js "dirtier". All it does is move the necessary conversion somewhere else.

Before you go far into that, getters are by default non-enumerable, which causes util.inspect to not display it unless you pass extra options (or change the default options).

Although debuggers will display the getter once the object is expanded, not sure if you can display the value because at least Dev Tools doesn't.