Discovery Laravel Package

Product Decisions This Supports

• Decoupling dependencies: Enables SDKs/libraries to support PSR interfaces (e.g., HTTP clients, logging) without forcing users to adopt specific implementations (e.g., Guzzle, Monolog). Reduces friction for developers using alternative stacks (e.g., Symfony, Laminas).
• Roadmap for modularity: Aligns with a strategy to build composable, pluggable components (e.g., "bring your own" HTTP client/cache). Critical for microservices or multi-vendor ecosystems.
• Build vs. buy: Avoids reinventing discovery logic (e.g., manual if/else checks for class existence). Lowers maintenance burden for teams prioritizing PSR compliance.
• Use cases:
  • SDKs: PHP libraries (e.g., payment gateways, APIs) where users may prefer their own PSR-18 client over a bundled one.
  • Testing: Simplifies dependency injection for unit tests (e.g., mock PSR-11 containers without hardcoding).
  • Legacy modernization: Gradually adopt PSR standards in monoliths by letting users opt into implementations.

When to Consider This Package

• Adopt when:
  • Your product relies on PSR interfaces but needs to avoid hard dependencies (e.g., "users must install Guzzle").
  • You’re building a library/SDK targeting diverse environments (e.g., Laravel, Symfony, custom setups).
  • You want to reduce configuration overhead (e.g., no need for config.php to specify implementations).
  • Testing or CI/CD requires flexible dependency mocking (e.g., swapping PSR-6 caches for testing).
• Look elsewhere if:
  • You need strict version control of PSR implementations (e.g., enforcing Guzzle 7+). This package uses "first found," which may not guarantee compatibility.
  • Your use case requires advanced discovery (e.g., priority rules beyond class path order).
  • You’re in a performance-critical path where autoloading multiple PSR implementations adds latency.
  • Your team lacks familiarity with PSR standards (steep learning curve for non-PHP devs).

How to Pitch It (Stakeholders)

For Executives: "This package lets us build PHP libraries that ‘just work’ with any PSR-compliant tool—without locking users into specific vendors. For example, our payment SDK could support Guzzle or Symfony’s HTTP client, reducing churn. It’s like ‘plug-and-play’ for dependencies, cutting support costs and expanding adoption. Low risk (MIT license, battle-tested in PSR projects), and minimal dev overhead."

For Engineering: *"Discovery solves a common pain point: ‘How do I support PSR-X without forcing users to install Y?’ It’s a lightweight (~1KB) autoloader for PSR interfaces (HTTP, caching, logging, etc.). Key benefits:

• No config: Users auto-get their preferred implementation (e.g., if they have symfony/http-client, it’s used).
• Test-friendly: Mock PSR-11 containers or PSR-3 logs without hardcoding.
• Future-proof: Works with any PSR-compliant library (e.g., swap Guzzle for Buzzle later). Tradeoff: ‘First found’ may need validation for edge cases (e.g., conflicting versions). Recommend pairing with a psr-discovery/*-implementations meta-package for stricter control."*