Promotions Bundle Laravel Package

Product Decisions This Supports

• Build vs. buy — and where to buy it. This package is a read-only, backward-compatibility mirror of a Sylius bundle, not an installable library. It does not support a "just add this dependency" decision. What it does inform is the real decision: if we want Sylius's rule/action promotion model, we adopt Sylius core as a platform, not this artifact. Treat this as an input to a platform evaluation, not a component selection.
• Stack-fit gate. Despite the "Laravel/PHP package" framing, this is Symfony/Sylius code with Doctrine, its own resource/registry layer, and a workflow engine baked into the promotion domain. For a Laravel product this is a re-implementation, not an integration. Use it to close the "Laravel + Sylius promotions" question early rather than spending evaluation cycles on it.
• Roadmap hygiene / tech-debt register. Any service whose composer.json or lockfile still resolves sylius/promotions-bundle is carrying a legacy pin — potentially pinned to a personal fork. That's a concrete backlog item: inventory, confirm the code now lives in sylius/sylius, and remove or repoint. This is a one-PR cleanup, but only if we know it's there.
• Design reference for a first-party promotions engine. The bundle encodes a mature domain model — promotion rules as conditions, actions as strategies, eligibility checkers gating application, coupon codes with usage limits and expiry, priority/exclusivity semantics, cart-vs-order application, order adjustment recalculation. If we scope a native promotions module, this is a strong spec to read for a day. It is not a component to ship.
• Supply-chain and vendor-risk register. Zero stars, zero dependents, zero score, archived-by-design. That combination is a standing "do not depend on" flag — it belongs in architecture notes so the question isn't re-litigated next quarter.
• Feature scoping for a promotions capability. If promotions/discounts are on the roadmap, this package tells us the capability is a core platform concern in the Sylius world. Our real options are: adopt Sylius (Symfony), build a thin Laravel-native rules engine scoped to our pricing model, or buy a SaaS promotions layer if time-to-market dominates. Those are the three options this evaluation should route into.

When to Consider This Package

Consider it only in these narrow cases:

• Legacy Sylius maintenance. You are supporting an older Sylius install whose lockfile still resolves sylius/promotions-bundle, and you need to understand what moved where before upgrading to the monorepo.
• Architectural study. You want a concrete reference implementation of promotion rules/actions/priority/eligibility, and you are reading the source rather than installing it to design an internal discount engine.
• Dependency triage. You found it (or a fork of it) in a composer.json and need to classify it as a BC shim so it can be removed from the explicit requirements with confidence.

Look elsewhere when:

• Greenfield work of any kind. Read-only and BC-only by design — there is no forward development, no patches, no CVE response.
• The product stack is Laravel. This is Symfony/Sylius. The cost is not a port; it's a re-implementation plus a second framework and a second persistence layer.
• You need active maintenance, security patching, community support, or current-version compatibility. None of those are available here.
• You want a promotion engine without adopting the whole Sylius platform. Compare against Sylius core (if already on Symfony), a Laravel-native promotion/discount implementation, a thin first-party rules engine scoped to our pricing model, or a SaaS promotions layer if time-to-market dominates.
• You are evaluating the fork specifically (pjedrzejewski/SyliusPromotionsBundle). A 0-star personal mirror is a snapshot, not a distribution channel; its repo name doesn't even match the Composer package. Resolve why it's pinned before shipping anything that touches it.

How to Pitch It (Stakeholders)

One-liner: This is an archived, read-only piece of Sylius history — not a library we can adopt or depend on, and not Laravel-compatible.

For executives: We evaluated it and the recommendation is do not adopt. It has no maintenance, no community, no security patch path, and zero downstream users. The only strategic decision it unlocks is whether Sylius itself belongs in our commerce roadmap — and that's a platform-level conversation with a real licensing and upgrade-cost analysis, not a bundle-level one. Cost to close this out: a short engineering spike plus one cleanup PR if it appears in a lockfile.

For engineering: Don't add it. If you find it in a lockfile, that's legacy Sylius — the code has moved into the sylius/sylius monorepo, and any explicit require (or, worse, a VCS pin to the personal fork) should be removed or repointed so the platform is pinned explicitly. Verify with composer why sylius/promotions-bundle and a dry-run update, then regression-test promotion flows: eligibility evaluation, coupon redemption with usage limits, order adjustment recalculation on cart mutation, and admin promotion editing. If we decide to build promotions ourselves, spend a day reading its rule/action/eligibility/priority model as a design reference — that part is genuinely good — then write our own against our pricing and cart model. Reaching productivity in the Sylius promotion domain from a Laravel-only baseline is a multi-week effort, not a multi-day one.

Recommendation: Close as do not adopt. Keep it on a short list of design references for a first-party promotions engine. Log a tech-debt ticket for any existing references (especially fork pins) and route them into a single cleanup PR. Escalate the real question — "do we want a Sylius-based commerce platform, or a Laravel-native promotions module?" — into platform evaluation with proper scope, three concrete options, and an owner.