Pricing Bundle Laravel Package

Product Decisions This Supports

• Pricing engine build vs. buy vs. fork. This package is a reference design for the core pricing question — "given a purchasable subject plus context (channel, currency, customer group, quantity, date), what is the effective price?" It should inform an internal build decision, not a procurement decision. The realistic path is ~1 sprint to reimplement the resolver chain natively in Laravel, which gives you an owned asset instead of an unmaintained dependency.

• Contextual pricing roadmap. The resolver-chain model (ordered resolvers, most-specific-wins, explicit fallbacks) is exactly the mental model stakeholders already hold for tiered, channel-specific, and promotional pricing. It gives you a concrete vocabulary for prioritizing which pricing contexts ship first: multi-currency, then channel overrides, then customer-group tiers, then scheduled/volume rules.

• Price precedence policy. A recurring product argument — does a discount apply before or after currency conversion, does a channel override beat a customer-group tier — is settled by codifying an explicit ordering and fallback contract. The package demonstrates the shape of that contract; the decision itself is yours and should be ratified with Finance before build.

• Tech-debt / vendor-risk framing. Archived status, 10 stars, and zero dependents make adoption a first-party maintenance commitment on day one. That is a legitimate roadmap input: "we are taking ownership of the price path" is a staffing and budget line item, not a footnote.

• Opportunity signaling. The high opportunity score alongside near-zero adoption tells you the domain (contextual price resolution) has few credible OSS incumbents. That supports sequencing pricing earlier if it is a differentiator for your product, and deprioritizing it if it is table stakes you can buy elsewhere.

• Use cases it directly informs: channel-specific catalogs, B2B/customer-group pricing, scheduled price changes with effective dates, promotional overrides, and an admin pricing screen with visible precedence rules.

When to Consider This Package

Consider it (as reference material) when:

• You are evaluating or designing a pricing subsystem and want a small, readable prior art example. The whole thing is small enough to read in an afternoon and produces a one-page decision table (input → resolver → output) that your team can use as a spec.
• Your team has the appetite to fork or extract the pattern into an owned internal package, with named ownership and a test budget. The code volume is trivial; the value is the interface shape.
• You need an explicit precedence/fallback contract and want a validated example of ordered resolvers rather than inventing one under deadline pressure.
• You want to avoid a long vendor evaluation cycle — this is a design input, not a vendor, so it costs hours rather than weeks.

Look elsewhere — or skip entirely — when:

• You are on Laravel. This is a Symfony DI bundle, not a framework-agnostic library. It assumes Symfony bundle registration, compiler passes, Doctrine ORM mapping, and sylius/resource-bundle. There is no clean install path on Laravel 10–12 / PHP 8.2+. Any "add it" plan is secretly a rewrite plan wearing a composer require costume — budget it as a rewrite.
• You need a supported dependency. Archived means no maintainer, no releases, no security response. On the price path — the most revenue-sensitive code you own — an unpatched transitive dependency is a materially different risk class than an unmaintained utility.
• You need catalog-scale performance out of the box. A naive per-object resolver chain invites N+1 lookups on catalog and cart rendering. You will design caching and invalidation yourself regardless.
• You need ecosystem validation. Zero dependents means no community answers, no third-party integrations, no evidence the API survived contact with real traffic outside Sylius core.
• You are already on Sylius. Use Sylius core pricing; this standalone bundle is superseded and installing it invites duplicate/competing services.

Treat the supplied opportunity score (8.29) as a supply-side signal — few alternatives, little competition — and explicitly not as evidence of fitness. Do not let it into the adoption justification.

How to Pitch It (Stakeholders)

To executives (one paragraph): Pricing logic matters strategically, but this specific package does not. It is a small, archived, zero-adopter open-source component from the Sylius e-commerce stack that models how to resolve prices across channels, currencies, and customer groups. It is not installable in our Laravel stack, and adopting it would mean owning unmaintained code on our most revenue-sensitive path. Recommendation: do not take it as a dependency. Use it as a free design reference and fund roughly one to two engineer-weeks to build an owned pricing resolver internally. The favorable read is that no credible open-source option occupies this space, so an in-house resolver is a defensible low-cost asset rather than reinventing a solved problem — and we end up owning the code either way, but with tests and a maintainer.

To engineering (the real ask): This is a Symfony DI resolver chain — ordered price resolvers plus a price-provider contract — deliberately decoupled from the rest of Sylius. It is small enough to read in an afternoon and translate into Laravel idioms in a week. Do not port the Doctrine mappings or the bundle wiring; port only the resolver contract, the precedence rules, and the fallback semantics. Implement resolvers as small injectable classes, execute them through Illuminate\Pipeline\Pipeline so ordering is explicit and testable, and model prices in Eloquent with money as integer minor units and explicit currency/channel/price-type keys. Two non-negotiables up front: fail loudly on "no resolver matched" rather than defaulting to $0.00, and fix the rounding-and-conversion order in the contract before writing a single test.

Risk to name out loud: the failure modes here are discovered by customers and Finance, not by test suites — a missing resolver silently emitting a zero-price line item, a currency mismatch falling back to base price, or stale cached prices after an admin edit. Budget for shadow-mode comparison against the current code path behind a feature flag, with a defined reconciliation window before cutover. Also budget a half-day knowledge transfer from whoever found this package, paired with a written decision table, so the rationale does not live in one person's head.

Ask: approve a short spike to extract the resolver abstraction into an internal package under our ownership, with the explicit understanding that upstream support does not exist and that maintenance is our line item from day one.