Nova Searchable Filter Laravel Package

Product Decisions This Supports

• Build vs. buy for internal admin tooling. Nova is already a paid, licensed admin layer; this package is a thin extension of it, not a new platform commitment. The real decision is "write a custom Nova filter ourselves (~50–100 lines of PHP) vs. pull in a dependency vs. live with Nova's default BelongsTo filter." This package only makes sense as a cheap default option in that comparison.
• Ops/support efficiency roadmap. The default Nova BelongsTo filter renders a plain <select> of every related record. Once a parent table crosses roughly a few hundred rows (customers, accounts, SKUs, tenants), filtering becomes scroll-and-pray. A searchable dropdown is a small, measurable support-agent time saver — a legitimate line item in an "internal tools quality" backlog.
• Feature prioritization for admin surfaces. If your product roadmap includes self-serve reporting, exports, or delegated admin for non-engineers, filter usability on high-cardinality relationships is a prerequisite, not a nice-to-have. This is a stopgap that unblocks that without a custom admin build.
• Risk/technical-debt accounting. With 4 stars, 0 dependents, and a last release in August 2023, this is effectively a single-maintainer, unproven dependency. Adopting it is a decision to own it, not to consume it — factor a fork/vendor step and a Nova-major-upgrade check into the estimate.
• Not a decision it supports: public-facing UX, multi-tenant data isolation policy, or anything security-sensitive. This is a search widget for an authenticated back office.

When to Consider This Package

Adopt (or, more accurately, evaluate) when all of the following hold:

• You are on Laravel Nova 4.x and have no near-term plans to jump to Nova 5. Verify compatibility against your exact Nova minor version before writing code — the package has not shipped since 2023 and will not have tracked Nova's release cadence.
• The pain is specifically BelongsTo filters with high-cardinality parent tables. That is the entire scope of the package.
• The admin panel is internal-only, small surface area, and a broken filter degrades convenience rather than revenue.
• Your team is comfortable vendoring or forking a ~4-star dependency into packages/ or app/Nova/Filters/ and owning it. At this maturity level, treat it as reference code you copy, not a library you composer require and forget.
• You have more than a handful of these filters to build, so the boilerplate savings are real rather than a one-off.

Look elsewhere — or just write it yourself — when:

• You are on Nova 5, or your Nova version is unpinned.
• You need BelongsToMany, MorphTo, dependent/cascading, or multi-select searchable filters. Out of scope.
• You need active maintenance, security response, or a support contract. Four stars and zero dependents means no community backstop.
• The relationship cardinality is modest (tens of rows) — Nova's built-in filter is fine and the dependency earns nothing.
• Your org has a dependency-vetting policy with minimum-maintenance or CVE-response criteria; this will not clear it.

How to Pitch It (Stakeholders)

To executives: This is a small, low-cost usability fix for our internal admin panel, not a product feature. Support and ops staff currently wade through unsorted dropdowns of every customer/account record when filtering; a searchable picker cuts that to a few keystrokes. The package itself is a minor open-source utility with essentially no adoption (4 GitHub stars, no downstream users, no release in over a year), so we should treat it as a reference implementation we copy into our codebase, not a dependency we rely on. Total exposure: roughly a day of engineering, no licensing cost, no vendor relationship, and no lock-in — we can delete it at any time without touching product code.

To engineering: Scope is narrow — a searchable BelongsTo filter for Nova 4. It saves writing the same custom filter repeatedly across resources. Because the package is unmaintained and unproven, the recommendation is to vendor the source into our own app/Nova/Filters directory so we control compatibility and can fix breakage ourselves during Nova upgrades. If the estimate to replicate it in-house comes in under half a day, skip the dependency entirely and write it — that is the preferred outcome. If we do adopt it, add a note to the Nova upgrade checklist so it gets revalidated on every major version bump.