All Laravel Package

Product Decisions This Supports

• Decoupling dependencies: Enable SDK/library development where users can choose their own PSR-compliant implementations (e.g., HTTP clients, caches) without hardcoding dependencies in the SDK.
• Flexible architecture: Support modular Laravel applications where components (e.g., logging, caching) can be swapped without breaking changes.
• Roadmap alignment: Accelerate adoption of PSR standards (e.g., PSR-18 HTTP clients) by reducing friction for developers integrating third-party libraries.
• Build vs. buy: Avoid reinventing discovery logic for PSR implementations; leverage this package to reduce technical debt.
• Use cases:
  • SDKs (e.g., payment gateways, SaaS APIs) requiring PSR-18 HTTP clients but allowing users to inject Guzzle, Symfony HTTP Client, etc.
  • Laravel plugins where caching (PSR-6) or logging (PSR-3) must be configurable post-installation.
  • Microservices where runtime discovery of PSR implementations (e.g., event dispatchers) improves extensibility.

When to Consider This Package

• Adopt when:
  • Your project relies on PSR interfaces (e.g., PSR-11 Container, PSR-14 EventDispatcher) but needs to avoid coupling to specific implementations.
  • You’re building a library/SDK where users should control their own dependencies (e.g., "Use any PSR-18 client").
  • Your Laravel app requires dynamic discovery of services (e.g., swapping Redis for Memcached via PSR-6).
  • You prioritize loose coupling and runtime flexibility over compile-time dependencies.
• Look elsewhere if:
  • Your project has strict monolithic dependencies (e.g., always uses Guzzle + Symfony Cache).
  • You need performance-critical discovery (this package scans classes at runtime).
  • Your team lacks familiarity with PSR standards or Composer autoloading.
  • You’re targeting PHP < 8.2 (minimum requirement).
  • You require centralized configuration (e.g., config/app.php overrides) instead of runtime discovery.

How to Pitch It (Stakeholders)

For Executives: "This package lets us build Laravel libraries/SDKs that support any PSR-compliant implementation (e.g., HTTP clients, caches) without locking users into specific vendors. For example, a payment SDK could use psr-discovery/all to auto-detect Guzzle, Symfony HTTP Client, or others—reducing support overhead and expanding adoption. It’s a lightweight, standards-based way to future-proof our tech stack while keeping dependencies flexible."

For Engineering: *"This meta-package bundles discovery for PSR-18 (HTTP), PSR-17 (factories), PSR-14 (events), PSR-11 (containers), PSR-6 (caches), and PSR-3 (logs). Use it to:

• Decouple SDKs: Let users inject their own PSR implementations (e.g., new PsrDiscovery()->findHttpClient()).
• Simplify Laravel plugins: Discover caching/logging layers dynamically without hardcoding.
• Reduce boilerplate: No need to manually check for GuzzleHttp\Client, Symfony\Component\HttpClient\Psr18Client, etc. Tradeoff: Runtime discovery adds ~5ms overhead per call (negligible for most use cases). Requires PHP 8.2+."*

For Developers: *"Need to support multiple PSR implementations without bloating your composer.json? This package scans your autoloaded classes and returns the first match for interfaces like Psr\Http\Client\ClientInterface. Example:

$discovery = new \Psr\Discovery\Discovery();
$client = $discovery->findHttpClient(); // Auto-picks Guzzle, Symfony, etc.

Perfect for SDKs, plugins, or apps where users should control their stack."*