Product Decisions This Supports
- Build vs. buy for numeric input in Streams Platform / PyroCMS admin UIs. If your product runs on the Streams Platform (PyroCMS's underlying field-type system), this package answers a narrow but real question: do we hand-roll a decimal field type, or install one? It supplies the field type registration, storage, and admin form input for decimal values so engineers don't write it from scratch.
- Feature completeness for admin-authored numeric data. Relevant when non-technical users (ops, finance, catalog managers) enter prices, rates, weights, or measurements through a CMS admin panel and you need proper decimal handling rather than a free-text or integer field with client-side hacks.
- Scope containment. It's a single-purpose field type — no dashboard, no reporting, no validation policy beyond the type itself. That makes the buy/build decision low-risk and easy to reverse, and it keeps the "buy" line item from expanding into a platform commitment.
- Roadmap signal, not roadmap driver. With zero stars, zero dependents, and a last release in mid-2023, this should not anchor a roadmap. Treat it as an opportunistic accelerator inside an existing Streams-based stack, not a reason to adopt that stack.
- Use cases where it fits cleanly: internal back-office tools, product catalogs with price fields, inventory/admin CRMs, and any Streams-based content model where a decimal column needs a first-class admin editor.
When to Consider This Package
Adopt only when all of the following hold:
- You are already running the Streams Platform (typically via PyroCMS) and are extending it with custom field types. Outside that ecosystem this package does nothing for you — it is an addon, not a standalone Laravel validation or casting library.
- The need is genuinely a decimal field type, not money arithmetic. This is an input/persistence component; it is not a money value object, currency-aware, or a rounding-policy library. For financial calculations you still want
brick/money or moneyphp/money alongside it.
- You've audited the code yourself. Zero stars, zero dependents, and a single dated release mean no community backstop. Budget for a read-through of the source and a fork-you-own-it posture.
- You can pin the version and accept maintenance ownership, including future compatibility with Streams/PHP upgrades.
Look elsewhere when:
- You're on plain Laravel — use the framework's
decimal validation rule plus a cast, or a money library. There is no reason to bring this in.
- You need locale-aware formatting, multi-currency, rounding modes, or high-precision arithmetic — none of that is in scope here.
- Your organization requires active maintenance, security response, or vendor support. A dormant single-maintainer addon fails that bar.
- Migration cost matters: coupling your data model to an unattributed addon raises the cost of ever leaving Streams.
How to Pitch It (Stakeholders)
For executives: This is a small, free (MIT) plugin that adds a decimal-number input to our CMS admin so staff can enter prices and rates correctly without engineering work. It saves a few days of build time inside a platform we already run. It carries no license cost and no vendor lock-in, but it is also effectively unmaintained — zero community adoption, last updated in 2023 — so we should treat it as a fork-and-own component, not a supported dependency.
For engineering: It's a Streams Platform field type for decimals: registration, storage, and form input, nothing more. It is not a money library and makes no claims about precision, rounding, or currency. We should vendor or fork it, pin the version, add our own validation and formatting layer, and cover it with a test that asserts round-trip precision in the database. If we're not on Streams, skip it and use Laravel's decimal rule with an explicit cast.
Recommendation: Conditional adopt — a low-cost accelerator for Streams-based admin UIs, gated on an internal code review and a clear owner. Do not adopt it as a strategic dependency, and do not let a zero-star package influence platform-level decisions.