Filament Range Field Laravel Package

Technical Evaluation

Architecture fit yepsua/filament-range-field is a single-purpose UI extension for Filament: a form field that renders a range/slider input and binds to a Livewire model property. Architecturally it slots into the standard Filament extension pattern — a Field subclass plus a Blade view, registered through the panel's form component namespace or auto-discovery. There is no service layer, no database footprint, no queue or event surface. It is a presentation-layer dependency only, which keeps blast radius small: if it fails, one form component fails, not the application.

The fit is good if the target application is already a Filament admin/panel app on the matching major version. It is a poor fit for headless APIs, Inertia/Vue front ends, or Livewire-only apps without Filament — the dependency would pull in Filament scaffolding for a single widget.

Integration feasibility High in the happy path: composer require, optionally publish views, add RangeField::make('weight') to a schema. An engineer familiar with Filament custom fields should complete a spike in half a day.

The gating question remains Filament major version. v0.3.4 is a patch on the existing 0.3.x line and carries no signal of a v4-compatible branch, so the package should still be assumed to constrain to ^3.0. Filament's form component API is internal and has historically broken across majors (schema/component namespaces, state hydration contract, asset registration), so "works on v3" does not imply forward compatibility. The patch release does not change this.

Technical risk

• Abandonment (high, marginally softened). Single maintainer, 36 stars, 0 dependents — but v0.3.4 demonstrates the maintainer still triages and ships fixes. Recalibrate from "no release in ~2 years" to "very low cadence, roughly one patch every year or two, still alive." That is a maintenance signal, not a support signal: there is still no SLA, no security contact, and no changelog discipline. Treat it as unmaintained source you may adopt, with a lower probability of total rot than previously assessed.
• Version lock-in (high, unchanged). Adopting it pins the panel to Filament 3.x or forces a fork at upgrade time. A 0.3.x patch does not move this.
• State semantics (medium, possibly de-risked — verify). Release notes name only "Issue #1" with no description. If that issue was the string-coercion / dehydration defect, this patch may have resolved the most likely data-integrity failure. If it was cosmetic, nothing changed. Read the diff before relying on it. Still verify casts to int/float, min/max/step defaults, nullable handling, and whether dehydrateStateUsing runs.
• Validation surface (medium, unchanged). The browser constrains the handle, but that is not server-side enforcement — min/max/step must be mirrored in Laravel validation rules or the field becomes a validation bypass.
• Accessibility/theming (low-medium). Unknown keyboard support, ARIA labelling, dark mode, and RTL behaviour. A one-issue patch is unlikely to have touched this.

Key questions

1. What Filament and Livewire versions are actually supported — read composer.json constraints, not the README, and confirm the constraint is unchanged in v0.3.4?
2. What exactly was Issue #1, and does the v0.3.3→v0.3.4 diff touch state hydration or type casting? This is the new first-order question; the answer determines whether the data-integrity risk drops.
3. Is state dehydration typed and nullable-safe? Do integer columns round-trip without casting surprises?
4. Are min/max/step enforced anywhere except the browser?
5. Is there a test suite, and does the v0.3.4 change ship with a regression test, or was it a drive-by commit?
6. Does it support a two-handle range, or only a single value? Most "range" packages mean single-thumb.
7. Who owns the fork when Filament 4 lands, and how large is the delta?

Integration Approach

Stack fit Requires Laravel 10/11, PHP 8.1+, Livewire 3, Filament 3.x — re-verify against composer.json at v0.3.4 rather than assuming the patch left constraints alone. Confirm against the application's actual composer.lock before anything else; a mismatch here ends the evaluation.

Migration path

• Greenfield Filament 3 panel: low-friction adoption, but budget for a fork from day one.
• Existing panel on Filament 3: drop-in, isolated to the forms that use it. v0.3.3 → v0.3.4 is a single-issue fix and should be a low-risk in-place bump.
• Filament 4 roadmap or upgrade pending: do not adopt the package. Either vendor the source into app/Filament/Forms/Components under our own namespace, or build the field internally — the implementation is a small Blade partial plus a Field subclass, roughly 1–2 developer days with tests. The v0.3.4 release does not change this recommendation.
• No Filament: out of scope; use a native numeric input.

