Weave Code
Php Expression Laravel Package
kitano/php-expression
kitano/php-expression is a lightweight PHP library for parsing and evaluating expressions safely without eval. It supports variables, operators, and functions, making it useful for dynamic formulas, rules, and configurable logic in PHP applications.
PHP Expression Language
Frequently asked questions about Php Expression
- How do I install kitano/php-expression in a Laravel app?
- Install it with composer require kitano/php-expression. There is no service provider, facade, config file, or migration to publish, because the package is framework-agnostic plain PHP. Wrap it in your own adapter class and bind that in Laravel's container so controllers, models, and jobs never touch package classes directly.
- Does kitano/php-expression work with Laravel 10 and Laravel 11?
- The package contains no Laravel-specific code, so compatibility is governed almost entirely by the PHP version constraint in its composer.json rather than by the Laravel release. Check that constraint against the PHP version your Laravel install runs, then cover it with your own tests. Because there is no service provider or facade, there is nothing to break on a Laravel upgrade beyond PHP-level changes.
- Is kitano/php-expression safe for user-supplied expressions?
- Be careful here: the package parses an expression into an AST, compiles it to a PHP code fragment, and evaluates that fragment, so the 'no eval' framing in the description should not be repeated in a security review. Safety rests entirely on the grammar being tight enough that generated code can only reference allowlisted variables and never arbitrary function calls, static calls, backticks, or object access. That is testable with a negative suite attempting system(), backticks, new, static calls, and superglobals, and it must be tested. Expressions authored by end users or tenants should not be accepted without a hardened sandbox, strict variable allowlisting, complexity limits, and a second review.
- How does kitano/php-expression compare to symfony/expression-language?
- Both parse expressions with variables, operators, and custom functions, but symfony/expression-language has far broader adoption, documented sandboxing, and long-term commercial-backed support behind it. kitano/php-expression is much smaller, easier to read, fork, or vendor, and MIT licensed, but its adoption signals are weak. Compare grammar safety, sandboxing, performance, and maintenance commitment before standardizing on either.
- Can I cache compiled expressions instead of parsing on every request?
- Yes, and you should. The compile-once, evaluate-many workflow is the library's intended pattern: compile the expression to a fragment, cache the compiled artifact, and evaluate it with different variable sets. Key cache invalidation on both the expression source and the installed package version, so a dependency upgrade cannot leave stale compiled code behind. Never re-parse on hot paths such as pricing, checkout, or notification triggers.
- How do I add custom functions and variables to an expression?
- Variables and custom functions are supplied through the evaluator, so you can register domain helpers without editing anything in src/. Keep the allowlist of permitted function names and variable keys in a Laravel config file so the security posture is reviewable in one place. Confirm the exact extension API against the source, since documentation is sparse, and add tests that assert disallowed functions are rejected.
- What happens when an expression has a syntax error or fails at runtime?
- Failures can surface as a ParseError from the generated fragment, or as an Error or Exception thrown during evaluation, depending on where things break. Catch all of them inside your evaluator adapter and map them to domain-specific exceptions with the expression source and inputs attached for debugging. Never let a bad compiled fragment escape as a 500, especially on pricing or eligibility paths where a silent wrong answer is worse than an outage.
- Is kitano/php-expression actively maintained?
- Adoption signals are weak: roughly 30 GitHub stars, no known dependents, no commercial support, and a repository profile that looks dormant rather than mature. It is MIT licensed and small enough to read, fork, or vendor, which is the real mitigation. Pin the version, watch the issue tracker, and be prepared to maintain a fork if the package stalls.
- Which PHP and Laravel versions are supported and tested?
- Check the require constraint in the package's composer.json, since that is the only real compatibility gate for a framework-agnostic library. Do not assume a CI matrix covering PHP 8.2 or 8.3 and current Laravel; verify it or run those versions in your own pipeline. Because the library generates PHP code fragments, retest after every PHP upgrade rather than assuming generated code stays valid.
- How should I structure kitano/php-expression in a Laravel codebase?
- Bind a single RuleEvaluator or ExpressionEvaluator interface in the container and keep package classes out of controllers, models, jobs, and Blade templates. Put allowed variables, allowed functions, and complexity ceilings in a config file, and centralize logging, timing, caching, and error mapping in that one adapter. That boundary is also where a future sandbox or a swap to symfony/expression-language would live.
Weaver
How can I help you explore Laravel packages today?