Integer Field Type Laravel Package

Technical Evaluation

What this package actually is. visiosoft/integer-field_type is an addon for the PyroCMS Streams Platform (anomaly/streams-platform), the addon framework underneath Visiosoft's OpenClassify classifieds product. It contributes an IntegerFieldType class — a FieldType subclass that declares a form input view, a validation/persistence hint (integer), and little else. Expect the entire code surface to be one or two classes plus a Blade partial rendering <input type="number">. It is a leaf node in the Streams addon graph, not a standalone Laravel library.

Architecture fit. Fit is binary, and narrow:

The architectural value is therefore informational: it documents the canonical shape of a Streams field type and the conventions (service provider registration, namespace, view namespace, column type declaration) we would mirror if we were building our own field types into OpenClassify.

Integration feasibility. Composer-only: composer require visiosoft/integer-field_type. Feasibility hinges on resolution rather than on code quality — the package's composer.json will carry a PHP 7.x constraint and a Streams ~1.x constraint with no modern equivalent. On PHP 8.1+ / Laravel 9+, expect composer update to fail or to force a downgrade cascade across the Streams dependency tree. There is no CI badge, no test directory evidence, and the Packagist name (visiosoft/...) diverges from the repository owner (openclassify/...), so we must confirm the published artifact matches the repo before pinning.

Technical risk. Rate as high probability, low blast radius:

• Abandonment — last release 2020-03-16; five-plus years without a commit. No security surface worth worrying about, but no PHP 8 or Streams 2.x support either.
• Bus factor 1 → 0 — 0 stars, 0 dependents, 0 forks implies nobody is exercising it. Any defect we find, we fix.
• Opacity — with no documentation, the contract is whatever the source says. We must read it, not assume it.
• Low remediation cost — the compensating control is that the code is trivially replaceable. A 150-line MIT addon is a fork-and-vendor decision, not an architecture decision.

Key questions to resolve before any decision.

1. Do we actually run a Streams/OpenClassify estate, or is this being evaluated for a non-Streams Laravel app? If the latter, close the evaluation.
2. What does the addon add over a plain integer field — min/max, step, nullable handling, formatted display, filtering/sorting in the Streams query layer? If the answer is "nothing," its only value is as a reference implementation.
3. What are the php and anomaly/streams-platform constraints in composer.json, and does the release tag resolve against our locked Streams version?
4. Is the Packagist artifact visiosoft/integer-field_type byte-identical to openclassify/integer-field_type at the 2020 tag? Verify by commit hash.
5. Does it handle null vs. zero, and integer overflow/PHP_INT_MAX on 32-bit and 64-bit targets? These are the classic failure points of naive integer field types.

Integration Approach

Stack fit. Only pursue if the target application is PyroCMS 3.x / OpenClassify on the Streams Platform with a PHP 7.x runtime. In that case it slots in as a registered addon with no schema migration of its own — the field type is selected per Stream field and the column type is handled by Streams' field migration. In any other stack, treat it as a reference pattern, not a dependency, and cite it in the design doc for our own equivalent.

Migration path. Two viable routes, ranked:

1. Vendor, don't depend (preferred). Copy the class and view into our own addon namespace under a maintained vendor prefix, keep the MIT notice, and add tests. This eliminates the abandoned transitive dependency, gives us PHP 8 compatibility, and preserves the addon's behaviour exactly. Cost: hours, not days.
2. Depend and pin (only if we already ship OpenClassify). composer require visiosoft/integer-field_type:^1.0 with an exact lock, then verify resolution in a throwaway branch before it touches the mainline. Accept that any future Streams upgrade may require us to fork in place.

Do not fork to a new public package. There is no audience at 0 stars, and publishing creates a maintenance obligation we will not staff.

Compatibility. Confirm three axes explicitly: PHP version (expect 7.1–7.4), Streams Platform major (expect ~1.x), and Laravel major implied by that Streams release (expect 5.5–6.x). If our runtime has moved past any of these, option 1 is the only route — a composer require on an unsupported combination will either fail or silently pull an incompatible Streams tree.

Sequencing.

1. Clone and read the full source; record LOC, class list, view files, and the exact composer.json constraints. (1 hour)
2. Diff the Packagist artifact against the repo tag. (30 min)
3. Decide build-vs-buy with the key questions above answered. (Product)
4. If Streams host: vendor into an internal addon, add a test asserting integer persistence, null acceptance, and overflow rejection. (1–2 days)
5. If not Streams host: close the evaluation and write up the field-type pattern as internal guidance. (half day)

Operational Impact

Maintenance. Effectively zero upstream maintenance, so all maintenance transfers to us at adoption. Positively, the code is small and stable — integer fields are a solved problem, so the absence of commits is closer to "finished" than "rotten." Budget a recurring line item only for the fork: keep it in our addon repo, pin nothing externally, and revisit if the host Streams major changes.

Support. No upstream support channel. Issue and PR response is unlikely. Internal support burden is low but non-zero: any developer who sees integer in composer.json will assume an external owner exists. Mitigate by annotating the dependency in our ADR and README so nobody wastes a cycle filing upstream.

Scaling. Runtime cost is negligible — a field type is resolved during form/render and persistence, not on hot paths, and adds no queries, no middleware, and no boot-time work beyond the addon registrar. The scaling risk is organisational, not technical: addon count in a Streams estate grows superlinearly in upgrade cost, and every unmaintained addon raises the price of the eventual framework upgrade. This package makes a Streams upgrade marginally harder, never an application slower.

Failure modes. Ranked by likelihood:

• Composer resolution failure on PHP 8 / Laravel 9+ — the most probable outcome of a naive require.
• Contract drift — a future Streams release changes the FieldType abstract or the field migration API; our vendored copy breaks at boot rather than at render, which is the good case.
• Semantic gaps — null coerced to 0, silent truncation on overflow, locale-decimal input rejected, negative values accepted where the domain forbids them. These fail quietly in production data, which is the expensive case.
• Supply chain — an unmaintained package with 0 stars is a plausible typosquat target; verify the artifact hash at install time.
• Namespace collision if we ever run both the public package and our vendored fork.

Ramp-up. Low for any Laravel developer: the class is short and idiomatic. The actual learning curve is Streams addon conventions — service provider boot order, view namespaces, field type registration, and the difference between field type and field migration. Estimate one to two days for a competent Laravel engineer to be productive in this addon space, and under a week to be confident enough to author and maintain our own field types. That ramp-up is a reusable team asset independent of whether we adopt this specific package, which is the strongest argument for running the evaluation even at a score of 0 stars.