Laravel Prices Laravel Package

Technical Evaluation

Architecture fit. whitecube/laravel-prices is a Laravel-side value-object package for handling monetary amounts on Eloquent models — the release history (v1.6.x → v2.0.0) is consistent with a thin adapter that wraps a money library and exposes model casts, accessors, and formatting helpers. Its footprint is therefore small and additive: it decorates models rather than owning persistence, so it does not impose architectural constraints on the wider application. Fit is good where prices are already modelled as integer minor units plus a currency, and poor where prices are stored as floats or as pre-formatted strings — in the latter case the package will surface inconsistencies rather than resolve them.

Integration feasibility. Low-effort. Integration is typically a composer require plus a cast declaration on the relevant model attributes; there is no service provider ceremony beyond auto-discovery and no migration requirement. The dominant cost is not installation but the audit of existing price-bearing columns and the decision of whether to retrofit existing models or apply the package only to new code.

Technical risk. The v2.0.0 risk profile is almost entirely a platform-support risk rather than a behavioural one. The release notes list only framework/runtime support changes (adds Laravel 13 and PHP 8.5; drops PHP 8.2 and Laravel 10) and do not announce API changes. That is a favourable signal — major version bumps that are purely support-matrix changes are usually low-hazard — but it is also an inference from an incomplete changelog: the notes are generated and truncated, and a semver-major bump implies the maintainers considered something breaking, most plausibly the dropped platform floor itself. Secondary risks: the package sits on the money-handling path, so any currency-rounding or locale-formatting regression is a correctness issue with financial-adjacent consequences, not a cosmetic one; and it is a single-maintainer package (one contributor credited on this release), which is the real long-term risk, not the version bump.

Key questions.

• Which of our services are still on Laravel 10 or PHP 8.2, and what is their upgrade timeline? v2.0.0 is unusable for them, and v1.6.0 will stop receiving fixes.
• Did v2.0.0 change any cast, accessor, or formatting behaviour beyond the support matrix? The generated changelog does not say; confirm against the diff before adopting.
• What is the underlying money library and its version constraint? A transitive major bump would be the more interesting breaking change.
• Is the package used in any write path where rounding differences would produce persisted data discrepancies, or only on read/display paths?

Integration Approach

Stack fit. Targets Laravel 13 / PHP 8.5 at the top end and, by elimination, Laravel 11–13 on PHP 8.3–8.5. It is a conventional Composer package with Laravel auto-discovery; there is nothing exotic in the dependency shape and no runtime service, daemon, or extension requirement.

Migration path. Two distinct decisions, and they should be sequenced rather than bundled:

1. Adopt the package (v1.6.0 → v2.0.0 for existing users, or greenfield adoption). For existing v1.x users the upgrade is a constraint change plus a framework upgrade; the blocker is the host application's Laravel/PHP version, not the package.
2. Upgrade the host application to Laravel 11+ and PHP 8.3+. Where the application is already there, v2.0.0 is a low-ceremony bump; where it is not, the package cannot move first.

For teams not yet using the package, adopt v2.0.0 directly and skip v1.x entirely — there is no reason to onboard onto a version whose framework floor is already EOL.

Compatibility. Dropping Laravel 10 is defensible: Laravel 10 reached end of security support in early 2025, so v2.0.0 is aligning with a platform the vendor no longer patches. Dropping PHP 8.2 is more aggressive — 8.2 remains in security-only support through the end of 2026 — so the practical effect is to exclude a runtime that is still receiving security fixes. PHP 8.5 support at launch means the package is tracking new runtimes promptly, which is a positive maintenance signal. Net: the floor is reasonable for new work and will be the binding constraint for any legacy service.

Sequencing.

1. Inventory usages: which models, which columns, which are write paths vs. display paths.
2. Confirm the actual diff for v2.0.0 against v1.6.0 — verify the changelog's implication that nothing beyond the support matrix changed.
3. Pin v1.6.0 explicitly in any service that cannot yet reach Laravel 11, and record that as a tracked technical-debt item with the Laravel 10 EOL as the forcing function.
4. Upgrade Laravel/PHP first, then lift the package constraint in the same or a follow-on change.
5. Only after that, consider expanding coverage to models not currently using the package.

Avoid doing the package bump and a broad model retrofit in one change; if formatting output shifts, you want a clean bisect.

Operational Impact

Maintenance. Low ongoing burden by design — the package is a small surface area and its releases track framework versions rather than introducing features. The maintenance cost that does exist is concentrated in keeping the host application's Laravel/PHP versions current, since the package's support floor will keep advancing. Budget for a routine bump roughly in step with Laravel majors rather than treating this as a one-off.

Support. Single-maintainer project with a small contributor base. Historically responsive to framework-version PRs (the Laravel 13 support landed as an external contribution), but bus factor is the honest concern. Mitigation: the package is thin and its behaviour is largely determined by the underlying money library, so a fork or in-house replacement is a bounded, low-days effort if upstream stalls. Keep the version pinned and treat abandonment as a contained risk rather than an existential one.

Scaling. No scaling characteristics worth flagging. Casting and formatting are per-attribute, in-process operations with no I/O, no cache, and no external calls. Cost is proportional to the number of price attributes hydrated per request — negligible relative to typical query cost. It will not be a bottleneck, and it will not help with one either.

Failure modes.

• Dependency-floor drift (most likely): a future minor/patch raises the framework floor and silently blocks upgrades of unrelated services pinned to the package. Mitigate by pinning and reading release notes before bumping.
• Rounding/formatting divergence: two code paths formatting the same value differently — one via the package, one hand-rolled — producing inconsistent output or, worse, inconsistent persisted minor units. Mitigate by making the package the single formatting path and covering it with tests.
• Currency/locale edge cases: zero-decimal currencies (JPY), three-decimal currencies (KWD), and negative amounts are where money libraries typically break. Verify against your actual currency mix before broad rollout.
• Abandonment: low probability, low-to-moderate impact, bounded by the small surface area.

Ramp-up. Effectively zero for a Laravel developer — the API is a cast plus formatting helpers, learnable in an hour. The ramp-up cost that matters is domain-side, not API-side: the team must agree on canonical storage (integer minor units), currency source of truth, and rounding policy. That conversation is required with or without this package; the package just makes the answer explicit. For a team currently storing prices as decimals or floats, expect the retrofit — data migration plus backfill validation — to dominate the effort and the package adoption itself to be a rounding error against it.