types: make application command option union easier to use

[suneettipirneni]

Please describe the changes this PR makes and why it should be merged:

The previous way that autocomplete was enforced create types that were hard/near impossible to use. This PR sacrifices the type strength for usability making it waaay easier to adopt. So essentially choices and autocomplete are no longer mutually exclusive.

[vladfrangu]

I don't understand how this fixes anything. If anything, you should've added autocomplete?: false to the options that can also have choices, instead of merging them again in one type

[suneettipirneni]

I don't understand how this fixes anything. If anything, you should've added autocomplete?: false to the options that can also have choices, instead of merging them again in one type

That won't work because of the way discriminated unions work.

In our case we use type as the tag for each union. If we split the autocomplete options up and the choices options up, we'll end up with two interfaces that both have type set to string number or integer.

Because there's two interfaces with the same type values. It breaks the union and it'll no longer work properly.

[vladfrangu]

No it won't? Playground Link

Are you sure this is breaking anything? Could you build a playground url where it breaks?

Even then, I am not merging this PR in its current state as you removed min and max_values from number options.

[suneettipirneni]

No it won't? Playground Link

Are you sure this is breaking anything? Could you build a playground url where it breaks?

Even then, I am not merging this PR in its current state as you removed min and max_values from number options.

Here's a playground that shows what I'm talking about:

playground link

[vladfrangu]

Easy fix. Playground Link

[suneettipirneni]

Easy fix. Playground Link

🤦‍♂️ I'm dumb

[vladfrangu]

Are you sure that fixes it? because it also looks wrong

[kyranet]

When in doubt, add tests, lots of type tests. That should tell us whether or not they're fixed.

Although... yeah. We first need a unit test suite in this repository.

[vladfrangu]

How do you unit test... types? Also, we do have tests, with tsd, in the tests folder

[kyranet]

Oh, I didn't see that directory.

How do you unit test... types?

Just like how we have been unit testing types in the main library for months? Even this project's tests test types:

discord-api-types/tests/v9/interactions.test-d.ts

Lines 26 to 27 in c7efcd5

	if (interaction.type === InteractionType.MessageComponent) {
	expectType<APIMessageComponentInteraction>(interaction);