Value Filter Laravel Package

Product Decisions This Supports

• An admin-tooling decision, not a product roadmap decision. This package only enters the conversation if we already run Laravel Nova and have a backlog of "ops needs to filter the index page" tickets from support, sales ops, finance, or moderation. It has zero bearing on customer-facing features, pricing, GTM, or anything that touches a customer. Scope the conversation to internal tooling and keep it there — that framing alone prevents most of the wasted evaluation cycles these tiny packages attract.

• Build vs. buy vs. fork — and the honest answer here is "own." With 3 stars, 0 dependents, a last release of 2023-05-15, and a total surface area of roughly one PHP filter class plus a small Vue component, this is not a vendor relationship; it's a reference implementation. The PM decision is not "do we adopt this dependency," it's "do we copy ~50 lines into app/Nova/Filters and own them forever, or do we write them from scratch." Cost the ticket as the copy-in path from day one. Vendoring now is cheap; discovering we needed to vendor during an unrelated Laravel security upgrade is expensive.

• Effort sizing for a concrete backlog item. The integration is one class reference in filters() plus a staging smoke test — hours, not days — which makes it a genuinely useful anchor for scoping. If the package's behavior is "good enough" for a single equality filter on an indexed column, the ticket stays small and shippable this sprint. If the requirement turns out to need operators, ranges, multi-column logic, tenant scoping, or soft-delete handling, rewrite the ticket as an in-house filter immediately rather than discovering that mid-sprint. The package's tiny surface stops being leverage and starts being something we fight.

• Risk posture for anything adjacent to a critical path. Default governance if we touch it at all: pin to an exact version or commit, disable automated update PRs, assign a named owner, add it to the Nova major upgrade checklist, and require one regression test asserting the filtered index returns the expected record IDs — not "the page loads." The failure mode is a silently wrong list an operator acts on, with a 200 response and no error to alert on. That's a data-quality risk wearing a UI costume, and it's the reason the regression test is a launch gate and not a nice-to-have.

• A documentation-quality signal worth acting on. The package's own description pitches a general-purpose "filter, normalize, and transform values" sanitization library. It is not that — it is a single Nova filter. That mismatch is a real red flag about the package's stewardship and its stated scope. Concretely: do not let it drift into a role as our input-validation or sanitization layer. If a stakeholder asks for "the sanitizer library," that's a separate and more consequential decision, and this package is not the answer.

• Use cases in scope: admin-only filtering of records by one discrete value — order status, user role, tenant/owner, ticket priority, moderation state — reducing bespoke Nova filter UI work, and unblocking small internal dashboard improvements quickly without a design cycle.

When to Consider This Package

Consider it only when all of the following hold:

• We already run Laravel Nova, with working auth.json credentials in every environment that resolves composer.lock (including CI). Nova is a hard gate, not a nice-to-have — without it, composer require fails with an error that never mentions this package and burns an afternoon of misdirected debugging.
• The need is a single equality filter on one indexed, low-cardinality column. status, role, priority. Nothing more.
• The surface is internal admin tooling — no customer visibility, no SLA, no revenue-critical view, no security-sensitive or multi-tenant-critical path.
• Someone will read src/ before we estimate. With 3 stars, 0 dependents, and no issue-thread lore, there is no external answer key. Confirm the FQCN, key(), name(), and exactly what apply() does with null, arrays, and unexpected types. This is minutes of work and it is not optional.
• We have a named owner and a copy-in exit ramp documented before the first commit.

Look elsewhere — or write it in-house — when:

• We don't run Nova. Full stop. The package does nothing for us.
• The requirement is genuine input sanitization or validation (form requests, API payloads, jobs). The description implies this; the code does not deliver it. Use Laravel's validators and a real sanitization approach.
• The requirement exceeds simple equality — ranges, multi-select operators, date windows, cross-column logic, tenant scoping baked into the query. At that point our own filter is smaller than the workarounds.
• We're pre-Nova-5 or mid-upgrade. A 2023-05-15 release predates Nova 5, Laravel 12, and PHP 8.3+, giving three independent break lines. If the upgrade is anywhere on the horizon, vendor the class rather than taking the dependency.
• The filtered column isn't indexed and the table is large. An EXPLAIN on production-shaped data is a prerequisite; an unindexed filter on millions of rows turns the admin panel into a support ticket.

How to Pitch It (Stakeholders)

To executives: This is a small internal admin-tooling decision, not a product investment. It affects how fast our ops and support teams can slice records in the Nova admin panel, and nothing a customer sees. The recommendation is to treat it as a code pattern we copy, not a dependency we buy into — roughly half a day of engineering, zero licensing cost, and no vendor risk. The real risk isn't adopting it; it's adopting it lazily, letting a stale third-party class sit on the admin panel through a Laravel or Nova upgrade, and having an operator act on a silently wrong list with no error to alert on. We mitigate that with a pinned version, a named owner, and one regression test.

To engineering: Read the source first — the package is a Nova filter, not the general-purpose sanitizer its description advertises, and that mismatch is the whole story. Confirm the FQCN, key(), name(), and apply()'s handling of null and arrays before estimating. Then take the vendor path: copy the filter class into app/Nova/Filters (and the Vue component if it ships one), drop the Composer dependency, and own ~50 lines. If we do install it, pin to an exact tag, disable automated update PRs, register it on one low-traffic Resource first, subclass it to own the query semantics (apply()), supply options explicitly (options()) so operators can't typo their way to wrong results, gate visibility with canSee(), and ship a query-contract test that asserts the filtered index returns the expected IDs — with explicit cases for null, unknown values, and wrong types. Never test the Vue component; test the outcome. Document the intended semantics in the repo so the next engineer doesn't reverse-engineer apply() from scratch.

Bottom line: Approve the ticket only as an in-house copy-in, scoped to internal admin filtering on indexed columns, with a named owner and a regression test as the launch gate. Reject anything that puts it on a critical path or casts it as our validation layer.