Rer User Bundle Laravel Package

Product Decisions This Supports

• Build vs. buy for identity and role management. If we are already inside the Performer / PerformerSpa vendor ecosystem, this bundle is the cheapest source of consistent user, role, and authorization semantics across our reporting modules — it lets us defer one to two quarters of in-house identity plumbing. If we are not, it is a schema reference, not a dependency.
• Roadmap sequencing for RBAC and SSO. The bundle encodes the vendor's baseline model (user, role, authorization scope). Reviewing it early tells us whether next quarter's investment should go to federation (OIDC/SAML/SCIM, MFA) or to aligning on vendor semantics and deferring that work.
• Framework and platform strategy — the decisive decision. This is a Symfony bundle, not a Laravel package: Bundle suffix, Performer\… namespace, Doctrine ORM mappings, tagged services, no service provider, no vendor:publish config. For a Laravel product that converts the question from "should we composer require?" into "is the domain model worth porting?" — a design-reference decision, not a dependency decision.
• Prioritization signal, read carefully. An opportunity score of 8.68 against 3 stars and 0 dependents reads as capability gap in a niche, not market-ready component. That combination justifies a time-boxed evaluation spike, never a roadmap line item.
• TCO and commercial model. A vendor-published, single-maintainer bundle with no dependents implies a support contract or renewal. It must be costed as a licensed integration plus permanent internal ownership — not free OSS. Absent a commercial relationship, the adopter inherits security patching and version upgrades permanently.
• Use-case fit. Best matched to enterprise CPM / consolidation / regulatory-reporting applications with multi-entity, multi-role organizational structures and auditable authorization requirements.
• A low-cost artifact even if rejected. The user/role/scope decomposition is reusable as an input to our own schema. We can walk away from the package and still bank the domain design.

When to Consider This Package

Evaluate when:

• We are an existing Performer customer or implementation partner and need user/role alignment with the rest of the suite.
• The target application is Symfony-based, or we are willing to run a Symfony sidecar/service behind an HTTP contract rather than share a bundle.
• A vendor support contract exists covering security patching and Symfony/PHP version compatibility for our stack.
• The "RER" domain semantics actually match our business domain — the acronym is undocumented in the repo, and a mismatch is a hard stop that invalidates the entire evaluation.
• We have engineering capacity to read vendor conventions and place an anti-corruption layer in front of it.

Look elsewhere when:

• We are greenfield on Laravel. The stack-native answers — Laravel Breeze/Fortify/Jetstream, Sanctum or Passport, spatie/laravel-permission — are better supported, better documented, and free of cross-framework translation risk.
• We need modern identity: OIDC, SAML, SCIM provisioning, MFA. This bundle is unlikely to deliver it, and identity is the wrong place to accept an unmaintained component.
• We require published release cadence, tests, a changelog, a security disclosure policy, or issue triage. With zero dependents there is no community backstop — effectively zero public operational evidence.
• The vendor relationship does not exist or vendor responsiveness is unknown. A 3-star, single-maintainer artifact on the authentication path is a bus-factor risk we should not underwrite.

Due-diligence gate before any commitment: license terms and fork/redistribution rights; last commit and last tagged release; PHP/Symfony/Doctrine constraint matrix; test coverage and CI; security disclosure process; composer audit on the transitive tree; whether it is a thin shim over another internal package; and a written definition of "RER."

How to Pitch It (Stakeholders)

To executives: Our enterprise reporting vendor publishes an off-the-shelf user and role management component that could remove roughly one to two quarters of identity plumbing from the roadmap — but only if we are already in that vendor's ecosystem and only as a domain reference, because it targets Symfony while our product is Laravel. The upside is speed and semantic consistency with the rest of the suite. The risk is concentration: negligible public adoption (3 stars, zero dependents) means no community maintenance, and a user bundle sits directly on the authentication and PII hot path. We de-risk by requiring a vendor support commitment and by isolating anything we take behind our own interface so it can be replaced without touching product code. Recommendation: fund a two-week evaluation spike, not a roadmap line item, and make any adoption conditional on the vendor's support terms and on the "RER" semantics matching ours. The default outcome is reject, and that is an acceptable result — we still keep the domain model as a design input.

To engineering: Treat this as a vendor artifact to be read, not a dependency to be installed. It is a Symfony bundle — bundle class, Doctrine mappings, DI extension, no Laravel service provider — so nothing boots in our app; the realistic path is vendoring and re-implementing against Eloquent and Laravel's Auth/Gate stack, or running it as an isolated service behind an HTTP boundary. Assume zero upstream maintenance: pin versions, run composer audit, own the upgrade path, and plan for a fork with a named owner. Confirm license, PHP/Symfony constraints, and test coverage before writing code. The highest-severity failure mode is silent authentication/authorization divergence when Symfony security voters are incompletely mapped to Laravel policies — that surfaces as privilege escalation or lockout and is typically caught only at audit. Ambiguity in the package's core concept is a stop signal, not a detail to resolve later.