Discord Client Bundle Laravel Package

Product Decisions This Supports

• Build vs. buy for Discord OAuth onboarding. Unchanged in scope by v0.15.0. The package remains a reference implementation of the "buy" side of a narrow decision: wiring Discord's OAuth2 authorization-code flow into a PHP app (authorize redirect, callback route, token exchange, user identity fetch). It helps scope what "done" looks like — two routes, a state/nonce guard, a token exchange, and a user-mapping step — before you commit engineering time to building it yourself or evaluating a heavier identity provider.
• Feature discovery for "Login with Discord" / community-gated access. Still useful as a checklist when defining acceptance criteria: what happens on first login, how refresh tokens are stored, how guild membership or role claims are surfaced to your authorization layer, and how account linking works for users who already signed up by email.
• Roadmap sizing for community-integrated products. If your roadmap includes Discord bots, role-gated content, or community tiers, this repo concretely demonstrates the OAuth-only slice of that work. Nothing in the new release note indicates bot presence, webhooks, gateway events, or slash-command support, so it still should not be used to size a full Discord integration.
• Framework-fit decision, not a feature decision. The package is a Symfony bundle, not a Laravel package, and the release note gives no reason to think that changed. For a Laravel codebase this remains a signal to compare against laravel/socialite (with the community Discord provider) rather than adopt this directly. The decision it informs is "which ecosystem do we standardize on," which is a genuine architecture call worth making explicitly rather than by accident.
• Maintenance signal: revised, not resolved. The prior assessment's "no release since April 2023" line is now stale — v0.15.0 exists, and the compare range (v0.6.0...v0.15.0) implies a series of releases since. But the release note is a bare changelog link: no described features, breaking changes, deprecations, license change, or security policy, and no dates. A 0.x series also signals pre-1.0 churn. Treat this as "has shipped, still unverified," not "actively maintained."
• Not a vendor-risk decision. Adoption signals were not part of this release and no data here suggests a change (previously: 1 star, 0 dependents). It should still not appear on a build-vs-buy comparison as a viable third-party dependency. Its value to a PM is as documentation and prior art, not as a supply-chain choice.

When to Consider This Package

Consider it only as a read-only reference — a source of design cues for the Discord OAuth handshake — when:

• You are on Symfony 5/6 and want a small, self-contained OAuth client rather than pulling in a full social-login abstraction.
• You need a known-good example of Discord's token endpoint and /users/@me response shape to sanity-check your own implementation.
• You are writing an internal spike and want a working scaffold to compare against, quickly.

Look elsewhere — and by default, plan to look elsewhere — when:

• You are on Laravel. This is a Symfony bundle with Symfony service container, routing, and event conventions; v0.15.0 does not advertise Laravel support. Making it work in Laravel means porting, not installing. Use Socialite or call Discord's endpoints directly with the HTTP client.
• License clarity is required. The license field reads NOASSERTION, and the release note contains no licensing change. For any commercial product that is a blocker until a human reads the actual license file and legal signs off. Do not let this into a dependency tree on the assumption it is "probably MIT."
• Maintenance matters. The project is still a single-maintainer, zero-dependent package with no visible security policy, and Discord's API and OAuth scopes evolve. Read the v0.6.0...v0.15.0 changelog yourself before relying on it at all — the release note tells you nothing about PHP/Symfony compatibility, token or scope handling changes, or upgrade breakage. Assume you own the code the moment you adopt it.
• You need more than OAuth. No bot, webhook, gateway, or slash-command support described. If the requirement is "our Discord integration," this covers roughly the login step and nothing further.
• You need SLAs or security disclosure processes. Not appropriate for handling OAuth tokens and refresh credentials in production.

How to Pitch It (Stakeholders)

For executives (one paragraph): A small open-source component that handles "Sign in with Discord" for PHP applications. The project shipped a new version (v0.15.0) but published no description of what changed. Our recommendation is unchanged: do not take it as a dependency — it is built for a different PHP framework than ours, has an unclear license, has essentially no adoption, and remains a single-maintainer project with no security policy. We recommend using it only as a design reference and implementing Discord login in-house with our existing HTTP and auth tooling, roughly a one-to-two-week effort, which removes the legal and maintenance risk entirely.

For engineering: Treat mrgoodbytes8667/discord-client-bundle as a Symfony reference implementation, not a candidate dependency. It shows the expected shape — authorize redirect with state, callback route, code-for-token exchange, /users/@me fetch — but it is a Symfony bundle, single-maintainer, zero dependents, and carries a NOASSERTION license. Release v0.15.0 adds no reviewable information (the note is only a v0.6.0...v0.15.0 compare link), so before citing it as an example: read that diff, pin whichever tag matches our target PHP/Symfony version, and assume breaking changes given the 0.x jump across an unknown timeline. Recommended path is unchanged: Laravel teams use Socialite's Discord driver or a thin custom client over Discord's OAuth2 endpoints; Symfony teams use a maintained OAuth2 client such as knpu/oauth2-client-bundle with a Discord provider. Either way, we own token storage, refresh handling, and the mapping from Discord identity to our user records — that mapping is the part with real product logic in it, and it is the part no off-the-shelf bundle will get right for us.

Ask: Approve the in-house build (~1–2 weeks, one engineer) and close out the third-party evaluation. If we later need a heavier identity layer, revisit with vendors that offer a support contract rather than single-maintainer packages.