Rbac Laravel Package

Technical Evaluation

Architecture fit. sylius/rbac is not a Laravel package. It is a Symfony/Sylius component that layers hierarchical role semantics (à la Symfony's role_hierarchy) onto Sylius's Doctrine-backed resource model. It assumes Symfony Security's RoleHierarchyInterface, Doctrine ORM entities, and sylius/resource-bundle abstractions. Laravel's authorization model — Gate, Policy, and a flat roles/permissions schema via spatie/laravel-permission — has no natural seam for this component. Adopting it in a Laravel application would mean importing Symfony Security and Doctrine into a framework that deliberately avoids both, which is a net-negative architectural trade. Fit for a Symfony/Sylius storefront is reasonable; fit for anything else is poor.

Integration feasibility. Low for Laravel, moderate for Sylius. The [READ-ONLY] prefix is the critical signal: this repository is a subtree split of the Sylius/Sylius monorepo, published only for Composer consumption. It has no independent issue tracker, no independent CI, and no independent release cadence. Combined with Archived: yes, this means the split is frozen and no longer receives patches. Any dependency on it must be pinned to a specific tag and vendored or forked; you cannot file a bug against this repository and expect a fix.

Technical risk. High. Three compounding factors: (1) archived status means no security patches — RBAC is a security-adjacent component, so unpatched CVEs in the transitive Symfony/Doctrine tree become your liability; (2) 12 stars and a 0.21 score indicate near-zero independent adoption, so there is no community to lean on for workarounds; (3) the split-vs-monorepo confusion means version constraints resolved against this package may silently diverge from the parent Sylius release line. The MIT license is the one unambiguously favorable attribute — forking is legally clean.

Key questions. Is the target application actually Laravel, or is this evaluation mis-scoped and the real host is a Symfony/Sylius system? Which Sylius major version is in use, and does that version still ship this component or has it been superseded by Symfony's native security.yaml role hierarchy? What is the full transitive dependency set (Doctrine ORM major, Symfony Security major, PHP floor)? Is there existing production code depending on this component, or is this greenfield? Who owns the fork if we adopt it?

Integration Approach

Stack fit. Reject for Laravel. The honest recommendation is spatie/laravel-permission (hierarchical roles emulated via permission inheritance and a Gate::before hook) or a thin in-house role-hierarchy service if the hierarchy is genuinely deep. For an existing Symfony/Sylius stack, do not consume the split — require the component through the sylius/sylius metapackage or the monorepo path repository so version resolution tracks the parent release.

Migration path. If this component is already in composer.json, treat it as technical debt with a defined exit. Steps: pin the current tag exactly; vendor the source into a packages/ directory or a private fork; snapshot the current role hierarchy into fixtures; then migrate to Symfony's native role_hierarchy configuration (which covers the overwhelming majority of hierarchical RBAC use cases) or to a maintained bundle. If this is a greenfield decision, do not adopt — there is no path from an archived split to a supported dependency.

Compatibility. Constraints are unknown from the supplied metadata and must be read directly from the pinned tag's composer.json before any decision. Expect a PHP floor tied to the parent Sylius release, Doctrine ORM 2.x, and a Symfony Security major that will age out of support on a predictable schedule. That PHP floor is the practical forcing function for the migration timeline — once the host application upgrades PHP, this package will block it.

Sequencing. (1) Confirm the host framework and parent Sylius version — this may invalidate the entire evaluation. (2) If retained, pin and vendor within one sprint. (3) Run a spike replacing the component with native Symfony role_hierarchy against a copy of the production role table; measure the diff in effective permissions per user. (4) Migrate behind a feature flag with dual-read of permissions and a single-write cutover. (5) Decommission the dependency. Do not sequence anything else before step (1).

Operational Impact

Maintenance. Entirely on the adopting team. Archived means upstream has stopped; the [READ-ONLY] split means even a submitted patch has no landing zone. Budget ongoing effort for dependency bumps, security triage of the transitive tree, and a named owner for the fork. This is a permanent, if small, tax.

Support. No maintainer, no SLA, no issue tracker for this artifact. Community support exists only through Sylius channels and only insofar as the parent monorepo is still discussed. Escalation for a production authorization bug is: read the source yourself.

Scaling. Role hierarchies are typically resolved in memory per request; the cost is in loading the hierarchy and any Doctrine role/permission queries behind it. At scale this needs a request-scoped cache plus a cache-busting strategy on role edits. The component's Doctrine-backed model will produce N+1 queries on user-to-role-to-permission traversals unless explicitly eager-loaded — a common and expensive surprise.

Failure modes. Recursive or cyclic role definitions causing infinite hierarchy resolution; stale permission caches after a role edit, which manifests as users retaining revoked access — a compliance-visible failure; orphaned roles after user deletion; and silent drift when the pinned split diverges from the parent Sylius version's behavior. The cache-staleness mode is the one to instrument first, since it fails open rather than closed.

Ramp-up. For a Symfony developer, roughly a day to read the component and understand the hierarchy model. For a Laravel-only team, substantially longer — Doctrine entity mapping, Symfony Security's voter and role-hierarchy internals, and the Sylius resource abstraction are all unfamiliar, and none of that knowledge transfers back to the Laravel codebase. This ramp-up cost is real and should be counted against the alternative of adopting a native Laravel authorization package, which requires near-zero ramp-up.