Prices Combinations Laravel Package

Technical Evaluation

Architecture fit. mibo/prices-combinations is a Composer library that extends mibo/prices, which positions it as a thin additive layer rather than a framework. That is architecturally attractive: it should slot into the domain/service layer of a Laravel application without touching HTTP, persistence, or queue concerns. The package ships a "Price property," which strongly suggests it is a presentation/integration binding for a specific admin or UI package (most likely Laravel Nova, given the vendor's package history) rather than a pure value-object library. That distinction matters: if the UI binding is the primary artifact, the underlying composition logic may be under-tested and under-documented, and adopting it pulls in a UI dependency we may not want in our domain layer.

Integration feasibility. Mechanically trivial — one composer require, autodiscovery of the service provider if present, and a small public API surface. The realistic effort is in validation, not installation: confirming PHP/Laravel version constraints against our matrix, confirming the required range of mibo/prices and moneyphp/money (or equivalent) does not conflict with our lockfile, and confirming behavior against our existing money handling.

Technical risk. High, and dominated by project-health signals rather than code quality. Zero stars, zero dependents, and a one-line description mean no external production validation, no community bug-finding, and an effectively single-maintainer bus factor. The description ("Extension of prices") does not enumerate the combination semantics — addition, subtraction, discount application, tax composition, currency conversion — nor the rounding and immutability guarantees, which are exactly the behaviors that cause financial defects. We cannot infer stability from a 0.x-style version scheme, and abandonment risk is material.

Key questions.

1. What precisely does "combination" mean — arithmetic composition of two prices, a collection/matrix of prices, or price-plus-adjustment? What are the rounding rules and at which step do they apply?
2. Are currency mismatches rejected at construction time or coerced? What exception types are raised?
3. Is immutability preserved (returns new instances) or is mutation exposed?
4. Does the "Price property" require Laravel Nova or another paid/UI package as a hard dependency, or is it optional?
5. What is the supported PHP/Laravel range, and is there CI proving it?
6. What is the license/CLA posture for forking if the maintainer stops (MIT — forkable, which materially reduces the risk)?
7. Is the same logic achievable with ~150 lines over moneyphp/money or brick/money, both of which have adoption and audit history?

Integration Approach

Stack fit. Fits a conventional Laravel stack as a domain-layer dependency. The correct placement is behind an internal boundary: our own PriceComposition interface plus a thin adapter that delegates to the package. That keeps the package out of controllers, models, and Blade/Nova resources, and makes replacement a one-file change.

Migration path. Assume no migration of existing data — this is greenfield adoption, not a replacement. If we already store monetary values as integers in minor units, do not convert storage; use the package strictly as an in-memory calculation layer and persist the resulting minor units. If we already have ad-hoc float arithmetic somewhere, treat this as an opportunity to standardize on a single money type, but scope that as a separate initiative — do not bundle it with package adoption.

Compatibility. Pin an exact version (not a caret range) for the first release. Verify the transitive graph resolves against our lockfile before any code is written; the highest-probability failure at this stage is a version conflict on the base prices package or its money dependency, not an API mismatch.

Sequencing.

1. Spike (1–2 days): branch-only install; write characterization tests that pin actual behavior for arithmetic, rounding, currency mismatch, zero/negative values, and high-precision inputs. These tests are the deliverable regardless of the go/no-go outcome.
2. Decision gate: compare the spike output against a 150-line in-house implementation on the same test suite. Choose in-house if the package's value-add over moneyphp/money is not clearly demonstrated.
3. Adapter (if adopted): land the internal interface and adapter with the characterization tests attached to the adapter, not the vendor class.
4. Pilot: one low-blast-radius surface (e.g., internal admin display) before any customer-facing pricing.
5. Rollout: remaining surfaces, one at a time.

Operational Impact

Maintenance. Budget a standing 30-minute quarterly review: check for releases, PHP version support, and security advisories. Because the package is MIT, the fallback is explicit — fork to internal/prices-combinations and vendor the source if the maintainer goes dark. Decide the fork trigger now (e.g., no release in 12 months, or a PHP major unsupported) so the choice is not made under pressure.

Support. Community-only, effectively none. There is no SLA, no issue-triage history to gauge responsiveness, and no Stack Overflow corpus. Our on-call runbook must treat this as "our code" — the first responder is the team that adopted it.

Scaling. Runtime cost is negligible; these are in-memory value objects and will not appear in a profile. The scaling risk is correctness at volume, not throughput: rounding applied per-line versus per-order produces cumulative drift across large baskets, and that error scales with order count. Pin the rounding point in the adapter and assert it in tests.

Failure modes.

• Silent precision loss through implicit float coercion at the adapter boundary — the highest-severity risk, and financial.
• Currency mismatch either throwing at an awkward point in the request lifecycle or being silently coerced; behavior must be characterized, not assumed.
• Transitive version drift breaking the build on an unrelated composer update.
• UI coupling — if the Price property hard-requires Nova, an upgrade path for the admin layer becomes a constraint on the domain layer, which we do not want.
• Abandonment leaving us on an unsupported PHP version at a future framework upgrade.

Ramp-up. Low. A mid-level engineer can be productive in half a day at the API level. The real ramp-up is domain literacy: engineers must understand minor-unit storage, rounding policy, and currency invariants before touching pricing code, independent of which package we choose. That training cost is fixed and should not be counted as a cost of this package.

Recommendation. Do not adopt on current evidence. Run the spike, and default to a small in-house composition layer over an already-adopted money library unless the characterization tests show the package encodes non-obvious semantics we would otherwise have to derive ourselves. The zero-adoption profile is not disqualifying for a small pure-PHP utility, but it does mean we must buy the confidence ourselves — and if we are paying that cost, the dependency needs to earn it.