Php Conditional Proxy Laravel Package

Product Decisions This Supports

• Build vs. buy on "fluent conditional" plumbing. The package solves a narrow but recurring ergonomics problem: invoking a method only when a condition holds, without wrapping the call in an if and breaking a method chain. As a PM, the decision is not "is this valuable?" (it obviously is when you have chains) but "is this worth a dependency vs. 30 lines in-house?" — a low-stakes, reversible call.
• Feature-flag and rollout work. Conditional chaining is a natural fit for optional behavior toggled by flags, entitlements, or tenant settings — e.g., appending ->when($featureEnabled)->withBetaFormatting() to a report/notification/export builder. This makes staged rollouts cheap to express and cheap to delete later.
• API ergonomics as a product surface. If your product is a platform/SDK, or if internal teams consume your service classes, fluent builders are part of the developer experience. Reducing if noise in those builders improves readability of the code that defines customer-facing behavior, which shortens review cycles and lowers the chance of a conditional being silently dropped during refactor.
• Use cases it unlocks: conditional configuration of service objects (mailers, exporters, PDF/report builders), conditional query refinement on custom Eloquent builders, conditional notification-channel selection, seeding/test-fixture setup where only some options apply, and any place where a null/"do nothing" branch is the common case.
• Roadmap signal, not a platform bet. At ~32 stars and a single-maintainer profile, treat adoption as a tactical convenience, not an architectural commitment. It should never appear in a critical-path design doc; it can appear in a style guide.

When to Consider This Package

Adopt when:

• You have multiple fluent/builder-style APIs in your own codebase where conditional method calls recur across controllers, jobs, and services — the repetition, not the concept, is what justifies the dependency.
• The conditional calls are side-effect or configuration oriented (set a header, add a channel, enable a mode). Chained conditional calls that need to return values are a poor fit, since a proxied call typically resolves to the proxy itself rather than the underlying return value — confirm this against the source before designing around it.
• You're already comfortable with __call-based magic: your team runs PHPStan/Larastan and an IDE that tolerates magic methods, and you're willing to add @method docblocks for completion.
• You want one consistent shape for conditional chains across the team rather than each developer inventing their own if-guard or tap()/optional() workaround.

Look elsewhere when:

• Laravel's built-in Conditionable trait (when() / unless()) already covers you. If the class in question can use Conditionable, that is the zero-dependency default — it takes a closure rather than returning a proxy, which is fine for most cases. Reach for this package only when the closure-per-call ergonomics genuinely hurt readability.
• You need the return value of the conditionally-invoked method, or you need the condition itself to be lazy/evaluated later — a proxy that eagerly gates calls changes semantics in ways that are easy to misread in review.
• The team is small, the chains are few, or the codebase is one service — a static helper or a two-line guard is cheaper to own than a transitive dependency and its upgrade cadence.
• Long-horizon platform components. Single-maintainer, low-star packages are fine in leaf/utility positions; don't put one under your public SDK surface without a fork-and-vendor plan. MIT license makes that plan trivial, which is precisely why the risk is acceptable — but write it down.

How to Pitch It (Stakeholders)

For executives (30 seconds): "There's a small, MIT-licensed utility that lets our code apply optional configuration to a builder-style API without if statements — it makes conditional, flag-driven behavior cheaper to write and, more importantly, cheaper to remove when a rollout ends. Cost is a single dependency with no runtime footprint and a permissive license. Risk is that it's a low-traffic, single-maintainer package, so we'd use it only in leaf utilities and keep a vendor-it-ourselves escape hatch. Recommendation: adopt narrowly, don't standardize on it."

For engineering leads:

• Problem it removes: repeated if ($cond) { $builder->method(); } blocks that interleave with fluent configuration and force temporary variables or duplicated chains.

• Integration shape: a trait on your builder/service class, plus a when($condition) entry point that returns a proxy; subsequent calls either pass through or no-op. Roughly:

  $report->when($user->isAdmin())->withInternalMetrics()
         ->when($tenant->hasFeature('beta'))->withBetaLayout()
         ->generate();
  

• Semantics to agree on before merging: what the chain returns when the condition is false, and what happens to methods that return values. Document this in the PR — it is the only real footgun.

• Dependency posture: MIT, tiny surface, no framework coupling. Vendor or reimplement if the maintainer goes quiet; the abstraction is small enough that a fork is a morning's work, not a migration.

• Guardrails: allow it in builders, services, and test setup; disallow it in anything on the public SDK boundary or in code paths where the return value is consumed. Add @method annotations so static analysis stays green.