- What does astrotomic/php-conditional-proxy actually do?
- It provides a trait and a small class that let you conditionally forward method calls inside a fluent chain. Instead of wrapping part of a chain in an if block, you call when() or unless() with a boolean and the following calls either execute or are skipped. The chain itself never breaks, so optional logic stays readable and colocated with the rest of the builder or pipeline.
- How do I install astrotomic/php-conditional-proxy with Composer?
- Install it as a normal Composer dependency with composer require astrotomic/php-conditional-proxy. There is no service provider, no config file, no migrations, and no environment variables to publish or wire up. Adoption is purely code-local: add the trait to a builder class or wrap an object in the proxy class and start chaining.
- Does this package work with Laravel?
- Yes, but it is not a Laravel-specific package. It is plain PHP with no framework coupling, so it works in any Laravel application as well as standalone PHP projects within the supported version range. In Laravel codebases it fits naturally alongside fluent APIs like query builders and pipelines, where when() style helpers already feel familiar.
- Which PHP and Laravel versions are supported?
- The package is pure PHP with no extensions or native code, so support is bounded by the range declared in its composer.json. Check that constraint against your current runtime and your next planned upgrade before adopting, since a stalled dependency can become an upgrade blocker. Verify the CI matrix and tagged releases to confirm the claim against the versions you actually run.
- How is this different from Laravel's Conditionable trait and when() helper?
- Laravel's Conditionable trait gives you when() and unless() on classes that explicitly use it, and it passes the target into the callback. This package focuses on forwarding arbitrary method calls through a proxy so you can gate a segment of a chain without wrapping it in a closure or an if statement. It complements rather than replaces Laravel's helpers, so pick one idiom per codebase to avoid two when() styles that read identically but behave differently.
- Does the conditional proxy break PHPStan, Psalm, or IDE autocompletion?
- Conditional forwarding typically relies on __call magic dispatch, which degrades static analysis, IDE completion, and go-to-definition. Teams with strict static-analysis gates should expect to add baseline entries or stubs for the proxied calls. If your pipeline treats new static-analysis errors as blocking, plan for that work before rollout rather than after.
- What does a forwarded method call return: the proxy, the target, or the callee's result?
- This is the detail to confirm first, because it determines whether the proxy can be composed with your existing builder contracts. Read the source or write a quick test that asserts the return type after a forwarded call on your own classes. If your builders rely on returning $this for chaining, verify that the proxy honors that expectation rather than returning the wrapped target or the last call's result.
- Does it support when and unless symmetry, multiple conditions, and nested chains?
- The package is designed around when/unless-style boolean gates that keep optional logic clean and fluent. For multi-condition composition or deeply nested chains, check the source and tests to confirm behavior rather than assuming parity with Laravel's Conditionable. If your use case needs compound predicates, evaluate it on a single feature branch first.
- How do I test code that uses conditional method forwarding?
- Silent no-ops are the main behavioral risk: when a condition is false the calls simply disappear instead of failing loudly, so a mis-specified predicate can run cleanly and do the wrong thing. Write tests that assert both branches, including that the skipped calls genuinely had no side effects. Cover the predicate itself with the same rigor as the chain, because the condition is where the bugs will live.
- Is this package actively maintained and should I just vendor it in-house instead?
- Assess carefully: the repository has limited stars and a single-maintainer profile, and the tooling flagged the repository status as unknown, which is a supply-chain vetting gap regardless of license or code size. Pin to a tagged release with a verifiable commit history before depending on it. Because the implementation is small, vendoring the trait and class directly into your codebase is a legitimate fallback that removes the dependency while preserving the ergonomics.