Dependent Filter Laravel Package

Technical Evaluation

Architecture fit. The package addresses a genuine gap in Laravel Nova: Nova's native Filter class exposes a single options(Request $request) method, and the filter panel fetches options once when it opens. There is no first-class mechanism for one filter's option set to react to another filter's selected value. okol/dependent-filter fills that gap by wrapping Nova's filter contract with a parent/child relationship and a client-side listener that re-requests child options when the parent changes. For a Nova-backed admin panel with hierarchical data (region → territory, tenant → project, category → subcategory, team → member), this is the correct layer to solve the problem — it avoids duplicating filter logic into every Resource's filters() method.

Integration feasibility. High on paper, low in confidence. Installation is a standard composer require plus registration of the filter classes; there is no schema change, no service provider conflict expected, and no queue or cache dependency. The integration cost is measured in hours, not weeks. However, feasibility cannot be validated against documentation alone: with 0 stars and 0 dependents there is no evidence base of working installs, no issue history to mine for edge cases, and no signal on which Nova major versions are actually supported.

Technical risk. This is the dominant concern and it is concentrated in one place: the package almost certainly depends on Nova's internal front-end contract — the shape of the filter payload, the Nova API endpoint used to resolve options, and the Vue component registration mechanism. None of these are guaranteed stable public APIs. Nova 4 moved to Vue 3 and reworked the filter UI; Nova 5 continued that drift. A package pinned to one Nova minor version is a package that breaks on upgrade of a paid, closed-source dependency you cannot patch yourself. Secondary risks: an unversioned or single-maintainer release history, no visible test suite, and an AJAX round-trip per parent change that needs authorization review (child option endpoints must scope results to the authenticated user's Nova-visible resources, or you leak cross-tenant data in dropdowns).

Key questions.

• Which Nova major/minor versions are supported, and is that stated anywhere testable?
• Does the child option endpoint reuse Nova's authorization middleware, or does it define a new route that bypasses Nova::check / policy scoping?
• Is option resolution query-safe under large cardinality (e.g., 50k child rows), or does it hydrate everything?
• Does it degrade gracefully if the parent filter is cleared, or does the child retain a stale value in the query string?
• Is there a test suite, and does CI run against multiple Nova versions?
• What is the maintenance commitment from the author, given zero external usage?

Verdict on technical merit: sound idea, plausible implementation, unverifiable quality. Treat it as a reference implementation to read, not a dependency to install.

Integration Approach

Stack fit. Requires Laravel + Nova (paid license) + Vue toolchain consistent with the Nova version in use. It is a Nova-only package — it does nothing for Blade/Livewire or Inertia front ends. If the team runs Nova 4 or 5, compatibility must be confirmed empirically in a scratch environment before any planning commitment; if the team runs Nova 3, expect the Vue 2 component to be the relevant path and verify separately.

Migration path. Recommended: vendor the source, do not depend on it. Copy the filter base class and the Vue component into the application (or an internal packages/ path repository), pin them to the installed Nova version, and own them. This converts an unmaintained third-party risk into ~200–400 lines of first-party code with a known owner. The alternative — a composer require with a version constraint — leaves the team exposed to a silent break on the next Nova upgrade with no upstream fix path. If the composer route is chosen anyway, add a lockfile pin plus a smoke test that renders the filter panel.

Compatibility. Enumerate explicitly and test: Nova major version, Laravel version (10/11/12), PHP version (8.1+), and whether the app uses any Nova filter customizations or theme overrides that could collide with the component registration. Also confirm the interaction with Nova's filter "memory" / persisted filter state per user, since dependent filters and persisted state interact badly if the parent's stored value no longer exists.

Sequencing.

1. Spike in a throwaway branch: install, wire one real parent/child pair against a production-shaped dataset, observe the network calls and authorization behavior. Timebox to 1–2 days.
2. Security review of the option-resolution route — confirm tenant/policy scoping on the child endpoint.
3. Decide build-vs-vendor based on the spike. Given the maintenance profile, the default recommendation is vendor-and-own.
4. If adopted, add a regression test that asserts the filter panel renders and the child endpoint returns scoped results, so Nova upgrades fail loudly.
5. Roll out to one internal admin surface before any client-facing or multi-tenant panel.

Estimated effort: 2–4 days for spike + hardening for a single filter pair; 1–2 weeks to generalize into an internal pattern if more than a handful of dependent filters are needed.

Operational Impact

Maintenance. The package is effectively unmaintained from a consumer's perspective — 0 stars and 0 dependents means no community to surface regressions, no issue triage, and no realistic expectation of a patch when Nova ships a breaking change. Ownership of the code, in practice, transfers to the adopting team on day one. Budget for a review at every Nova upgrade; that review is cheap if the code is vendored and expensive if it is a black-box composer dependency.

Support. No vendor support, no SLA, no documented troubleshooting. Internal knowledge must be captured deliberately — a short ADR plus inline comments on the Nova API coupling points — or the next engineer to touch filters will rediscover the constraints from scratch.

Scaling. Two dimensions. First, option cardinality: each parent change triggers an options request; if the child query returns tens of thousands of rows the dropdown becomes unusable regardless of package quality. Enforce server-side limits and search. Second, request volume: a filter panel with several dependent chains multiplies API calls per session; on a busy admin this is measurable but unlikely to be material — admins are low-concurrency users. The real scaling risk is data scoping under multi-tenancy, not throughput.

Failure modes.

• Silent break on Nova upgrade — filter panel renders but child options never populate, or the component fails to register. Highest-probability failure; mitigate with a UI smoke test.
• Authorization gap — child endpoint returns options outside the user's permitted scope, exposing tenant or customer names in a dropdown. Highest-severity failure; mitigate with explicit policy scoping and a test.
• Stale state — parent cleared or changed, child retains a prior selection and the query silently filters on an invalid combination, producing empty result sets that look like data loss.
• N+1 / unbounded hydration on large parent sets.
• Abandonment — author archives the repo; no path to a fix other than the fork you should have made anyway.

Ramp-up. Low for a Laravel developer familiar with Nova — the filter contract is small and the concept is standard. The non-obvious cost is Nova's internal front-end API, which is undocumented; expect a day of reading Nova's compiled assets or source to understand the component registration and endpoint contract if any customization is needed. Document that once; it is the reusable artifact.

Bottom line. Solve the right problem at the right layer, but do not take a production dependency on a zero-adoption, single-maintainer package that couples to a closed-source framework's internal APIs. Spike it to validate the approach, then reimplement or vendor it as first-party code with an owner, tests, and explicit authorization scoping. The opportunity score of 31.57 reads correctly: real niche, weak supply-side signal.