mrgoodbytes8667/discord-interaction-bundle
A Symfony bundle for handling Discord interactions in your PHP application. Register slash commands, route interaction payloads, and respond to Discord requests through a structured, framework-integrated setup, keeping Discord-specific plumbing and signature verification out of your controllers.
Architecture fit. Unchanged. The v0.1.0 release does not alter the fundamental mismatch: this is a Symfony bundle, not a Laravel package. It ships a Bundle subclass, a DI extension, services.yaml, routing resources, and listeners wired to Symfony\Component\EventDispatcher\EventDispatcherInterface. Laravel has no bundle contract — no kernel registration, no compiler passes — so nothing installs as-is regardless of which Symfony major it targets. What remains portable is the concept: an HTTP endpoint that receives a Discord interaction POST, verifies X-Signature-Ed25519 / X-Signature-Timestamp, answers PING with PONG, and dispatches a domain event per application command. That maps cleanly onto a Laravel route + middleware + Illuminate\Contracts\Events\Dispatcher.
Integration feasibility. Still moderate effort / low fidelity, and the recommended path is unchanged. (a) Treat the repo as a reference implementation and hand-roll a ~300-line Laravel controller + signature middleware + event classes — days, not weeks. (b) Sidecar Symfony service — still only viable if you already run Symfony. (c) Fork and providerize — still the highest-fidelity, highest-ownership option. Path (a) remains correct.
Technical risk. High, but the nature of the risk shifted marginally with this release. Two prior claims need correction:
console, http-foundation, process are 6.x on Laravel 10), so the Composer conflict risk is reduced but not eliminated — the bundle still pulls symfony/framework-bundle and the HttpKernel, which Laravel neither needs nor wants.Everything else stands. Still zero stars, zero dependents in any meaningful sense. The release note describes a CI/testing change, not a feature: no Discord API surface was added. A 2021-era capability set almost certainly still means classic slash commands only — no components, modals, autocomplete (type 8), context menus, entitlements, or premium buttons. The license remains NOASSERTION; legal review is still a hard gate before vendoring or redistributing. Note also that the version went 0.0.3 → 0.1.0: under 0.x semver, a minor bump is permitted to break, and a Symfony constraint jump from 5 to 6 is exactly that kind of break for any existing Symfony 5 consumer. There is no evidence of a functional breaking change, but there is also no changelog beyond a single PR title.
Key questions. What Symfony and PHP constraints does the updated composer.json declare, and did Symfony 5 support get dropped? Is there any change beyond CI configuration — specifically, did the Discord interaction handling itself change? What is the actual license text (unchanged blocker)? Does it implement Ed25519 verification itself or delegate? Does it dispatch per-command events or a single generic interaction event? Does it support components/modals/autocomplete? Is there a non-bundle core library underneath? Has the maintainer signalled a roadmap, or was this a one-off CI fix?
Stack fit. Unchanged. Target Laravel 10/11 on PHP 8.2+ with ext-sodium enabled. Webhook route excluded from CSRF, registered outside the web middleware group, Discord signing key in config. Stock queue, cache, and logging cover the rest.
Migration path. Ranked identically: (1) reference-only reimplementation — recommended; (2) sidecar Symfony container; (3) fork-and-providerize. The Symfony 6 alignment makes option (3) very slightly less painful and option (1) no more attractive than it already was. Do not begin with composer require; the framework-bundle conflict is still the likely outcome, now just against a newer floor.
Compatibility. Two hard gates remain. Composer: symfony/framework-bundle vs. Laravel's pinned Symfony components — narrowed by this release, not closed. Protocol: still verify against the current Discord API version and interaction types, because the release added no protocol coverage. Signature verification and the PING handshake are stable and will work; command payload shapes are where drift bites, and drift is untouched by v0.1.0.
Sequencing. Unchanged. Phase 0 (2 engineer-days): spike a hand-rolled controller that passes endpoint validation, verifies signatures, answers PING, handles one slash command synchronously. Phase 1 (1 week): command registry, event classes, per-command listeners. Phase 2: deferred responses (type 5) plus follow-up webhooks for anything exceeding the 3-second budget. Phase 3: components, modals, autocomplete — only if the product needs them. If Phase 0 succeeds, the package still adds no value; kill it there.
Maintenance. Improved from "zero upstream" to "sporadic upstream" — one release in roughly four years, and it was CI hygiene rather than capability. Planning assumptions should not change: if you fork, you own it. Budget 10–20% of one engineer per quarter for a fork; near-zero if you only borrowed the architecture.
Support. Still no vendor, no community, no consequential issue history. The maintainer is reachable enough to merge a PR, which is a modest positive signal for the license and roadmap questions — worth asking, but not worth waiting on. The license ambiguity remains the primary support risk and is a legal question, not an engineering one.
Scaling. Unchanged and independent of this release. The endpoint is stateless HTTP and scales with the web tier. The 3-second acknowledgement deadline is the binding constraint: signature verification is cheap, but any database or third-party call must be fast or deferred to a type-5 response plus follow-up webhook. Follow-ups are rate-limited (~5 per interaction), and Discord retries failed deliveries — key the handler on interaction ID for idempotency.
Failure modes. Unchanged. Missing or invalid PONG fails endpoint validation and the app cannot be registered. Signature failures return 401 and repeated errors get the endpoint disabled. Responses slower than 3 seconds surface as "This interaction failed." Retries without idempotency duplicate side effects. Clock skew or a stale timestamp window rejects legitimate requests. Signing-key rotation and leaked bot tokens remain the two credential incidents to plan for.
Ramp-up. Low. A mid-level Laravel developer reaches a working slash-command endpoint in two to three days without reading this repo. The cost asymmetry is unchanged and still inverted: the expensive path is adapting a stale, ambiguously licensed Symfony bundle rather than writing a small amount of first-party code.
Verdict. v0.1.0 is a CI/testing change with a version bump, not a capability release. It softens two negatives — the project is not fully abandoned, and it now targets Symfony 6, which is closer to Laravel 10/11's dependency floor. It does not address the two disqualifiers: no Laravel install path, and no clear license. Use this repository as a design reference for the event-dispatch shape, not as a dependency.
How can I help you explore Laravel packages today?