Acl Bundle Laravel Package

Product Decisions This Supports

• Build-vs-buy for authorization, closed fast. The package's profile (0 stars, 0 dependents, Symfony-only) is a decisive negative signal that lets you retire the "can we just pull in an ACL bundle?" line item and redirect the effort into a native build.
• Framework standardization. It forces the question "do we standardize on Laravel-native authorization (Gates/Policies + spatie/laravel-permission) or chase cross-framework, Symfony-derived ACL tooling?" — and the answer here is to standardize on Laravel, treating any portability ambition as a separate, future decision.
• Granularity scoping. Frame whether the roadmap actually needs per-object, per-record ACL entries or whether coarse roles plus policies cover 80% of it. Most products over-spec an ACL requirement they don't have.
• Enterprise/compliance readiness. Customer-managed roles, tenant isolation, access-change audit trails, and periodic access reviews are roadmap prerequisites, not implementation details. An ACL layer is a decision point — but this specific package is not the layer.
• Migration/portability planning. If the product may ever run Symfony services or share auth logic across frameworks, this flags the real cost of that ambition and lets you defer it deliberately rather than accidentally.
• Risk posture. A zero-traction dependency transfers all support, patching, and CVE-response burden to us. That is a product risk decision, not just an engineering one.

When to Consider This Package

Consider only if all of the following hold:

• The codebase is genuinely Symfony, not Laravel. A Symfony bundle cannot be dropped into Laravel; only the underlying symfony/security-acl component could be Composer-installed, and bridging it into Laravel's Auth/Gate stack is bespoke work with no community precedent.
• You need fine-grained, per-object ACL entries (record-level grants), not just roles and permissions — Laravel policies already cover most of that.
• You are prepared to vendor or fork it: no stars, no dependents, no visible release cadence, no security disclosure process. You own maintenance, patching, and upgrades indefinitely.
• You accept that Symfony's legacy ACL component was deprecated in 3.4 and removed in 4.0, so this is a short-term bridge, not a foundation.

Look elsewhere (strongly recommended) if:

• You are on Laravel → native Gates & Policies plus spatie/laravel-permission for role/permission storage, with tenancy support added as needed.
• You need policy-as-code or centralized authorization across services → evaluate OPA/Rego, AWS Cedar, Casbin, or SpiceDB/Authzed.
• You need supplier assurance — maintenance guarantees, CVE response, license clarity, or a signed security questionnaire. A 0-star, zero-dependent package cannot support any of these.
• Timeline is short: integration cost for a niche bundle will exceed building on native primitives.
• Onboarding matters: the Symfony ACL model (object identities, security identities, permission masks, ACE ordering) is unfamiliar to most Laravel engineers and has little transferable value.

How to Pitch It (Stakeholders)

Executive summary: We evaluated short-edition/acl-bundle for our permissions and authorization needs and recommend not adopting it. It is a Symfony bundle — incompatible with our Laravel stack — with no community traction (0 stars, 0 dependents) and no evident maintenance or security process. Adopting it would transfer all support risk to us while solving only part of the problem: we'd end up maintaining a fork of a component Symfony itself retired, alongside our existing Laravel authorization, leaving two systems with no single source of truth.

Recommendation: standardize on Laravel's native Gates and Policies, using spatie/laravel-permission for role and permission storage, and revisit a dedicated policy engine (OPA or SpiceDB) only if cross-service or high-scale object-level authorization becomes a hard requirement. If per-object ACL semantics are genuinely needed later, port the data model — not the code — into Eloquent behind a single gate, so it stays replaceable.

Impact: no licensing cost; materially lower integration and long-term maintenance risk; roughly a 1–2 sprint foundation for roles and permissions that we own, can extend for tenant isolation and access auditing, and can defend in a security review.

Ask: approval to close this evaluation and proceed with the native approach.