Nova Permissions Laravel Package

Technical Evaluation

Architecture fit

• Unchanged. Nova authorization remains Laravel-native: Policies and Gates surfaced through canViewAny, canUpdate, canSee, etc. This package is an admin surface (Nova resources/tooling) over role and permission data, not an authorization engine. Enforcement still lives in your policies.
• The separation it encodes is still the right one: permissions in code (versioned, PR-reviewed, deployed atomically), roles in DB (runtime, ops-owned, changeable without a deploy). That reduces permission drift and makes least-privilege auditable.
• Fits cleanly only if Nova is already your admin layer. v3.1.0 adding Nova 5 support reinforces how Nova-coupled it is by design; there is no reuse outside Nova.
• Still presumed to be a UI/glue layer over spatie/laravel-permission. This release does not answer that question — no PHP dependency changes appear in the changelog, so the underlying engine's identity and constraint remain unconfirmed.

Integration feasibility

• Low mechanical effort, unchanged: composer install, publish config/migrations, migrate, seed the permission catalogue, register the tool. Hours-to-days for a pilot.
• The real cost is modelling: enumerating permissions per Nova resource/action and rewriting every policy to consult them. Budget for that, not the install.
• One prior blocker is now cleared: Nova 5 is supported as of v3.1.0, so a Nova 5 stack is no longer disqualified at the outset.

Technical risk

• Nova compatibility — materially reduced, not eliminated. The sharpest risk in the prior assessment (a low-adoption package lagging a Nova major, freezing your admin-panel upgrade path) has been addressed by PR #93. Residual risk: the support claim is a single PR with no visible CI matrix in the release notes, and the next Nova major restarts the same clock.
• Semver signal is weak — new observation. Nova 5 support shipped as a minor (3.1.0), not a major. The maintainer treats platform-major support as non-breaking. Practical consequence: your dependency automation will not flag Nova-compatibility changes as breaking, so you cannot rely on version numbers to gate a Nova upgrade. Pin exactly and test.
• Frontend supply chain — newly visible. 12 of the 14 changes are npm bumps in the build toolchain (webpack, express, braces, ws, elliptic, micromatch, cross-spawn, nanoid, http-proxy-middleware). Several correspond to published advisories. This confirms the package ships Node-built assets and that its JS hygiene is dependabot-driven. Most look dev-time only, but confirm none reach the shipped compiled assets in dist/.
• Bus factor. Unchanged and arguably accentuated: 136 stars, 0 dependents, single maintainer, no visible security disclosure process. The only substantive commit in this release is the maintainer's own. Adoption signal remains weak; you are still an early adopter.
• Enforcement gap. Unchanged. Installing this does not "add permissions." Nothing is enforced until policies/gates call into it.
• Super-admin bypass. Unchanged. Unscoped Gate::before remains the classic source of silent, global over-permissioning.

Key questions

• Is Nova 5 support dual-tracked with Nova 4 on the same branch, and is that pairing covered by CI, or is Nova 5 support an untested claim?
• Does 3.1.0 require republishing assets, config, or migrations when upgrading from 3.0.x? Any Nova 5 behavioural differences documented beyond the version constraint?
• Are the npm bumps dev-only, or do any affect committed compiled assets? Is there a build provenance/rebuild step?
• Does it depend on spatie/laravel-permission, and at what constraint? Who owns upgrading that transitive dependency?
• Does it ship any enforcement primitive (policy base class, middleware) or purely UI plus models?
• Multi-guard and teams support? How is permission cache invalidation handled on write?
• Is there an audit trail for role/permission changes — who changed what, when?
• Now that Nova 5 has landed, what does the maintainer's stated support window look like for the next Nova major?

Integration Approach

Stack fit

