feat(MessageAttachment): allow files to be marked as spoilers

[J-Human]

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

This allows users to mark media as spoilers before sending them to Discord's API. The motivation behind this is for convenience, as in, users not needing to place the SPOILER_ string.

You'll see a validation if the given argument is false, as it's possible to have the spoiler string inside the string itself, hence removing the title users would expect.

I have adapted this PR from #6473 but I didn't make it an equivalent setter as the function is more easy to use.

Resolves #6473

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)

[Jiralite]

Has this been tested? This method is calling the spoiler getter, which returns the basename utility method and passes the URL across. But that won't exist via instantiating this class and will throw an error?

[ImRodry]

I suggested the brackets exactly because of that. You should install eslint locally so that it tells you about these errors before pushing.

[ImRodry]

Imo you only need 1 return at the end, the others are redundant. Otherwise LGTM

[Jiralite]

This is a bit strange now. If a user runs .setSpoiler(), the attachment will be marked as a spoiler that is yet to be sent. If they decide to run the .spoiler getter to see if it's been marked as a spoiler, it'll throw an error because it's expecting a URL. Right now it's valid only for received messages... maybe it should be adjusted for to-be messages also?

[ImRodry]

This is a bit strange now. If a user runs .setSpoiler(), the attachment will be marked as a spoiler that is yet to be sent. If they decide to run the .spoiler getter to see if it's been marked as a spoiler, it'll throw an error because it's expecting a URL. Right now it's valid only for received messages... maybe it should be adjusted for to-be messages also?

Tbh it should’ve been like that from the beginning, and it’s as simple as adding ?? this.name inside the Util.basename call

[J-Human]

This is a bit strange now. If a user runs .setSpoiler(), the attachment will be marked as a spoiler that is yet to be sent. If they decide to run the .spoiler getter to see if it's been marked as a spoiler, it'll throw an error because it's expecting a URL. Right now it's valid only for received messages... maybe it should be adjusted for to-be messages also?

Tbh it should’ve been like that from the beginning, and it’s as simple as adding ?? this.name inside the Util.basename call

Yeah, I actually agree with this idea since it's the shortest approach to do and it simplifies the job and any future tasks that needs name validation. I'll commit this, along with the if/else-if thing, as it was suggested to be removed by ckohen earlier on.

[NotSugden]

remove x === boolean in favour of x and !x

[J-Human]

Done, suggestions have been committed

[J-Human]

This is unusual. It seems all 4 checks failed to request npm. Kindly rerun them again later. 😄

[kyranet]

It seems like npm hates you. I'll be re-running until it goes through.

[J-Human]

Done