User Bundle Laravel Package

Product Decisions This Supports

• Scoping the "user accounts" epic for an MVP. The bundle's feature surface — registration, login, password reset, profile editing, email confirmation, group/role management — works as a checklist for what "we need users" actually implies across roadmap conversations. Use it to size the auth epic, then discard the package.
• Build vs. buy, resolved toward build. Auth is a commodity: frameworks ship first-party primitives (Symfony Security + MakerBundle's make:user/make:auth; Laravel Breeze/Jetstream/Fortify). A third-party package only wins if it is actively maintained — this one is a deprecated fork with 0 stars and 0 dependents, so the buy case collapses and the build case is a 1–2 sprint spike, not a quarter.
• Stack-fit gate. Despite being listed among Laravel/PHP packages, this is a Symfony bundle (a fork of FOSUserBundle) built on Symfony's DI container, EventDispatcher, UserInterface/UserProviderInterface, Doctrine mappings, and kernel bundle registration. Laravel has none of those surfaces — service providers, facades, Auth guards and Eloquent instead. If the roadmap is Laravel, close this out of the backlog immediately rather than re-evaluating later.
• EOL migration planning. Upstream FOSUserBundle is deprecated and unmaintained. For any product still running it, this fork does not solve the problem — it relocates the liability to us. That directly informs a migration decision toward native Symfony security, with a deprecation date attached and budget for password-hash migration plus re-registration/confirmation flows.
• Dependency policy precedent. A concrete case to justify a standing rule: no forks of deprecated packages, and no security-sensitive code without a named maintainer, a release cadence, and a subscribable advisory feed.
• Estimating sequencing work. The realistic paths are (1) one engineer-day of discovery to confirm stack target and read the fork diff against upstream, (2) a decision gate — adopt / migrate-off / reject, (3) a scoped migration spike for the auth module if legacy, and only then (4) an estimate.

When to Consider This Package

Adopt only under narrow, uncomfortable conditions:

• You have inherited a legacy Symfony app already wired to FOSUserBundle and need a temporary, pin-to-a-commit stopgap while a migration is funded.
• You need it as a read-only reference artifact — the source is a worked example of classic Symfony auth flows (form login, reset tokens, confirmations) that can inform your own implementation. This is the most credible use for a PM: a one-day discovery input, not a dependency.
• You are prepared to fork and own it: security patches, Symfony/PHP version bumps, and a named maintainer on your team with Symfony idiom knowledge (bundles, DI tags, event subscribers) — days of ramp-up per engineer, recurring with every new hire.

Look elsewhere in every other case:

• New Symfony app → Symfony Security component + MakerBundle; add knpu-oauth2-client for social login.
• Laravel app → Breeze, Jetstream, or Fortify; Socialite for OAuth. This package is not applicable and Composer installing successfully is not integration.
• Needing MFA, passkeys, or modern session handling → first-party or actively maintained options only.
• Anywhere auth sits on the critical path — 0 stars and 0 dependents means no community review of security-sensitive code, which is disqualifying on its own. Additional verification before any deeper work: the composer.json constraints (deprecated Symfony bundles frequently pin PHP 7.x / Symfony 3–4), and whether the fork diverges from upstream, which would invalidate upstream docs and Stack Overflow answers and extend every debug cycle.

How to Pitch It (Stakeholders)

Executive summary: We evaluated grizzlylab/user-bundle as a shortcut for user accounts and recommend against adoption. It is a low-activity fork of FOSUserBundle, a Symfony bundle whose upstream is deprecated — 0 stars, 0 dependents, no named maintainer, no security feed we can subscribe to. Putting unmaintained code in the authentication path is a security and continuity risk we would have to absorb ourselves with no external support, and it is a permanent unbudgeted maintenance tax on a deprecated codebase.

To engineering: it's Symfony, not Laravel — no service provider, no artisan command, no autodiscovery hook — so it does not fit our stack, and there's no realistic adapter short of rewriting it. Even on Symfony, the modern path is the framework's native security plus MakerBundle: fewer dependencies, first-party support, no fork to babysit. If we need OAuth or MFA, we pick an actively maintained library at that time. Failure modes to plan around if we adopted anyway: silent runtime breakage on a Symfony/PHP bump, an unpatched CVE in the auth path with no upstream fix, bus factor of one, fork divergence, and password-hash lock-in that makes migration progressively harder.

Recommendation: close this out. Fund a short spike to implement auth on native framework primitives (Symfony Security + MakerBundle, or Laravel Fortify/Breeze), and record the outcome as precedent for a "no deprecated forks in security-sensitive paths" dependency rule. Do not re-open unless we inherit a FOSUserBundle app and need a stopgap — in which case treat this as a decommissioning input and budget the migration before committing to a replacement plan.