Pel Bundle Laravel Package

Product Decisions This Supports

• Rules-as-configuration vs. hardcoded logic. PEL (PHP Expression Language) exists to evaluate string expressions safely at runtime — the substrate for pricing tiers, discount eligibility, promo stacking, feature-flag targeting, access-control conditions, and workflow guards that product wants to tune without a deploy. The bundle is the Symfony wiring for that capability, so it's relevant to any decision of the form "should business rules live in YAML/DB rather than in PHP?"
• Build vs. buy for a rules engine. PEL is a small, spec-style evaluator (parser + AST + evaluator), not a full engine. That makes the real decision "adopt a lightweight expression evaluator or hand-roll a DSL?" — PEL's design is a useful reference for scoping that build even if you don't adopt it.
• Deploy-cadence reduction in the roadmap. Expression-driven config shortens the loop between a pricing/promo change and production. Worth citing as a lever when leadership asks why engineering time goes to "plumbing" instead of features.
• Legacy Symfony surface area. Relevant only where you're deciding whether to keep, containerize, or migrate an existing Symfony app that already depends on it. It has zero bearing on greenfield product choices.
• Scope correction for this evaluation: the request framed this as a Laravel/PHP package. It is a Symfony bundle and is not usable as a Laravel package without rewriting the integration layer. Any Laravel roadmap item should treat this as out of scope.

When to Consider This Package

Consider it only under a narrow, unlikely conjunction:

• You are on a legacy Symfony 2.x/3.x-era application that already uses PEL, and you need the bundle to keep DI container / annotation integration working during a maintenance window.
• You specifically need PEL's semantics (not Symfony's ExpressionLanguage) — e.g., an existing expression corpus that depends on PEL-specific behavior — and re-writing those expressions is costlier than keeping the dependency.
• You are reading it as a reference implementation for how to wire an expression evaluator into a container, not shipping it.

Look elsewhere — which is the default recommendation — when:

• Maintenance and supply chain matter. 4 stars, 0 dependents, score 0.02 signals an effectively dead package. For a PM this is a one-way-door risk: no security patches, no PHP 8.x guarantee, no maintainer to escalate to.
• You want this capability on Laravel. Use symfony/expression-language directly (it's framework-agnostic and a common transitive dependency), or a dedicated rules library (rulerz, hoa/ruler), or a thin parser you own.
• symfony/expression-language is available. It is the maintained successor in the same lineage and is already a Symfony Framework dependency — adopting it costs you nothing in dependency surface, and PEL would cost you a second, unmaintained evaluator.
• Evaluation is security-sensitive or performance-sensitive. Expression sandboxing, compile/cache strategy, and per-request evaluation cost are product-visible (latency, tenant isolation). An unmaintained evaluator is the wrong place to accept that risk.

How to Pitch It (Stakeholders)

To executives: This is not a build recommendation. The capability it represents — business rules evaluated at runtime so pricing, promos, and entitlements can change without a release — is worth funding; this specific package is not the way to get it. Adoption numbers (4 stars, zero dependents, dormant) make it a maintenance liability with no offsetting benefit. Cost of the alternative is effectively zero because Symfony's own expression-language component is already in the stack.

To engineering: Treat kitano/pel-bundle as a historical artifact and reference implementation, not a dependency. symfony/expression-language supersedes PEL, is maintained, and is already transitively present in most Symfony apps — recommend it as the standard for any rules-as-config work, with a thin internal wrapper so we can swap evaluators later. If any service already depends on PEL, add a migration ticket rather than a new feature ticket; flag it in the dependency-risk review. For Laravel services, the bundle is a non-starter — plan on symfony/expression-language or an owned minimal evaluator.