Nova Dependent Filter Laravel Package

Technical Evaluation

Architecture fit. The package is a point solution that lives entirely inside Laravel Nova's filter panel. It does not stand alone: it augments Nova's existing Filter contract so that one filter's option set resolves against the value of a parent filter. That makes it architecturally clean — no new services, no schema changes, no background jobs — but also means it inherits Nova's undocumented frontend internals as its foundation. Fit is high only if the product already runs Nova and the need is genuinely cascading filters on admin screens. It is a back-office operator-efficiency tool, not a customer-facing capability, and should be scoped as such from the outset.

Integration feasibility. Mechanically straightforward for a team already on Nova: composer require, extend the package's base filter class rather than Laravel\Nova\Filters\Filter, declare parent(), register the parent filter before the child in the resource's filters() method, and run nova:publish. The trap is a hard prerequisite: installation fails dependency resolution if laravel/nova is not already installed and locked, and the error message will not say so. Feasibility therefore hinges on three pre-checks that should be done before any commitment: the exact Nova major pinned by the package (4.x vs 5.x, Vue 2 vs Vue 3), the PHP floor, and whether it ships precompiled JS or raw .vue requiring a consumer build. If the team's Nova version falls outside that constraint, the frontend component will not mount and the whole evaluation is over.

Technical risk. Concentrated in ownership rather than code complexity:

• Bus factor of one. 3 stars, 0 dependents, single maintainer. Functionally this is source code the organization now owns, regardless of what the composer.json says.
• Nova upgrade coupling. The package rides on Nova's frontend internals, which churn between majors. Budget roughly a day per Nova major upgrade to patch or replace, and assume upstream will not ship a fix on the team's timeline.
• Authorization gap. Dependent filters return real IDs and labels. If options() is not scoped through the same policies as the index query, a user who can see the child filter can enumerate records they cannot view. This is the one risk with a security dimension, not just an availability dimension.
• Cold-start performance. An unguarded options() that plucks the full set when the parent is blank turns the first page load of a large admin index into an unbounded query. This is a predictable, self-inflicted incident pattern.
• Silent failure modes. Wrong base class or wrong registration order produces a filter that renders correctly and never cascades — invisible to a happy-path demo, expensive to diagnose later.

Key questions.

1. Which Nova major is this pinned to, and does it match ours exactly?
2. Does the frontend refetch options server-side per parent change, or preload client-side sets? This determines both performance profile and how it debugs.
3. Does options() have any authorization awareness, or is policy scoping entirely our responsibility in the subclass?
4. How many Nova resources actually need cascading filters — one, or several? This is the build-vs-buy hinge.
5. Who is the named internal owner, and where is the fork?
6. Does URL state survive a copy-paste into a new tab and a "Reset Filters" action?

Integration Approach

Stack fit. Requires Laravel + Nova, full stop. It brings no new runtime, no new datastore, no queue or cron surface. The only frontend implication is asset publishing: Nova assets are published per deploy, not per request, so a stale-JS mismatch between server and source is a live failure mode. For a team already operating a Nova deploy pipeline, this is an incremental step, not a new capability.

Migration path. There is nothing to migrate — it is additive. Introduce it behind an internal wrapper so the third-party code is isolated to one file on day one, not later:

• Create App\Nova\Filters\DependentSelect extending the package base class.
• Have every dependent filter extend that, never the package class directly and never Nova's Filter.
• For multiple resources sharing a cascade, put shared query logic in one abstract base with an abstract parent() and a protected options builder, so a Nova break is a single-file fix.

This wrapper is the exit plan made concrete. Swapping to a hand-rolled implementation becomes a one-file change, which is what makes adopting a 3-star package defensible at all.

Compatibility. Two guardrails, both mandatory:

• Pin the package version explicitly and verify the Nova constraint on every Nova upgrade — treat them as coupled dependencies, not independent ones.
• Add php artisan nova:publish --force to the CI/deploy pipeline. This is not optional housekeeping; skipping it is the classic silent failure where filters render but options never refresh.

