Laravel Policies Laravel Package

Product Decisions This Supports

• Authorization architecture standardization. This package addresses a narrow but real decision: whether model→policy mapping lives in Laravel's naming convention (App\Models\User → App\Policies\UserPolicy) or in an explicit registry. If your codebase has non-conventional policy names, policies outside app/Policies, or domain modules that own their own authorization, an explicit registration layer is a legitimate pattern to evaluate.
• Build vs. buy (verdict: build). The functionality is a thin wrapper around Gate::policy() and Laravel's policy resolution — on the order of tens of lines. The decision this package informs is not "should we adopt this dependency" but "should we write a small internal policy registry and copy this approach." Recommend the latter.
• Brownfield authorization audits. Useful as a reference implementation when scoping a refactor of a legacy Laravel 6/7/8 app where policies were registered ad hoc across multiple service providers. Read the source, extract the pattern, own the code.
• Roadmap / dependency-risk input. With 2 stars, 0 dependents, and no release since 2020-12-01, this is a signal input to a don't depend on this decision rather than a capability decision. Treat it as evidence for a "minimal third-party surface area in auth code" roadmap principle.
• Not a supported input for: multi-tenant authorization, role/permission modeling, or ABAC-style rules. Those are separate decisions (evaluate spatie/laravel-permission, Laravel's native Gate abilities, or a policy-plus-scope approach) and this package does none of that work.

When to Consider This Package

Consider (as reference only, not as a dependency):

• You are on Laravel 6/7/8 and have a genuine need for explicit, non-conventional policy registration that Gate::guessPolicyNamesUsing() doesn't cleanly cover.
• You want a worked example of a policy registry before writing your own ~50-line version.
• You are doing a one-off migration and need to read how someone else structured the provider/registry split.

Look elsewhere (the default case):

• You are on Laravel 8+. Native policy auto-discovery plus Gate::policy() and Gate::guessPolicyNamesUsing() cover the overwhelming majority of registration needs with zero dependencies.
• Maintenance risk is unacceptable. No release since December 2020 means no Laravel 9/10/11 verification, no PHP 8.1+ guarantees, no security response path, and effectively no community to catch regressions. 0 dependents and 2 stars also means near-zero field testing — you would be the primary user.
• You need more than registration. Roles, permissions, teams, tenant scoping, or audit trails are out of scope; pick a purpose-built package or model it on Gate abilities.
• You need a supply-chain review to pass. An unmaintained, single-author, low-adoption package in the authorization path — the code that decides who can do what — is a poor risk trade for a few dozen lines of saved effort.

How to Pitch It (Stakeholders)

To executives (one line): "We evaluated a small open-source Laravel package for organizing authorization policies and recommend not adopting it — it hasn't been updated since 2020, has essentially no users, and does work we can own internally in under a day of engineering at lower long-term risk."

To engineering (the substance):

• The problem it solves is real — explicit model→policy mapping beats relying on naming conventions in modular or brownfield codebases.
• The package is not a viable dependency: last release 2020-12-01, 2 GitHub stars, 0 dependents, no maintainer activity, unverified against current Laravel/PHP versions. Placing it in the authorization path creates an unpatched single point of failure for access control.
• The pattern is cheap to replicate: a service provider that iterates a config map and calls Gate::policy($model, $policy), optionally with a Gate::guessPolicyNamesUsing() fallback. This gives us the same clarity with full test coverage and version control.
• Recommendation: read it, don't require it. Spend the half-day to implement internally; revisit only if we end up needing policy grouping or discovery semantics we can't express natively.
• Follow-up decision to log: adopt a standing rule that authorization-path dependencies require active maintenance (a release within ~12 months) and at least non-trivial adoption.