Slider Field Type Laravel Package

Product Decisions This Supports

• Numeric-range inputs in a CMS admin UI: the package registers a slider field type for the Streams Platform (the data layer behind PyroCMS 3.x), letting editors pick a bounded numeric value with a range control instead of typing a raw number. Relevant for settings like opacity, column widths, spacing, discount percentages, rating thresholds, or confidence levels.
• Build vs. buy for a bounded numeric field: the honest answer here is build. This is a few-dozen-line field type — one class extending the field type base, one view partial, a config array for min/max/step. The buy case rests entirely on already being inside a Streams-based product where installing an addon is cheaper than writing one.
• Validation-by-UI decisions: if your roadmap includes "reduce bad data entry from free-text numeric fields," a slider is a UX-level constraint (bounded, stepped) rather than a validation rule. Worth weighing against simply adding min/max server-side validation to an existing number field — cheaper, no new dependency.
• Platform commitment signal: adopting this only makes sense as part of a broader "we are standardizing on Streams/PyroCMS for admin tooling" decision. It should never be the trigger for that decision.
• Roadmap risk register: with 1 star, 0 dependents, and an overall score of 0.245, this belongs on the "known unmaintained dependency" list if adopted — plan for a fork rather than upstream fixes.

When to Consider This Package

Consider it only when all of the following hold:

• You are already running PyroCMS 3.x / the Streams Platform and adding field types via Composer is your normal workflow.
• You need a bounded numeric input in an admin form and want to avoid writing custom Streams field-type boilerplate (the base class, the getView()/getConfig() wiring, the language file).
• You are comfortable vendoring or forking it. The MIT license permits this; the star count says nobody else will.

Look elsewhere — or write ten lines of Blade plus a type="range" input — when:

• You are not on Streams/PyroCMS. This package has zero utility outside that ecosystem; it is not a general Laravel form component.
• You need maintained dependencies. Anomaly Labs' CMS line is effectively dormant; a single-star, zero-dependent addon is a supply-chain liability with no community backstop.
• You need accessibility, keyboard semantics, live value display, or non-linear scales. A bare range input is a weak accessibility story (aria-valuetext, focus styling, touch targets) and you'll be doing that work yourself anyway.
• You need a rich slider (dual-handle ranges, tick labels, formatted values). Reach for a maintained front-end component instead.
• Your use case is a one-off. The integration cost exceeds the implementation cost.

How to Pitch It (Stakeholders)

For executives: "This is a small, free, MIT-licensed UI addon for our CMS admin — it turns a number field into a bounded slider so editors can't enter out-of-range values. It's only usable if we stay on our current CMS platform, and it has essentially no community around it, so treat it as code we adopt and own rather than a vendor product. Recommendation: reuse only if we're already committed to the platform; otherwise a native input with validation gets us 90% of the benefit at zero dependency cost."

For engineering: "A Streams Platform field type that renders a range input for numeric fields, with min/max/step config. One star, zero dependents, no upstream maintenance signal — assume we fork it. The entire value is the Streams boilerplate it saves us, roughly an afternoon. Outside a Streams codebase it's inert. If we adopt, pin the version, vendor it, and add it to the dependency-review list; if we don't, implement the equivalent directly and keep the accessibility work in our own hands."