Prices Combinations Laravel Package

Getting Started

This package extends mibo/prices, so treat it as a thin layer on top of an existing value-object library rather than a standalone tool. Before installing, make sure you understand how mibo/prices represents a price (a value object holding multiple named price "types" — e.g. retail, sale, list) because the combinations package is essentially about composing or deriving those types.

Minimal setup:

composer require mibo/prices-combinations

Because the repository has no stars, no dependents, and a score of 0, start by reading the source in the src/ directory and the tests/ folder — they are the de facto documentation. Check composer.json for the required version of mibo/prices and the supported PHP/Laravel range, since the package will silently break if the base Price API shifts underneath it.

Where to look first:

1. composer.json — pin the mibo/prices version constraint so future composer update runs don't pull a breaking base library.
2. src/ — find the class that wraps or extends Mibo\Prices\Price and the "property" class referenced in the description. That wrapper is what you'll interact with.
3. tests/ — they show the intended constructor signature and the expected output shape, which is more reliable than the README for a package this small.
4. If a service provider is registered in composer.json's extra.laravel.providers, confirm it's auto-discovered; otherwise add it to config/app.php.

First use case: a product that needs a Price with combination-derived types.

use Mibo\Prices\Price;
// namespace to verify against src/
use Mibo\PricesCombinations\CombinedPrice;

$price = new CombinedPrice([
    'retail' => 1999,
    'sale'   => 1499,
]);

echo $price->getValue('sale'); // 1499

Wire it into an Eloquent model as a cast so day-to-day usage stays clean:

protected $casts = [
    'price' => \Mibo\PricesCombinations\...

CombinedPrice::class,
];

(Verify the exact class name and constructor in src/ before copying — the description references a "Price property", so the entry point may be an attribute/cast class rather than the CombinedPrice guessed above.)

Implementation Patterns

Treat mibo/prices as the contract. mibo/prices-combinations should never be the only place prices exist in your app. Use plain Mibo\Prices\Price in domain code and only reach for the combination wrapper at the edges (imports, admin forms, reporting). This keeps you portable if the combinations package stops being maintained — which is likely given the 0-star/0-dependent status.

Use it where "combination" semantics actually apply. The plausible use cases are:

• Deriving a display value from multiple component types (e.g. sale falls back to retail).
• Building a composite price from several source prices (a cart line combining base + options).
• Validating that a set of price types is internally consistent before persisting.

Encode these as small methods around the package rather than scattering combination logic through controllers.

Form requests / validation. Because the library ships a UI-facing "property", it makes sense to validate incoming combinations with a dedicated FormRequest rule instead of trusting the package's own coercion:

$request->validate([
    'price' => ['required', 'array'],
    'price.retail' => ['required', 'integer', 'min:0'],
    'price.sale'   => ['nullable', 'integer', 'lte:price.retail'],
]);

Validate first, then instantiate the Price/combination object. Don't let a malformed payload reach the value object.

Testing. The base library is a value object, so tests should be assertion-heavy and dependency-free:

public function test_sale_falls_back_to_retail(): void
{
    $price = new Price(['retail' => 1000]);
    $this->assertSame(1000, $price->getValue('sale') ?? $price->getValue('retail'));
}

Wrap the combination logic in a small helper so you can test it independently of the package's quirks and swap the package out later.

Persistence. Store prices as integers (minor units) in separate columns or as a JSON column cast to the value object. If you use JSON, add a migration/backfill step — combinations can produce a different shape than the previous flat price.

Integration with existing mibo/prices code. If you already have plain Price objects, don't mix them at the same layer. Pick one boundary (e.g. a repository or a model accessor) where Price becomes the combination object, and keep everything above that boundary agnostic.

Gotchas and Tips

Maintenance risk is the headline issue. Zero stars, zero dependents, score 0. Pin the exact version in composer.json ("mibo/prices-combinations": "1.0.0", not ^1.0) and add a note in your team docs that this package is unmaintained. If it's critical, vendor the relevant class into your own namespace — it's tiny enough that this is realistic.

Version coupling. This package depends on mibo/prices at a specific version. Upgrading Laravel or PHP without checking the base package's constraint is the most likely way to break production. Run composer why-not mibo/prices-combinations after any framework upgrade.

The "Price property" is the ambiguous part. The description says the library "comes with a Price property" — confirm whether this means a Laravel Nova field, an Eloquent attribute, or a plain property on a class. The installation path differs wildly:

• Nova field → register in NovaServiceProvider::fields(), and Nova major-version compatibility becomes a hard blocker.
• Eloquent cast → just a $casts entry.
• Plain property → no framework integration required.

Read src/ and composer.json's require block before assuming which one it is.

Combination key ordering. If combinations are array-based and order-sensitive (e.g. ['retail', 'sale']), don't rely on PHP's implicit array ordering in user input. Normalize and sort keys in a FormRequest or DTO before constructing the price.

Silent coercion. Value objects of this type often coerce strings/floats silently. Add assertions or validation on the boundary. A price of '1499' (string) vs 1499 (int) can produce subtle equality failures in tests and in database queries.

Debugging. When a combination produces an unexpected value, dump the underlying component array first ($price->toArray() or whatever the base library exposes) — the bug is almost always upstream of the combination wrapper. Use ray() or dump() immediately after construction, not after persistence.

Extension points. Since the package is thin, extend at the edge rather than forking the package: a small PriceFactory in your app that encapsulates construction logic is usually enough. If you need a new combination rule, add it to your factory rather than a custom subclass — subclasses will break on the next mibo/prices bump.

Config quirks. If the package publishes a config file (php artisan vendor:publish), publish it explicitly and commit it. Small packages often change default config keys between patch releases without a migration path.