Nova Acl Laravel Package

Product Decisions This Supports

• Build vs. buy for admin-side RBAC. If we run Laravel Nova, "who can see/edit what in the admin panel" is a recurring roadmap item. This package is a data point in that decision: it shows the minimal shape of a Nova ACL tool (roles, permissions, pivots, Nova resources) and lets us estimate the real cost of building our own — which is small.
• Confirms the ecosystem is already consolidated. Two stars, zero dependents, archived. That is not a gap in the market; it is evidence that Nova teams solve this with spatie/laravel-permission plus a thin Nova UI, or with Nova's own tooling. It argues against allocating roadmap capacity to a competing internal package.
• Vendor risk register input. Archived + last release Feb 2023 means no CVE response, no Laravel/Nova major-version tracking, and no maintainer to escalate to. Useful as a concrete example when we justify a dependency policy (maintenance status, release recency, dependent count thresholds).
• Compatibility scoping. Reading its composer.json constraints tells us which Nova/Laravel generation it targeted, which is a cheap way to bound how much of our admin surface would be affected if we standardized on one ACL approach.
• Prior-art review / migration due diligence. If any legacy service already vendors it, this assessment starts the replacement ticket rather than waiting for a security finding.

When to Consider This Package

Consider only in these narrow cases:

• A timeboxed (≤1 day) internal spike or demo where we need a Nova ACL screen and will throw the code away.
• As a fork-and-own starting point: the codebase is small enough to vendor, audit, and maintain ourselves — but we should price that as "we now own a package," not "we saved a dependency."
• As a reference read during design review of our own ACL schema, to sanity-check model/pivot structure.

Look elsewhere when:

• Anything production, or anything touching customer data, SSO, or an audit/compliance requirement. Archived software has no patch path; a single unpatched authorization bug is a severity-1 event, not a backlog item.
• We are on current Nova or Laravel majors. Compatibility is unverified and the maintainer is gone — assume it breaks and that we will be the ones fixing it.
• We need multi-tenancy, team-scoped roles, guard-aware permissions, policy generation, or audit logging. spatie/laravel-permission is the de facto standard, actively maintained, and has multiple maintained Nova front-ends.
• We want support, SLAs, or a vendor to point at in a security questionnaire.
• We do not hold a Nova license — the addressable audience for this package is inherently small, which partly explains the adoption numbers.

How to Pitch It (Stakeholders)

To executives: Do not adopt. The install cost is near zero and the ownership cost is not — archived code with two stars and no maintainers means every future Laravel or Nova upgrade becomes our problem, and every future security review becomes an exception request. This is not a cost saving; it is an unquantified liability. The access-control capability we actually want is available from a maintained open-source library at the same price, so there is no trade-off to debate.

To engineering: Treat this as a reference implementation, not a dependency. Spend at most a day spiking it behind a feature flag, extract whatever schema ideas are useful, and then build the Nova layer on spatie/laravel-permission — where permissions are already guard-aware, tested, and maintained. If we do want to keep this code, we adopt it explicitly as a fork we own, with a named maintainer and a test suite, and we record that decision in the dependency register. What we should not do is add it to composer.json and let it quietly become load-bearing.

Recommendation: No-go as a dependency; go as a one-day reference spike. Revisit only if we deliberately choose to own a forked ACL layer, and even then the fork should be built on the maintained permission library rather than on this code.