Rule Bundle Laravel Package

Technical Evaluation

Architecture fit. elcodi/rule-bundle is a Symfony bundle, not a Laravel package. Its value proposition — persistable rules composed of conditions and actions, evaluated against a domain context — is exactly the abstraction a TPM wants when scoping promotions, coupons, shipping, or pricing logic. But the deliverable is not the concept; it is Symfony-specific packaging: a bundle class, DI extension, compiler passes, YAML/XML service wiring, Doctrine entity mappings, and event subscribers. None of that boots under a Laravel kernel. Conceptually aligned with a Laravel commerce roadmap; architecturally misaligned with a Laravel runtime.

Integration feasibility. Two routes exist and only one is durable.

1. Side-by-side Symfony components: pull individual Symfony services in and instantiate the rule manager/factory/repository manually, skipping the kernel. Fastest to a spike, brittle to maintain, and leaves you straddling two DI paradigms indefinitely.
2. Extract the domain core: fork the subtree internally, strip Symfony wiring, re-register via a Laravel service provider, and port persistence to Eloquent or retain Doctrine DBAL. More upfront cost, but produces an artifact we own and can version.

Composer reality check: this is a Symfony 2.x/3.x-era artifact. Laravel 10/11 pins Symfony 6/7. Constraint conflicts are near-certain, and Elcodi's own transitive pins (Doctrine, PHP floor) will compound them. Route 1 likely fails at composer require before it fails at runtime.

Technical risk. High, and stacked rather than singular.

• Read-only subtree split: no issues, no PRs, no releases here. Upstream is the monorepo.
• 0 stars / 0 dependents on this artifact: no production signal, no downstream bug discovery, no community fixes.
• Dormant project: support channels referenced in the README are effectively archival.
• PHP 5.x/7.0-era idioms: unverified PHP 8.x compatibility; expect dynamic properties, removed functions, and old Doctrine APIs.
• MIT license removes legal risk and simultaneously transfers 100% of maintenance to us.

Key questions.

• What is the evaluation mechanism — Symfony ExpressionLanguage, a custom evaluator interface, or a callable registry? This determines whether we can reuse symfony/expression-language directly in Laravel and skip most of the fork.
• Is the domain layer free of Symfony/Doctrine imports, or is evaluation coupled to container-resolved services? Extractability hinges entirely on this.
• Are there runnable unit tests in this artifact we can use as characterization tests before any refactor?
• What are the exact composer.json constraints on symfony/*, doctrine/*, and php?
• Do rule semantics (grouping, precedence, short-circuiting, context contracts) exceed what we'd write in a week against Eloquent models plus ExpressionLanguage?
• Who owns the fork, and what is our policy on evaluation failure — fail-open or fail-closed? This must be decided before code, not after an incident.

Integration Approach

Stack fit. Poor as-shipped. The pragmatic baseline for a Laravel app is symfony/expression-language over Eloquent models with our own rule/condition/action tables. Only pursue Elcodi's model if its semantics are materially richer — rule groups, precedence rules, typed context contracts — than that baseline. Assume they are not until proven otherwise by reading the core.

Migration path. Fork the subtree into an internal path-repository package (e.g. packages/rule-engine). Strip the bundle class and DI extension; port service definitions to a Laravel service provider with publishable config. Replace Doctrine repositories with Eloquent, or keep Doctrine DBAL if the rule persistence schema is already clean and stable. Preserve the evaluation core verbatim through the port so behavior can be diffed against the original in characterization tests.

Compatibility. Audit composer.json before writing a line of code. Expect Symfony 2.x/3.x pins, a PHP floor below 8.x, and Doctrine versions Laravel no longer tolerates. Check for each(), mcrypt, dynamic properties (PHP 8.2 deprecation), and legacy Doctrine query APIs. Budget an explicit modernization pass: typed properties, return types, null-safe operators, and a PHPUnit suite we author ourselves since none ships in this artifact.

Sequencing.

1. Spike (days, not weeks): clone, install in a scratch Laravel app, instantiate the rule domain classes directly without the kernel, and write characterization tests around evaluation.
2. Decision gate: extract vs. reimplement. Lean reimplement if the domain layer is small or heavily container-coupled — which is the likely outcome.
3. If extracting: publish internally, wire the service provider, port persistence, add config publishing and a migration path for rule definitions.
4. Shadow mode: run the new engine in parallel with existing hardcoded promotion logic in staging, log divergences, feature-flag per rule category.
5. Document rule semantics and context contracts as the internal spec — this document, not the package, becomes the durable asset.

Operational Impact

Maintenance. We own it fully and permanently. Read-only upstream plus a dormant project means no bug fixes, no security patches, no PHP/Symfony version support from anyone but us. Every PHP minor upgrade becomes a fork-rebase exercise. Price this into the build-vs-adopt comparison honestly — it is the dominant ongoing cost.

Support. The referenced Gitter, StackOverflow, and Twitter channels are stale; there is no maintainer, no SLA, and no escalation path. Every issue is an internal ticket assigned to whoever owns the fork. This is acceptable only if that owner is named before adoption, not after the first pricing bug.

Scaling. Rule evaluation sits in the request path during cart, checkout, and pricing — the worst possible place for latency surprises. Watch for: N+1 rule loading from persistence, repeated expression parsing on every request, and unbounded rule-set growth as merchandisers add promotions. Mitigate with compiled-rule caching keyed by rule version, per-context memoization, and benchmarks at realistic rule counts (hundreds, not tens) before go-live.

Failure modes.

• Malformed expressions throwing during checkout — customer-facing revenue impact.
• Undefined default semantics on evaluation error: fail-open discounts incorrectly, fail-closed blocks valid purchases. Both are expensive; pick deliberately and test both paths.
• Rule ordering/precedence bugs producing incorrect pricing or eligibility that surfaces only at specific cart compositions.
• Context shape drift: Elcodi assumes a specific e-commerce domain model (cart, product, currency, customer) that will not map cleanly onto our entities; adapters accumulate and rot.
• Partial rule-group failure: one group errors while others succeed, producing internally inconsistent totals.

Mitigation: make fail-open vs. fail-closed an explicit, tested policy per rule category; log every evaluation error with rule ID, context hash, and outcome; and add a circuit breaker so a rule engine failure degrades to last-known-good pricing rather than blocking checkout.

Ramp-up. Moderate for a competent Laravel team, higher than the code size suggests. The rule model itself is compact, but unpacking Symfony-era idioms and implicit Elcodi domain assumptions costs real time. Expect roughly 1–2 sprint-weeks for spike plus extraction, extending meaningfully if persistence is ported and PHP 8 modernization is required. Symfony DI familiarity helps conceptually and does not transfer cleanly to Laravel's container idioms.

TPM recommendation. Do not adopt this bundle as a runtime dependency in a Laravel application. Use it as reference architecture: spend a day reading the rule/condition/action decomposition, then design a minimal framework-agnostic engine on symfony/expression-language with Eloquent-backed persistence, owned internally. Revisit only if Elcodi revives with active maintenance and modern framework constraints, or if a maintained Laravel-native rules engine emerges.