Rbac Bundle Laravel Package

Technical Evaluation

Architecture fit. Effectively zero for a Laravel target. sylius/rbac-bundle is a Symfony2 bundle — it registers via a Bundle subclass, a DependencyInjection extension, and YAML service wiring. Laravel has no bundle registry; there is no ServiceProvider, facade, config publish, migration, or Eloquent model to hook into. The repository is [READ-ONLY], pinned to Symfony2 (EOL since 2018) and pre-PHP 7-era constraints. The underlying sylius/rbac component (hierarchical roles, permission inheritance, voter-style checks) is the only conceptually transferable asset; the bundle itself is glue we cannot install.

Integration feasibility. Low-to-moderate, and only through extraction, not adoption. Three viable paths exist: (1) spike sylius/rbac standalone to see whether its role-hierarchy resolver is framework-agnostic or bound to symfony/security-core contracts; (2) vendor the hierarchy-resolution logic into our own domain layer as a reference implementation; (3) skip it and build the equivalent on spatie/laravel-permission plus a thin inheritance service. Path 1 is the only one that reuses real code, and it is gated on that component not dragging Symfony security interfaces into a Laravel runtime.

Technical risk. High. Abandoned and archived means no security patching in the authorization layer, which is the worst place to carry unpatched code. Add Symfony2 dependency-graph conflicts, probable PHP-version mismatch, no maintainer to escalate to, and license/provenance diligence before vendoring. The feature itself is small — graph traversal over parent_id with cycle detection and cached permission expansion — so build-versus-borrow favors build once maintenance exposure is priced in. Adoption signal is negligible: 11 stars, 0 dependents, score 0.3275.

Key questions.

• Does sylius/rbac bind to Symfony security interfaces, or can its role resolver run standalone on our PHP runtime?
• Is our authorization model genuinely hierarchical (inherited roles with cycle risk), or is flat roles-plus-permissions sufficient?
• Is there a maintained successor — Sylius absorbed RBAC concepts into core admin, and spatie/laravel-permission is the live Laravel-native option?
• What does the vendoring license/provenance review require before any code is copied?
• Who owns the decision to keep a legacy Symfony2 reference in the architectural record versus removing it?

Integration Approach

Stack fit. Mismatched by construction. Our stack is Laravel/PHP 8+, and every integration seam — service registration, config, migrations, model layer, authorization checks — has to be authored by us. There is no Laravel version to compatibility-test against because none exists.

Migration path. Recommended: do not integrate. Treat the repo as a specification for hierarchical role resolution and implement the pattern (self-referencing role table, role-permission pivot, upward traversal, cached map) in 200–400 lines behind our existing Gate/Policy layer. If hierarchy is a genuine requirement, adopt spatie/laravel-permission for roles/permissions storage and caching, and add inheritance as an explicit domain service — cycle-detected, cache-invalidated on role/permission writes. The only defensible reuse route is a timeboxed spike that vendors sylius/rbac standalone, proves it runs without Symfony security contracts, and adapts it to Laravel's authorization pipeline with a documented fallback.

Compatibility. Assume incompatible until proven. Symfony2 bundle conventions, DI compiler passes, Doctrine ORM expectations, event-dispatcher assumptions, and old PHP constraints are all likely blockers. Doctrine mappings are the most portable artifact if we were unusual enough to run Doctrine in a Laravel app; otherwise rewrite as Eloquent migrations.

Sequencing. (1) Requirements pass — confirm whether inheritance is real or assumed; capture the intended hierarchy (ROLE_ADMIN > ROLE_MANAGER > ROLE_USER) and permission granularity (user.create, user.delete). (2) Two-to-three-day spike: test sylius/rbac standalone against current PHP and decide if its resolver is separable. (3) Side-by-side comparison against spatie/laravel-permission + custom hierarchy on effort, security posture, and maintenance. (4) Decide; default to the maintained Laravel-native path. (5) Only if the spike is clean and hierarchy complexity truly justifies it, vendor behind an interface with a kill-switch and a seeder/console command that idempotently loads the role tree.

Operational Impact

Maintenance. Unacceptable as a runtime dependency. Archived, read-only, zero dependents means no upstream fixes, no CVE response, and no path to PHP or framework upgrades. If we vendor any part of it, that code becomes ours to own, patch, and test — and that estimate must appear in the plan, not get discovered later.

Support. None. No maintainer, no issue triage, no security advisories, no vendor escalation. Internal escalation terminates at the TPM. That is a governance problem for anything touching authorization on a customer-facing surface.

Scaling. The workload itself is cheap: role-tree resolution and permission expansion are small graph operations and should be cached as a flattened role-to-permission map, invalidated on role/permission change. The real scaling risk is organizational — an unmaintained authorization component in a security-critical path compounds risk as the codebase, team, and compliance surface grow.

Failure modes. Permission resolution recomputed per request without caching; a silent cycle in the role hierarchy causing infinite recursion or hard failure at login; an unpatchable transitive dependency vulnerability; an upgrade blocker at the next PHP/framework bump; and key-person risk once the engineer who understood the vendored logic leaves. Each of these is a realistic incident for a dependency we did not write and cannot patch.

Ramp-up. Steep and low-value on the bundle path — engineers must learn Symfony2 DI and bundle conventions to read code we cannot reuse, then learn our adapter on top. Near-zero on the alternative: spatie/laravel-permission is Laravel-native, widely adopted, and likely already familiar. Net: the learning cost inverts the usual build-versus-buy math toward build.

Recommendation. Do not adopt. Score 0.3275, opportunity 2.37, archived status, and zero dependents all align with the technical picture: this is a design reference, not a dependency. Budget a short, timeboxed spike to confirm framework coupling and extract the hierarchy requirements, then implement on a maintained Laravel-native foundation with an explicit inheritance layer only if requirements demand it. Flag any existing usage for replacement and add it to the legacy-dependency migration list.