plugin-gateway: port ApplicationEmoji (with its manager) and ApplicationCommand (discord.js parity) #207

Activity

1. pullfrog commented on Oct 5, 2026

   

   pullfrogBot

   on Oct 5, 2026 – with Pullfrog

   Last edited by pullfrog

   Contributor

   More actions

   Assessment

   Actionable, but I'd split it into three PRs, and one design decision needs a maintainer answer first (see "Decisions needed"). I checked the claims in the issue against packages/plugin-gateway and the installed @discordjs/core@2.6.0 and @wolfstar/http-framework@6.1.0.

   Findings

   • Nothing exists yet. src/ has no ClientApplication, no ApplicationEmoji, no ApplicationCommand, and no client.application. The only application-adjacent code is the Integration#application payload field. The READY dispatch (src/util/dispatch.ts:154) builds client.user but discards data.application.
   • The REST surface is complete in @discordjs/core. ApplicationsAPI has getCurrent, getEmojis, getEmoji, createEmoji, editEmoji and deleteEmoji. ApplicationCommandsAPI has the global and guild CRUD, bulkOverwriteGlobalCommands, bulkOverwriteGuildCommands, getGuildCommandPermissions, and editGuildCommandPermissions(userToken, ...). No raw Routes.* escape hatch should be needed.
   • There is a clear template for the emoji half. Emoji (src/structures/emojis/Emoji.ts) is already a shared base, with GuildEmoji as a subclass. GuildEmojiManager and GuildEmoji show the exact create, edit, delete, fetchAuthor shape, and the structure edit() and delete() conventions. GuildEmoji#equals is the model for ApplicationEmoji#equals.
   • The framework overlap is real. ApplicationCommandRegistry.pushGlobalCommands() in http-framework PUTs Routes.applicationCommands(clientId), which is a bulk overwrite. A client.application.commands.set() here would replace whatever the framework registered. This is the risk the issue's first question raises.
   • The cache story favours fetch-only. @wolfstar/plugin-cache already holds applicationCommandPermissions, a plain MemoryEntityCache outside cacheOptions. It is the only entity with a gateway event (APPLICATION_COMMAND_PERMISSIONS_UPDATE). Commands and application emojis have no gateway events, so a cache would go stale and nothing could repair it.

   Proposed split

   PR 1: ClientApplication (prerequisite). Scope is feat(plugin-gateway).

   • Add src/structures/applications/ClientApplication.ts, with id, flags (from READY's application), emojis and commands getters, and fetch() via api.applications.getCurrent().
   • Expose client.application: ClientApplication | null. It is set in the READY handler next to client.user, in the same way. The ID also falls back to client.id, so the REST-only managers work before READY.
   • Leave out owner/team, install params, role connection metadata, SKUs and entitlements. Each can be its own follow-up.

   PR 2: ApplicationEmoji and ApplicationEmojiManager.

   • ApplicationEmoji extends Emoji, with id, name, animated, author, application, edit(), setName(), delete(), fetchAuthor() and equals().
     • The equals() argument is ApplicationEmoji | APIEmoji-shaped. It returns false for a foreign argument, as plugin-gateway: structure compatibility of equals() across structures (discord.js parity) #203 does, and has no roles comparison.
     • The API payload has no managed, requires_colons or available. Either port discord.js' defaults or compare only the fields the payload carries; I'd lean towards the latter, and the PR should say which.
   • ApplicationEmojiManager is a plain BaseManager and fetch-only, like WebhookManager. It has fetch(id?), create() (reusing resolveImage), edit(), delete() and fetchAuthor().
   • It takes the application ID from ClientApplication. GatewayError codes go in errors/Messages.ts if needed.

   PR 3: ApplicationCommand and its managers.

   • ApplicationCommand structure with the fields listed in the issue, plus edit(), the set*() helpers, delete(), equals(command, enforceOptionOrder?) and the static optionsEqual(). Option comparison is recursive and ported from discord.js.
   • ApplicationCommandManager (global) and GuildApplicationCommandManager (guild.commands, a new instance per access like the other guild sub-managers). Both have create, fetch, edit, delete and set.
   • ApplicationCommandPermissionsManager with fetch, has and, for writes, set, add and remove. The writes take a bearer token option, passed through to editGuildCommandPermissions(userToken, ...). Without a token they throw a typed GatewayTypeError.
   • Reads can reuse the existing applicationCommandPermissions store, kept in sync by the gateway event. That is the only cached piece.
   • Tests live in packages/plugin-gateway/tests/, with the usual mocked core.api pattern. A type-level case goes in tests/types/*.ts if the resolvable types are public.

   Each PR also needs:

   • A changeset for @wolfstar/plugin-gateway (minor).
   • Exports through index.ts and managers/index.ts.
   • The four quality gates: pnpm lint, pnpm build, pnpm typecheck, pnpm test.
   • A README or API docs mention.

   Decisions needed before implementing

   1. Cached or fetch-only? I recommend fetch-only for emojis and commands, with the existing applicationCommandPermissions store as the only cached piece. It avoids new plugin-cache entity types, and a cache with no events to invalidate it would go stale.
   2. Framework overlap. I suggest keeping set() because the issue asks for parity, but documenting that it overwrites the http-framework registry, and not wiring anything automatically. Is that acceptable, or should set() be omitted or guarded?
   3. Separate issue for ClientApplication? I'd keep it as PR 1 under this issue, since it is small, and split further ClientApplication fields into their own issues.
   4. Permission writes need a bearer token. I'd accept an explicit token option and not add any OAuth handling. Is that enough?

   I haven't started implementing. Say which of these you want changed, or whether to begin with PR 1.

     ^{｜ Implement plan ➔ ｜ View workflow run ｜ via Pullfrog ｜ Using claude-sonnet-5-5 ｜ 𝕏}
2. RedStar071

   changed the title [-]plugin-gateway: port ApplicationEmoji and ApplicationCommand with their managers (discord.js parity)[/-] [+]plugin-gateway: port ApplicationEmoji (with its manager) and ApplicationCommand (discord.js parity)[/+] on Oct 5, 2026
3. RedStar071

   added 2 commits that reference this issue on Oct 17, 2026

   feat(plugin-gateway): add ApplicationEmoji and ApplicationEmojiManager

   ...

   8dd73a3

   feat(plugin-gateway): add ApplicationEmoji and ApplicationEmojiManager

   ...

   ff4c69a
4. RedStar071 commented on Oct 17, 2026

   

   RedStar071

   on Oct 17, 2026

   MemberAuthor

   More actions

   Done: ApplicationEmoji and ApplicationEmojiManager in #250, ApplicationCommand with its managers in #252. Both are fetch-only, as discussed (no new plugin-cache entity).
5. RedStar071

   closed this as completedon Oct 17, 2026