Filament Slider Input Field Laravel Package

Product Decisions This Supports

• Form UX for numeric range inputs in admin panels. Filament forms are where back-office configuration lives; sliders are the right control for bounded, exploratory numerics (discount %, score weights, price bands, alert thresholds, opacity, radius, pagination size). This package buys you that control without a custom field build.
• Build vs. buy for a micro-capability. The realistic "build" alternative is roughly 50–150 lines of Blade + Alpine.js around noUiSlider, plus Livewire state binding and validation wiring. That is a one-to-two-day task for a Filament-fluent engineer, including tests. This package is only worth adopting if it saves that build and you accept pinning it.
• Scope containment on internal tooling. It is a legitimate choice for internal admin tools where a slider is a nice-to-have and the cost of a stalled dependency is "we swap the field" rather than "customer-facing outage."
• Roadmap signal, not a platform bet. At 18 stars, zero dependents, and a v0.0.6 release whose entire changelog is "upgraded for compatibility with Filament v3," this is a single-maintainer package in maintenance mode. The 0.0.x version line is itself an honest signal: the maintainer has not declared a stable API. Treat it as a reference implementation or a vendored snippet, not an internal standard.
• Licensing. MIT removes legal friction and permits forking into your own namespace — which is the decision I'd actually recommend if you adopt it.

When to Consider This Package

Adopt (with conditions) when all of the following hold:

• You are on Filament v3. The v0.0.6 release now states this explicitly, which is an improvement over inferring it from the release date — but it also means v0.0.6 is the floor, not a nice-to-have; any earlier 0.0.x tag predates the stated compatibility. Filament's asset and field APIs move between majors, and a field wrapper written for v3 is the most likely thing to break on v4.
• The slider is non-critical UI sugar: the underlying numeric input is validatable and correct even if the JavaScript fails to load.
• You are willing to pin the exact version, vendor or fork the field into app/Filament/Fields, and own it. Budget a few hours per Filament major upgrade.
• Your team has at least one person comfortable reading a Filament custom field's resources/views and asset registration.

Look elsewhere or build in-house when:

• You need two-handle range (min/max) with server-side validation that the pair is ordered — verify the package exposes this. The v0.0.6 release note is a compatibility bump only and answers none of the open capability questions; assume nothing about range support until you read the field source.
• Accessibility or automated browser tests are requirements. Slider widgets are notoriously hard to make WCAG-conformant (keyboard, ARIA role="slider", value announcements). A compatibility-only release is evidence that no accessibility work has landed, and noUiSlider's accessibility story is only as good as its configuration.
• You need a support expectation — commercial product, SLA, security review, or an answerable "who fixes this in 18 months."
• You want ecosystem proof: zero dependents means no one else has stress-tested it against your Filament version. A compatibility commit published to clear a version gate is not the same as the ecosystem validating it.

How to Pitch It (Stakeholders)

To executives: This is a tiny, MIT-licensed UI component that adds slider controls to our Filament admin forms. Cost is effectively zero and it is reversible — the worst case is that we replace one form field. It is not a platform dependency. The most recent release (v0.0.6) is a one-line compatibility fix for Filament v3, not a feature investment; it still has one maintainer, zero downstream users, and sits on a 0.0.x version line. I recommend we either skip it and spend a day building the field ourselves, or adopt it pinned and vendored with a named internal owner. Do not add it to architecture or vendor-risk registers as anything more than low-tier.

To engineering: It is a thin noUiSlider wrapper for Filament form fields. v0.0.6 confirms Filament v3 compatibility — take that version as the minimum and inspect the diff rather than trusting the note, since it is the only stated compatibility commit. Before adoption, check the field's validation and Livewire binding behavior, and confirm whether it supports a two-handle range before you design a form around it. If we proceed: pin the version, fork it into our namespace so upgrades are ours to control, ensure a plain numeric input remains the source of truth so the form degrades gracefully, and write one browser test for keyboard interaction. If those conditions are unattractive, copy the approach and write the field in-house — the surface area is small enough that a fork is cheaper than the dependency risk.