fix(ApplicationCommand): remove false negatives in equals

[ImRodry]

Please describe the changes this PR makes and why it should be merged:
This fixes a bug where having a local command that doesn't declare integrationTypes explicitly would cause it to not be equal to the command returned by Discord as they send a default value of [ 0 ]. In order to fix this, it defaults the value to this.client.application.integrationTypesConfig?.keys() or [ApplicationIntegrationType.GuildInstall] if that's null

Status and versioning classification:

• Code changes have been tested against the Discord API, or there are no code changes
• I know how to update typings and have done so, or typings don't need updating

[vercel]

The latest updates on your projects. Learn more about Vercel for Git ↗︎

2 Skipped Deployments

Name	Status	Preview	Comments	Updated (UTC)
discord-js	⬜️ Ignored (Inspect)	Visit Preview		Nov 17, 2024 2:11am
discord-js-guide	⬜️ Ignored (Inspect)	Visit Preview		Nov 17, 2024 2:11am

[ImRodry]

Since I've seen semver:major PRs starting to be merged I'm not sure if this could fit into a v14.16.4 or a v14.17.0 but it would be nice if it could!

[Jiralite]

We are currently backporting pull requests if possible to v14.

[imnaiyar]

According to documentation, 0 is not default.

Defaults to your app's configured contexts

According to this discord/discord-api-docs#7108 (comment) it's 0 for only older commands

Upon testing, it depends on installation contexts set by users on dev portal when using bulk overwrite route, so it's not just one thing that's returned by the api.

In any case, this is not the correct approach. I'm not sure what would be an appropriate solution, but imo, it should be left as is

[ImRodry]

It should absolutely not be left as it is, as a local command should always be equal to the version sent by Discord, and this method is often used to check for changes locally and update them with Discord accordingly. I believe it is safe to assume that apps made with discord.js will default to guild installs (I'm not sure if a user install can even be made with discord.js) but I'd be happy to change the approach if the maintainers think otherwise

[ImRodry]

Also upon further investigation, my bot has no integrationTypesConfig (it's set to null), so I think it would be safe to assume that the default is [0] in that scenario, though we could also make the default be client.application.integrationTypesConfig?.keys() ?? [0] if I'm reading the documentation correctly

[imnaiyar]

D.js doesn't decides default value, it's discord. And it varies depending on situation

• for older commands, it default to [0]
• for commands created via POST method, it defaults to [0]
• for commands created via Bulk Overwrite route (PUT), it depends on the installation contexts.

So if a person has both for installation contexts, the default value will be [0, 1] if they created the command via PUT route. And discord.js can't simply know that. So there's a chance of false negatives in any solution, so even if we use integrationTypesConfig to determine the default, it'll will be false for first two points and vice versa.

[imnaiyar]

Also upon further investigation, my bot has no integrationTypesConfig (it's set to null), so I think it would be safe to assume that the default is [0] in that scenario

Also you are thinking only for yourself, not everyone applies to your situation

[vladfrangu]

Hmm, this definitely highlights an issue (and an oddly inconsistent behavior in Discord's own API, re: POST/PUT) that can't be fixed just by slapping in a 0 in the if-not-nullish array. I guess since we have the application we can also try defaulting to the app config? 🤷

[ImRodry]

Yeah that was my suggestion, but what should we do when that config is also null like the case I described above?

[ImRodry]

Also upon further investigation, my bot has no integrationTypesConfig (it's set to null), so I think it would be safe to assume that the default is [0] in that scenario, though we could also make the default be client.application.integrationTypesConfig?.keys() ?? [0] if I'm reading the documentation correctly

Applied this solution, let me know if this is better