Nova Input Filter Laravel Package

Product Decisions This Supports

• Build vs. buy for a narrow admin interaction. This package is a thin presentation primitive: a Vue text-input component wired into Nova's filter panel plus a base Filter class. It does not ship search, ranking, or query logic — you still write apply(). The decision it informs is therefore small on both sides: buy a filter input control versus roughly a day of bespoke Nova component work. Decide it quickly at the team level rather than escalating it.
• Roadmap: unblocking internal search on large resource indexes. Support, ops, finance, and fulfillment teams doing email / order-number / tracking-code / SKU lookups on big Nova tables are the beneficiaries. Fixed-option select filters degrade into unusable 500-item dropdowns past a few dozen values; free-text does not. This is typically a same-sprint "nice to have": one composer require, one filter class, one line in filters().
• Replacing filter sprawl in mature Nova installs. It cleanly supersedes the clunky exact-match checkbox filters that accumulate over time, consolidating several one-off controls into a single legible input with a stable URL parameter.
• Dependency governance classification. Admin-only, MIT, no schema changes, no customer-facing surface, no state to migrate, replaceable and forkable. That profile justifies approval at a lower threshold than a product or platform dependency — but it does not remove the need for a named owner. The precedent worth setting: low-adoption admin tooling is acceptable when a fork-into-app/Nova/Filters contingency is agreed before adoption, not after something breaks.
• Security review scope shifts to us — and that changes resourcing. The package supplies the component and the filter lifecycle; the query is entirely our code. A naive where('name', 'like', "%{$value}%") copied from an example is an injection path from an authenticated admin surface. This is the highest-severity failure mode in the whole evaluation and it lives inside our review boundary. Budget review time and a written rule (bound parameters only, grouped orWhere closures) as part of the adoption cost, not as a follow-up.
• Operational metrics worth targeting. Time-to-find for internal users, engineering interrupts avoided, and ad-hoc "can you pull this record" SQL requests replaced by self-serve admin lookups. These are cheap to capture during a pilot and they justify the next admin-tooling decision.
• Reuse threshold. Adopt if it will land on two or more resources with a plausible path to more. On a single resource, an in-house filter class is cheaper than adding a dependency.

When to Consider This Package

• Prerequisites are non-negotiable. You must be on a licensed Laravel Nova install (v4 or v5), PHP 8.1+, Laravel 10–12. There is no published Nova support matrix — the package ships a compiled Vue asset that rides Nova's frontend pipeline, so Nova's major version is the compatibility ceiling.
• Adopt when: you have one or more high-volume Nova indexes where the natural lookup key is free text (name, email, SKU, order number, tracking code); your users currently ask engineering for these lookups; and you have an owner who will review the generated SQL.
• Look elsewhere when the input has numeric or date semantics. Placeholder, inputmode, and type="number" are not exposed in the PHP config — customizing them means overriding the Vue component and pulling yourself back into the frontend build you were avoiding. Nova's built-in date/number filters are the right call there.
• Look elsewhere (or pair it) on very large tables. A leading-wildcard LIKE cannot use a B-tree index; it is a sequential scan. Past low-hundreds-of-thousands of rows, use prefix matching, add a trigram/fulltext index, or pair the input with a narrowing date/status/tenant filter so the LIKE runs over a pre-filtered set. Run EXPLAIN against production-like row counts during the spike, not after rollout.
• Dependency-health caveat: 24 stars, 0 public dependents, single-maintainer agency, last release January 2025. None of that is disqualifying for an admin-layer primitive, but it means pinning the Composer constraint ("1.x" or an exact tag) and treating the version as deliberate. The entire package is a base class plus a component — small enough to copy into app/Nova/Filters and drop the dependency in an afternoon. Agree that fork path now.
• Upgrade checklist impact. A stale compiled component against a new Nova major typically fails silently — the filter panel renders blank or the input never mounts. Add "open every input filter on staging" to the Nova upgrade runbook; this cannot be reasoned about from source alone.
• Ambiguity to resolve up front. Empty input has no defined meaning until we define it. Decide between "no-op" and "zero rows" and encode it with a blank($value) guard in every apply(). Users cannot distinguish "filter applied, no matches" from "filter didn't apply," and that erodes trust in the admin panel faster than a missing feature.

How to Pitch It (Stakeholders)

For executives: This is a one-command, MIT-licensed add-on that turns our admin panel into a self-serve lookup tool. Support and ops stop filing tickets to engineering for "find this order by email," and we retire the unwieldy dropdown filters that no one uses. No database changes, no customer-facing surface, no migration, no data risk. Total cost is hours, not weeks, and the primary investment is a code review of the queries we write — which is work we would have to do anyway.

For engineering: It is a base Filter subclass plus a compiled Vue input component; there is no service provider, no publish step, no asset build. We own apply() entirely, so the query shape is our decision and our review: bound parameters only, grouped orWhere closures, and an explicit blank($value) guard for the empty case. It is only useful inside a licensed Nova install, so Nova's major version is the compatibility ceiling, and the compiled asset can fail silently on upgrade — we add an "open every filter on staging" step to the Nova upgrade checklist.

What we are asking for: approval to add it as a pinned admin-only dependency, with a named owner, a documented query-review rule, and a pre-agreed contingency to fork the two files into app/Nova/Filters if upstream goes quiet. Pilot it on the highest-volume resource index first, measure time-to-find and engineering interrupts avoided, and roll it out to further resources if those numbers hold. If it only ever lands on one resource, we build the filter in-house instead — that is the threshold we are holding ourselves to.