- What is frontastic/rulerz and what problem does it solve?
- frontastic/rulerz is a PHP rule engine that implements the Specification pattern, letting you define business rules once as readable DSL expressions, closures, or Specification classes and reuse them across data sources. The same rule can be evaluated in memory over arrays, compiled to SQL or DQL through Doctrine, or translated into Elasticsearch DSL by target-specific visitors. It is lightweight and framework-agnostic, which means it fits the domain layer of a Laravel app but ships no Laravel-specific plumbing.
- How do I install frontastic/rulerz in a Laravel application?
- Install it with composer require frontastic/rulerz, then bind the engine in a Laravel service provider as a singleton behind your own narrow interface, for example SpecificationEngine::filter(iterable $items, Specification $spec): iterable. Keeping controllers and models off the library directly makes it easier to swap the engine later. The package ships no service provider or config file, so all wiring is your responsibility.
- Does frontastic/rulerz support Laravel Eloquent query builders?
- Not out of the box. The package ships Doctrine and array targets, but Illuminate\Database\Query\Builder needs a custom Target or visitor, roughly 200 to 400 lines of work, or a DBAL bridge. In-memory filtering over Laravel Collections works today, so start there unless query pushdown is genuinely required for the first use case.
- Which Laravel and PHP versions does frontastic/rulerz support?
- There is no published PHP or Laravel compatibility matrix, so treat official support as unverified until you check the repository's CI. The evaluation assumes PHP 8.2+ with Laravel 10, 11, or 12, and recommends adding your own PHPUnit and PHPStan matrix at adoption time. Upstream heritage in hoa/ruler and hoa/compiler has known PHP 8.x friction, which this fork likely exists to patch, so test on your target PHP version early.
- What are common use cases for a rule engine like this in a Laravel app?
- Typical uses are eligibility and segmentation rules, pricing and discount logic, dynamic access control, and translating admin UI filter input into consistent predicates. The value is defining a rule once and applying it to arrays, Doctrine queries, or other data sources instead of scattering conditionals across controllers and models. In a Laravel pilot, in-memory filtering over Collections is the cheapest first use case.
- How does frontastic/rulerz relate to K-Phoen/rulerz, and is it maintained?
- frontastic/rulerz is a fork of K-Phoen's RulerZ implementing the Specification pattern, and it appears to exist mainly to patch PHP 8.x friction in the hoa/ruler and hoa/compiler dependencies. It is effectively a single-maintainer fork with no stars, no dependents, and no known consumers, so longevity and supply chain are the dominant risks rather than code quality. Before adopting, diff it against upstream to see what changed, pin a commit SHA, and consider vendoring it with your own CI.
- Is the RulerZ DSL safe to expose to end users?
- If the DSL is authored by developers behind your own interface, the risk is low. If end users can save or edit rules, treat the expression string as untrusted input: restrict operators with an allowlist, confirm the compiler binds parameters rather than interpolating them, and cap expression complexity to prevent denial-of-service. The evaluation flags user-supplied DSL as a medium injection and DoS surface.
- How should I test specifications and rules built with frontastic/rulerz?
- Write PHPUnit tests against Specification objects and assert the same result sets across every target you rely on, which guards against behavioral drift between in-memory and query-based evaluation. Add PHPStan to your CI matrix alongside PHPUnit to catch signature drift when the library or its transitive dependencies change. Contract tests per target are the practical way to detect when an operator or spec cannot be translated by a visitor.
- What are alternatives to frontastic/rulerz for business rules in PHP?
- symfony/expression-language is a strong alternative that can sit behind the same Compiler interface and is far better maintained, though it lacks ready-made Doctrine or Elasticsearch targets. A hand-rolled predicate tree or plain Specification objects over Laravel Collections may be enough if you only need in-memory filtering. K-Phoen/rulerz is the upstream project, and Laravel's own validation and pipeline primitives cover simple rule cases without any DSL.
- Can frontastic/rulerz filter in-memory collections and Doctrine queries with the same rule?
- Yes in principle: the same rule can run in memory over arrays and Collections, compile to SQL or DQL through the Doctrine target, and translate to Elasticsearch DSL through a target-specific visitor. Coverage differs per target, and the Elasticsearch visitor supports only a subset of the DSL, so document the supported operators and fail loudly on untranslatable specifications. Contract tests asserting identical result sets per target are the recommended guard against behavioral drift.