Rulerz Bundle Laravel Package

Product Decisions This Supports

• Feature-level: rules as data instead of hardcoded conditionals. The underlying engine (RulerZ) lets teams express eligibility, targeting, and filtering logic in a compact DSL and compile it to Doctrine ORM/DBAL queries, Elasticsearch queries, or in-memory array filters. One abstraction maps to several product surfaces: promotion/coupon stacking, tier and entitlement gating, seller or marketplace eligibility, audience/content targeting, and admin-defined catalog filters.
• Build vs. buy for a "rules layer." The real comparison is hardcoded if/else (cheap today, costly at the third rule change), a commercial BRMS or feature-flag SaaS (real money, real lock-in, but authoring UI and audit included), or an in-house DSL (highest cost, highest fit). RulerZ sits in the middle: free and expressive, but you own the authoring UX and operational tooling around it.
• Roadmap: one rules surface vs. N bespoke implementations. If two or more teams independently implement "is this customer eligible," standardizing on a shared rule representation is a defensible platform investment. The compile-to-multiple-datastores property is the strongest argument — the same rule filters SQL for admin lists and Elasticsearch for the storefront.
• What this specific package decides: almost nothing. frontastic/rulerz-bundle is Symfony DI wiring for RulerZ, not the engine. It is a vendor fork (Frontastic, now part of commercetools) with 0 stars, 0 dependents, and a near-zero opportunity score. The product decision is "adopt RulerZ?" — and this bundle is an implementation detail to be resolved by engineering, almost certainly in favor of the upstream k-phoen/rulerz-bundle.
• Stack caveat that shapes the decision. Despite the framing, this is a Symfony bundle, not a Laravel package. On a Laravel 10/11 codebase it will not install cleanly (Symfony component constraints conflict), does not register a service provider or facade, and offers no Laravel container lifecycle integration. Any value here is in the engine, not this wrapper.

When to Consider This Package

Consider it only if: you are already inside the Frontastic/commercetools package ecosystem and need version parity with their stack; or you are on Symfony with RulerZ already in the codebase and this fork is what your dependency graph resolved to.

In every other case, look elsewhere:

• New adoption → use upstream. k-phoen/rulerz plus k-phoen/rulerz-bundle is the maintained lineage with actual community usage. A 0-star, 0-dependent fork provides no independent security response path, no upgrade path separate from the vendor, and no reason to be in your composer.json.
• Laravel shop — the bundle adds nothing; you would need to write the service provider and config yourself, at which point you are just wrapping the core library.
• Non-developers must author rules. RulerZ gives you a DSL, not a rule-builder UI, versioning, approval workflow, dry-run/simulation, or evaluation audit trail. If PMs or marketers are the intended authors, you are committing to build a BRMS-lite around it — price that in before signing up.
• High-throughput or latency-sensitive evaluation. Compiling rules per request against a datastore can be fine, but measure it. Hot-path evaluation at scale is better served by cached/compiled queries or a dedicated engine.
• Low tolerance for unmaintained dependencies. Zero dependents is the signal that matters: no one else is absorbing upgrade cost, so you will be first to hit every PHP, Symfony, and Doctrine incompatibility.
• You need SLAs, support, or indemnity — MIT OSS fork, none of that exists.

How to Pitch It (Stakeholders)

To executives: There is a small, MIT-licensed capability — a rules engine called RulerZ — that would let us express eligibility and targeting logic (who gets which price, promotion, or content) as configurable rules rather than code changes, shortening the loop between a commercial idea and shipping it. It is not a platform purchase and is easily reversed. However, the specific package in front of us is a vendor fork with effectively zero community footprint, and it targets Symfony rather than our Laravel stack. My recommendation is to approve a one-week spike against the upstream project rather than commit to this fork. The decision is cheap now and only gets expensive if we later build a rule-authoring UI on top of it — which is a separate, larger call.

To engineering: This is a Symfony bundle that registers RulerZ's compiler and specification services in the container — small surface area, quick to prototype against, and essentially a reference implementation of the wiring we would write ourselves. The catch is maintenance: 0 stars, 0 dependents, pinned to Frontastic's stack, no response path for CVEs or Symfony/PHP majors, and it will not install cleanly on Laravel 10/11. Proposal: treat the bundle as documentation only; spike on k-phoen/rulerz core to confirm it runs on PHP 8.2+ and that the DSL covers our top three rule types; then ship a thin internal adapter (service provider, config, RuleEvaluator contract, compiled-rule cache). Keep rule definitions storage-agnostic so swapping the engine later stays cheap, and fall back to this fork only if we are already transitively dependent on Frontastic packages.

Net recommendation: Evaluate RulerZ as a capability via the upstream library; do not adopt this bundle as a dependency unless ecosystem constraints force it.