Rule Engine Bundle Laravel Package

Product Decisions This Supports

• Build vs. buy for configurable business logic. A rule engine is the standard answer to "the business wants to change eligibility/pricing/approval criteria without a deploy." This package represents one implementation of that pattern — event-driven rule evaluation on top of Symfony's ExpressionLanguage — and is most useful as a reference design, not as a dependency.
• Where policy should live. It supports the decision to extract hardcoded conditionals (discount tiers, fraud thresholds, routing rules, feature gating, notification triggers) into declarative expressions owned by ops/product rather than engineering.
• Roadmap sequencing. If rule churn is a recurring roadmap tax (every promo = a ticket + release), that's a signal to invest in a rules layer this quarter rather than staff around it.
• Vendor/platform evaluation. Gives you a concrete comparison point against hosted alternatives (LaunchDarkly/Flagsmith for flags, Drools or a rules SaaS for heavier decisioning) and against the do-nothing option (keep writing if statements).
• Important caveat for the decision record: this specific artifact does not enable those outcomes today. Last release April 2018, 6 stars, 0 dependents, and it is a Symfony bundle, not a Laravel package — it ships no service provider, no config publishing, no Laravel integration. The decision it supports is "adopt the pattern, reject the dependency."

When to Consider This Package

Consider it only when all of the following hold:

• You are on Symfony (the bundle's EventDispatcher + ExpressionLanguage wiring is the entire value), not Laravel. For Laravel, the bundle is inert; you would need to write an adapter anyway.
• You are pinned to a legacy Symfony/PHP line where the 2018-era APIs still resolve, or you are willing to fork and maintain.
• You need exactly the thin primitive it offers: register rules, fire an event, evaluate expressions, dispatch outcomes. Nothing more.
• You are evaluating the underlying intaro/rule-engine library rather than the bundle — that's the reusable piece.

Look elsewhere (or just build it) when:

• You are on Laravel. Add symfony/expression-language directly plus a small service provider and a Rule model — roughly a day of work, fully maintained, no bundle baggage.
• Maintenance matters. Seven years stale, zero dependents, no security response path. ExpressionLanguage's evaluation/caching API and the symfony/event-dispatcher-contracts interfaces have both moved since.
• Expressions are user-authored. ExpressionLanguage is not a sandbox; evaluating untrusted input is an injection vector. Any multi-tenant or admin-editable rule authoring needs a hardening layer this package does not provide.
• You need authoring UI, versioning, simulation/dry-run, or decision audit logs. None of that is here; it's the part that actually costs money and time.
• You need real decisioning throughput. This is a synchronous in-process evaluator, not a rules service.

Net: the honest cost comparison is "adopt an unmaintained bundle" vs. "write ~200 lines against a maintained first-party component." The second wins on every axis except day-one effort.

How to Pitch It (Stakeholders)

To executives: There's a category of product capability — letting the business change eligibility, pricing, and routing rules without engineering releases — that we should have on the roadmap. This package is an old, unmaintained implementation of that idea: last shipped in 2018, effectively zero adoption, and built for a different framework than ours. I'm not recommending we take the dependency. I am recommending we note the pattern and budget a small, contained build against a maintained component, or evaluate a managed feature-flag/rules service if the need is broad. Expect the build to be small; expect the authoring, versioning, and audit surface to be the real investment.

To engineering: intaro/rule-engine-bundle evaluates ExpressionLanguage expressions in response to dispatched events. It is a Symfony bundle — no Laravel integration — last released 2018, 6 stars, 0 dependents, and predates current ExpressionLanguage and event-dispatcher contract APIs. Recommendation: do not adopt. If we want this capability, vendor symfony/expression-language (actively maintained, already in our dependency graph) behind a RuleEvaluator service with rules stored in a table, and keep evaluation server-side only — never on user-supplied strings without a whitelist. Rough effort: 1–2 days for the core, plus whatever we choose to spend on authoring and audit.