Pel Bundle Laravel Package

Technical Evaluation

Architecture fit — This is not a Laravel package; it is a Symfony bundle. KitanoPelBundle is a Bundle subclass with a DI extension and a kitano_pel configuration tree, loaded through Symfony's kernel. Laravel has no concept of bundles, no AppKernel, and its service container does not honor Symfony's Extension::load() / compiler-pass lifecycle. Nothing in this repository is dropped into a Laravel app without rewriting the glue.

Integration feasibility — Three options, in descending order of cost:

1. Run Symfony's DI component inside Laravel to boot the bundle — not viable; you would be maintaining a second container and container-bridge for one expression evaluator.
2. Port the bundle's glue (roughly a few hundred lines: service definitions, config normalization, the expression-language factory) into a Laravel service provider. Feasible but pointless — the glue is the only thing the bundle adds.
3. Skip the bundle entirely and depend on symfony/expression-language directly. It is a standalone component with no framework coupling, works in Laravel unchanged, and is the direct successor to PEL. This is a 1–2 hour task.

Technical risk — High, on multiple axes:

• Superseded technology. PEL (PHP Expression Language) predates Symfony's official ExpressionLanguage component (shipped in Symfony 2.4, 2013). The official component occupies the same niche, has the same class of API, and is actively maintained.
• Abandonment signal. 4 stars, 0 dependents, composite score 0.02. That is a package nobody in the ecosystem depends on. Expect PHP 5.x-era constraints, no PHP 8 support, no security response, and a dead issue tracker.
• Low ceiling on value. The bundle's entire contribution over the underlying library is container wiring. You are not buying functionality; you are buying a configuration convention for a framework you are not using.

Key questions for the requester

• Is PEL a hard compatibility requirement (existing expressions in production, a partner system emitting PEL), or was it simply the evaluator that was available when the feature was scoped?
• Which expression features are actually needed — arithmetic, boolean logic, comparisons, property/array access, method calls, custom functions?
• Who authors expressions: developers (trusted config) or end users (untrusted input)? This drives the sandboxing decision far more than the library choice.
• What is the target PHP version, and is there any legacy service written against Kitano bundles that needs interop?
• Is there existing Symfony code in the estate, or is this an all-Laravel shop? If all-Laravel, the bundle has no natural home.

Integration Approach

Stack fit — Target Laravel 9/10/11 on PHP 8.1+. symfony/expression-language is a framework-agnostic Composer dependency that installs cleanly alongside Laravel; its transitive footprint is small (Contracts, Cache for parsed-expression caching). Syntax is PEL-compatible in practice — literals, operators, and/or/not, ternary, in/not in, matches, array/attribute access, and function calls all carry over. API surface differs modestly: ExpressionLanguage::evaluate($expr, array $values) and ->compile($expr) versus PEL's compiled-expression objects.

Migration path (only if PEL expressions already exist in production)

1. Inventory every expression string and every custom function/provider registered with PEL. This list is the actual spec.
2. Add symfony/expression-language; register an ExpressionFunctionProviderInterface implementation per domain (e.g., pricing, eligibility) rather than one global function bag.
3. Re-implement custom functions as ExpressionFunction instances; the compiler callback is required if you intend to compile.
4. Where PEL syntax diverges, put a thin PricingExpression adapter in app/Support/ that translates and delegates — do not fork the bundle.
5. Shadow-run: evaluate both engines over a sampled corpus of real expressions/inputs in staging and diff results before cutover.

Compatibility — Bind the evaluator as a singleton in a service provider; inject it by constructor or interface (ExpressionEvaluator) so it stays swappable and mockable in tests. Do not expose a Facade — it invites static calls into what should be an injected policy boundary. Pin the component major/minor in composer.json and let Dependabot track it.

Sequencing

1. Confirm expression inventory and trust model (1 day).
2. Add component + provider + interface binding (0.5 day).
3. Port custom functions, with unit tests per function (1–3 days, proportional to function count).
4. Compile-and-cache layer keyed by expression hash + provider version (0.5 day).
5. Shadow-run in staging, diff, cut over, then remove PEL and its bundle from composer.json (1 week elapsed, mostly observation).

Total: roughly one engineer-week, versus days-to-weeks of archaeology plus permanent ownership if the bundle is adopted.

Operational Impact

Maintenance — Adopting the bundle transfers upstream maintenance to your team permanently: PHP 8 compatibility, Composer constraint drift, and any security issue in a dependency with no release cadence. The Symfony component is maintained by the Symfony core team with a published LTS and security-advisory process. On a 0.02-score package, the fork cost is not hypothetical — it is the default outcome.

Support — No vendor, no SLA, effectively no community. Debugging lands on whoever is on call. The Symfony component has first-party documentation, a large Stack Overflow corpus, and staffable expertise in the market.

Scaling — Expression parsing dominates cost, not evaluation. Compile once and cache the compiled form (storage/framework/cache, keyed by hash of the expression plus a provider-version salt so function changes invalidate cleanly). Compilation turns evaluation into cheap PHP; without it, you pay a lexer/parser pass on every request. Memory is negligible; the real scaling constraint is CPU under high-cardinality expression sets, which caching resolves.

Failure modes to instrument

• SyntaxError on malformed input — catch and map to a 422/validation error, never a 500. Log the expression text (truncated) and the author.
• \Error/\TypeError from accessing absent array keys or properties — normalize the value bag defensively or require ??-style guards in expressions.
• Unbounded expression length or nesting — enforce a max length and node-depth cap at the input boundary.
• Security: ExpressionLanguage is not a sandbox. It cannot execute arbitrary PHP, but it can call any function you register and any method on objects you pass in. Only whitelist functions, never pass Eloquent models or container objects as values, and never evaluate user-supplied expressions with a full function set. This risk is identical under PEL, so the bundle buys no safety.
• Stale compiled cache after a function change — the version salt in the cache key is the mitigation; missing it produces silent wrong answers, which is the worst failure class here.

Ramp-up — With the Symfony component: half a day for a mid-level Laravel engineer to be productive, one day to be fluent in compile/cache and custom function registration. With the bundle: days of reading Symfony DI conventions that have no analogue in the target stack, followed by indefinite ownership. Team familiarity with Symfony's container is a prerequisite the bundle silently assumes.

Recommendation — Reject kitano/pel-bundle. It is a Symfony-only glue layer around a superseded expression library, with abandoned-package risk signals (4 stars, 0 dependents, 0.02 score) that no amount of internal effort fixes. Adopt symfony/expression-language directly behind an injected interface, port only the custom functions you actually use, and compile-and-cache from day one.