Rbac Bundle Laravel Package

Product Decisions This Supports

• Authorization architecture: build vs. buy. RBAC is a solved problem in the abstract but a high-blast-radius one in practice. This package is a candidate to buy rather than build when your permission model is conventional (roles → permissions → resources) and you do not need ABAC/policy-expression evaluation.
• Roadmap sequencing for RBAC-dependent features. Anything gated behind roles — admin consoles, tenant isolation, approval workflows, feature entitlements — inherits this package's release cadence and maintainer responsiveness. A patch-only release history means you should not schedule roadmap items that depend on capabilities this package has not yet shipped.
• Platform upgrade planning (PHP major-version readiness). v1.1.3 removes a fatal error on PHP 8.5, which means the package is tracking forward PHP compatibility. That is a positive input to a "when do we move to PHP 8.5" decision, and it removes the package as a blocker in that upgrade path.
• Security and compliance posture. Role-based access control is usually in scope for SOC 2 / ISO 27001 access-control evidence. A third-party dependency in this position needs a documented owner, an upgrade SLA, and a fallback plan — this release is a trigger to assign that owner rather than a reason to adopt.
• Framework-fit decision (Laravel vs. Symfony). The artifact is named rbac-bundle and ships a compiler pass and PHP attributes — hallmarks of a Symfony bundle. Before this enters a Laravel roadmap, confirm it is genuinely Laravel-native (service provider, config publishing, Gate/Policy integration) and not a Symfony package being evaluated by proximity. This is a gating decision, not a detail.
• Dependency hygiene / technical-debt triage. The fix removes an #[Attribute] that was applied to an interface — invalid in all PHP versions, fatal only on 8.5. That is a signal about the maturity of the codebase's static analysis and CI matrix, and belongs in a build-vs-buy scorecard.

When to Consider This Package

Consider it when:

• Your permission model is static and role-centric, and you need attribute- or annotation-driven declarations on controllers/services rather than runtime policy logic.
• You need a lightweight, low-ceremony authorization layer and are prepared to own the risk of a small-maintainer dependency (single named maintainer, pre-2.0 versioning, low release volume).
• You are on, or planning, PHP 8.5 and want a dependency that has already resolved the 8.5 fatal-error class of issue.
• You want the RBAC mechanism co-located with your code via attributes rather than configured in a database or external policy service.

Look elsewhere when:

• You need fine-grained or dynamic authorization (ABAC, ownership/relationship checks, policy expressions, per-tenant role hierarchies). Reach for Laravel's native Gate/Policy system or a mature policy engine instead.
• You require vendor-backed support, an SLA, or a security disclosure program — a patch release from a single maintainer does not provide these.
• Multi-tenancy, audit logging, or role-management UI are in scope; this package is an enforcement primitive, not an administration product.
• You cannot verify Laravel-native integration. If it turns out to be Symfony-shaped, stop and re-evaluate.
• You are pre-2.0 and cannot absorb minor-version API churn; semantic versioning below 1.x/2.x gives you limited compatibility guarantees.

How to Pitch It (Stakeholders)

For executives: We are evaluating a small open-source library for role-based access control — the mechanism that decides who can see and do what in the product. This release is a maintenance patch: it fixes a crash that would have occurred on the next PHP runtime version and cleans up a deprecation warning. No new features, no breaking changes. The strategic point is not the patch; it is that this is a security-adjacent dependency maintained by a very small team, and adopting it means accepting maintainer risk in exchange for avoiding a build. My recommendation is to treat it as viable for a conventional role model, contingent on confirming it is genuinely Laravel-native and on us assigning an internal owner with an upgrade SLA.

For engineering: v1.1.3 is a forward-compatibility fix — an invalid #[Attribute] on RBACAttributeInterface was removed because PHP 8.5 makes that fatal, plus a compiler-pass deprecation message was dropped. Two asks before we commit: (1) confirm Laravel integration surface — service provider, config publish, Gate/Policy binding — since the packaging looks Symfony-derived; (2) add this dependency to the upgrade matrix and pin it, because we are depending on a single maintainer for an authorization primitive. If we adopt, wrap it behind our own authorization interface so it stays replaceable.

Net PM position: adopt conditionally — pilot on one non-critical surface, verify framework fit and PHP 8.5 behavior in CI, and keep Laravel's native Gate/Policy as the documented fallback.