Permissions Bundle Laravel Package

Product Decisions This Supports

• Authorization architecture (RBAC → granular permissions): The package's core idea — collapsing many role checks into a single voter driven by a permissions directive — is a legitimate design pattern to evaluate when moving from coarse roles (ROLE_ADMIN) to named, per-action permissions (e.g. invoice.refund). This is a roadmap-level decision worth making deliberately rather than accreting $user->can() calls ad hoc.
• Build vs. buy for the authorization layer: The honest answer here is "build" — the pattern is ~100 lines of glue on top of a framework's native authorization primitives. The package's value is as a reference implementation for the single-voter approach, not as a dependency.
• Centralized permission registry: Supports the decision to maintain one canonical list of permission strings (seeded, versioned, testable) rather than scattering string literals across controllers, policies, and Blade templates — which directly enables an admin permission-matrix UI later.
• Auditability of access control: Annotation/attribute-driven checks make permission requirements visible at the call site and greppable, which supports compliance and code-review workflows in regulated or multi-tenant products.
• Explicitly not supported: Any decision requiring an actively maintained dependency. With 18 stars, 0 dependents, and a last release of December 2017, this cannot underwrite a security-sensitive roadmap item.

When to Consider This Package

Consider it only under narrow conditions:

• You are on a legacy Symfony 3.x application (this is a Symfony bundle, not a Laravel package — it wires into Symfony's security.voters and @IsGranted-style annotation system, which Laravel has no equivalent hook for), and you need a stopgap to consolidate sprawling role checks.
• You need a short, time-boxed spike to compare single-voter vs. multi-voter authorization ergonomics before committing to a design.
• You want to read the source as a pattern reference — this is the highest-value use, and it costs you nothing in dependency risk.

Look elsewhere when:

• You are on Laravel. This is the decisive disqualifier. Laravel's Gate/Policy system plus spatie/laravel-permission or josephsilber/bouncer covers the same ground natively, with active maintenance and PHP 8+ support. Adopting a Symfony bundle here means fighting the framework.
• You need maintenance guarantees. No release since 2017 means no PHP 7.4/8.x compatibility work, no security patching, and no Symfony 5/6 support. Zero dependents means zero community pressure to fix anything.
• Authorization is a security boundary (payments, PII, multi-tenant isolation). An unmaintained voter is an unacceptable attack surface.
• You are on modern Symfony. Symfony's native IsGranted attribute + voters, or the maintained symfony/security-bundle patterns, supersede this entirely.

How to Pitch It (Stakeholders)

To executives: We evaluated orbitale/permissions-bundle and recommend against adoption. Three disqualifiers: it is a Symfony bundle rather than a Laravel package, so it does not integrate with our framework; its last release was December 2017, meaning no security patches or PHP 8 support; and it has zero downstream dependents, so no one is maintaining it. The underlying idea is sound and cheap to replicate — we can implement the same single-permission-check pattern using Laravel's built-in Gate system in roughly a day of engineering, with full support and no third-party risk.

To engineering: Don't install this. It's a Symfony security voter keyed off a permissions annotation; Laravel's authorization pipeline has no seam for it. What we should take from it is the pattern: one Gate::before/dynamic-gate registration that resolves a permission string against a single source of truth, rather than N bespoke policies. Concretely — define permissions as an enum or seeded table, register them via Gate::define in a service provider loop, and enforce with $this->authorize() in controllers and @can in views. That gives us the same ergonomics, the same auditability, and no abandoned dependency. If anyone wants the 2017 source as a design reference, read it; don't require it.