User Bundle Laravel Package

Product Decisions This Supports

• Identity architecture for multi-actor products. The bundle’s core value proposition is supporting several distinct user classes (e.g., customer, admin, vendor) behind one authentication surface, plus OAuth login. That directly informs how we model actors in the domain: separate tables per actor vs. a single polymorphic user record with roles. This is a foundational schema decision that is expensive to reverse, so it should be settled before feature work on accounts, permissions, or checkout begins.
• Build vs. buy for the auth layer. Adopting this bundle is effectively “buy,” but with a maintenance tail. The decision framework: does the bundle save us more than the cost of owning a fork? Release history now shows a v1.10.0 maintenance bump (PHP 8 support, PHP 7.3 dropped) after a long dormancy since 2021-04-06, alongside 1 star, 0 dependents, and a read-only mirror status. A single compatibility release is hygiene, not a maintained roadmap. The honest answer for anything long-lived is still “use it as a reference implementation, not a dependency.”
• OAuth / social login roadmap feasibility. The package claims OAuth support, which is a real product requirement for consumer-facing signup funnels (Google/Apple/Facebook reduce registration drop-off). The assessment here is whether OAuth is a “configure and ship” item or a “build the integration ourselves” item — with this package it is the latter, scoped against maintained alternatives (league/oauth2-client + a maintained Symfony client bundle, or the framework’s own OAuth/OIDC support).
• Ecosystem lock-in and migration planning. If we are already on Sylius/Monofony, this bundle is the incumbent — and the PHP 8 release at least keeps it installable on a modern runtime. The decision is whether to track upstream Sylius, fork and own this mirror, or migrate off. If we are not on that stack, this is a non-starter and the decision collapses to “pick the native auth stack.”
• Dependency governance and vendor risk policy. A package that went dormant for years and resurfaced only to bump a PHP version constraint is a useful forcing function for a written policy on acceptable dependencies: last-release age, cadence (one release ≠ maintained), maintainer activity, transitive surface area, and who is on the hook for security patches. This one still fails most reasonable thresholds, which makes it a clean example to codify the rule around — including the rule that a lone compatibility commit does not reset the clock.
• Roadmap sequencing. Identity is a prerequisite for almost everything downstream (billing, entitlements, multi-tenant roles). Whatever we choose, it needs to land early and be treated as platform, not feature — the cost of swapping identity providers mid-flight is measured in quarters, not sprints.

When to Consider This Package

Consider it when:

• You are already inside the Monofony/Sylius ecosystem and want a drop-in, familiar user model rather than inventing one — v1.10.0 makes this viable on PHP 8, which was previously a blocker.
• You are building a prototype, internal tool, or throwaway demo on PHP 8 where the auth layer is not security-critical and speed matters more than longevity.
• You want a reference implementation: read the source to steal the polymorphic user + OAuth wiring design, then implement it against the framework’s native security component. The MIT license makes this straightforward and legally clean.
• You need a small, self-contained codebase to reason about multi-user-type modeling without pulling in all of Sylius.

Look elsewhere when:

• The target is Laravel. This is a Symfony bundle built around Symfony’s security, DI, and event system. It does not port. Laravel teams should be evaluating Fortify/Breeze/Jetstream, Sanctum or Passport for tokens, and Socialite for OAuth. The underlying product question (multiple user types) is answered in Laravel with guards/providers or a single users table plus roles — not with this package.
• The product is long-lived or regulated. The v1.10.0 notes cover PHP 8 only; nothing indicates Symfony 6/7 certification, a support window, or a security-response process. A years-long gap followed by a single constraint bump does not restore our confidence in CVE turnaround on the auth path. Auth is the highest-blast-radius code you own; a stale dependency here remains an unacceptable risk for anything handling PII, payments, or compliance obligations.
• You need support or a community. 1 star and 0 dependents means no Stack Overflow corpus, no third-party tutorials, no one else hitting your bugs. Every issue is yours alone.
• You need modern OAuth/OIDC. Current expectations (PKCE, OIDC discovery, provider churn as APIs change) outpace a codebase whose feature surface last moved in 2021. Use actively maintained client libraries.
• You need MFA, passkeys, or session management policy. These are table stakes now and are not in scope. Note that dropping PHP 7.3 is a breaking platform change for anyone still on 7.x — budget a runtime upgrade before you can even take the patch.

How to Pitch It (Stakeholders)

To executives (one paragraph): We re-reviewed monofony/user-bundle following its v1.10.0 release. The change is narrow — PHP 8 support added, PHP 7.3 dropped — and it is the first movement since April 2021. It is MIT-licensed and solves a real problem (multiple user types plus social login), but one compatibility release does not make it maintained: one star, zero dependent projects, a read-only mirror, and no stated support or security process. Adopting it would still mean we inherit all future maintenance, Symfony upgrade work, and security patching for the most sensitive code in the product. My recommendation is unchanged: use it as a free design reference rather than a dependency, and build on maintained libraries. Net effect: no license cost, a small upfront design saving, and we avoid an open-ended maintenance liability on the auth path.

To engineering (the short version): Read-only Sylius-derived bundle; gives you a polymorphic multi-user model and OAuth wiring out of the box. v1.10.0 adds PHP 8 and drops PHP 7.3 — so it installs on a modern runtime, but that is the entire delta. Assume no Symfony 6/7 certification beyond what the constraint allows and no CVE response. If we are on Sylius/Monofony already, pin to v1.10.0 and budget for owning the fork; otherwise, copy the model into our own security.yaml + user provider and use league/oauth2-client (or the framework-native equivalent) for OAuth. Either way, we own the identity layer — the only question is whether we also own a dormant dependency.

Decision requested: Reaffirm “reference-only” status for this package and fund the identity layer as a scoped build against maintained components. The v1.10.0 release does not change the risk profile or the recommendation; estimated effort remains bounded and front-loaded, while the alternative is an unbounded tail.