Conditionable Laravel Package

Product Decisions This Supports

• Feature velocity on conditional-heavy logic. Product surfaces that branch constantly — plan-tier entitlements, regional availability, beta-flag gating, admin overrides — can be expressed as readable chains (->when($isEnterprise, ...)) instead of nested if/else ladders. This matters to a PM because conditional sprawl is where regressions and "we forgot the edge case" bugs live.
• Build vs. buy: this is effectively "buy at zero cost." illuminate/conditionable is a read-only split of the official laravel/framework repository (MIT, ~35k stars). The PM-level decision is not "should we buy this?" but "should we stop paying engineers to hand-roll conditional-chaining helpers?" The answer is use the first-party trait and redirect that effort to product work.
• Roadmap sequencing. Because the trait is already inside illuminate/support in any modern Laravel app, there is no migration project, no procurement, no security review gate, and no version-lock risk. It can be adopted inside an existing sprint rather than planned as an initiative.
• Use cases worth naming in a spec or ticket:
  • Dynamic query building (filters assembled from user role, locale, or subscription state).
  • Conditional API response shaping — include/omit fields or relationships based on caller context.
  • DTO and job construction where queue, timeout, or middleware depend on config or environment.
  • Collection transforms filtered by feature flags without breaking the chain.
• Standard-setting, not just tooling. Adopting it creates a reviewable convention ("no nested conditionals in chainable service code"), which makes code review faster and onboarding of new engineers cheaper — an organizational decision a PM can sponsor.
• Portability signal for library work. If the team publishes internal Composer packages, depending on this small package (rather than the full framework) keeps those libraries lean while retaining the fluent conditional API.

When to Consider This Package

Adopt when:

• The product runs on Laravel or Lumen (or a package/library that already depends on illuminate/support).
• Three or more classes need the same conditional-chaining behavior — models, collections, DTOs, jobs, service objects.
• Readability of branching business rules is a stated maintainability concern, or the codebase already shows deep nesting in controllers/jobs.
• You want first-party, MIT-licensed, framework-maintained code with no separate vendor relationship — the opposite of a supply-chain risk.
• You are building a standalone package that wants when() without dragging in the whole illuminate/support surface.

Do not require it directly when: the application already installs illuminate/support — the trait is present already, and an explicit composer require just adds a redundant constraint to maintain. Declare it only if you genuinely need it as a standalone dependency.

Look elsewhere when:

• The stack is not Laravel — Symfony, Doctrine, vanilla PHP, or a Node/Go service. There is no portable equivalent here; use language-native constructs or a pipeline/middleware library.
• The condition is a single, non-chained if. Wrapping one branch in when() is ceremony, not clarity.
• The logic needs to change the object's type or short-circuit the chain entirely. when() returns the same instance on a false condition by design; forcing it to model complex control flow produces code that looks elegant and behaves surprisingly.
• The team would be tempted by an unofficial fork or mirror of this package. Insist on the laravel/framework-sourced split or the framework itself; unvetted reimplementations of a five-line trait are pure downside risk.
• Heavy functional or event-driven pipelines are the real need — a dedicated pipeline package models staging and failure semantics better than nested when() calls.

How to Pitch It (Stakeholders)

Executives (one paragraph): "This is a small built-in capability of the Laravel framework we already run — MIT licensed, maintained by the Laravel core team, used by essentially every modern Laravel application. It lets engineers write conditional business rules as a single readable chain instead of deeply nested if statements, which measurably reduces the defect rate in rule-heavy features like plan entitlements, regional availability, and beta gating. Cost is zero, adoption requires no migration or vendor contract, and it removes a recurring temptation for engineers to build and maintain bespoke helper code. Recommendation: endorse it as a house standard for branching logic in chainable code, not as a standalone initiative."

Engineering (short brief): "Conditionable gives you when($condition, fn($self) => ...) and, in newer versions, unless(). The closure receives the instance and the method returns the instance regardless of the condition, so chains never break and never return null unexpectedly. It ships inside illuminate/support — do not add a redundant direct dependency unless you're publishing a package that needs it standalone. Use it on Eloquent models, collections, DTOs, jobs, and service objects to flatten nested conditionals; skip it for single branches where if is clearer. Add @method self when(...) to class docblocks where IDE inference matters, since traits can confuse static analysis. Hard rule: pin to the official Laravel source, and never vendor an unofficial reimplementation of a trait the framework already owns."