huuloc4193/nova-range-input-filter
A Laravel Nova filter that adds range input controls to resource indexes, letting users filter records by numeric minimum and maximum values. Register it with your Nova filters to provide fast, intuitive range-based filtering without writing custom filter logic.
Architecture fit. This package is a Laravel Nova extension (tool/card/field/resource layer), not core application logic. Release 2.0 explicitly targets Nova 5, which pins the surrounding stack to Laravel 10/11 and PHP 8.1+. Fit is clean only if our admin layer is already on, or moving to, Nova 5; on Nova 4 or earlier this release is a hard no. Because the package sits in the presentation/admin tier, adopting it does not reshape domain architecture — the decision is really a Nova-version decision.
Integration feasibility. Requires a valid Nova 5 license and installation, Laravel 10/11, PHP 8.1+ (8.2/8.3 preferred), and a Composer constraint bump to ^2.0. The real feasibility question is the surrounding Nova ecosystem: Nova 5 moved its front-end asset pipeline to Vite, so every other Nova tool, card, and field in the admin panel must also be Nova 5-compatible. Any published views, config, or custom Nova components from v1 need review and likely republication.
Technical risk. Breaking by definition: a major version whose sole stated change is a Nova major alignment means Nova 4 support is dropped. Blast radius is confined to the admin UI and internal users, not customer-facing runtime — that materially lowers severity. Residual risks: silent asset/JS breakage from the Vite migration, dependency dead-ends if other admin packages lag Nova 5, and the Nova license cost/seat implications of the upgrade.
Key questions. Which Nova version is in production today, and is there a funded owner for a Nova 5 upgrade? Does 2.0 include any non-Nova changes (renamed classes, namespace moves, config key changes, dropped methods) that the one-line release note does not disclose? Does the package ship publishable assets/views/config that must be republished? Which other Nova extensions block 5.x? Is a Nova 4 branch maintained for security fixes during our transition window? What is the maintainer's release cadence and issue responsiveness?
Stack fit. Target Laravel 10/11, PHP 8.1+, Nova 5. Confirm platform requirements and align the CI matrix before touching application code.
Migration path. Upgrade Nova first (4 → 5 per Laravel's Nova upgrade guide), then bump this package to ^2.0. Do not attempt in place on production. Working sequence: feature branch → dependency audit (composer outdated, composer why-not) → staging install → republish assets/views/config → smoke test every surface this package renders.
Compatibility. Inventory all Nova extensions and mark each as Nova 5-ready, blocked, or replaceable. A single laggard blocks the whole upgrade; decide early whether to wait or substitute. Verify Node/Vite toolchain availability for rebuilding any custom Nova assets.
Sequencing. (1) Extension inventory and Nova 5 readiness matrix; (2) Nova 5 upgrade on staging; (3) this package to 2.0; (4) regression pass on admin workflows; (5) internal-admin pilot; (6) production rollout in a maintenance window. Retain the Nova 4 branch and the prior package constraint until the upgrade has baked, so rollback is a single coordinated revert.
Maintenance. Expect lockstep major bumps with each Nova major — this is a recurring upgrade tax, not a one-off. Pin Composer constraints, subscribe to upstream releases, and budget Nova-cycle upgrade work explicitly.
Support. A one-line changelog ("upgrade nova V5") signals thin release documentation; assume we will read the diff and source rather than release notes. Validate maintainer activity and issue-response history before committing — a small package tracking a fast-moving framework major can go stale quickly.
Scaling. No meaningful scaling surface: admin-only, low concurrency. Any scaling concern belongs to the Nova application itself, not this package.
Failure modes. Blank or broken tool panels, missing compiled assets, JS console errors post-Vite migration, class-not-found after namespace changes, config key drift, and stale published views shadowing v2 views. The coupling of package and Nova versions widens rollback scope — reverting one requires reverting both.
Ramp-up. Low for end users (UI is broadly unchanged); moderate for engineers unfamiliar with Nova 5's asset pipeline. Fund a short spike to validate the package and its peer extensions on staging before committing to an upgrade window.
How can I help you explore Laravel packages today?