refactor(MessageOptions): move replyTo to reply#messageReference and add failIfNotExists

[ckohen]

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

Add support for new fail_if_not_exists parameter in message_reference
ref: discord/discord-api-docs#2572

This also changes the replyTo parameter to be more in line with the API

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
• This PR changes the library's interface (methods or parameters added)
• This PR includes breaking changes (methods removed or renamed, parameters moved or removed)

[iShibi]

Nice 👍, I was just thinking that shouldn't the field name emphasize more on the error part. The API calls it fail_if_not_exists, which makes it clear that something will fail. Even though our description of this field states that it will error, the name doesn't sound like an error will occur.

[iShibi]

I would suggest the name errorIfDeleted for this field. The reason being that:

1. It emphasizes the error part and conveys the meaning of the field better.
2. It will be in line with the API. Right now we are flipping the booleans and because of the field name, our default for this field is opposite of the API's default. The errorIfDeleted can be documented to be true by default just like fail_if_not_exists.

[ckohen]

My only issue with errorIfDeleted is that it doesn't indicate it only applies to replies and is a confusing name when not in that context. I will consider this though

[vaporoxx]

deleted shouldn't be included in the name at all since passing an invalid id would also have different behavior depending on the parameter. I think that errorOnInvalidReply or similar would maybe be a better name here

[almostSouji]

So far we've always decided to stick with the API names for options, I'd personally vote for this specific one to not become an exception.

[ckohen]

Hmm, I would like to stick with API names as there is clearly a lot of thought in creating these names, but that poses the problem that the library doesn't expose message_reference whatsoever. This means that MessageOpitons#failIfNotExists has no indication that it is reply specific other than the jsdoc string.

Maybe this needs to wait until #5296 lands and have that name? Even then I still don't like that it has no indication of being part of message_reference.

[monbrey]

Hmm, I would like to stick with API names as there is clearly a lot of thought in creating these names, but that poses the problem that the library doesn't expose message_reference whatsoever. This means that MessageOpitons#failIfNotExists has no indication that it is reply specific other than the jsdoc string.

Maybe this needs to wait until #5296 lands and have that name? Even then I still don't like that it has no indication of being part of message_reference.

Replies haven't been released in a stable release yet. If you want to rename MessageOptions#replyTo to messageReference I don't see the issue with that.

[ckohen]

Yep, Souji and I talked about it in the discord, and this is going to end up being a refactor + add

[iShibi]

⚠️ Typings for WebhookMessageOptions will need another update (see #5476) once this PR merges.

stale