Integer Field Type Laravel Package

Technical Evaluation

What this is: anomaly/integer-field_type is a single-purpose addon for the Streams Platform (the Laravel-based engine behind PyroCMS 3.x, maintained by Anomaly Labs). It registers an integer field type into Streams' field type registry so that stream fields, form builders, and data grids can be declared as integers. It is not a general-purpose Laravel package — it has no standalone value outside a Streams installation.

Architecture fit:

• Fits cleanly only if the host application already runs Streams (or PyroCMS 3) and uses its stream/field abstraction for content modeling.
• Implementation surface is small and idiomatic: a service provider that registers the field type binding, plus a field type class exposing input/validation/output behavior and, typically, a migration stub and language files.
• In a non-Streams Laravel app, adopting this package would mean adopting Streams itself — a platform-level commitment far larger than the field type's benefit.

Integration feasibility:

• Mechanically trivial in an existing Streams app: composer install, service provider auto-discovery, field type appears in the admin field picker.
• Blocked in every other scenario: no meaningful integration path exists without Streams as a dependency.
• Composer resolution will be the real work — the addon's version constraints must line up with the Streams core version and the underlying Laravel/Illuminate major.

Technical risk:

• Ecosystem risk dominates. 0 stars, 0 dependents, composite score 0.27 indicates essentially no external validation, no downstream users to surface regressions, and no community patch flow.
• Maintenance risk. Bus factor is effectively the upstream maintainer team; a single-purpose field type is unlikely to receive priority attention.
• Abandonment risk. Streams/PyroCMS itself occupies a narrow niche; the addon's useful life is bounded by the platform's.
• Low code risk. The payload is small and the logic is straightforward — an integer field type is near-primitive. Forking or reimplementing is cheap.
• Opportunity score of 33.24 reads as whitespace in a category that may simply not have demand, not as unmet need.

Key questions:

1. Are we, or will we be, running Streams/PyroCMS 3? If no, this evaluation ends here.
2. If yes: does the Streams core already ship an integer field type, making this redundant?
3. What Streams core and Laravel versions are we pinned to, and does this addon's constraint set resolve against them?
4. Is upstream actively releasing, or is the pinned commit the terminal state?
5. Would a 150-line in-house field type — fully owned, no external constraint — be cheaper over a 3-year horizon than a dependency with zero dependents?
6. Who on the team owns Streams-specific knowledge today, and is that knowledge transferable?

Integration Approach

Stack fit:

• Target stack must be PHP + Laravel + Streams Platform. Everything else is a non-fit.
• Complements, not replaces: pairs with other anomaly.field_type.* addons (text, boolean, select, etc.) that together define the content model vocabulary.
• Conceptually overlaps with core scalar handling — confirm whether Streams core already provides numeric handling before adding a dependency for one primitive.

Migration path:

• Greenfield on Streams: composer require, verify auto-discovery, confirm the type renders in the field picker and persists through migrations. Under a day.
• Brownfield non-Streams: do not migrate the app to Streams for this. If integer typing is needed, implement it natively in the existing model layer.
• Exit path: if upstream goes dark, vendor the package into the repo (path repository or a fork) and treat it as first-party code. Given the size, this is the realistic long-term posture.

Compatibility:

• Version-lock the addon alongside anomaly/streams-platform in the same composer constraint — they must move together.
• Validate against the actual Laravel major in use; Anomaly addons have historically lagged Illuminate releases.
• Test the admin UI path (field picker, form render, list/grid column) — breakage here is often presentation-layer, not data-layer.

Sequencing:

1. Confirm Streams dependency and core-version pin (blocking gate).
2. Check for a core-provided integer type — if present, stop.
3. Sandbox spike: install, render, persist, validate a 2–3 field stream end to end.
4. Decide dependency vs. fork vs. reimplement on the spike result.
5. If adopted, add a smoke test in CI that asserts the field type registers and round-trips a value — this is the only regression net you'll have.

Operational Impact

Maintenance:

• Near-zero ongoing code maintenance in steady state; the cost is in tracking — monitoring upstream for compatibility-relevant releases against Streams core.
• Expect to absorb maintenance yourself eventually. Budget for periodic vendor refresh or a one-time fork.
• Add a dependency-health check to the quarterly review; a package with zero dependents will not announce its own decay.

Support:

• Self-support only. No community forum depth, no issue-tracker throughput to rely on.
• Internal documentation burden is real: the Streams field/stream/assignment model is the actual onboarding barrier, not this package.
• Escalation path for bugs is "patch the fork" — assign an owner up front.

Scaling:

• Runtime cost is negligible; an integer field type adds no meaningful overhead at request or query time.
• Scaling constraints sit in Streams itself (entry storage, EAV-style query patterns), not in this addon.
• No horizontal-scaling concerns attributable to the package.

Failure modes:

• Silent registration failure after a core upgrade — field type disappears from the picker; content editing breaks with no error surfaced.
• Version drift between addon and Streams core causing composer conflicts or class-not-found at boot.
• Schema/migration mismatch — field type expects an integer column where an existing string column lives; data coercion issues on legacy entries.
• Admin UI regression on a Laravel or Streams minor bump; data intact, editing broken.
• Upstream disappearance — repository archived, leaving no patch source.

Ramp-up:

• For a developer already fluent in Laravel: half a day to understand the addon, one to two weeks to become productive in Streams' content-model concepts.
• For a team without Streams exposure: the field type is the easy part; the platform mental model is the actual cost, and it is a niche skill with limited external hiring pool.
• Recommend one designated owner; spreading a zero-dependents package across a team diffuses accountability without reducing risk.

TPM recommendation: Treat this as a conditional, low-leverage dependency. Adopt only inside an existing Streams/PyroCMS footprint, and even then prefer a vendored fork or a small in-house equivalent so ownership and lifecycle sit with the team. Do not introduce Streams to gain this package.