Radish Bundle Laravel Package

Getting Started

This is a Symfony bundle, not a Laravel package. The bundle layer (RadishBundle) only registers DI services and config; the actual rule engine lives in radish/radish. For a Laravel codebase you should not install radish/radish-bundle — pull radish/radish directly and wrap it yourself (see Gotchas).

If you are on Symfony (2.x/3.x era), minimal steps:

1. composer require radish/radish-bundle
2. Register RadishBundle\RadishBundle in AppKernel::registerBundles()
3. Add a radish: block to app/config/config.yml and point it at a rules file (YAML/PHP) — the extension is in RadishBundle/DependencyInjection/RadishExtension.php
4. Inject the ruleset/engine service into your controller or domain service and evaluate a fact (an associative array) against it

Where to look first, in order:

• Radish\Rule\RuleSet and Radish\Rule\RuleSetBuilder in the core package — this is where rules are assembled
• Radish\Engine\* — the evaluation loop (forward chaining; rules can trigger other rules)
• RadishBundle/Resources/config/services.yml — the actual service IDs and class wiring, which is the only real documentation this bundle has

First use case: given a fact array like ['customer' => ['age' => 17, 'country' => 'US']], load a ruleset that expresses "deny if age < 18 and country is not FR", and read back the resulting flag / action output. Rules are data; keep them out of PHP classes so non-devs can iterate.

Implementation Patterns

Rules as configuration, engine as a service. The bundle's whole value is that rule definitions live in config files loaded at container compile time, and the RuleSet/engine is a shared service. Treat it as a black-box evaluator: build facts, hand to engine, inspect result.

Fact-shaped DTOs. Radish evaluates against arrays and dot-path expressions. Normalise your Eloquent models into plain arrays with stable keys before calling the engine. Do not pass models directly — nested accessors (order->customer->tier) will not resolve the way rule expressions expect.

Rule authoring loop. Keep a rules/ directory, version it in git, and add a console command / artisan command that evaluates a fixture fact against the current ruleset. Every rule change should be smoke-tested against 3–5 fixture facts in CI. With a 2017 package and no upstream activity, you are the test suite.

Isolating the engine behind an interface. Define your own RuleEvaluator contract in the app, with a Radish-backed implementation. This is the single most important pattern: it lets you swap in a maintained engine (Ruler, Hoa\Ruler, or hand-rolled) without touching call sites, which you will very likely want to do.

Action handling. Rules typically name actions rather than executing code. Use action names as tokens, resolve them in your own dispatcher (match ($actionName) { ... }), and keep side effects in your application, not in rule definitions.

Layered rulesets. Compose small rulesets (eligibility, pricing, fraud) and evaluate them in sequence with the output of one feeding facts into the next. This is more debuggable than one 200-line ruleset and lets you cache/reload independently.

Gotchas and Tips

• Symfony-only, PHP 7 era. Last release March 2017. Expect incompatibilities with PHP 8 (likely each(), loose assert()-style assumptions, no return types). Test on your target PHP before committing.
• Laravel integration is DIY. In a Laravel app: composer require radish/radish, bind RuleSet/engine as singletons in a service provider, load rules from config/ or a rules/ directory, and skip the bundle entirely. The bundle contributes almost nothing you can't rebuild in ~40 lines.
• Maintenance risk is the headline. 1 star, 0 dependents, no releases in 7+ years. There is effectively no community, no security response, and no Stack Overflow corpus. Assume you own the code on day one; vendor-fork it if you rely on it.
• Silent no-matches. A rule whose fact path doesn't exist usually evaluates falsy rather than throwing. Log the fact array alongside the ruleset name on every evaluation during development, or you will spend hours chasing "why didn't rule X fire."
• Expression syntax is the DSL's, not PHP's. Don't assume == semantics match PHP's loose comparison, and don't assume null/missing-key handling. Write a test per operator you use (and, or, not, comparisons, membership) before building on it.
• Config caching. In Symfony, rules loaded via the extension are frozen into the compiled container. In Laravel terms: if you load rules at boot, config:cache will bake them in — load rules lazily from disk instead.
• Debugging. There's no tracing/profiling story. Add a thin decorator around the engine that records (ruleset, fact, matchedRules, result) and dump it on failure. This decorator is also your easiest path off the package later.
• Extension points. Custom fact providers and action resolvers are the clean seams; subclassing the engine is not (the evaluation loop is tightly coupled). If you need custom operators, you're better off forking.
• Verdict. For a new Laravel project, don't adopt this. Use it only if you inherit a Symfony app already on it, and immediately wrap it behind your own interface so the dependency stays shallow.