Decimal Field Type Laravel Package

Technical Evaluation

Architecture fit. This is not a general-purpose Laravel package — it is a Streams Platform field type addon, and its value is entirely contingent on running OpenClassify (the PyroCMS/Streams fork). It plugs into the FieldType abstraction so that a decimal field can be assigned to a Stream, rendered in the admin control panel form builder, persisted to an entry column, and rehydrated on read. If our application is Streams-driven, the fit is clean and idiomatic: one small class, a config schema, a view, and language lines, discovered via service provider. If our application is plain Laravel/Eloquent, the fit is effectively zero — we would be importing an entire CMS abstraction layer to get a numeric input, which is the wrong trade.

Integration feasibility. Mechanically trivial. composer require visiosoft/decimal-field_type, confirm auto-discovery, then attach the field to a stream either through the control panel or programmatically via the Streams migration/assignment API. The package surface is small enough to audit in an afternoon, and MIT licensing means we can fork without negotiation. The real feasibility question is not "can we install it" but "can we survive its dependency graph" — it is pinned against a specific generation of visiosoft/streams-platform, and that constraint, not the field type itself, will drive our Composer resolution.

Technical risk. Concentrated in four areas:

• Adoption signal is effectively null. Zero stars, zero dependents, one release in 2023. There is no community acting as a second pair of eyes, no downstream project exercising edge cases, and no evidence of a security or compatibility review. Treat the code as unaudited.
• Bus factor of one. Single-vendor, single-maintainer ecosystem. If upstream goes quiet, we are the maintainers — which is acceptable only if we pre-commit to that.
• Numeric correctness. Decimal fields are where silent data corruption lives. The critical unknowns are whether values are cast to float anywhere in the retrieve path, whether scale/rounding is enforced on save versus only on display, and whether server-side validation (min/max/step/precision) exists or whether the HTML step attribute is doing all the work.
• Locale and API exposure. Decimal separators, negative values, and grouping characters vary by locale; and field types often behave differently through the CP form versus the REST/JSON path or CSV export. Unvalidated API writes are a plausible failure mode.

Key questions for the maintainer (or our own fork review).

1. What precision and scale are configurable per field, and is the underlying column type generated as DECIMAL(p,s) or something lossy?
2. Is the value hydrated as a string or a PHP float? (Any answer other than string/Brick-style value object is a red flag for monetary use.)
3. Is validation enforced server-side, or only via client-side input constraints?
4. Which visiosoft/streams-platform, Laravel, and PHP versions are supported, and is PHP 8.2/8.3 tested?
5. How does the field serialize through the Streams API and CSV/Excel export paths?
6. What is the upstream maintenance commitment, and what is our exit cost if it lapses?

Integration Approach

Stack fit. Only proceed if the target application is already on OpenClassify/Streams. In that case this package is the correct shape of solution: it respects the platform's field type contract rather than bolting a custom Blade partial onto the entry form. If we are not on Streams, the recommendation is to reject the package and implement a native decimal:2 cast plus a form request with decimal validation rules — roughly a day of work, no dependency risk.

Migration path. Do not consume this from Packagist on a floating constraint. Fork it into our own namespace, vendor it via a private VCS repository, pin to an explicit tag or commit, and add a thin test suite that covers save/retrieve round-trips at boundary values (zero, negative, max scale, values exceeding scale, locale-formatted input). This converts an unmaintained third-party dependency into a first-party asset with a known owner, at a cost of perhaps two days.

Compatibility. Before committing, resolve three constraints in order: PHP version, Laravel major, and visiosoft/streams-platform version. Conflicts here are the most likely reason the integration stalls, and they are not fixable by patching the field type — they are ecosystem-level. Verify that the platform version we run still exposes the FieldType contract this package implements; Streams has evolved its field type API across major versions, and a 2023 release may target an older contract.

Sequencing.

1. Sandbox spike (1–2 days). Install in a disposable branch, define a decimal field on a throwaway stream, round-trip data through CP create/edit, API read/write, and export. Capture actual column DDL and actual JSON payloads.
2. Build-vs-adopt decision. Based on the spike: adopt-and-fork if the field type is sound; reject if precision handling is lossy or validation is absent.
3. Fork hardening. Private repo, CI, boundary tests, documented patch policy.
4. Data model sign-off. Fix precision/scale conventions per field before any production data exists — this is a one-way door for financial or measurement data.
5. Scoped rollout. Enable on a single non-critical stream behind a feature flag, observe for a release cycle, then expand.

Operational Impact

Maintenance. Upstream is dormant; assume no fixes arrive. Our obligation is to track Streams Platform upgrades, not this package — the field type is thin and stable, but the contract it implements is not. Budget a recurring review each time the platform major-bumps, and keep the fork's diff from upstream near zero so rebasing stays cheap.

Support. No vendor, no SLA, no issue-tracker responsiveness to rely on. Internal documentation is the support model: record the precision conventions, the fork location, the patch log, and the upgrade procedure. Anyone who touches entries with decimal fields needs to know the storage contract.

Scaling. Runtime cost is negligible — a field type is a rendering and casting concern, not a hot path. The scaling risk is data-shaped, not load-shaped: precision decisions made at field-creation time propagate to every downstream consumer (reporting, exports, integrations, invoices). Get scale right once, and prefer storing in minor units or a high-scale decimal over anything that involves a float.

Failure modes to monitor.

• Silent truncation or rounding on save when input exceeds configured scale.
• Float coercion on read producing 0.30000000000000004-class artifacts in exports and invoices.
• Locale separator parse failure causing order-of-magnitude errors (comma-as-decimal).
• Validation bypass through the API path where the CP's client-side constraints do not apply.
• Schema drift if Streams re-runs assignments and the generated column type diverges from what we documented.
• Composer resolution deadlock on platform upgrade, blocking unrelated dependency work.

Ramp-up. For a developer already fluent in Streams field types, roughly half a day to productivity. For a developer without Streams exposure, one to two days — and the learning cost is in the platform's field/assignment/entry model, not this package. The TPM takeaway: the opportunity signal here is real (decimal handling is an underserved need), but this package is a narrowly correct answer to a narrow question. Fund it as a bounded spike inside the OpenClassify context, and decline it outright anywhere else.