Rbac Bundle Laravel Package

Getting Started

• This is a Symfony bundle, not a Laravel package. There is no service provider, no config/rbac.php to publish, no facade, no Eloquent integration. It hooks into the Symfony DI container via a compiler pass. If you are working in a Laravel app, the only realistic use is as a standalone library in a non-Laravel sub-project — don't plan on dropping it into composer require of an existing Laravel codebase and expecting php artisan vendor:publish to do anything useful.
• Look first at the attribute classes, specifically anything implementing RBACAttributeInterface. That interface is the extension point: custom attributes implement it, and the bundle's voter/checker layer reads them off controllers, actions, or services. Read the interface, then read the built-in implementations — that is the whole mental model of the package.
• First use case: gate a controller action with a role/permission attribute rather than a hand-rolled Gate-style check. Then move the role→permission mapping into the bundle's config so authorisation stops being scattered across conditionals.
• Pin ^1.1.3 if you are on PHP 8.5. 1.1.2 is a fatal error on that runtime (see Gotchas), not a warning.

Implementation Patterns

• Attribute-per-action, single check per method. Keep attributes declarative and thin; put the decision logic in the role/permission hierarchy config, not in custom attribute constructors. This mirrors how you'd use Laravel policies — the attribute is the entry point, not the implementation.
• Treat RBACAttributeInterface as your custom-attribute contract. For in-house rules (tenant scoping, resource ownership), implement the interface and register the attribute the same way the built-ins are registered. Don't subclass built-in attributes to "extend" them — the bundle's metadata reader is looking at the attribute class, not your subclass's intent.
• Compile-time, not runtime. The bundle resolves attributes through the container/compiler pass, so changes to attribute config surface as container compile errors or stale behaviour. Wire it into your deploy step: bump version → clear cache → boot the kernel in CI before shipping.
• Version-bump discipline in CI. Add 8.5 to the PHP matrix in the same PR that bumps this dependency. The failure mode in 1.1.2 is a fatal error at class load, so it will not be caught by a unit test that never instantiates the interface's implementors — you need a kernel boot or at minimum an autoload-then-reflect smoke test.
• Keep the compiler pass observable. 1.1.3 stops emitting a deprecation message from the compiler pass. If your own code was branching on that deprecation appearing in logs, that signal is gone; assert on the pass's actual output instead of on log noise.

Gotchas and Tips

• #[Attribute] cannot be applied to an interface — that is the entire 1.1.3 fix. 1.1.2 annotated RBACAttributeInterface with #[Attribute], which PHP 8.5 rejects as a fatal error. If you forked or vendored the bundle, apply the same removal to your copy; the annotation was always invalid, 8.5 just stopped tolerating it.
• If you write custom attributes, remember the marker goes on the class, not the interface. This is the single easiest way to reintroduce the bug above in your own code.
• Don't expect Laravel-style debugging affordances. No dd()-friendly facade, no container binding you can app()->make(). Debugging means reading the Symfony container compile output and var/cache, so budget time for the first integration.
• Clear cache after every attribute change. Cached container metadata is the usual explanation for "I added the attribute and nothing happened."
• Deprecation-message removal is cosmetic, not behavioural. Nothing in your authorisation logic changes between 1.1.2 and 1.1.3 except PHP 8.5 survivability — don't schedule a retest of access rules purely for this upgrade.
• Upgrade is safe and non-breaking. No API changes, no removed config keys, no new required arguments. Bump the constraint, clear cache, run your kernel-boot test suite, ship.