Utils.common.conditioninterface Laravel Package

Product Decisions This Supports

• Build vs. buy for composite rule logic. This package answers a recurring product question: "do we standardize how the product expresses conditional business rules?" It ships a single ConditionInterface (isOk(): bool) plus composites like AndCondition and OrCondition. That is the entire product surface — roughly a day of internal engineering. The decision it informs is therefore less "should we adopt this" and more "should we formalize a shared predicate contract at all, and is this the shape we want?"
• Feature gating and rule composition architecture. Any roadmap item that smells like "only show/allow X when Y and (Z or W)" — eligibility checks, entitlement rules, pricing/discount stacking, onboarding gates, approval workflows, notification suppression — is a candidate for a composable condition tree. This package is a reference implementation for that pattern, useful as a design sketch even if the code is never installed.
• Roadmap sequencing: abstraction now vs. later. Adopting a third-party interface to avoid writing your own is a classic premature-abstraction trap. The PM decision is whether the condition contract is a product-level concept worth owning (and versioning) or an implementation detail that should stay local to the feature. Given zero dependents and no releases since 2019, this is not a strategic dependency — it's a pattern, not a platform.
• Vendor/dependency risk posture. With 3 stars, 0 dependents, and a last release of 2019-08-29, this informs the "acceptable dependencies" policy conversation: micro-packages with a single maintainer and no downstream usage sit in a gray zone between "harmless" and "unmaintained."
• Use cases it does not unlock. No Laravel service provider, no config, no facades, no Expression Language, no serialization of rules from a database. If the roadmap requires business users or admins to author conditions (rather than developers code them), this package contributes nothing beyond vocabulary — and you'd be looking at a rules engine or symfony/expression-language instead.

PM read: the opportunity score (41.43) and score (0.015) point the same direction — the idea of a condition contract is mildly interesting, the artifact is not. Treat this as prior art for a design doc, not a line item in the dependency manifest.

When to Consider This Package

Consider it if:

• You are already inside the Mouf / TCM ecosystem (thecodingmachine packages, Mouf DI container) and want a shared ConditionInterface so independently developed packages can compose conditions without a common base class.
• You want an interface-only contract with no baggage — MIT licensed, no framework coupling, PHP-only, trivially readable in five minutes. It is genuinely framework-agnostic and could sit under Laravel, Symfony, or plain PHP.
• You need a teaching/reference artifact — a canonical example of the Composite pattern applied to predicates — for a design review or an architecture doc.
• You are prototyping a rule tree internally and want a naming convention (isOk) that other teams can adopt cheaply.

Look elsewhere — or write the interface yourself — if:

• You are Laravel-first. Laravel's own Illuminate\Support\Traits\Conditionable (when/unless), Illuminate\Validation\Rule objects, Gates/Policies, and pipelines cover most of the same ground with first-class support, testing, and documentation. Adding a 3-star PHP 5-era package to a modern Laravel app is a net negative for onboarding and code review.
• You need business-authorable rules (stored in DB, edited in an admin UI, evaluated at runtime). Look at symfony/expression-language, a rules engine (e.g., nikic/php-parser-based or JSON-logic ports), or a dedicated feature-flag service. This package has no parser, no serialization, and no evaluation context — every condition is a hand-written class.
• You need context-aware conditions (user, tenant, cart, time window). isOk() takes no arguments, so context must be injected via constructor — workable, but it forces a container wiring decision per rule and makes conditions stateful in ways that complicate caching and testing.
• Supply-chain hygiene matters. Zero dependents and no release in ~6 years is a maintenance signal. Even though the code is trivial and MIT, adding it means an entry in composer.json, a lockfile diff, and a future migration. The correct PM call is usually: copy the ~30 lines, attribute the MIT license, own it internally.
• You need NotCondition, XorCondition, or short-circuit guarantees. Verify against the actual source before committing; the description promises only And/Or, and composite semantics (evaluation order, exception propagation) are not documented.

Adoption bar I'd set: the package must save more than one engineer-day of work and must not be the only thing standing between you and a framework-native solution. On current evidence, it clears neither.

How to Pitch It (Stakeholders)

For executives (30 seconds):

This is a tiny, MIT-licensed PHP utility that defines a standard "yes/no rule" interface so that conditions can be combined — all of these must be true or any of these must be true. It is not a platform, not a service, and not a dependency we'd build a roadmap on. Value: it names a pattern our product already uses informally (eligibility checks, feature gating, discount rules). Recommendation: do not adopt as a dependency; instead, cite it as prior art and, if we need the contract, own a five-line internal interface. Cost to replicate: negligible. Risk of adopting: an unmaintained, three-star package with no downstream users and no release since 2019 in our lockfile for no measurable benefit.

For engineering (the actual ask):

If we find ourselves writing a third independent if ($a && ($b || $c)) gate, we should introduce a shared Condition contract with isOk(): bool and And/Or/Not composites. This package is the minimal reference for that shape — MIT, framework-agnostic, ~30 lines. We should vendor the pattern, not the package: put it in app/Support/Conditions with a test for composite short-circuiting and a rule that conditions are constructor-injected and side-effect free. If we ever need admin-authored rules, that's a separate evaluation (symfony/expression-language or a rules engine) and this package won't get us there — flag it early so we don't over-invest in hand-written condition classes.