User Bundle Laravel Package

Product Decisions This Supports

• Build vs. buy for authentication — but this is a "build," not a "buy." The package is a fork of FOSUserBundle, the long-abandoned Symfony user-management bundle. There is no vendor, no support contract, and no release cadence to buy into (last release 2021-07-23, 0 stars, 0 dependents). The decision it actually informs is "we will own this code," not "we will depend on this vendor."
• Roadmap scoping: identity is table stakes, not differentiation. Registration, login, password reset, email confirmation, profile editing, and role/group assignment are commodity capabilities. Treat them as a two-to-five-day enabler and keep the roadmap budget on the actual product surface.
• Platform/stack decision that needs correcting before it becomes a sunk cost. The package is a Symfony bundle, not a Laravel package — FOSUserBundle is explicitly Symfony-only (Doctrine ORM/ODM, Symfony's security firewall, Symfony DI container). Any Laravel-side product decision here is a category error; the equivalent Laravel decisions are Breeze/Jetstream/Fortify plus Sanctum or Passport.
• Legacy-sustainment decisions. The only defensible use case is a decision like "do we keep our existing FOSUserBundle install alive for one more release, or do we fund a migration?" This fork is evidence that the upstream is unmaintained, which is itself an input to the migration-vs-patch tradeoff.
• Supply-chain and security posture decisions. Auth sits inside the blast radius of SOC 2 / PCI / ISO 27001 scope. A 0-star, 0-dependent, single-author fork with no CVE pipeline means the decision is "we accept unpatched auth risk" — one that should be escalated, not absorbed by an engineer.
• Provenance decision. The repo name (MrDanshur/FOSUserBundle) republishes a well-known abandoned package under a different Packagist vendor. Regardless of intent, that pattern is indistinguishable from typosquatting and warrants a "do not install without a code review" ruling.

When to Consider This Package

Consider it only if all of the following hold:

• You are already on Symfony (3.x/4.x) with FOSUserBundle wired into an existing firewall, entities/documents, and templates.
• You need a stopgap patch (PHP 8.x or Symfony 5.x compatibility) and have no budget this quarter for a migration.
• You have, or will immediately perform, a line-by-line diff against upstream FOSUserBundle and a dependency audit of the fork.
• You accept that you are now the maintainer, and you have scheduled a deprecation date rather than a "someday."

Look elsewhere — decisively — when any of these are true:

• It is a Laravel project. This package cannot serve you at all. Use laravel/breeze or laravel/jetstream (which pull in Fortify), laravel/sanctum for SPA/mobile tokens, or laravel/passport for full OAuth2.
• You are greenfield on Symfony. Go native: symfony/security-bundle with maker-bundle (make:user, make:auth, make:registration-form). You get first-party maintenance, docs, and a CVE channel for free.
• You need API/JWT auth. Use lexik/jwt-authentication-bundle (Symfony) or Sanctum (Laravel).
• You need 2FA, SSO/SAML/OIDC, or social login. Use scheb/2fa-bundle, knpu/oauth2-client-bundle, or a managed IdP (Auth0, WorkOS, Cognito, Keycloak). Buying identity is cheaper than forking it.
• You have any compliance obligation. No maintained fork, no security contact, no advisories = a finding in your next audit.
• You are on a small team. One engineer leaving the company should not orphan your login system.

How to Pitch It (Stakeholders)

To executives: We evaluated a community fork of a retired user-login library. It is not a product or a vendor — it is one person's copy of an abandoned project, with zero downstream users and no release in over three years. Recommending against it. Authentication is the front door to customer data, so it belongs inside our security and compliance perimeter, and this dependency would sit outside it with no patching path. The alternative is to use the frameworks' first-party, actively maintained auth components at effectively the same build cost — roughly a few engineering days — which is cheaper than owning a fork forever.

To engineering: This is a Symfony bundle (FOSUserBundle fork), so it is not applicable to our Laravel services. Where a Symfony app is still on FOSUserBundle: do not adopt the fork by default; instead run a timeboxed spike comparing (a) symfony/security-bundle + MakerBundle's make:user/make:auth and (b) migrating to a managed IdP if SSO/2FA is on the roadmap. If we do take the fork as a stopgap, we diff it against upstream, pin the commit in composer.json, add it to the dependency-review and advisory watchlist, and file a ticket with a hard removal date. Estimated effort: 2–4 days for the native path, 1 day plus permanent ownership for the fork.

Bottom line: Do not adopt. Treat this repo as a signal that our FOSUserBundle dependency is end-of-life and fund the migration.