rosamarsky/nova-range-filter
A Laravel Nova filter that adds range-based filtering to your resources, letting users narrow lists by numeric or date intervals instead of single values. Drop it into a Nova resource's filters array for quick between-style queries.
Architecture fit. This is a single-purpose Nova filter — a thin Vue component plus a filter class that mutates an Eloquent query builder inside apply(). It does not touch routing, auth, persistence, or the domain model. That makes the architectural fit decision unusually simple: if the estate includes Laravel Nova, it slots into the existing filters() contract on a Resource or Lens with no new infrastructure; if the estate does not include Nova, the package has zero value and the evaluation ends in one line. The only genuine architecture question is whether the base class is concrete or abstract (subclass-per-range versus parameterized configuration), which determines whether we extend it or wrap it, and that is answered by reading src/ — a task measured in minutes.
Integration feasibility. High confidence, low effort, with one gating dependency: the laravel/nova version constraint in composer.json. That is a ten-second check and the single most likely reason the package fails outright. The second gating item is whether dist/ is committed and registered via Nova::script(); if yes there is no Node build and the estimate is roughly a day of engineering including tests, and if no we inherit a Vue build against Nova's toolchain and the estimate moves to days. Neither of these is a research project, but both must be resolved before we commit to a date — they are the difference between a one-day slot-in and a small frontend project.
Technical risk. Risk is concentrated almost entirely in ownership rather than in code quality. At 5 stars, 0 dependents, and dormant upstream, there is no maintainer signal that will warn us when a Nova major upgrade breaks rendering or silently stops applying the filter. A filter that stops filtering is worse than no filter — it produces confidently wrong result sets in an ops tool. Compounding risks: empty-string inputs arriving as '' rather than null (the documented #1 bug, producing plausible-looking empty result sets), NULL rows being invisible to BETWEEN/>=/<=, inclusive-bound off-by-ones, unqualified column names causing ambiguous-column errors on joined resources, date truncation excluding the final day, and full table scans on unindexed filtered columns. Every one of these is fixable in a small apply() override — but only if we own the code and test it.
Key questions.
name()/column()) or abstract, and what is the actual namespace and value shape (['min'=>..,'max'=>..] versus a delimited string)?Stack fit. Requires Laravel Nova and a PHP/Laravel backend compatible with the package's constraint. Fits as a Resource filter on index screens and, for free, on Lenses — which means one filter yields consistent range behavior anywhere the model is queried through Nova, provided we audit any lens that returns its own filters() array (it will silently drop ours). Best-fit use cases are internal, admin-only, non-critical surfaces: order totals, stock counts, prices, weights, ages, signup windows. It is not a customer-facing component and should not be sequenced or pitched as one.
Migration path. There is no migration in the data sense — no schema change, no backfill, no data store. The migration is a dependency-vetting path: read composer.json and src/ first, confirm the Nova constraint and asset situation, then decide vendor versus require. Given dormant upstream, the recommended path is to vendor or fork the class into app/Nova/Filters on day one and pin the version explicitly, treating Packagist as the source of the code rather than a runtime dependency. MIT license makes this a five-minute decision, and it converts an unmaintained transitive dependency into a first-party file we control.
Compatibility. Two axes. First, Nova major version — the dominant failure mode, with no community early warning; if we are on a major the package was not built against, fork the class rather than debug abandoned assets. Second, frontend tooling: committed dist/ means no build step; absent dist/, we own a Vue build against Nova's toolchain and should budget accordingly. Secondary compatibility concerns are on us, not the package: column qualification on joined resources, index coverage on the filtered column, and decimal handling via filter_var(..., FILTER_VALIDATE_FLOAT) rather than relying on driver coercion.
Sequencing. (1) Verify Nova constraint and dist/ status — minutes. (2) Read src/ end to end and confirm the value shape. (3) Vendor/fork into the repo and pin. (4) Write apply() defensively with the three-branch shape (both bounds → whereBetween, min-only → >=, max-only → <=, neither → return builder unmodified) and is_numeric() coercion. (5) Ship unit tests on apply() asserting toSql() shape and results against SQLite; cover both-bounds, min-only, and max-empty. (6) Roll out on one low-risk resource with production-like data volume and inspect the generated SQL and query plan. (7) Only then extend to additional resources, one subclass per range — never two instances of the same filter class on one resource, since Nova keys filter state by class name and they will collide.
Maintenance. The package is small enough that maintenance is a code-reading exercise, not a dependency-management one — but it is maintenance we own regardless, because upstream will not tell us when Nova changes break it. The minimum viable regime: pinned version or vendored fork, one line in the repo README naming the internal owner, and the apply() smoke tests as a regression net across Nova upgrades. Without that, the failure mode is silent — the filter stops applying and users get unfiltered result sets that look authoritative.
Support. Support load is the business case. Every range filter shipped retires a class of "can you pull all orders over X" tickets, and unlike most admin-panel work the payoff shows up in support queue volume rather than a dashboard nobody opens. Worth instrumenting before/after if we want the case to survive a quarterly review. Countervailing support risk: the NULL-invisibility and empty-string behaviors will generate "why am I seeing 4 of 12 orders" tickets unless we decide the orWhereNull policy up front and document it — there is no config flag for either.
Scaling. Two dimensions. Query side: a range filter on an unindexed multi-million-row column is a full scan every time a user touches an input, and the filter fires on interaction, not on submit — confirm index coverage before rollout, not after. Surface side: scaling to many resources and lenses is cheap and mostly mechanical (one subclass per range), but it multiplies the number of places where a Nova upgrade can silently break behavior, so the test suite should grow with the adoption count rather than staying at one smoke test. Composing with other filters also needs a convention: Nova does not deduplicate, so a SelectFilter and a range filter on the same column AND together into contradictory WHERE clauses. Pick the rule (never pair them on one column) rather than debugging it later.
Failure modes. Ranked by likelihood: Nova version drift breaking render or apply silently; empty strings coerced to 0 on MySQL returning nothing ("no results until I type both values"); NULL rows vanishing from result counts; inclusive whereBetween producing off-by-one boundary complaints; ambiguous-column SQL errors on joined resources; date truncation excluding the final day of a range; unindexed full scans degrading the index screen; and upstream abandonment meaning none of the above is ever fixed for us. All are mitigable inside a fork, none are mitigable by waiting on the maintainer.
Ramp-up. Very shallow for anyone fluent in Laravel and Nova — the whole package is readable in an afternoon, and the apply() contract is a handful of query-builder calls. New engineers can be productive on it in under a day, and the unit-test pattern (instantiate the filter, set value, call apply(), assert toSql()) is a reusable template they will apply to every subsequent range filter. The ramp cost is not learning the package; it is learning the four or five defensive habits — numeric coercion, column qualification, inclusive-bound awareness, index verification — that the package does not enforce for you.
How can I help you explore Laravel packages today?