Optionally fork under the org account before rollout rather than after the first breakage. Forking later means waiting on someone else's timeline for a patch you already need.

Sequencing.

1. Spike (days, not weeks). Read composer.json; confirm Nova major, PHP floor, asset delivery, and option-fetch strategy. If any mismatch, stop.
2. Name the owner and fork the repo under the org account before any code is written.
3. Build the wrapper and one cascade — country → city — on a single non-critical resource. Enforce the guard clause (blank($parent) ? return [] : ...) from the first commit, and route options() through the same policy scoping as the index query.
4. Smoke-test the render, not just the logic: an authenticated request to the Nova resource index asserting 200. Nova majors break rendering more often than they break filter logic.
5. Two-week pilot on that one resource with a defined metric — time-to-filter on a support workflow, or reduction in "wrong filter returned nothing" tickets.
6. Expand only if the metric moves. If it does not, drop the package and hand-roll the filter for that specific screen; a custom Vue Nova filter is comparable effort to this integration and gives full ownership.

Operational Impact

Maintenance. The real cost of this package is ownership, not license. Assume full responsibility for the code the moment it is in composer.json. Maintenance load has three components: a per-Nova-major patching budget (roughly a day each), ongoing review of the wrapper as resources adopt the pattern, and the standing cost of tracking an upstream that may never publish again. Confining the dependency to one abstract class is what keeps this number small; spreading direct inheritance across a dozen filters is what makes it balloon.

Support. Support load comes from a small set of recurring, diagnosable complaints, and the mitigation is a documented decision tree rather than heroics:

• "Filter does nothing." Parent not registered first, or filter extended the wrong base class.
• "Options don't refresh." nova:publish did not run for the current deploy.
• "Empty results after clearing a filter." Orphaned child state — clearing the parent does not clear the child's query-string value. Treat stale children as a no-op in apply() or document the reset path.
• "Two tabs conflict." Filters are URL state; two tabs on the same resource stomp each other. Almost never a package bug — reproduce with a copied URL before code-diving.

Publish the debugging checklist and the URL-state behavior to the support team. The cost of an undocumented cascade is measured in triage time.

Scaling. Scale risk is query-shaped, not traffic-shaped — admin tooling has low concurrency but can hit large tables. Two controls: the empty-parent guard (return [], never the full set, never an unbounded pluck) and short-lived caching of option lists keyed by parent ID and tenant, with a one-minute TTL that is entirely adequate for admin workflows. Both are implementation responsibilities, not package features — the package will not protect against either by default. Multi-tenant deployments need tenant in the cache key and, more importantly, in the authorization scoping.

Failure modes. Ranked by blast radius:

• Authorization leakage through unscoped options(). Highest severity; the only failure with a security dimension. Mitigate by policy scoping from the first commit.
• Silent non-function — renders, never cascades. High frequency, low severity, high triage cost.
• Stale assets after deploy. High frequency, one-line fix, invisible until someone notices.
• Cold-start query storm on a large index. Predictable and preventable; becomes an incident only when the guard is missing.
• Nova upgrade breakage. Low frequency, known cost, unfixable upstream on your timeline — which is exactly why the fork and wrapper exist.
• Cross-tab state collision. Low severity, high noise; document rather than fix.

Ramp-up. A capable Laravel/Nova engineer gets productive in under a day given the wrapper already exists — the mental model is small (base class, parent(), options(), registration order). The onboarding artifact that matters is not the README, which is thin, but two internal documents: the debugging checklist and the extension-point boundary. Treat the base class options(), the parent() declaration, and any parent-change hook as the only stable surfaces; everything else is private and should be treated as such. Ramp-up cost is front-loaded into that documentation and repaid the first time someone other than the original author has to debug a cascade.

Boundary decision — make it explicit and in writing. This should not become load-bearing infrastructure for revenue-, support-, or finance-critical workflows. That is a product decision, not an engineering one, and it should be recorded before rollout alongside the named owner, the pinned Nova version, and the exit plan. The package pays off when the pattern repeats across several Nova resources and a single-major Nova pin is acceptable; it does not pay off for one screen, and it never pays off as a platform dependency.