- Can I use sylius/rbac in a Laravel application?
- No. sylius/rbac is not a Laravel package; it is a Symfony/Sylius component built on Symfony Security, Doctrine ORM, and sylius/resource-bundle abstractions. Laravel applications should use spatie/laravel-permission or a small in-house role hierarchy service instead.
- Is sylius/rbac still maintained?
- It is archived and published as a read-only subtree split of the Sylius monorepo. That means there is no independent issue tracker, CI, or release cadence, and the split no longer receives patches. Treat any dependency as frozen and pin it to an exact tag while you vendor or fork the source.
- How do I install sylius/rbac with Composer?
- For a Sylius application, require the component through the sylius/sylius metapackage or a monorepo path repository so version resolution tracks the parent release. Do not consume the split directly for new work. If you must retain an existing dependency, pin the exact tag, vendor the source, and read that tag's composer.json for the full constraints.
- What Laravel version does sylius/rbac support?
- None. sylius/rbac has no Laravel version constraints because it is not a Laravel package. Its compatibility is tied to the parent Sylius release line and its Symfony Security, Doctrine ORM, and PHP floors.
- How does sylius/rbac compare to spatie/laravel-permission?
- sylius/rbac adds Symfony-style hierarchical role semantics over Sylius Doctrine resources. spatie/laravel-permission provides flat roles and permissions that integrate with Laravel Gate and Policy. In Laravel you can emulate hierarchy through permission inheritance or a Gate::before hook, which is usually a better fit than importing Symfony Security.
- What are the requirements for sylius/rbac?
- The supplied metadata does not list exact constraints, so read the pinned tag's composer.json before deciding. Expect a PHP floor tied to the parent Sylius release, Doctrine ORM 2.x, a Symfony Security major, and assumptions about RoleHierarchyInterface and sylius/resource-bundle. Those transitive constraints will drive your support and migration timeline.
- Is sylius/rbac safe for production?
- It carries high technical risk for production because it is archived, security-adjacent, and has near-zero independent adoption. There are no security patches from this repository, and version constraints resolved against the split may diverge from the parent Sylius release. The MIT license makes forking legally clean, but you must own patching and compatibility.
- How do I migrate away from sylius/rbac?
- Pin the current tag exactly, vendor the source or create a private fork, and snapshot the existing role hierarchy into fixtures. Then move to Symfony's native role_hierarchy configuration or a maintained bundle, or to spatie/laravel-permission if the host is Laravel. Confirm the host framework and parent Sylius version first, because that may change the entire migration plan.
- Why is sylius/rbac marked READ-ONLY?
- The READ-ONLY prefix signals that the repository is a subtree split of the Sylius monorepo, published only for Composer consumption. It has no independent issue tracker, CI, or release cadence, and the archived status means the split is frozen. File fixes against the parent project or maintain your own fork instead.
- Does sylius/rbac support hierarchical roles like Symfony role_hierarchy?
- Yes, it layers hierarchical role semantics similar to Symfony's role_hierarchy onto Sylius's Doctrine-backed resource model. It assumes Symfony Security's RoleHierarchyInterface and sylius/resource-bundle abstractions. Laravel's Gate and Policy model has no natural seam for it, so use Laravel-native authorization instead.