- Is elcodi/rule-bundle a Laravel package?
- No. It is a Symfony bundle from the Elcodi e-commerce suite, shipped as a read-only subtree split of the main elcodi/elcodi monorepo. It contains a bundle class, a dependency-injection extension, compiler passes, YAML/XML service wiring and Doctrine entity mappings, none of which boot under a Laravel kernel. The underlying concept, persistable rules built from conditions and actions evaluated against a domain context, is still relevant to Laravel commerce work, but you would be porting an idea rather than installing a package.
- Can I install elcodi/rule-bundle in a Laravel 10 or 11 application with Composer?
- Realistically no, or not without heavy constraint surgery. This is a Symfony 2.x/3.x-era artifact, while Laravel 10 and 11 pin Symfony 6/7 components, so composer require will almost certainly fail on symfony/* conflicts before you ever reach a runtime error. Elcodi's own transitive pins on Doctrine and its PHP floor will compound those conflicts further. Audit the composer.json constraints on symfony/*, doctrine/* and php before writing any code.
- What does the Elcodi Rule bundle actually do?
- It provides a flexible rules engine in which rules are composed of conditions and actions and evaluated against a domain context. In an e-commerce setting that abstraction maps to promotions, coupons, shipping rules and pricing logic. Rules are persistable, so they can be stored, edited and re-evaluated without redeploying code. The value is the domain model, not the Symfony packaging around it.
- Which PHP and Symfony versions does elcodi/rule-bundle support?
- The codebase uses PHP 5.x and 7.0-era idioms and targets Symfony 2.x/3.x, and there is no verified PHP 8.x compatibility. Expect dynamic properties, removed functions and outdated Doctrine APIs to surface if you try to run it on a modern runtime. Check the exact composer.json constraints before assuming anything about support. Treat any PHP 8 compatibility claim as unproven until you run the tests yourself.
- How would I integrate elcodi/rule-bundle into a Laravel application?
- There are two routes, and only one is durable. The quick route is to pull individual Symfony services in and instantiate the rule manager, factory and repository manually, skipping the kernel, which works for a spike but leaves you straddling two DI paradigms indefinitely. The durable route is to fork the subtree into an internal path repository, strip the bundle class and DI extension, re-register services through a Laravel service provider with publishable config, and port persistence to Eloquent or keep Doctrine DBAL. Preserve the evaluation core verbatim during the port so behavior can be diffed against the original in characterization tests.
- Is elcodi/rule-bundle still maintained, and where do I report bugs?
- This artifact is read-only, so issues, questions and pull requests are not handled here; upstream is the elcodi/elcodi monorepo. The project is effectively dormant, and the support channels referenced in the README, including Gitter and Twitter, are archival. With zero stars and zero dependents on this split, there is no production signal and no downstream bug discovery to lean on. The MIT license removes legal risk but transfers all maintenance to you.
- What are the alternatives to using Elcodi's rule bundle in Laravel?
- The pragmatic baseline is symfony/expression-language evaluated over Eloquent models, backed by your own rules, conditions and actions tables. That gives you typed evaluation without dragging in a Symfony kernel or Doctrine mappings, and it is a small amount of code to own. Only pursue Elcodi's model if its rule semantics, such as rule groups, precedence and typed context contracts, are materially richer than that baseline. Assume they are not until you have read the core evaluation code.
- Does elcodi/rule-bundle have tests I can use before refactoring?
- You need to verify whether runnable unit tests exist in this subtree split, because they would serve as characterization tests for any port. If they are present, run them against the evaluation core first and record the results before changing a single line. If they are absent or tied to the Symfony kernel, write your own characterization tests around the rule manager, factory and repository before refactoring. That baseline is what lets you prove the Laravel port behaves identically.
- Is the Elcodi rule engine's evaluation logic coupled to Symfony or Doctrine?
- That is the key question that determines extractability, and it must be answered by reading the core rather than the README. If the domain layer is free of Symfony and Doctrine imports, you can reuse the evaluation logic directly and skip most of the fork. If evaluation resolves services from the container or depends on Doctrine entities, the port becomes substantially more invasive. Also determine whether evaluation uses Symfony ExpressionLanguage, a custom evaluator interface, or a callable registry, since that decides how much can be reused in Laravel.
- What production risks should I consider before adopting this rules engine?
- Risk here is stacked rather than singular: an unmaintained read-only artifact, unverified PHP 8 support, stale Doctrine APIs and near-certain Composer conflicts. Decide your failure policy before code, not after an incident, meaning whether a rule evaluation error fails open and grants the promotion or fails closed and blocks it. Assign explicit ownership of any internal fork, since MIT licensing means you carry 100 percent of maintenance. If the semantics do not clearly exceed a week of work against Eloquent plus ExpressionLanguage, build the simpler thing.