Compatibility Pin to the exact tag v0.3.4 rather than a floating constraint, and record the resolved version in the dependency decision log. Read the v0.3.3→v0.3.4 diff before bumping — release notes are a single line and give no scope information. Verify asset publishing behaviour — Filament v3 auto-injects component assets via FilamentAsset, so a missing registration shows up as an unstyled native slider rather than an error, which is easy to miss in review.

Sequencing

1. Diff review (0.25 day, new): read the v0.3.4 commit, identify Issue #1, and confirm whether the change touches hydration, casting, or validation defaults. This gates steps 2–3.
2. Spike (0.5 day): install the pinned tag in a scratch branch, render one field, confirm it binds, persists, and rehydrates a typed value.
3. Isolation (0.5 day): wrap usage behind our own App\Filament\Forms\RangeInput that extends or replaces the vendor class, so swapping implementations touches one file.
4. Validation pairing: ship a min/max/step rule set alongside the field so server-side and client-side constraints cannot drift.
5. Rollout: one form, one release cycle, watch for hydration errors before broadening. If v0.3.4 did fix a hydration defect, re-test any previously observed bad values rather than assuming history is clean.
6. Reassessment gate: re-evaluate at the next Filament major; default decision is to internalise.

Operational Impact

Maintenance The dominant cost is still the future fork, not today's install. Budget ~20–40 engineering hours per Filament major to re-home the component, plus a few hours per year of dependency hygiene. Because the codebase is small and MIT-licensed, forking is cheap and legally clean — that materially reduces the risk. The v0.3.4 release is a modest positive: it confirms the upstream is not fully dead, so the odds of being stranded mid-cycle on a broken Filament patch release are slightly lower. The correct mental model is unchanged: "vendored snippet with a Composer convenience wrapper," not "supported library."

Support GitHub issues only; no SLA, no security contact, no changelog discipline. The v0.3.4 notes — one line, "Issues fixed: Issue #1" — are themselves evidence of that. Assume near-zero upstream responsiveness and staff accordingly; the existence of a fix confirms triage happens eventually, not that it happens on our timeline.

Scaling Negligible. The field is client-side markup with Alpine-driven interaction; no server load, no query pattern, no cache implications. Rendering cost is a Blade partial per field instance. The only scaling-adjacent concern is bundle weight if many Filament plugins each publish assets — audit the panel's asset manifest after install.

Failure modes

• Silent render loss: Filament upgrade changes the component contract; the field disappears or renders as an unstyled input with no exception. Mitigate with a smoke test that asserts the component class resolves.
• Data integrity: client-only min/max/step enforcement lets out-of-range values persist via crafted requests. Mitigate with mirrored server-side rules. If the v0.3.4 fix was in this area, re-baseline the risk and add a round-trip regression test rather than relying on the upstream patch.
• Type drift: string values from the DOM written to integer/decimal columns, producing 0 or truncation on some drivers. Mitigate with explicit casts and a round-trip test.
• Upgrade deadlock: the package's Filament constraint blocks a framework upgrade, forcing an emergency fork mid-migration. Mitigate by internalising before the upgrade window opens.
• Scanner false comfort (new): a fresh v0.3.4 publication resets the "last published" clock in several supply-chain and licence scanners, which can mask a one-maintainer, thirty-six-star bus factor. Record the underlying ownership assessment in the dependency decision log so the green badge does not substitute for judgement.

Ramp-up Low. Any Laravel developer with Filament experience can contribute to the field within a day; the whole component is a few hundred lines. The organisational ramp-up is the real cost — establishing that this is our code now, with an owner, a fork point, and a test, rather than a third-party dependency we hope stays healthy. The v0.3.4 release is a reason to keep the dependency one cycle longer; it is not a reason to change that ownership posture.