Rulerz Bundle Laravel Package

Technical Evaluation

Architecture fit. The package is a Symfony Bundle, and its entire surface area is Symfony DI plumbing: a Bundle subclass, a DependencyInjection extension, compiler passes, and tagged-service wiring for RulerZ operators and compiler targets. None of that maps to Laravel's service-provider/container model. The actual value — the RulerZ specification-pattern engine and its DSL — lives in the upstream kphoen/rulerz library, which is framework-agnostic. The bundle is therefore the wrong artifact to consume; the underlying library is the right one, and only if we accept its constraints.

Integration feasibility. Installing wallabag/rulerz-bundle directly in a Laravel application is a non-starter: it pulls Symfony components, registers nothing usable outside a Symfony kernel, and assumes a bundle-registration lifecycle we do not have. Feasible paths are (a) require kphoen/rulerz directly and write a small Laravel service provider (~1–2 engineering days), or (b) skip RulerZ entirely. Option (a) is low effort but the payoff is uncertain given the maintenance posture.

Technical risk. High on maintenance, moderate on capability. Zero stars and zero declared dependents indicate this is a wallabag-internal fork rather than a community-maintained artifact — bug fixes and Symfony version bumps will move on wallabag's schedule, not ours. Upstream RulerZ has had a sporadic release cadence. Symfony major-version constraints will drift out of support, and no one outside wallabag has an incentive to remediate that. The DSL is genuinely expressive (predicates, custom operators, target adapters for Doctrine/Elasticsearch/arrays), but the operator and visitor model carries a real learning curve.

Key questions. Which data sources actually need rule evaluation (Eloquent, Elasticsearch, in-memory collections)? Do we need a user-facing DSL, or does a query-builder API cover the requirement? Is kphoen/rulerz still accepting releases, and what is its current PHP/Laravel compatibility matrix? Who owns the upgrade path if we depend on it? Is there a Laravel-native alternative (spatie/laravel-query-builder, raw scopes) that covers 80% of the use case?

Integration Approach

Stack fit. Poor as shipped, acceptable at the library level. RulerZ core makes no framework assumptions, so a Laravel adapter is straightforward: a service provider binding the RulerZ facade/compiler as a singleton, a config file for targets and operator registrations, and optionally a Ruleable trait on Eloquent models. This mirrors what the Symfony bundle does with tagged operators and compiler services in roughly 150 lines of Laravel-native code.

Migration path. Do not migrate the bundle — replace it. Require kphoen/rulerz (or a maintained fork), define operators in a config-driven registry, and expose a single RuleEngine service. Keep the DSL surface identical to RulerZ so rule strings remain portable if we revisit the backend. Where stored rules already exist (wallabag-style saved filters), keep them as plain strings and evaluate at query time.

Compatibility. Pin PHP, Laravel, and the RulerZ dependency explicitly and freeze them. Verify only the target adapters we actually need — most likely SQL translation via Doctrine DBAL/Eloquent rather than Elasticsearch. If DB-level evaluation is required, expect to write and maintain a custom compiler target; that is the largest hidden cost in the whole exercise.

Sequencing. (1) Spike: prove one end-to-end rule against a representative model in a throwaway branch (1–2 days). (2) Build the Laravel provider and a single operator registry. (3) Migrate one internal feature — saved filters or alerting — as a pilot. (4) Only then expose the DSL to end users, gated behind parser-level validation and rule versioning.

Operational Impact

Maintenance. This is the deciding factor. A fork with no external dependents means we own the upgrade treadmill: Symfony component bumps, PHP 8.x deprecations, and upstream RulerZ changes all land on us. Budget a few days per year per major ecosystem release plus unplanned breakage. The cheaper option is to fork the ~150 lines of DI glue into our own provider and depend only on RulerZ core, shrinking the blast radius.

Support. No meaningful upstream support channel. Wallabag maintains this for its own needs; issues that don't affect wallabag are unlikely to be prioritized. Incident response and on-call must assume first-party ownership, including root-cause analysis of parser and compiler failures.

Scaling. Cost depends entirely on the target adapter. Pushed down to SQL via a compiler target, it scales with the database. Evaluated in PHP over hydrated collections, it does not: O(n) rule evaluations per request plus memory pressure on large result sets. For user-defined rules at scale, require DB-level translation or restrict evaluation to indexed columns with hard result caps.

Failure modes. Unsafe rule strings that fail at execution rather than at save time; operator mis-registration yielding silent empty results; overly broad predicates producing unbounded queries; and version drift where an upstream RulerZ change alters DSL semantics under us. Mitigate with a rule-validation step on save, query timeouts and row limits, and a conformance suite over a corpus of representative rules.

Ramp-up. Two curves. The DSL itself is approachable for product and support staff — it reads like a predicate language. The compiler and target internals require an engineer comfortable with Symfony-style DI and AST visitors. Estimate one engineer-week to reach productive velocity on the internals, plus documentation effort, since upstream docs are thin and the bundle adds no documentation of its own.