fix(typings): return types for 'Webhook(Client)#send()'

[izexi]

As shown below, Webhook(Client)#send() would either return a Message (if the client was initiated and the channel was cached) or it would return the raw message response from the API (which has been added as a APIRawMessage interface in this PR).

discord.js/src/structures/Webhook.js

Lines 162 to 164 in d234165

	const channel = this.client.channels ? this.client.channels.cache.get(d.channel_id) : undefined;
	if (!channel) return d;
	return channel.messages.add(d, false);

Cuurently the typings do not reflect this behaviour, this PR fixes that.

I did consider making use of the APIMessage over on discord-api-types but that would mean introducing another dependency which be a breaking change for all Typescript developers.

⚠️ This change is breaking for Typescript developers that make use of properties or methods exclusive to a Message and not within the APIRawMessage from the resolved returned value of Webhook(Client)#send().

Here's a snippet of how I tested these changes

import { expectType } from 'tsd';
import { WebhookRawMessageResponse, Message, WebhookClient } from 'discord.js';

const webhookClient = new WebhookClient('', '');

expectType<Message | WebhookRawMessageResponse>(
  await webhookClient.send('foo')
);

expectType<(Message | WebhookRawMessageResponse)[]>(
  await webhookClient.send('foo', { split: true })
);

expectType<
  Message | WebhookRawMessageResponse | (Message | WebhookRawMessageResponse)[]
>(await webhookClient.send({ embeds: [] }, { split: true }));

expectType<Message | WebhookRawMessageResponse>(
  await webhookClient.send('foo', { embeds: [] })
);

expectType<
  Message | WebhookRawMessageResponse | (Message | WebhookRawMessageResponse)[]
>(await webhookClient.send('foo', { embeds: [], split: true }));

Status

• 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

Semantic versioning classification:

• This PR changes the library's interface (methods or parameters added)
  • This PR includes breaking changes (methods removed or renamed, parameters moved or removed)
• This PR only includes non-code changes, like changes to documentation, README, etc.

[vladfrangu]

I don't see how adding a dependency on discord-api-types is breaking for TS developers (note: dependency, not dev/peer dep).. 👀

[NotSugden]

these overloads should be applied to WebhookClient directly, as the Webhook class is instantiated by internal methods and always has a client, thus always returns a full message

[izexi]

I don't see how adding a dependency on discord-api-types is breaking for TS developers (note: dependency, not dev/peer dep).. 👀

@vladfrangu I was assuming that they had to go under devDependicies since that's where the other type packages were listed. Although, as mentioned by Sudgen some of the OAuth2 properties wont be present so I could Omit them I guess but I'm not sure about adding it as a dependency just for the APIMessage.

---

these overloads should be applied to WebhookClient directly, as the Webhook class is instantiated by internal methods and always has a client, thus always returns a full message

@NotSugden If the channel isn't within the ChannelManager#cache Collection then it would return the raw message, although this isn't possible unless the developer removes the channel manually I believe it should still be accounted for.

[kyranet]

I don't see how adding a dependency on discord-api-types is breaking for TS developers (note: dependency, not dev/peer dep).. 👀

@vladfrangu I was assuming that they had to go under devDependicies since that's where the other type packages were listed. Although, as mentioned by Sudgen some of the OAuth2 properties wont be present so I could Omit them I guess but I'm not sure about adding it as a dependency just for the APIMessage.

Since we're releasing this for discord.js v13, I personally don't see a reason to not include discord-api-types, we can afford semver-major this time.

[iCrawl]

For what its worth: I would like to keep this as is and move forward like this until we have a clear path for modularization.