Typings for creating select values with emoji incorrect, blocking creation of dropdown menus with emoji

[Nephrited]

Please describe the problem you are having in as much detail as possible: When attempting to create a select dropdown with an emoji, the TS enforces a full emoji object of type EmojiIdentifierResolvable, when the Discord API requires only a partial Emoji object consisiting of at most the id, name and animated fields.

Include a reproducible code sample here, if possible:

const actionRow = new MessageActionRow().addComponents(
    new MessageSelectMenu()
        .setCustomId('exampleSelect')
        .setPlaceholder('Nothing selected')
        .addOptions([
            {
                label: 'Label',
                description: 'A description',
                value: 'value-1',
                emoji: {
                    name: "♥",
                    //id: "1234", // optional field for custom emoji
                    //animated: false, // optional field for custom emoji
                }
            },
        ])
);

await interaction.reply({
    content: 'This is a test',
    components: [actionRow],
});

Further details:

• discord.js version: 13.1.0
• Node.js version: 16.7.0
• Operating system: Ubuntu 20.04.2 LTS
• Priority this issue should have – please be realistic and elaborate if possible: Low. It's annoying but hardly a mission critical feature for bots, and can be worked around, but still should be fixed.

Workaround

emoji: {
    name: "♥",
} as any

Relevant client options:

N/A

[Jiralite]

Odd? This method accepts this type definition for which the emoji property is ultimately this:

export type EmojiIdentifierResolvable = string | EmojiResolvable;
export type EmojiResolvable = Snowflake | GuildEmoji | ReactionEmoji;

I fail to see how this could even occur. It looks like you're passing a RawEmoji instead, which isn't documented nor typed to be sent across?

[Nephrited]

RawEmoji looks to be exactly what the DiscordAPI accepts for this call, as documented here on the Discord API, and it does work if forced through.

With that said, an EmojiResolvable looks to be the right way to handle this via the library, so perhaps a non-issue after all. I'll update my code to use it.

[Jiralite]

This is a library, so things can be altered! If you have a custom emoji, just pass the id. If you want to use a default emoji, just pass the Unicode variant. Under-the-hood, this is transformed to the necessary payload (RawEmoji) to be sent across. Simply specifying an id or the Unicode variant is a convenience here.

TS enforces a full emoji object of type EmojiIdentifierResolvable

This can be a string or an id, so it's not always an object!

[Nephrited]

Makes total sense to me. I'll close this out, hopefully anyone with a similar problem will run into it!

[monbrey]

Arguably this is just a typings issue then, and RawEmoji could be added to resolvable items.