Integer Field Type Laravel Package

Product Decisions This Supports

• Content modeling for a Streams/PyroCMS build. This addon registers an integer field type in the Anomaly Streams Platform, so it directly enables storing and editing whole-number values on CMS entries — quantities, stock counts, ages, sort weights, year values, numeric IDs, and similar attributes.
• Build vs. buy on a commodity field. The decision this really informs is small: adopt a ~1-file MIT addon versus writing a field type against the Streams contract yourself. For a team already inside the ecosystem, "buy" (i.e., composer-require) is almost certainly cheaper than a day of engineering to reimplement.
• Platform standardization. If your roadmap includes multiple Streams-based modules or client sites, adopting the canonical anomaly/*-field_type package keeps your content model consistent with upstream conventions rather than accumulating bespoke field types that become migration liabilities.
• Validation and data-entry scope. Choosing this field type commits you to whole-number semantics at the entry layer. That is a legitimate product decision (integer vs. decimal vs. string), and it should be made explicitly so that pricing, measurements, or currency values don't land in the wrong type and force a later data migration.
• Ecosystem viability checkpoint. With zero stars, zero dependents, and a low composite score, this package is not a signal of anything — it is a symptom. It should trigger a broader roadmap question: is the underlying Anomaly/PyroCMS/Streams platform still a supported bet for us, or are we accruing maintenance debt on a dormant dependency tree?

When to Consider This Package

Consider it when:

• You are already running PyroCMS 3.x or the Anomaly Streams Platform and need an integer field on one or more streams. This is the intended and only sensible use case.
• You want the field to render through the platform's standard form builder and respect its field-type contract (assignment, form input, presentation, validation) rather than bolting a text field with regex onto your content model.
• You have a small number of integer attributes and want the lowest-effort path to correct typing, sorting, and filtering.
• You are comfortable pinning the version in composer.json and, because upstream is effectively unmaintained, forking or vendoring if you need a change.

Look elsewhere when:

• You are on modern Laravel without Streams — this package has no meaning outside that platform. Use native migrations, casts, and a form library (Filament, Nova, Livewire) instead.
• Your value needs decimals, currency, or arbitrary precision. Use a decimal/float field type or a money library; integers will silently truncate or misrepresent.
• You need values beyond PHP's integer range (large external IDs, hashes, snowflakes) — use a string field or a dedicated identifier type.
• You require active maintenance, security response SLAs, or vendor support. Zero stars, zero dependents, and a dormant parent project mean the bus factor is one and the code is frozen. Treat it as "freeze-and-fork" software, not as a supported dependency.
• You are evaluating whether to adopt PyroCMS/Streams at all. This package is trivia; the platform decision dominates. Do not let a convenient field type pull you onto an unmaintained CMS.

How to Pitch It (Stakeholders)

For executives (one paragraph): We can add proper whole-number fields to our CMS content model with a free, MIT-licensed addon instead of custom development — roughly zero cost and zero licensing exposure. The important caveat is not about this package but about its ecosystem: it has no community traction, no dependents, and sits on the Anomaly/PyroCMS Streams Platform, which is no longer actively developed. Adopting it is a two-hour, low-risk tactical decision; the strategic decision worth their attention is whether we continue building on that platform at all.

For engineering leads: It's a thin field-type implementation against the Streams Platform contract — composer-require it, pin the version, and expect no upstream fixes. Budget a fallback plan: if we need min/max validation, formatting, or a bug fix, we fork it into our own namespace. Prefer it over a hand-rolled field type for consistency, but do not let it become an undeclared dependency in code that outlives the CMS.

For product/design: Whole-number entry becomes available on any Streams-based content type, which unblocks quantity-, count-, and year-style attributes and makes them sortable and filterable in the admin. It does not solve currency, measurements, or identifiers — flag those as separate type requirements so we don't discover a data-modeling mistake after content has been entered.