Multi User Bundle Laravel Package

Technical Evaluation

Architecture fit — poor, and there is a framing mismatch to resolve first. Despite being presented as a "Laravel/PHP package," pdfloresjdav/multi-user-bundle is a Symfony bundle (PUGXMultiUserBundle), a re-packaging of the legacy PUGX multi-user extension for FOSUserBundle. It is built around Symfony's service container, event dispatcher, Doctrine ORM inheritance mapping, and FOSUserBundle's user manager — none of which have equivalents in a Laravel application. If our target stack is Laravel, architecture fit is effectively zero: there is no Eloquent, no Laravel auth guard integration, no Laravel migration path. If our target stack is Symfony, the fit is still poor because the bundle's core dependencies (FOSUserBundle, Symfony 2.x/3.x-era APIs, PHP 5.x/7.x idioms) are end-of-life. The only transferable asset is the design pattern — modeling multiple user types via Doctrine MappedSuperclass / single-table or joined inheritance with a DiscriminatorMap, plus per-type registration forms and routes.

Integration feasibility — not feasible as a dependency. Installation would require pinning an EOL Symfony version, an EOL FOSUserBundle, an EOL Doctrine ORM, and correspondingly old PHP. Modern Symfony (6/7) removed or BC-broke the extension points this bundle relies on (pugx_multi_user config tree, MultiUserManager, PUGXMultiUserBundle route loading, template overrides of FOSUserBundle views). Laravel has no viable shim. Realistically, integration means vendoring and rewriting — which is not integration, it is reimplementation with the repo as a reference implementation.

Technical risk — high, on every axis.

• Supply chain: 0 stars, 0 dependents, score 0. No external validation that the code works, no downstream users to surface bugs, no evidence of CI. A single-maintainer, zero-adoption bundle is an unreviewed code-execution surface in our auth path.
• Security: authentication and user provisioning are the highest-sensitivity code we own. FOSUserBundle-era code predates current password hashing guidance, and the surrounding ecosystem has known CVEs with no patch stream.
• Abandonment: Symfony's own docs direct users away from FOSUserBundle; the upstream line is unmaintained. There is no upgrade path, so we inherit a dead end on day one.
• Correctness of the core idea: Doctrine inheritance for users is a known scaling and migration hazard (schema changes across discriminator maps, joins on every auth query, awkward polymorphic FKs from related tables). Even a clean port should not copy this naively.

Key questions to resolve before any spike:

1. Is the target application Laravel or Symfony? If Laravel, this evaluation ends at "reimplement the pattern."
2. How many distinct user types do we actually need, and do they differ by behavior (different auth, different profile fields, different permissions) or only by attributes? Most "multi-user" requirements collapse to a single users table plus roles/flags.
3. Do these user types share one identity namespace (can an email be both a "customer" and a "vendor")? That answer, not the bundle, drives the schema.
4. Are we willing to own this code indefinitely, including security patches, with no upstream?
5. Is there a licensing or provenance concern with a fork of PUGX/FOSUserBundle (attribution, abandoned upstream license terms)?
6. What is the actual requirement — multiple user classes, or multiple guard providers / SSO tenants? The latter is a framework config problem, not an inheritance problem.

Recommendation: do not adopt. Treat the repository as a design reference only, and budget for a native implementation (Laravel: separate models + guards/polymorphic relations; Symfony: security firewalls + a UserProvider per type) rather than a port.

Integration Approach

Stack fit. Laravel: no fit. The bundle's assumptions (YAML/XML service definitions, Doctrine EntityManager, Symfony form types, Twig overrides of bundle templates) have no Laravel analogue, and the auth surface we would need to touch — Illuminate\Auth guards, Authenticatable, password brokers, policies — is entirely different. Symfony: fit only on legacy 2.x/3.x branches, which we should not be running. If a legacy Symfony service genuinely needs this behavior, it is a maintenance task on that service, not a greenfield integration.

Migration path. Two viable shapes, both avoiding the dependency:

• Preferred — single table, single guard. One users table with a type column (or a user_type enum) plus nullable profile fields or a profiles side table; one auth guard; authorization expressed through roles/policies. Lowest migration cost, no inheritance hazards, trivially indexable, and it survives future auth changes.
• If types are genuinely divergent — one table per type with a shared identities table holding credentials and a polymorphic profileable reference. This preserves the "multiple user classes" intent without Doctrine discriminator maps and keeps the login query a single indexed lookup.

Sequence the work as: (1) confirm the requirement is really multi-type; (2) model schema and auth guards; (3) implement registration/login flows per type, sharing a base service; (4) migrate any existing users with an explicit type backfill and a cutover window; (5) decommission FOSUserBundle/PUGX artifacts if present. If we ever do look at the bundle's code, it belongs in step 1 only, as a reference for the per-type registration form and route wiring.

Compatibility. Treat as incompatible unless proven otherwise on a pinned legacy matrix. Before any spike, verify: supported Symfony versions in composer.json, supported PHP range, whether friendsofsymfony/user-bundle is a hard requirement and at which version, whether the bundle ships tests, and whether it runs on our current PHP. A spike that cannot composer require on our runtime is a two-hour answer, not a sprint.

Sequencing and gates. Gate 1: stack confirmed and requirement confirmed as multi-type. Gate 2: composer require succeeds on a current supported runtime in a throwaway branch, with auth flow smoke-tested. Gate 3: security review of the dependency and its transitive tree. If Gate 2 fails — the expected outcome — close the evaluation and proceed with the native design as the default plan, so no delivery time is lost.

Operational Impact

Maintenance. We would own the bundle outright. There is no release cadence, no issue triage, no compatibility work for new PHP/Symfony versions, and 0 dependents means nobody else will file the bugs we will hit. Every future framework upgrade becomes our problem to solve inside a fork. Even a successful integration converts an upgrade into a re-port.

Support. There is no support channel with a meaningful response expectation. Escalation for a production auth outage would be internal only, with a codebase no one on the team authored. For an auth-path component, that is an unacceptable support posture regardless of how the code reads.

Scaling. The Doctrine inheritance pattern scales poorly in the dimensions that matter for identity: login queries fan out across discriminator joins, adding a user type means a schema migration touching the discriminator map, and polymorphic foreign keys from orders/sessions/audit tables become ambiguous. Operationally, expect index pressure on the auth lookup and painful schema evolution as user types multiply. A flat table with a type column scales monotonically and keeps the hot login path a single indexed read.

Failure modes. Most likely: dependency resolution failure at install; silent breakage on the next PHP minor via deprecated FOSUserBundle/Symfony APIs; auth bypass or privilege confusion if two user types share a credential namespace but different guards; migration deadlock when adding a discriminator; and orphaned profile rows on type change. Each is a production auth incident, and none has an upstream fix path.

Ramp-up. Deceptively high. The API surface looks familiar, which invites the assumption that a mid-level engineer can adopt it in a day. In practice the cost is in reverse-engineering abandoned Symfony 2/3 conventions and FOSUserBundle internals before writing a line of usable code. Estimate 2–4 days for a competent engineer to reach a confident go/no-go — and a native implementation of the same requirement in Laravel or modern Symfony is typically less total effort than the port, with none of the inherited risk. Plan for zero knowledge transfer from the package maintainer.

Overall. Zero adoption, zero dependents, and zero maintenance signal on an authentication component make this a clear no-adopt. Use it as a pattern reference, build the multi-type user model natively on the current stack, and keep the auth path inside the framework's supported upgrade envelope.