Multi User Bundle Laravel Package

Technical Evaluation

Architecture fit — poor, with a framework mismatch that dominates everything else. Despite the "Laravel/PHP package" framing of this request, rollerworks/multi-user-bundle is a Symfony bundle, not a Laravel package. It cannot be installed into a Laravel application without a Symfony kernel, a service container with compiler passes, and FOSUserBundle — none of which exist in Laravel. If our stack is Laravel, this evaluation ends at stack fit.

Within its native Symfony context the architecture is actually a recognizable pattern: a "multi-user" layer sits on top of FOSUserBundle and lets each logical user class (e.g. Customer, Admin, Vendor) own an isolated set of services — user manager, form type, form handler, templates, and a dedicated security firewall/provider. A compiler pass registers these per-type service groups and a MultiUserManager-style registry resolves the correct one at runtime based on the firewall/route in play. That is a sensible design for apps that genuinely need distinct user entities with distinct login flows, rather than just roles.

Integration feasibility — low to negligible. Last release April 2015, repository archived, org literally named rollerworks-graveyard, description self-labels "DISCONTINUED!!". Composer constraints will target Symfony ~2.3–2.8 / PHP 5.x-era tooling and FOSUserBundle 1.x/2.x. Modern Symfony (5/6/7) removed or deprecated the components this bundle leans on (templating, ContainerAware, form type getName() conventions, security UserProvider signatures). FOSUserBundle itself is effectively legacy-maintained, so we would be stacking one unmaintained dependency on another in the authentication path.

Technical risk — high and asymmetric. This is an auth-adjacent package: a defect is not a UI bug, it is a potential cross-user-type privilege escalation if firewall or provider scoping is wrong. With zero dependents, 56 stars, ten years of no releases, and an archived repo, there is no upstream security response, no CVE triage, and no community validation of edge cases. Any finding becomes an internal fork obligation. The "opportunity" score of 4.25 is misleading here — it likely reflects unmet functional demand in the ecosystem (multi-user-type auth is a real gap), not the fitness of this artifact to meet it.

Key questions before any further spend:

1. What framework are we actually on — Laravel, Symfony, or both across services? If Laravel, close this out and evaluate native multi-guard auth instead.
2. Is the requirement multiple user entities with separate credentials/firewalls, or just roles and permissions on one user table? The latter is solved natively everywhere and needs none of this.
3. If Symfony: is there a live legacy app pinned to Symfony 2.x/FOSUserBundle that this would extend, or are we greenfield? Greenfield makes adoption indefensible.
4. Do we need tenant-scoped user providers (multi-tenancy), or per-audience login (admins vs customers)? These are different problems with different modern solutions.
5. What is our appetite for owning a fork of abandoned auth code, including a named internal maintainer?

Integration Approach

Stack fit. Two branches, and they should be decided before any engineering time is booked.

• Laravel: no fit. Map the requirement to native guards and providers — separate EloquentUserProvider per guard in config/auth.php, distinct models, distinct route groups and middleware, plus spatie/laravel-permission if authorization granularity is the real need. For tenant-scoped users, stancl/tenancy or hyn/multi-tenant with per-tenant connections. This is days of work, fully supported, and security-reviewed by a large community. The Symfony bundle contributes nothing here beyond inspiration for the guard-per-user-type idea.
• Legacy Symfony: viable only as a tactical patch on an existing Symfony 2.x/FOSUserBundle app. Pin the bundle and its transitive constraints, lock PHP to the supported ceiling, and treat the app as frozen — no parallel Symfony upgrades.

Migration path. Do not attempt to carry this bundle forward into a modern Symfony app. If the underlying requirement survives, the migration target is Symfony's native security: one UserProvider and one firewall per user class, make:user-generated entities, and a small internal registry service that resolves the active user type from the firewall name. That reproduces the useful 20% of this bundle — the discriminated registry — in roughly a few hundred lines we own and can test. For a genuine FOSUserBundle exit, migrate to Symfony's native security plus a supported auth package; FOSUserBundle's own docs have long pointed this direction.

Compatibility. Expect friction on: PHP version ceiling, Symfony minor-version pinning, Doctrine ORM/DBAL coupling, form type naming and templating assumptions, and FOSUserBundle event/subscriber signatures. Verify each explicitly in a throwaway container before committing — do not assume composer require resolves.

Sequencing.

1. Framework clarification (½ day). Confirm stack; if Laravel, stop and redirect to native guards.
2. Requirements decomposition (1–2 days). Separate "multiple user types" from "multiple roles" from "multi-tenant users." Most requests collapse into the cheaper category.
3. Isolated spike (3–5 days, only if legacy Symfony). Pinned Symfony 2.8 + PHP 7.x container, two user types, verify firewall isolation and form handler wiring, attempt one deliberate cross-type access to confirm it is blocked.
4. Build-vs-fork decision. Default to a thin internal implementation of the registry pattern; fork only if the spike proves the bundle is load-bearing in an app we cannot otherwise touch.
5. If forking: vendor the code in-repo, add CI, pin all transitive dependencies, and document the diff from upstream so future maintainers know what is ours.

Operational Impact

Maintenance. Effectively infinite ownership with zero upstream. Every dependency CVE in the auth path becomes our patch. The 2015 release date means the code predates a decade of PHP and Symfony security hardening; expect to audit it line by line rather than trust it. Budget a named owner and a recurring review cadence, or accept that it will silently rot.

Support. No issue triage, no maintainer response, archived repo. Internal engineers will be the only source of truth. 56 stars and 0 dependents means no Stack Overflow corpus, no blog posts, no prior art to consult when something breaks — debugging is entirely first-principles against 2015-era Symfony internals.

Scaling. The bundle is thin orchestration over DI and security configuration; it is not a throughput bottleneck. Compiler-pass registration is boot-time only. Real scaling constraints live in session storage, firewall/provider configuration, and database schema — all outside this package. So scaling is neutral: it neither helps nor hurts, which is the best thing that can be said for it.

Failure modes. Ranked by severity:

• Privilege escalation across user types — misconfigured firewall or provider scoping lets a Customer authenticate into an Admin context. Highest-severity, hardest to detect in review, and the bundle's own abstraction is what makes the mistake plausible.
• Silent service override collisions — compiler passes from this bundle and another bundle competing for the same service IDs, producing load-order-dependent behavior.
• Route and form-type name collisions across user types.
• Dependency drift — a transitive update or a PHP patch release breaking auth with no upstream fix.
• Knowledge concentration — one engineer understands the wiring; their departure is an outage risk.

Ramp-up. High cost, low transferable value. Engineers must understand Symfony DI compiler passes, FOSUserBundle internals (events, controllers, form handlers), and firewall/provider semantics simultaneously before they can safely change anything. That is a multi-week curve for a pattern they could learn in a day from a native multi-guard implementation. The skills do not transfer to our other stacks, and the pool of engineers who worked with 2015-era FOSUserBundle is shrinking every year.

TPM recommendation. Do not adopt as a dependency under any scenario. Use it as a pattern reference only — the discriminated user-type registry is a good idea worth reimplementing in a few hundred owned, tested lines on whatever framework we actually run. The opportunity score reflects a real gap in the ecosystem; the artifact itself is a ten-year-old tombstone in that gap. Opportunity is not the same as fitness, and this package scores well on the first and disqualifyingly on the second.