Rulerz Bundle Laravel Package

Product Decisions This Supports

• User-facing filtering and saved searches. RulerZ is a rule/specification engine: one rule string compiles to a Doctrine query, an Elasticsearch query, or an in-memory filter. This is the package that lets a Symfony product expose "smart folders," saved filters, alerts, or segment builders to users without writing a new query for each surface. Directly relevant if you are building a content/reading/bookmarking product (this is wallabag's fork).
• One rule language, multiple execution targets. The core product argument is consistency: the same user-authored rule must produce the same result in the list view (SQL), the search page (Elasticsearch), and background jobs (in-memory). That consistency is a product promise, not just an engineering nicety.
• Business-rule authoring by non-engineers. Audience targeting, entitlement checks, promotional eligibility, moderation queue rules, and notification triggers can be expressed as rules instead of code branches — a roadmap enabler for "self-serve" admin tooling.
• Build vs. buy signal. The "buy" here is really RulerZ core; this bundle is the Symfony glue (service wiring, compiler/target configuration, request-parameter-to-spec resolution). So the real decision is adopt a DSL and own its integration layer vs. hand-roll Specification objects / Doctrine Criteria / Symfony ExpressionLanguage. For a narrow filtering need, in-house is 1–2 sprints and removes a dependency.
• Refactoring decisions. If filtering logic is currently scattered across QueryBuilders and controllers, consolidating on declarative specs is a defensible roadmap item — but the consolidation value comes from the pattern, not from this specific bundle.
• Diligence data that should inform the decision. 0 stars, 0 dependents, package score 0.06, MIT, maintained as a wallabag-internal fork of an effectively abandoned upstream. That is not evidence of a library to standardize on; it is evidence of a library one team already owns.

When to Consider This Package

Consider it when:

• You are already a Symfony shop running RulerZ core, and you need the bundle's DI wiring rather than rebuilding it.
• You have a genuine multi-backend filtering requirement (Doctrine + Elasticsearch + in-memory) and a user-facing rule editor on the roadmap.
• You have in-house PHP/Symfony capacity to own a fork — pin the version, vendor it if necessary, and accept that you, not a community, are the maintainer of record.
• Your Symfony/PHP versions match the fork's supported range. Verify this explicitly; a bundle of this vintage is unlikely to be tested against Symfony 6/7 and PHP 8.2+.
• You are wallabag or building something structurally similar (content corpus, saved searches, tag/reading-status filters).

Look elsewhere when:

• You are greenfield on Symfony 6/7 / modern PHP and need a dependency that will receive security and compatibility updates.
• Filtering needs are simple or single-backend — Doctrine Criteria, Symfony ExpressionLanguage, API Platform filters, or a small in-house Specification pattern cover it with zero external risk.
• You need vendor accountability, an SLA, or a support contract.
• You have no one who can read the bundle's internals when it breaks — and with zero dependents, there is no community to ask.
• The rule DSL is a nice-to-have rather than a product differentiator. Do not take on a maintained-fork obligation for a feature that a dropdown of filters satisfies.

Verdict: treat this as reference source code, not a dependency. If the DSL is strategic, budget explicit ownership and wrap it behind an internal RuleEngine interface so it can be replaced. If it is not strategic, do not adopt it.

How to Pitch It (Stakeholders)

For executives (one paragraph): We evaluated wallabag/rulerz-bundle, a Symfony integration for the RulerZ rule engine, as a way to let users and admins define their own filters and business rules once and have them run consistently across our database, search index, and background jobs. The capability is real and maps to roadmap items like saved searches and self-serve targeting. The package itself is not a safe standard: it is a fork maintained for one company's product, with zero external users and no community validation, built on an upstream library that is no longer actively developed. Recommendation: do not add it to our dependency register. If we want the capability, we fund roughly one to two sprints of in-house work behind our own interface — same product outcome, no orphaned dependency, and we keep the option to swap implementations later.

For engineering (summary): Thin Symfony glue over RulerZ: service definitions, compiler/target configuration, and request-to-spec resolution — likely a few hundred lines, not a framework. Risks: unmaintained upstream, uncertain Symfony/PHP version support, no external users to surface breakage, and the fork's priorities are wallabag's, not ours. If we proceed: vendor or fork it, pin exact versions, isolate behind an internal abstraction, and add our own tests around the compilers we actually use (Doctrine and Elasticsearch first; skip unused targets). If we don't need a user-authored rule language, prefer Doctrine Criteria or Symfony ExpressionLanguage and revisit only when a real multi-backend filtering requirement appears.