Novaspatiepermissions Laravel Package

Technical Evaluation

Architecture fit. This is a Nova tool package — it plugs into Laravel Nova's tool registration lifecycle (ToolServiceProvider, tool metadata, compiled Vue/JS assets) and surfaces Spatie's Role and Permission models through Nova's UI layer. It is not a domain library; it adds no authorization logic of its own. That means it only fits if we are already committed to both Laravel Nova (paid, per-project license) and spatie/laravel-permission as the RBAC backbone. If either half is absent or in question, the package has no standalone value.

The deeper architectural wrinkle is that Nova ships its own authorization story (Policies + Gate) which is not the same as Spatie's permission tables. A tool like this manages the Spatie side of the house; it does not reconcile Nova resource-level authorization with Spatie permissions. Any expectation that installing this gives us "permissions that work in Nova" is a misread — we would still own the Gate::before / policy glue ourselves.

Integration feasibility. Mechanically simple: composer require, register the tool in NovaServiceProvider::tools(), ensure compiled assets are present, and confirm the package's migrations don't collide with the Spatie migrations we've already published. The realistic blockers are version alignment, not effort. Nova tools are tightly bound to Nova's major version (the front-end stack changed materially between Nova 3 and 4, and again toward 5), and Spatie's laravel-permission has had breaking changes across v5 → v6. With zero stars and zero dependents there is no evidence anyone has run this combination against a current stack.

Technical risk — high. The absence of signal is itself the signal. A Score of 0 with no stars and no dependents means: no community validation, no third-party security review, no CVE watch, no issue-tracker history to read for known breakage, and no realistic expectation of upstream patches. We would be the only operator of this code in the wild.

Compounding that, this package sits on a high-blast-radius surface. A UI that creates roles and assigns permissions is a privilege-escalation surface by definition. If its routes are gated only by Nova's auth middleware rather than a specific "manage permissions" gate, then any Nova user who can reach the tool can grant themselves anything. That is a one-line misconfiguration away from a serious incident, and we would have to audit it ourselves because there is no upstream to ask.

Key questions to answer before any commitment:

• Which Nova major version is this built against, and does it ship compiled assets or source only?
• Which spatie/laravel-permission major version do the models/relations assume (v5 vs v6 changed team support and cache behavior)?
• What middleware guards the tool's routes, and is that guard configurable?
• Does it register or respect Gate::before, or does it rely entirely on Nova policies?
• Does it invalidate Spatie's permission cache on write, and is that per-user or global?
• Does every mutation go through Spatie's API (events fire) or does it write to tables directly?
• Is there any audit trail? (Spatie's activitylog integration is the usual answer; if it's absent, we add it.)
• Who is the named owner if this breaks during a Nova upgrade?

Integration Approach

Stack fit. Assumes Laravel 9–11, PHP 8.1+, Nova 4/5, and spatie/laravel-permission 5/6. All of that needs to be verified empirically, not inferred from the README.

Migration path — treat this as a fork, not a dependency. With zero dependents, the honest plan is: vendor the source into our monorepo as an internal Nova tool. That gives us a pinned, auditable artifact, lets us patch the middleware and cache-invalidation paths ourselves, and removes the failure mode where a composer update silently pulls an unmaintained package into a security-relevant surface. The alternative — build a minimal in-house tool — is roughly 2–4 days of work for basic CRUD over roles/permissions, which sets the ceiling on how much we should pay for this package in review and remediation time.

Compatibility. Pin exact versions of Nova, Spatie, and this tool together; Nova upgrades and tool compatibility must move as one unit. Verify the compiled asset bundle exists in the repo (many abandoned Nova tools ship source only and rely on the consumer running npm run dev, which will not work in CI).

Sequencing.

1. Confirm our Nova major, Spatie major, and PHP/Laravel versions.
2. Read the source — routes, middleware, controllers, Vue components — before installing anything. This is hours, not days.
3. Stand up a throwaway Nova instance in a sandbox; install and exercise every screen.
4. Security review: route guards, mass-assignment, cache invalidation, direct DB writes, audit logging.
5. Decide: fork-and-harden vs build-in-house. Default to build unless the source is clean.
6. If forking: add feature tests around "revoked permission takes effect immediately," vendor it, set up a dependency-update runbook.
7. Staging rollout behind a Nova gate restricted to a named admin group.
8. Production, with the tool's route disabled for all non-superadmin users.

Operational Impact

Maintenance — we own it entirely. Zero upstream activity means no patches, no security advisories, no compatibility fixes. Budget roughly 1–2 engineer-weeks per year for Nova major upgrades and Spatie breaking changes, plus whatever the initial hardening costs. That cost does not shrink over time; it compounds with each framework bump.

Support. There is no vendor, no SLA, and effectively no maintainer to escalate to. Internal documentation will have to be written from scratch by reading the source. Onboarding a new engineer onto this tool means onboarding them onto our fork, not onto a documented ecosystem standard.

Scaling. Low concern. Nova is an admin-plane surface with a handful of concurrent users; throughput is a non-issue. The one real scaling interaction is Spatie's permission cache: bulk role edits across a large user base cause per-user cache invalidation churn, and if the tool writes to tables directly rather than through Spatie's API, that cache may not be invalidated at all — producing stale authorization that looks like a scaling problem but is actually a correctness problem.

Failure modes to watch:

• Stale permission cache → a user retains access after revocation. Highest-severity, lowest-visibility failure; needs a test and a documented php artisan permission:cache-reset runbook.
• Privilege escalation via under-guarded routes → any Nova-authenticated user can self-grant. Mitigate with an explicit gate plus a route-level check, not just Nova's default auth.
• Migration collision → double-published Spatie migrations, duplicate tables, failed deploys.
• Nova upgrade breaks the tool → the tools route 500s; the admin panel degrades for everyone, not just permission admins. Isolate accordingly.
• Direct model writes bypassing Spatie events → downstream listeners (activitylog, notifications, cache clears) silently don't fire.

Ramp-up. Low for an engineer already fluent in Nova tools and Spatie — perhaps half a day to read the source and understand the shape. Moderate for anyone who hasn't built a Nova tool before, because the tool-asset build pipeline is the fiddly part and there's no upstream documentation to lean on. The real ramp-up cost is organizational, not technical: someone must be named as the owner of this fork before it goes to production, or it becomes orphaned code inside a security-critical surface.