- Does frontastic/rulerz-bridge work with Laravel?
- No. frontastic/rulerz-bridge is a Symfony bundle built around Symfony's DependencyInjection, tagged services, and compiler passes. Laravel does not consume those extension points, so installing it in a Laravel app adds Symfony dependencies without providing a Laravel service provider, facade, or config integration. The underlying RulerZ engine is framework-agnostic and can be used from Laravel directly, but the bridge itself is not a Laravel package.
- How do I install frontastic/rulerz-bridge in a Laravel project?
- You can run composer require frontastic/rulerz-bridge, but it will pull Symfony components into your Laravel application and still leave you without Laravel wiring. There is no service provider to register, so you would have to bootstrap the RulerZ executor and compilers yourself. For most Laravel projects it is cleaner to require the RulerZ core package and write a small service provider around it.
- What PHP and Laravel versions does frontastic/rulerz-bridge support?
- The README and composer.json constraints are the only source of truth, and this repository is a vendor bridge rather than a Laravel package, so there is no Laravel version matrix to check. You need to verify the PHP constraint of the bridge and of RulerZ core against your runtime, because bridges of this vintage often pin older Symfony and PHP versions. Treat any stated constraints as aspirational until you confirm them in CI.
- Can I use RulerZ specifications with Laravel Eloquent query builders?
- RulerZ can target query builders through its compiler system, but Laravel's Eloquent builder is not one of the compilers shipped by this bridge. The bridge's purpose is to compile RulerZ specifications into Frontastic-compatible filters, not Eloquent constraints. Using it with Eloquent would require a custom compiler or a translation layer, which is work you would own.
- What is the difference between RulerZ core and frontastic/rulerz-bridge?
- RulerZ core is the framework-agnostic rule parser, compiler, and executor; it is what actually evaluates specifications. frontastic/rulerz-bridge is a thin Symfony adapter that registers RulerZ services in a Symfony container and wires Frontastic's query layer. If you are on Laravel, the core is the part with reusable value; the bridge is a reference implementation of the wiring pattern.
- How do I define reusable specifications for promotions and eligibility rules?
- You define a specification as a class or rule string that describes a condition, then compile or evaluate it against a target such as a collection or query builder. The pattern keeps promotion, eligibility, pricing, and segmentation logic in one place instead of scattering if-statements. The bridge does not dictate your authoring model, so you still need to decide whether rules are PHP classes, stored strings, or config.
- Is frontastic/rulerz-bridge actively maintained and safe for production?
- Adoption signals are effectively zero: the repository has no meaningful stars, dependents, or issue history, and it is published primarily for Frontastic's own application. It is a single-vendor artifact with no stated support relationship for this repo, so archival or privatization would transfer maintenance to you. The code is thin and MIT-licensed, which caps abandonment cost, but that is also an argument for not taking the dependency.
- What are alternatives to frontastic/rulerz-bridge for rule-based filtering in Laravel?
- For Laravel teams the usual alternatives are RulerZ core with a small custom service provider, symfony/expression-language for simpler expressions, or plain Laravel policies, config flags, and query scopes when rules are static and engineer-owned. A full DSL and compiler layer is only worth it when rules change frequently, need to be stored, or must run consistently across multiple targets. The bridge itself is not an alternative for Laravel because of the framework mismatch.
- How should I test RulerZ rules before applying them to production queries?
- Test rules at two levels: unit-test the specification objects or rule strings, and integration-test the compiled output against representative data. RulerZ's in-memory array compiler is useful for dry-run previews and fast feedback, while production paths should be tested against the actual query target. The bridge does not provide a testing harness, so you own fixtures, validation, and regression cases for rule changes.
- Is it safe to let non-developers author RulerZ rules in an admin panel?
- The bridge does not solve rule safety. If rules can come from persisted config, an admin UI, or non-developers, you must allow-list operators, validate input, and cap complexity to prevent resource exhaustion or unintended query shapes. RulerZ compiles a DSL into query builders, so an untrusted rule is effectively untrusted query logic. That validation and authorization layer is the largest design obligation in the capability.