Integer Field Type Laravel Package

Product Decisions This Supports

• Build vs. buy for admin/form primitives. This package is a single field type in the Streams Platform (PyroCMS/OpenClassify) addon ecosystem. The real decision it informs is not "should we use this package" but "do we standardize on Streams field types as our form/admin layer, or build our own input primitives?" Adopting it signals we're buying into that ecosystem for CMS-style admin surfaces.
• Data model / schema choices for numeric attributes. If your roadmap includes fields that must be whole numbers — inventory counts, seat quantities, stock thresholds, age gates, tier levels, points/credits, rating scales — an integer field type is a schema-level decision. Choosing typed integer storage over a generic string/varchar field affects validation, indexing, sorting, and reporting downstream.
• Validation and data-integrity posture. Constraining a field to integers at the form layer prevents bad data entry (decimals, text, negatives where disallowed) before it hits the database. This is a product-quality decision that reduces support burden and cleanup work in reporting.
• Localization / input ergonomics for non-technical editors. A dedicated integer control beats a free-text box in CMS admin UX. Relevant if your roadmap includes self-serve content ops, classifieds listings (OpenClassify's domain: price, quantity, mileage, year), or marketplace seller tooling.
• Roadmap sequencing for admin tooling. If you're shipping a CMS or classifieds product on Streams, field types are table stakes infrastructure, not features. This package represents the "small, composable addon" path versus building a monolithic admin panel.
• Vendor/fork risk register. 0 stars, 0 dependents, last release March 2020. Treating this as a maintained upstream is not a defensible decision; the realistic options are fork-and-own, vendor-and-freeze, or reimplement.
• Ecosystem bet. A dependency in the Visiosoft/OpenClassify orbit implies your platform choice is already made. This package is a data point on whether the Streams addon ecosystem has enough first-party and community coverage to support your product without you writing every primitive yourself.

When to Consider This Package

Consider it if:

• You are already running the Streams Platform (PyroCMS, OpenClassify, or a Visiosoft-built product). Outside that runtime this package does nothing for you — it is an addon, not a standalone Laravel validation or form library.
• You need a basic whole-number input for an admin/editor form and want to avoid writing a field type class from scratch.
• You are comfortable vendoring or forking the code. At ~0 stars, 0 dependents, and a last release in March 2020, you should assume upstream is dormant. MIT licensing makes forking frictionless, which is the only reason this is viable.
• The requirement is genuinely narrow — an integer input with standard validation. If that's all you need, the fork cost is hours, not weeks.
• You want a reference implementation for how Streams field types are structured, even if you ultimately write your own.

Look elsewhere if:

• You are not on Streams/PyroCMS. Use Livewire/Inertia/Filament, Laravel's native validation (integer, min, max, digits_between), or a maintained form library. Those give you integer handling plus active maintenance, docs, and community.
• You need anything beyond "an integer": decimal/money types, units, ranges, currency formatting, locale-aware number input, masked input, step controls, or numeric validation tied to business rules. This package won't cover it, and the ecosystem around it is thin.
• Maintenance guarantees or security responsiveness are procurement requirements. A six-year-old unreleased-from-since package with no dependents fails almost any dependency policy — no CVEs found is not the same as actively reviewed.
• You are evaluating maturity signals. Zero stars and zero dependents mean no production feedback, no issue history to learn from, and no one else hitting the edge cases for you.
• You want community support or hiring leverage. Nobody on your team will have seen this package before; onboarding cost is unbounded by documentation quality.
• Your product needs accessibility, i18n, or mobile keyboard hints out of the box. A field type this small is unlikely to carry them, and you'd be adding them yourself anyway.

How to Pitch It (Stakeholders)

To executives: This is a very small, free (MIT) building block that adds a validated whole-number input to our admin/CMS forms — the kind of field you need for quantities, inventory, pricing tiers, or scores. It is not a strategic platform; it is one primitive. The honest framing: it saves us perhaps a day of engineering relative to writing the field ourselves, and it carries near-zero vendor lock-in because we can fork it freely. It should be presented as a tactical convenience, not an architecture investment, and budgeted accordingly.

To engineering: It's a Streams Platform field type addon. It does one thing — integer input — and it hasn't been released since March 2020, with no visible dependents. Recommendation: treat it as forked source, not an upstream dependency. Vendor the code into our repo, pin it, and accept ownership. Review it line-by-line (it's small enough), add any validation we need (min, max, nullable, step behavior), and add tests around the field type registration and rendering. Do not add it to our dependency-update pipeline expecting upstream fixes; add it to our fork register instead. If we want a maintained alternative, the real question is whether Streams field types are our long-term admin surface — and that's a platform decision worth a separate review.

To the product/design side: The user-facing benefit is small but real: editors get a number-only input with validation instead of a free-text box, which means fewer bad records and less cleanup in reporting. It sets no product direction on its own. The caveat is that integer-only is genuinely integer-only — if we later need decimals, currency, units, or ranges, this becomes a different, larger requirement, and we should not assume this package grows with us.

Bottom line: Low-cost, low-risk, low-ceiling. Adopt as a vendored primitive inside an existing Streams/OpenClassify stack; reject as a dependency anywhere else.