• Laravel + Nova + relational DB (PHP 8.1+, Laravel 10/11, Nova 4 or 5). Nova 5 is now a supported pairing — verify the exact constraint in composer.json rather than relying on the changelog line.
• If spatie/laravel-permission is already in the stack, this remains additive UI with near-zero architectural change. If it is not, you are still adopting spatie as a transitive architectural decision and should evaluate it on its own merits first.
• Confirm the Node/asset build story: whether dist/ is committed and whether you need a JS toolchain to rebuild after patching.

Migration path

• Phase 0 spike (2–3 days): install on a throwaway branch against your Nova major, confirm the version pairing, inventory what the package provides versus what you must build, and check for asset/migration republish requirements coming from 3.0.x.
• Define the permission catalogue in code — config- or enum-backed seeder — namespaced by resource and action (viewAny:Invoice, update:Invoice).
• Retrofit policies so canViewAny/canUpdate delegate to a single permission-check helper; avoid stringly-typed permission names scattered across the codebase.
• Backfill roles from existing role columns or legacy gates with a one-off command, then diff "who can do what" before and after to prove parity.
• Cut over behind a feature flag; keep legacy gates as a fallback for one release.

Compatibility

• Pin the exact package version (not a caret range), given the minor-version-carrying-a-major-platform-support precedent.
• Add a CI matrix job that runs both Nova 4 and Nova 5 against the pinned package so the next Nova bump fails loudly rather than silently. This is now the primary hedge replacing the old "wait for Nova 5" question.
• Verify migrations are idempotent and do not collide with pre-existing permission tables.

Sequencing

1. Spike and confirm version matrix against your Nova major → 2. permission catalogue design → 3. policy refactor (largest effort) → 4. data backfill → 5. shadow-mode comparison against legacy gates → 6. cutover → 7. remove legacy gates.

Operational Impact

Maintenance

• Code maintenance is outsourced but not risk-free; you own the fork if it stalls. Budget 1–2 days per quarter for Nova/Laravel/spatie upgrade tracking, escalating to a private fork or vendored copy if abandoned. Nova 5 support arriving is evidence the maintainer is active, not evidence of sustained throughput — one substantive commit in this cycle.
• The permission catalogue remains a governed artefact: owner, review rules, deprecation path for retired permissions.

Support

• Single maintainer, zero dependents, no visible security process. Do not place it on a security-sensitive boundary without an internal read of the model and migration code, and a documented plan to vendor it.
• The dependabot-driven JS advisories suggest reactive patching. That is better than nothing but is not a disclosure process — you will learn about vulnerabilities from commit titles, not advisories.

Scaling

• Read path is the underlying permission set served from cache — comfortable for typical admin populations (tens to low hundreds of admins). Writes are rare.
• Ensure a shared cache store (Redis) across nodes so permission caches invalidate consistently; otherwise revocation is per-node and inconsistent.

Failure modes to design against

• Stale cache after a role change → user retains access until flush. Enforce invalidation on write and document it.
• Permission removed in code but the row persists in DB → orphan grants. Add a reconciliation command run at deploy.
• Unscoped Gate::before super-admin → silent global bypass.
• Nova major upgrade lands; package lags; admin-panel upgrade freezes. Reduced for Nova 5, rescheduled for the next major — and invisible to dependency scanners because platform support ships as a minor.
• Missing seeder on a fresh environment → total lockout or total access, depending on default-deny posture. Gate this with a deploy check.

Ramp-up

• Engineer: 2–3 days, mostly Nova policy semantics rather than the package itself.
• Ops/support: hours; the role-assignment UI is the point of the package.
• Organisation: recurring process cost — permission-catalogue review is ongoing, not a one-off.

Build vs. buy

• The package substitutes for roughly 1–2 sprints of Nova UI plus model work. Buying remains defensible for a small team, and the case is now stronger: the Nova 5 answer that previously gated the decision is yes.
• The decision has narrowed to two considerations — your appetite to fork or vendor if the maintainer stalls, and the modelling effort to build the permission catalogue. Neither is resolved by this release. Treat this as a dependency you pin and monitor closely rather than one you set and forget.