Rulerz Bundle Laravel Package

Technical Evaluation

Architecture fit. The leverageable asset is the RulerZ engine, not this bundle. RulerZ is a framework-agnostic specification/rules engine that compiles a small DSL into array filters, Doctrine ORM/DBAL queries, or Elasticsearch queries — a genuinely useful abstraction for eligibility, targeting, pricing, and segmentation logic. frontastic/rulerz-bundle is only the Symfony DI wrapper: a container extension plus service definitions that register the compiler, targets, and operators. All product-facing capability lives upstream in kphoen/rulerz. For a Laravel/PHP team, the bundle contributes essentially nothing you would not write yourself in a few hundred lines.

Integration feasibility. Low as delivered. The bundle targets Symfony bundles and old Symfony constraints (framework-bundle ^2.7/^3.x in all likelihood); a modern Laravel 10/11 app runs Symfony components ^6.2/^7.x, so Composer resolution will fail outright. There is no Laravel service provider, no publishable config, no facade — nothing that speaks Laravel's container lifecycle. The realistic path is to evaluate kphoen/rulerz core behind our own Laravel adapter, and treat this bundle as a reference implementation at best.

Technical risk. High. Zero stars, zero dependents, composite score 0.03, upstream RulerZ itself dormant, no maintainer to ship CVE fixes in transitive dependencies, unverified PHP 8.2/8.3 compatibility, and no community contract behind a Frontastic/commercetools vendor fork. Adopting it means being the first to absorb every future PHP, Symfony, and Doctrine incompatibility with no upstream absorbing that cost alongside us.

Key questions.

1. Is the product decision "adopt RulerZ as a capability" — or "adopt this bundle"? These are separate decisions, and only the first has any upside.
2. Does the core library install and run on PHP 8.2+ today, and does the DSL cover our top three production rule types (eligibility, targeting, catalog filter)?
3. Which targets actually matter — array-only evaluation, or pushdown to Eloquent/SQL/Elasticsearch? This drives both latency and where the authoring surface lives.
4. Who authors rules: engineers in code review, or an admin/PM surface we must build ourselves? RulerZ is a DSL, not a rule builder — if self-service is the goal, the authoring layer is the real product investment.
5. If the core library is stale, is a ~500-line in-house specification engine cheaper to own than a dormant dependency plus a fork we maintain?
6. What is the blast radius if a rule fails to parse in production — a blocked checkout, or a degraded filter?

Integration Approach

Stack fit. Laravel 10/11, PHP 8.2+, MySQL/Postgres, Redis for cache. Verdict: do not install this bundle. Either adopt kphoen/rulerz core behind a Laravel adapter, or build the minimal specification engine we actually need and own it outright. The Frontastic bundle is an implementation detail; the product decision is "adopt RulerZ?"

Migration path.

1. Spike (1 week). On a throwaway branch, composer require kphoen/rulerz alone; confirm PHP 8.2+ install and runtime. Compile and execute three representative production rules against an array target and, if relevant, one DB target. Measure compile cost and cold-start latency.
2. Internal adapter (1–2 weeks). Ship a private acme/rulerz package: a RulerzServiceProvider binding the compiler as a singleton, config/rulerz.php for target and operator registration, a thin RuleEvaluator contract, and a compiled-rule cache keyed by hash(rule + target + version).
3. Domain migration (2–4 weeks, opportunistic). Replace hardcoded filter chains one domain at a time, starting with the lowest-risk surface (e.g., notification eligibility), never pricing or checkout first.
4. Authoring tooling (last). Only after two domains prove the pattern, and only if the business actually wants PM-authored rules.

Compatibility. Pin an exact core version; record the PHP matrix explicitly in CI; run PHPStan (level 5+) as a gate so PHP 8 regressions surface at build time. Add an architectural test asserting no Symfony DI classes leak into the application layer, and a schema assertion test so rules referencing renamed columns fail in CI, not at runtime.

Sequencing. Spike → go/no-go → adapter package → first domain migration → authoring tooling. This order is the cheapest-to-reverse sequence. Starting with a rule-builder UI is the most expensive and least reversible choice on the table.

Recommendation. Skip this bundle. Evaluate the RulerZ core in a one-week spike; if it is stale on PHP 8, build the small subset we need and own it. If ecosystem constraints ever force us to depend on Frontastic packages transitively, revisit — but do not adopt a 0-star, 0-dependent fork voluntarily.

Operational Impact

Maintenance. Adopting the bundle inherits fork tax: budget 2–5 engineer-days per quarter for PHP upgrades and dependency security review, or formally vendor/fork and own the code. With zero dependents, no upstream community is absorbing any of that cost for us.

Support. No vendor, no maintainers, no issue triage. Operational knowledge will concentrate in the one or two engineers who run the spike — a single point of failure. Mitigate with a written runbook, a rule-authoring test harness, and at least two engineers who understand the rule execution path before a second domain goes live.

Scaling. Cache compiled rules aggressively; uncached compilation per request will dominate latency in hot paths. The critical scaling decision is where evaluation happens: SQL/Elasticsearch pushdown scales with the datastore, while array-target evaluation in PHP pulls rows into memory and scales with table size. Enforce a per-request rule-count and rule-complexity ceiling as a monitored metric, not a convention, and warm the compile cache in the deploy pipeline to avoid post-deploy latency spikes.

Failure modes to instrument.

• Parse failure at runtime — a malformed rule throws mid-request; requires write-time validation plus a safe fallback path.
• Silent PHP-side filtering — a target mismatch causes full-table reads instead of filtered queries; alert on rows-scanned and query duration per rule.
• Compile cache stampede — cold cache after deploy or cache eviction; warm on release and monitor hit rate.
• Rule/datastore divergence — rules referencing renamed fields; assert schema in CI.
• DI wiring breakage — container or operator registration silently dropping after an upgrade; cover with a boot-and-evaluate integration test.

Ramp-up. The RulerZ DSL is a new syntax for the team and effectively a hard blocker for product managers authoring rules directly. Expect 1–2 weeks of engineering ramp-up plus real investment in documentation and a rule linter before anyone outside engineering touches it. If the actual product goal is self-service rules for PMs and marketers, the authoring layer — not this bundle, and arguably not RulerZ itself — is the real product investment and should be priced separately before any commitment.