Nova Range Input Filter Laravel Package

Technical Evaluation

Architecture fit

• The package occupies a narrow, well-defined extension point: Laravel Nova's filter system (Laravel\Nova\Filters\Filter subclasses registered via a resource's filters() method). It adds no models, migrations, service providers with side effects, or middleware — so architectural coupling is minimal.
• Fit is conditional on already running Laravel Nova. Nova is a paid, per-site licensed product; this package has zero standalone value outside a Nova installation, so the true cost of adoption includes Nova license overhead and upgrade cadence.
• A min/max range filter is a genuinely small piece of functionality (one PHP filter class plus one Vue component). The build-vs-buy calculus is therefore unusual: in-house implementation is plausibly 0.5–1.5 dev days.

Integration feasibility

• Mechanical: composer require juniora/nova-range-input-filter, add the class to filters(), publish/recompile Nova assets if the Vue component is not prebuilt.
• Blast radius is small and reversible — the filter only affects the index query for resources where it is explicitly registered.
• Real feasibility risk sits in version compatibility (Nova 4 vs 5, PHP 8.x) and in whether the shipped frontend assets were compiled against the Nova version we run.

Technical risk

• Injection surface (highest severity). Filter values arrive as JSON in the filters query-string parameter and are passed into apply(Request $request, $query, $value). If the implementation interpolates min/max into whereRaw rather than using bound parameters or whereBetween, crafted URLs yield SQL injection on an admin surface. Must be code-reviewed before any deployment.
• Frontend coupling. Custom Nova filter components depend on Nova's internal Vue mixins/component API. Nova minor upgrades have historically broken third-party field/filter components silently (blank UI rather than an exception).
• Adoption signal is zero. 0 stars, 0 dependents, single-org maintainer (JunioraTeam), no evidence of CI, test suite, security policy, or issue triage. This is the dominant risk, not the code.
• Driver semantics. whereBetween behaves differently across MySQL/Postgres/SQLite for dates and for numeric columns stored as strings; behavior with an open-ended range (only min, or only max) is unverified.
• License is MIT — permissive and fork-friendly, which materially de-risks the maintenance concern.

Key questions

1. Which Nova major/minor versions and PHP versions are declared in composer.json? What does composer why-not say against our pinned Nova?
2. Does apply() use parameter binding, or string interpolation into whereRaw?
3. Are frontend assets precompiled and committed, or must we run a Node build against Nova's toolchain?
4. How are one-sided ranges (min only / max only) and inverted ranges (min > max) handled — validation, silent no-op, or 500?
5. Is this a fork of a more established filter package, and is there any test coverage at all?
6. Does it apply to date columns as well as numeric, and is the comparison inclusive/exclusive?

Integration Approach

Stack fit

• Assumes Laravel 10/11 + Nova 4/5 + PHP 8.1+. Confirm the constraint matrix before anything else; if the package predates our Nova version, stop here.
• No database or infrastructure prerequisites beyond an index on whichever column the range filter targets.

Migration path

• Purely additive. There is no data migration and no state to backfill.
• Adopt incrementally: register the filter on one low-traffic resource first, validate behavior in staging against real data volumes, then roll to additional resources.
• Rollback is a one-line removal from the filters() array plus an asset republish; no user data is affected. Users with bookmarked URLs containing the filter param will simply see it ignored.

Compatibility

• Pin an exact version (no caret range) and mirror it in composer.lock. Third-party Nova extensions have a habit of breaking on Nova minor bumps; an unpinned constraint will surface that breakage during unrelated deploys.
• Include Nova in the upgrade test matrix: any Nova upgrade should trigger a smoke test of every registered custom filter.

Sequencing

1. Confirm Nova/PHP constraint compatibility (0.25 day).
2. Static read of apply() and the Vue component for binding and validation (0.5 day) — gate for security sign-off.
3. Staging spike on one resource with production-shaped data (0.5 day).
4. Decision gate: adopt as dependency vs. vendor/fork into an internal namespace vs. build in-house.
5. If adopted, publish assets through the standard deploy pipeline and add a regression test asserting the filter produces a bounded query.

Recommendation on path: given zero community validation and the small scope, the defensible options are (a) build a ~60-line internal filter and own it outright, or (b) fork this repo into an internal namespace and treat it as first-party code. Consuming it as an unpinned third-party dependency is the weakest of the three.

Operational Impact

Maintenance

• Effectively no upstream maintenance guarantee: one maintainer org, one release (Dec 2024), no visible release cadence. Assume we own the code the day we adopt it.
• MIT license makes forking frictionless; budget ~0.25 day to vendor it and wire autoloading, versus an indefinite tail of "will this break on the next Nova upgrade" risk.
• No CVE monitoring path exists for a package with zero dependents — it will not appear in typical dependency-scanning advisory feeds. Internal review is the only control.

Support

• No commercial support, no SLA, no documented escalation. Issue response is best-effort and unmeasurable.
• Internal support burden is low but non-zero: whoever writes the filter should document intended semantics (inclusivity, one-sided ranges, column types) in the repo, since the upstream docs likely won't.

Scaling

• The filter executes on each resource index request. On large tables, a whereBetween against an unindexed column becomes a full table scan and will degrade the admin panel precisely when datasets grow.
• Mitigation: only register on resources where the target column is indexed; verify with EXPLAIN on production-shaped data during the spike.
• No caching, queueing, or external service dependency — scaling profile is entirely inherited from the underlying query.

Failure modes

The last two are the ones that justify gating adoption on review rather than shipping on the strength of "it's a small filter."

Ramp-up

• Trivial: any Laravel developer productive in under half a day. Nova filter conventions are well documented, and the surface is one class plus one component.
• The real ramp-up cost is not learning the package but taking ownership of it — reading unfamiliar Vue/Nova internals to patch a component six months from now with no upstream fix available.