- What is sylius/promotions-bundle used for?
- It is the Composer package name for the Sylius promotion engine, the component that lets a Sylius store define promotions as reusable entities built from rules (conditions such as cart quantity, item totals or customer group) and actions (percentage or fixed discounts, free shipping, free units). Coupon codes, usage limits and per-customer restrictions are handled by the same engine. In current Sylius the actual code ships inside the sylius/sylius monorepo, and this package survives only as a backward-compatibility shim.
- Can I use sylius/promotions-bundle in a Laravel application?
- No. It is a Symfony bundle built on Symfony's DI container and compiler passes, Doctrine ORM, the Sylius resource and registry abstraction, and the Sylius cart and order domain model, so none of it plugs into Eloquent, Laravel's service container or Laravel's event and pipeline model. Making it work in Laravel would mean reimplementing the engine, not porting a package. For a Laravel storefront, model promotions in Laravel idiom with rules as predicates and actions as strategies, or use a Laravel-native discount package.
- How do I install sylius/promotions-bundle?
- In a legacy Sylius installation that still lists per-bundle packages, it is pulled in with Composer and registered in the kernel. On any supported Sylius version you should require sylius/sylius instead and let Composer resolve the shim transitively only if a third-party package still demands it. Run composer why sylius/promotions-bundle to confirm whether anything depends on it directly, and never add it to a Laravel project.
- Why is the GitHub repository marked READ-ONLY and why is it a fork?
- The READ-ONLY marker identifies it as a backward-compatibility artifact published while Sylius consolidated its per-bundle packages into the sylius/sylius monorepo. The repository under evaluation is a personal zero-star fork of that shim, and its name (SyliusPromotionsBundle) does not match the Composer package name, so it is a snapshot rather than a maintained distribution channel. The promotion engine itself lives in sylius/sylius, which is the dependency you should actually own.
- Which Laravel versions does sylius/promotions-bundle support?
- None. It is not a Laravel package and ships no service provider, facade or Laravel support declaration. Its version constraints track Sylius and Symfony releases, and the shim is only meaningful for legacy Sylius per-bundle installs. If you are selecting a dependency for a Laravel application, this is the wrong ecosystem entirely.
- How do promotions, rules and actions work in Sylius?
- A promotion is an entity composed of rules, which are eligibility checkers evaluated against the cart or order, and actions, which are the discounts applied when every rule passes. Built-in rules cover cases such as cart quantity, item totals and customer groups, while built-in actions cover percentage and fixed discounts, free shipping and free units. Because promotions are entities, marketing teams assemble and adjust campaigns from the admin panel without writing code. The engine integrates with the Sylius cart and order workflow, so discounts are applied and recalculated as the cart changes.
- How do coupon codes and usage limits work in Sylius promotions?
- A promotion can be restricted to a coupon code, and coupons carry usage limits plus optional per-customer restrictions, so a code can be capped in total or allowed once per customer. Coupon validity is evaluated together with the promotion's rules during cart and checkout processing. Priority and exclusivity rules decide which promotions win when several of them are eligible at the same time.
- How do I add a custom promotion rule or action?
- The bundle is built for extension: you register your own rule checker or action executor as a service, tag it appropriately, and expose it in the admin form so it becomes selectable on a promotion. A checker receives the promotion subject (cart or order) and returns whether the rule is satisfied, while an action mutates the subject's order adjustments. In a Laravel application that same pattern still has to be reimplemented inside your own domain module, since none of the Sylius extension points exist there.
- Should I pin this fork of sylius/promotions-bundle in a production composer.lock?
- No. A personal mirror with zero stars and no upstream maintenance gives you no CVE response, no compatibility bumps and no downstream validation, and it can be deleted or force-pushed at any time. Pin the canonical sylius/sylius at a supported version instead, and remove any repositories VCS entry that points Composer at the fork.
- What are the alternatives to sylius/promotions-bundle for a Laravel store?
- For Laravel, evaluate Laravel-native voucher or promotion packages, or scope a small domain module: rules as predicate classes, actions as strategy classes, coupons as a model with usage counters, and one service that evaluates promotions against the cart and writes order adjustments. That reproduces the rules-and-actions model the Sylius engine uses without pulling in a second framework and a second persistence layer. If you maintain an existing Sylius storefront, the alternative is not another package at all: depend on sylius/sylius and drop the shim.