Filament Range Field Laravel Package

Product Decisions This Supports

• Feature scope triage for admin surfaces. The package answers one narrow question: "can our Filament admin forms accept a bounded numeric input as a slider instead of a text field?" That's a small UI affordance, not an architecture decision — treat it as a scoped feature decision, not a platform bet.
• Build vs. buy (buy, but cheaply). The capability is a thin form component wrapping a native range input plus Filament's field lifecycle (state, validation, dehydration). The realistic alternatives are: (a) adopt this package, (b) write ~100–200 lines of in-house field code, (c) drop the slider and use a numeric input. Because the package is MIT and small, "buy" here costs almost nothing and "build" is not much more — the decision should hinge on maintenance risk, not effort.
• Use cases that justify it. Threshold and range settings in internal tooling: discount/price bands, alert and quota limits, percentage-based scoring or weighting, filter ranges in admin listing pages, feature-flag rollout percentages. These are cases where a slider meaningfully reduces input error versus a free-text number.
• Use cases that don't. Anything customer-facing, anything requiring dual-handle min/max range selection (verify before committing — a single-value slider is the common scope for a package this size), anything needing a numeric input fallback for accessibility or precision entry.
• Roadmap signal, not a roadmap item. 36 stars, zero dependents, and a long dormant period interrupted only by a single patch release (v0.3.4) that fixes one unnamed issue with no compatibility statement. That is useful evidence when someone proposes building a bespoke slider component: demand is demonstrably thin, so scope it as a one-off, not a reusable internal library with a support commitment. It is also useful evidence against treating a one-line patch as a sign of renewed maintenance — cadence and responsiveness are still unproven.
• Dependency policy decision. Adopting it forces a position on third-party Filament plugins with single-maintainer bus factor. This is a good forcing function to write down (or reaffirm) your plugin acceptance criteria.

When to Consider This Package

Consider it when all of the following hold:

• You are on Filament and confirmed there is no first-party range/slider field in your version — verify against your installed major version's docs before evaluating third-party options.
• The field appears in internal/admin-only UI where a degraded experience is tolerable and non-technical users are not the primary audience.
• Your Filament version is pinned and stable, and you are not planning a major Filament upgrade in the near term. The v0.3.4 release notes fix a single issue and say nothing about Filament version support, so assume the package's tested matrix is whatever it was at its last substantive release and test compatibility explicitly on a branch before adopting.
• The value is a single bounded number with a sensible default, and you can pair it with a visible numeric value display for precision.
• You are willing to fork or vendor the code. With 36 stars and zero dependents, assume no upstream support and no security response; a one-issue patch bump does not change that. Budget the fork as the real cost of ownership.

Look elsewhere (or build it yourself) when:

• You are on or migrating to a newer Filament major and compatibility is unverified — a stale dependency blocking an upgrade is a far larger cost than the field saves. The v0.3.4 patch does not resolve this: it is a bug fix, not a compatibility statement.
• You need dual-handle range input, tick labels with custom formatting, or a slider bound to a non-numeric scale. Confirm the package's actual surface area first; scope creep here is likely to exceed the package.
• Accessibility or precision entry is a requirement. Sliders are poor for exact values and keyboard/screen-reader support varies; you need a paired numeric input regardless of package choice.
• The field would ship to end users, or land in a code path with a compliance/audit requirement, where an unmaintained single-maintainer dependency is unacceptable.
• Your team already has a design-system form layer; a one-off field there is cheaper than introducing a plugin, a plugin-review process, and a supply-chain surface.

How to Pitch It (Stakeholders)

For executives: This is a small, free, MIT-licensed UI component that adds a slider input to our Laravel admin forms — the kind of control that makes threshold and percentage settings easier to enter correctly. It is not a strategic dependency: it covers one form field, has a single maintainer, 36 stars, and no downstream users. It recently shipped a patch release (v0.3.4) fixing one reported issue, which is a mildly positive sign but not evidence of active maintenance — the release notes contain no compatibility information and the project has been dormant otherwise. My recommendation is unchanged: a time-boxed trial in internal tooling only, contingent on verifying it works with our Filament version, with an explicit fallback to writing the field ourselves. Worst case we spend a few hours; we should not treat it as a long-term platform commitment or adopt it anywhere customer-facing.

For engineering: Single-purpose Filament form field for bounded numeric range/slider input. Constraints to validate before adoption: (1) compatibility with our current Filament major — v0.3.4 is a one-issue patch fix with no stated version support, so test on a branch; (2) confirm single-value vs. dual-handle behavior matches the product need; (3) accessibility and precision — plan to render the numeric value alongside the slider; (4) no upstream support and no visible review of what Issue #1 changed, so diff the patch and plan to vendor or fork and own the code. If all four check out, adopt for internal admin forms; otherwise implement the field in-house, which is a small, bounded task.