Slash command registration
How to keep Discord command definitions in sync without turning Shardwire core into opaque registration magic.
Shardwire delivers interactionCreate and interaction actions across the bridge. It does not automatically register slash commands with Discord’s REST API—that remains an explicit bot-side concern so registration stays testable and versioned with your command definitions.
Recommended options (in order)
1. MDX recipe + your script (default)
- Store command JSON or builder definitions in your repo.
- Run a deploy script in the bot process (or CI) that calls Discord’s REST endpoints when definitions change.
- Keep the bridge focused on runtime traffic only.
2. Small optional helper package (only if demand is clear)
If the community wants a shared helper, prefer a sibling package (for example scoped under @shardwire/…) that:
- runs only in the bot process
- accepts explicit inputs (application id, token, command payload list)
- is fully covered by tests
Do not hide REST registration inside createBotBridge startup without an opt-in flag and documentation— that makes failures harder to diagnose and couples Shardwire to Discord REST versioning more than necessary.
How this fits Shardwire’s model
- Manifest declares that your app consumes
interactionCreateand which interaction actions you need (Manifests). - Registration decides what Discord shows in the command picker—orthogonal to bridge negotiation.
Related
Recipe: music bot + remote web controller
Use Shardwire for Discord voice and member actions while a separate channel carries player/queue state for a dashboard—no custom wire primitives.
Deployment
Production deployment changes the transport story: use TLS, treat secrets as contracts, and verify capability scope before rollout.