- Can I install frontastic/rulerz-bundle in a Laravel 10 or 11 app?
- No. It is a Symfony bundle that registers RulerZ services through a Symfony container extension; it ships no Laravel service provider, facade, or publishable config. A modern Laravel 10/11 app pulls Symfony components 6.2/7.x, while the bundle targets old framework-bundle 2.7/3.x constraints, so Composer resolution will fail. For Laravel, evaluate kphoen/rulerz core behind your own adapter instead.
- What does frontastic/rulerz-bundle actually add on top of kphoen/rulerz?
- Only dependency-injection glue. The bundle wires the RulerZ compiler, targets, and operators into a Symfony container and exposes configuration for specifications and operators. Every product-facing feature — the DSL, array filtering, Doctrine ORM/DBAL pushdown, Elasticsearch targets — lives upstream in kphoen/rulerz. Treat this bundle as a reference implementation, not the capability itself.
- Does RulerZ work with Doctrine entities and query builders?
- Yes, through the underlying RulerZ engine. RulerZ compiles its small DSL into filters for plain arrays, Doctrine ORM entities and query builders, DBAL, and Elasticsearch queries, which covers eligibility, targeting, pricing, and segmentation rules. In the bundle those targets are registered via Symfony configuration; in Laravel you would register equivalent targets yourself in a service provider.
- Is frontastic/rulerz-bundle safe to run in production?
- High risk. The package has zero stars, zero dependents, a composite score around 0.03, and a vendor fork (Frontastic/commercetools) with no visible maintainer commitment. Upstream RulerZ is dormant, PHP 8.2/8.3 compatibility is unverified, and no one is shipping CVE fixes for transitive dependencies. Adopting it means absorbing every future PHP, Symfony, and Doctrine incompatibility yourself.
- How do I use RulerZ in Laravel for filtering arrays or Eloquent models?
- Require kphoen/rulerz directly and write a small service provider that binds the compiler as a singleton, plus a config file for target and operator registration. Array-target evaluation works immediately; pushing rules down to Eloquent/SQL or Elasticsearch needs a custom target you own. Add a RuleEvaluator contract and a compiled-rule cache keyed by hash(rule + target + version).
- Which PHP and Symfony versions does frontastic/rulerz-bundle support?
- The bundle targets old Symfony framework-bundle constraints (2.7/3.x), and PHP 8.2/8.3 support is unverified. It has no declared compatibility with the Symfony 6/7 components used by Laravel 10/11. If you experiment at all, pin an exact core version and record a PHP matrix in CI with PHPStan level 5+ as a gate.
- Can product managers author RulerZ rules without engineers?
- RulerZ is a DSL, not a rule builder. Rules are text authored in code and reviewed in pull requests; there is no admin UI, schema editor, or PM-facing authoring surface in this bundle. If self-service rule authoring is the actual goal, that layer is the real product investment and must be built separately on top of the compiler.
- What are alternatives to frontastic/rulerz-bundle for specification and business rules in PHP?
- The realistic options are kphoen/rulerz core behind a Laravel adapter, a roughly 500-line in-house specification engine you own outright, or existing framework primitives such as Symfony ExpressionLanguage or Laravel custom validation and filter chains. Weigh a dormant dependency plus a fork you maintain against the cost of owning a small, focused engine. For most teams the in-house engine is cheaper.
- How should I test and cache compiled RulerZ rules?
- Compile each rule once and cache the compiled artifact keyed by hash(rule + target + version) so cold-start cost is paid at deploy, not per request. Unit test three representative production rules against an array target and one DB target, and measure compile cost and latency in a one-week spike. Gate CI with PHPStan level 5+ and an explicit PHP version matrix.
- What happens if a RulerZ rule fails to parse in production?
- It depends entirely on where the rule sits. A failed parse in notification eligibility degrades a filter, but a failed parse in pricing or checkout can block revenue, so never migrate those surfaces first. Validate and compile all rules at deploy time, catch evaluation exceptions with a safe default, and feature-flag rule-driven paths.