- How do I install webmozart/expression in a Laravel application?
- Install it with Composer using composer require webmozart/expression. It does not require a Laravel service provider, facade, configuration file, or migrations. Pin the version explicitly and commit the lockfile. Because the last release was in 2015, prove runtime compatibility with your target PHP and Laravel versions through tests rather than assuming installation success.
- Does webmozart/expression work with Laravel 10 or 11 and PHP 8.x?
- There is no official evidence of modern Laravel or PHP 8.x/9.x validation for this package. It is framework-agnostic, but its last release predates modern Laravel and PHP runtimes. Composer may resolve it because of loose historical PHP constraints, but runtime compatibility must be proven with a test matrix. Check for deprecations, static analysis failures, and PHPUnit behavior under your exact target versions.
- What is webmozart/expression used for in Laravel domain code?
- It implements the Specification pattern with composable comparison, logical, arithmetic, and value nodes. It is useful for named, reusable, in-memory business rules such as eligibility checks, pricing conditions, or rule-based workflows outside controllers and Eloquent models. It is not suitable for database filtering because expressions are evaluated in PHP, not translated to SQL.
- Can webmozart/expression replace Laravel validation rules or Gates and Policies?
- No, it is not a replacement for Laravel validation, Gates, Policies, or query scopes. It overlaps with those native features and should only be considered for complex reusable in-memory domain rules. For most Laravel authorization and input-validation needs, framework-native tools are simpler and more maintainable. Use this package only where the Specification abstraction clearly earns its keep.
- Is webmozart/expression safe for production in a Laravel app?
- It carries high technical risk because it is effectively unmaintained, with a last release in 2015, an unknown repository, and a reported score of 1.47. Risks include PHP 8+ deprecations or fatal errors, Composer resolution conflicts, stale documentation, and no security response. If adopted, vendor or fork the code, wrap it behind an internal interface, add CI coverage, and pilot it on a non-critical rule set before production use.
- How do I test webmozart/expression expressions in Laravel with PHPUnit?
- Unit test composite expressions with PHPUnit, including truth tables and edge cases for nested logical and arithmetic nodes. Wrap the package behind an application-owned Specification or Rule contract so tests target your interface rather than the abandoned dependency directly. Include compatibility tests across your target PHP and Laravel matrix, plus static analysis and deprecation checks. Add regression tests for composite expressions if the rules affect pricing, eligibility, compliance, or authorization.
- Should I use webmozart/expression for filtering Eloquent queries?
- No, webmozart/expression evaluates rules in PHP and does not translate expressions into SQL. For database filtering, use Eloquent where clauses, query scopes, or dedicated query builders. In-memory expressions can be applied after fetching data, but that does not scale well for large datasets. Push filtering into SQL whenever possible and keep this package for in-memory domain rules.
- What are alternatives to webmozart/expression for the Specification pattern in Laravel?
- Laravel-native validation rules, Gates, Policies, query scopes, custom rule objects, and simple PHP predicates cover many use cases with less dependency risk. For a dedicated specification abstraction, consider a maintained package or a small internal expression implementation owned by your team. If you only need a subset of webmozart/expression, forking the minimal required classes under your organization's namespace may be safer. Favor maintainability and clear ownership over pattern purity.
- Does webmozart/expression require a Laravel service provider or configuration?
- No, it is a framework-agnostic PHP library with no Laravel service provider, facade, configuration, or migrations. You install it via Composer and use its classes directly in your domain or service layer. If you want container integration, bind it behind your own application-owned interface in a service provider, but the package itself does not require that. Keep the integration isolated so it remains replaceable.
- How do I decide whether to adopt or fork webmozart/expression?
- First confirm the business rule use case and whether Laravel-native validation, policies, or query scopes already solve it. Spike the package in a throwaway branch against your exact PHP and Laravel matrix, wrap it behind an internal interface, and pilot one non-critical rule set. Because the package is abandoned, decide whether to keep, fork, or replace it based on compatibility results and maintenance ownership. If adopted, vendor or fork the code, pin the version, commit the lockfile, and add CI coverage before production.