Ruler Bundle Laravel Package

Technical Evaluation

Architecture fit. The underlying model fits well in the abstract: rule evaluation is a pure function of a context array returning a boolean, with no persistence, no session state, and fully deterministic output. That shape is a good fit for embedded policy decisions — feature gating, entitlement checks, eligibility gates, promotion logic — where a TPM wants a single auditable decision layer instead of scattered if branches. What does not fit is the bundle layer itself: it is Symfony 2 dependency-injection wiring (service definitions, a config tree, possibly a profiler collector), all of which a Laravel product would discard. Net reusable assets are the evaluation model and the idea of declarative, config-declared rule sets. Everything else is dead weight.

Integration feasibility — the framing problem to surface first. This is not a Laravel package. There is no service provider, no facade, no publishable config, no Laravel version constraint. It targets Symfony 2 and is not an installable dependency for a modern Laravel application. Treating it as "add to composer.json and go" is the single most likely way to burn a sprint on this evaluation. The realistic path is to consume the underlying Ruler library directly, or — better — reimplement the ~150–300-line evaluation core as a framework-agnostic domain primitive and bind it Laravel-natively with one provider and one config file.

Technical risk — high, and mostly non-technical.

• Symfony 2 reached end of life in 2018; the bundle almost certainly pins Symfony 2.x and carries PHP 5.3-era syntax and PSR-0 autoloading. Expect it not to resolve on PHP 8.2+ without a fork.
• 26 stars, 0 dependents, no visible maintenance cadence. Assume no security patch pipeline, no PHP 8 path, no issue triage.
• The opportunity score (0.22) is consistent with the ecosystem signal: low strategic leverage. This is a pattern donor, not a platform bet.
• The engine is intentionally minimal: no persistence, no rule versioning, no rete/inference, no decision tables, no hot reload, no authoring UI, no result provenance. Appropriate for roughly a hundred engineer-owned rules; not a BRMS and should not be pitched to business stakeholders as one.

Key questions before any commitment.

• License, last commit/tag date, and whether a released version exists at all.
• Exact composer constraints (php, symfony/*, the wrapped engine) — run composer why-not against the target stack.
• Does the bundle do anything beyond services.yml wiring — compiler pass, config tree, data collector, console command? This determines whether any code is worth reading.
• Are rule sets config-declared or code-only? Any validation or dry-run tooling?
• Do the tests encode operator semantics (type coercion, precedence, short-circuit order)?
• Is the wrapped Ruler library maintained independently, and at what version?

Integration Approach

Stack fit: none directly. Do not install rezzza/ruler-bundle into a Laravel application. There is no supported path, and forking an EOL Symfony bundle to shim it into Laravel's container is strictly worse than a short port.

Recommended path — port the pattern, not the package.

1. Extract the model. Reimplement the evaluation core as a framework-agnostic domain class (RuleSet, Rule, Operator, evaluate(array $context): Decision). Target ~150–300 lines, PHP 8 typed, no framework imports, no container awareness. This is the highest-leverage move and costs days, not weeks.
2. Bind it Laravel-natively. One service provider, one publishable config file for rule-set registration, one interface for consumers to inject, optionally a facade for terse call sites. That is the entirety of what the Symfony bundle gave its users.
3. Source rule definitions from versioned fixtures (PHP arrays or JSON) rather than Symfony config trees, so rules are diffable, reviewable, and testable independently of application code.

If an off-the-shelf engine is preferred, take the underlying Ruler library as a standalone dependency and skip the bundle — but verify PHP 8 compatibility first, since the library is as old as the bundle.

Migration path. There is nothing to migrate from: no runtime, no data, no state. The work is greenfield authorship plus, where scattered if/else policy code already exists, a strangler refactor of those branches into named rules wrapped in golden-case tests.

Compatibility checklist. PHP version support, PSR-4 autoloading, operator type-coercion behavior under PHP 8 (string/numeric comparisons shifted subtly across 7→8), and determinism of the context contract. Any failure here is a fork-or-port decision, and port wins on cost almost every time at this size.

Sequencing.

1. Spike: encode three real production rules in a standalone evaluator; measure clarity and testability.
2. Benchmark: evaluation latency at realistic rule count (50–200 rules) and per-request call volume; confirm short-circuit ordering is controllable.
3. Build-vs-buy call: if rules stay engineer-owned, ship the ported evaluator as a first-party package. If business users need to author or change rules without deploys, stop — this class of engine is the wrong end state, and OPA/Cedar or a hosted decision service should be evaluated instead.
4. Ship with contract tests, a rule-authoring guide, and a rule-set version identifier emitted into logs.

Positioning against alternatives. Laravel has no first-class rules engine; Pennant is feature flags, not rules. That gap is real and is why the pattern is attractive — but it is filled by a ~300-line first-party primitive, not by resurrecting a 2015 Symfony bundle.

Operational Impact

Maintenance. Upstream maintenance is effectively zero. Every line depended on becomes ours to patch, port, and secure. The honest TCO comparison is not "bundle vs. build" — it is "abandoned code we now own vs. code we wrote and already own." The latter is cheaper and better documented by construction.

Support model. If this touches a real decisioning path (pricing, eligibility, entitlements), it needs a named internal owner and an escalation story for "why did this account get this outcome." An unmaintained third-party bundle cannot sit on that path. A ported primitive keeps the burden small, but the ownership must be explicitly assigned.

Scaling. Statelessness is a genuine strength: no shared cache, no session affinity, horizontally trivial, safe inside HTTP requests and queue workers alike. The cost is that rules are constructed and evaluated per call, with no compiled-rule cache and no memoization — CPU grows linearly with rule count times context size. Fine at tens to low hundreds of evaluations per request; a profiling target in the thousands. Short-circuit ordering and rule-set partitioning are the levers.

Failure modes to design against.

• Missing or misnamed context key → exception, or a silent false that looks like a legitimate "no."
• Operator type coercion (string vs. numeric, null handling) silently flipping a branch — the highest-risk bug class in this engine family, and the one most likely to have shifted between PHP 5 and PHP 8.
• Unknown operator or malformed rule set failing at evaluation time rather than load time.
• Logical precedence and ordering errors producing plausible-but-wrong decisions.
• No built-in provenance: a wrong decision requires manually logging inputs and matched rule identifiers to explain. Instrument from day one — rule-set version, input hash, matched rule IDs, latency — or the first incident will be unbounded.

Ramp-up. The evaluation model is small and readable; a mid-level engineer is productive in a day, and the resulting primitive is easy to test and reason about. The dead-end skill is Symfony 2 bundle wiring, which should deliberately not be taught to anyone. Documentation cost is ours either way: budget a short rule-authoring guide plus a golden-case regression suite, because rules are business logic and will drift silently without both.

Change management. Rule sets belong in version control with semantic versioning and a review gate. Roll out new rule sets in shadow mode against production inputs, compare decisions to the incumbent, and only then promote — the stateless design makes this cheap, and it is the cheapest insurance available against a silent policy regression.