Ruler Laravel Package

Product Decisions This Supports

• Build vs. buy for a rules layer. hoa/ruler is a small, embeddable PHP expression engine: you write business conditions in a readable DSL (user.age > 18 and user.country in ['FR','BE']) and evaluate them against your own data. It replaces hand-rolled if chains and one-off configuration flags with a single, testable evaluation path. The realistic decision is not "adopt vs. build a DSL" but "vendor/fork this vs. build a DSL from scratch" — the parser, lexer, and AST are the expensive part you avoid writing.
• Feature work it directly unlocks:
  • Eligibility and gating logic — promotions, trials, beta access, entitlement checks, KYC/risk tiering.
  • Dynamic pricing, discount stacking rules, and shipping/tax thresholds that finance or ops want to tune without a deploy.
  • Segmentation and targeting for campaigns and lifecycle messaging.
  • Routing and escalation policies — SLA tiers, approval chains, ticket assignment.
  • Feature flags and gradual-rollout predicates, plus spec-style assertions in test suites.
• Roadmap signal. If rules change more than once a quarter and every change currently requires an engineer, a deploy, and QA, that is a roadmap theme (self-serve business logic), not a one-off ticket. This package is a cheap way to validate that theme before investing in an admin UI, rule versioning, or a policy authoring experience.
• Architecture hedge. Using it behind a thin internal interface (RuleEvaluator::evaluate(string $expression, array $context): bool) lets you ship the capability now and swap the engine later — to Symfony Expression Language, a managed rules service, or a DMN/decision-table engine — without rewriting call sites.
• What it does not support: multi-step decision tables, forward chaining or RETE-style inference over large fact sets, temporal or retry-based reasoning, rule versioning/audit trails, or an authoring UI. If discovery surfaces those needs, this is a spike, not a platform.

When to Consider This Package

Consider it when:

• You are on PHP/Laravel, the rules are stateless boolean/arithmetic expressions over data you already have as arrays or entities, and you want them out of controllers and models.
• You need an evaluator that parses to an AST rather than using eval() — important if any rule text could ever come from a config file, customer admin, or tenant.
• The volume and complexity are modest: dozens to low hundreds of rules, evaluated per-request or per-record, not millions of fact combinations.
• You want a time-boxed spike or proof of concept to demonstrate "business logic without deploys" to stakeholders before committing budget to a rules platform.
• You are prepared to vendor or fork the code and assign an internal owner.

Look elsewhere when:

• Maintenance risk is disqualifying. The project is archived, last released May 2017, with essentially no downstream ecosystem. There will be no security patches and no upstream fixes. Expect PHP 8.x friction (implicit nullable parameters, dynamic properties, each()-era idioms in older Hoa components) that you must patch yourself.
• Compliance, audit, or regulated-change-control obligations apply — you need versioned rules, approval trails, and a support contract.
• Rules are genuinely complex: chained decisions, decision tables, conflict resolution, or high-throughput evaluation where an interpreter per rule per record is too slow.
• Non-technical stakeholders must author rules themselves — this package gives you an engine, not an editor, validator, or authoring experience.
• You need active community support, documentation, or hiring familiarity.

Pragmatic read: treat the pattern as strategically valid and the package as a disposable accelerator. The adoption signals (archived, zero dependents) mean it should enter the codebase behind an interface and with a named maintainer, and never become a hard dependency in a long-lived product without a fork plan.

How to Pitch It (Stakeholders)

To executives (30 seconds): Today, changing a pricing threshold or an eligibility rule means an engineering ticket, a code review, and a release. This package lets those rules live as readable business expressions that ops or finance can change in configuration — faster experiments, fewer deploys, less engineering time spent on routine logic changes. The caveat: the open-source project is no longer maintained, so I recommend a two-week spike to prove the value, with the engine hidden behind an internal interface so we can replace it with a supported alternative without rework. Cost is low; the strategic win is validating whether "business logic without deploys" is worth funding properly.

To engineering: Small, embeddable, no runtime services. Rules compile to an AST and are evaluated in a sandbox — no eval. Custom operators and functions are straightforward to register, and it binds cleanly into Laravel's container as a singleton evaluator service. Expressions are readable enough to double as documentation and to unit-test directly. The honest trade-offs: abandoned since 2017, PHP 8 compatibility patches will be ours to carry, no security backports, and no performance work for high-volume paths. Proposal: vendor the source under app/Support/Rules, wrap it in a single RuleEvaluator contract, cover it with a compatibility test suite, and keep the swap to Symfony Expression Language or a managed engine as a one-file change.

To the business owner: You get a fast feedback loop on rule changes and a clear audit of what the logic is — but rule authoring stays with engineering for now. Self-serve editing, versioning, and approval workflows are a separate, larger investment this spike will help you size.