Dependent Filter Laravel Package

Product Decisions This Supports

• Admin/ops UX investment: Decides whether cascading filter behavior (e.g., Country → Region → Account, or Category → Subcategory) is worth building into internal Nova resources, versus accepting flat, independent filters that force ops users to reason about irrelevant option sets.
• Build vs. buy vs. fork: The realistic decision this package informs is not "adopt" but "spike, then fork or reimplement." With 0 stars and 0 dependents, it is a pattern reference and a possible starting point, not a supported dependency. Expect the outcome to be a ~1-day spike that either vendors the package or reproduces its approach in-house.
• Roadmap prioritization for internal tooling: Dependent filters are a quality-of-life improvement for a small internal audience, not a customer-facing differentiator. This helps frame the work as low-effort ops efficiency rather than a roadmap line item.
• Standardization of filter patterns: If adopted, it sets a convention for how filters across resources declare dependencies — useful if you have many admin resources and want consistency rather than one-off Vue components per screen.
• Support-load reduction: Fewer "why can I select a city in the wrong country" tickets and fewer mis-scoped exports/reports generated from admin screens.

When to Consider This Package

Consider it when all of the following hold:

• You are already on Laravel Nova (a paid, opinionated commitment — this is a Nova-only solution).
• You have at least two filters whose option sets are hierarchical or mutually constraining, and users regularly pick invalid combinations.
• The consumers are internal staff, so a small amount of rough edge is tolerable.
• Someone on the team can read PHP and Vue and is willing to own a fork, because upstream maintenance is unproven.

Look elsewhere — or build in-house — when:

• You need a supported dependency with an SLA, version-compatibility guarantees, or a security review trail. Zero stars/dependents means zero community validation and no signal on Nova 5 compatibility.
• Your need is a single dynamic option list. Nova's options(Request $request) on a filter class, plus a small custom component, may cover it without a third-party dependency.
• A scoped search, a saved view, or a resource-level relationship constraint solves the same user problem more cheaply.
• You cannot commit maintenance ownership. An abandoned Nova package will break on the next major Nova upgrade, and Nova upgrades are not optional if you track Laravel releases.

How to Pitch It (Stakeholders)

To executives: This is a small, low-cost enhancement to our internal admin panel that reduces operator errors when filtering large datasets — the kind of mistake that produces wrong reports or wasted review time. It is not a customer-facing feature and should not consume roadmap capacity. Because the package is unmaintained and unproven (no adoption signal), I recommend a short, timeboxed evaluation and, if it works, taking ownership of a local copy rather than treating it as a long-term vendor dependency.

To engineering: The surface area is small — a Nova filter base class plus a Vue component that reacts to sibling filter state. Plan for a one-day spike: verify it works on our Nova version, confirm the dependency mechanism matches how we register filters, then decide between vendoring with a pinned fork or reimplementing the pattern (likely a few hundred lines). Budget ongoing ownership: assume we are the maintainers, not the community.