Decimal Field Type Laravel Package

Technical Evaluation

Verdict up front: this is not a package to adopt, it is a package to read, fork, or reimplement. It is a single-purpose addon for the Anomaly Labs Streams Platform (the engine behind PyroCMS 3.x), not a general-purpose Laravel library. Its entire value is contingent on already running that CMS. At 0 stars, 0 dependents, no release since June 2020, and a composite score of 0.36, it carries the classic profile of an abandoned micro-addon: small, MIT-licensed, trivially reproducible, and unsupported.

Architecture fit

The package contributes one field type to the Streams Platform's field type registry. It ships a field type class extending the platform's base FieldType, a presenter, a config block (decimal places, min/max, possibly step), validation rules, and a database column type mapping to SQL DECIMAL(p,s). Registration happens through the platform's addon service provider and manifest, not through anything a vanilla Laravel application would consume. If the target system is not Streams/PyroCMS, the architecture fit is zero — there is no reusable decimal value object, cast, or validation rule here that survives extraction in a meaningful way. If the target is Streams, the fit is good by construction: it uses the platform's own extension points exactly as intended, which is precisely why it is so small.

Integration feasibility

Mechanically easy: composer require anomaly/decimal-field_type, service provider auto-discovery, then enable the addon and assign the field type to a stream field in the admin UI. The real gate is dependency resolution — the addon will carry a constraint against anomaly/streams-platform of roughly the 1.x/Laravel 5.5–6.x era, and Composer will refuse or silently downgrade on a modern Laravel. Feasibility therefore collapses to a single question: what platform version is in production? On a frozen legacy PyroCMS install, integration is an afternoon. On anything current, it is a non-starter without a fork and rewrite.

Technical risk

Key questions

• Which Streams Platform and Laravel versions are actually in production, and is that stack frozen?
• Does the platform already ship a decimal or numeric field type that covers the requirement?
• What is the storage precision requirement (DECIMAL(10,2) vs. (19,4)), and does the addon's config expose scale independently of precision?
• How is rounding handled — truncation, half-up, or left to the database — and is that acceptable for the money/quantity use case driving the request?
• Does the input tolerate locale decimal separators, and what validation actually runs server-side?
• Is there any test coverage, or would we be adopting unverified behavior?
• Is the requirement genuinely "decimal field" or "currency field" (which implies formatting, symbol, and rounding policy the addon likely does not provide)?

Integration Approach

Stack fit

Migration path

Three realistic paths, in order of preference:

1. Reimplement internally (~1–2 days). The functional surface is a config schema, a validation rule set, a column type, and a form input. Reproducing it as an in-house Streams addon under your own namespace gives you PHP 8 / current-Laravel compatibility, tests, and a maintainer. This is the recommended path for any greenfield or actively upgraded system.
2. Fork and pin. Clone into a VCS repository under the org namespace, tag it, reference by explicit version or commit SHA in composer.json, and treat it as first-party code. Appropriate only if a legacy platform must stay untouched and reimplementation is politically or contractually blocked.
3. Direct dependency. Acceptable only for a legacy install where the platform version already matches and the addon is already in the lockfile. Never introduce it into a new build.

Compatibility

The decisive checks before committing to any path: run composer why-not anomaly/streams-platform in the target project; inspect the addon's composer.json for platform and PHP constraints; run the platform's test suite plus a manual smoke test of decimal entry, validation rejection, and reload on PHP 8.x. Watch for Laravel helper removals (str_*, array_*), nullable-parameter deprecations, and any use of the string/array helpers in the presenter or validation path.

Sequencing

1. Spike (0.5 day): read the source end to end; it is small enough that source review substitutes for documentation.
2. Decide build vs. fork based on the platform version answer and the currency-vs-decimal scoping question.
3. Implement or vendor: internal addon with tests covering precision, scale, boundary values, negative numbers, and invalid input.
4. Pilot on one content type / one stream in staging, including an admin round-trip and a database column inspection.
5. Roll out with a documented precision standard (e.g., DECIMAL(19,4) for money) enforced in config rather than per-field discretion.

Operational Impact

Maintenance

Ownership transfers to you on day one. That is not a burden here — the codebase is small enough to audit in an afternoon and rewrite in a day — but it must be an explicit line item, not an assumed inheritance. Budget a fork-maintenance line and a named owner; an unowned fork is worse than an unowned dependency because nobody is watching upstream either.

Support

There is no upstream support channel with meaningful activity. Internal documentation should capture the field type's config options, the chosen precision/scale convention, and the rounding behavior, because the original author will not be answering questions in 2027.

Scaling

Runtime cost is negligible — a decimal column and a form input. The scaling concern is semantic, not performance: inconsistent precision across streams, aggregation and reporting queries that silently round, and downstream exports or analytics that reinterpret scale. Standardize precision at the platform level and enforce it in code review.

Failure modes

• Precision/rounding drift between form validation, model casting, and the database column — the classic decimal bug, and the most likely production incident.
• Locale-driven input failure: comma decimal separators rejected or misparsed for non-US users.
• Validation bypass if the field is written through an API or importer that skips the field type's rules.
• Platform upgrade breakage at addon registration or manifest level, presenting as a missing field type rather than an obvious error.
• Silent abandonment — the package appears installed and healthy until the day a PHP upgrade forces a resolution.
• Scope mismatch: someone uses it for currency and discovers formatting, symbols, and rounding policy were never in scope.

Ramp-up

Low for a developer already fluent in Streams addon conventions — half a day to read, one to two days to reimplement with tests. Effectively infinite for a developer without Streams experience, because the learning cost is the platform, not the addon. That asymmetry is the strongest argument for treating this as a template to copy rather than a dependency to install.