Product Decisions This Supports
- Architectural Consistency: Standardizes dependency injection (DI) across a Laravel/PHP codebase, aligning with PSR-11 (Container Interface) and PSR-3 (Logging Interface) for better maintainability and team onboarding.
- Decoupling & Testability: Enables loose coupling between components, simplifying unit testing (e.g., mocking dependencies) and reducing spaghetti code in legacy systems.
- Roadmap for Microservices: Facilitates modular design by isolating dependencies, making it easier to split monolithic Laravel apps into microservices later.
- Build vs. Buy: Avoids reinventing a DI container from scratch (e.g., no need to build a custom solution like
Illuminate/Container alternatives) while offering flexibility to extend or swap containers (e.g., PHP-DI, Symfony DI) if needed.
- Use Cases:
- Refactoring legacy Laravel apps with tight coupling.
- Building greenfield projects requiring strict DI principles.
- Integrating third-party libraries that expect PSR-11 containers.
- Enabling dependency injection in non-Laravel PHP modules (e.g., CLI tools, APIs).
When to Consider This Package
- Adopt if:
- Your team prioritizes PSR compliance and wants to avoid Laravel-specific DI quirks.
- You need a lightweight, standards-based alternative to Laravel’s built-in container (e.g., for non-web PHP projects).
- You’re migrating dependencies between frameworks or services (e.g., Symfony ↔ Laravel).
- You require fine-grained control over service binding/resolution (e.g., for advanced caching or AOP patterns).
- Look elsewhere if:
- You’re deeply invested in Laravel’s ecosystem and prefer
Illuminate/Container for its Laravel-specific integrations (e.g., service providers, facades).
- Your project needs advanced features like autowiring (use
php-di/php-di or Laravel’s native autowiring).
- You lack developer buy-in for PSR standards (may require upskilling).
- The package’s lack of stars/maintenance (0 stars) raises concerns about long-term support (mitigate with a health check or fork).
How to Pitch It (Stakeholders)
For Executives:
"This package lets us adopt industry-standard dependency injection (PSR-11) for our PHP/Laravel codebase, reducing technical debt and making our system easier to test, scale, and maintain. It’s like upgrading from a custom-built toolbox to a standardized one—saving time on refactoring and future-proofing our architecture. The trade-off is minimal (no Laravel-specific features), but the long-term benefits for modularity and team productivity are clear."
For Engineering:
*"Why? We’re currently mixing Laravel’s container with custom DI logic, which makes testing and scaling harder. This package gives us:
- PSR-11 compliance: Works with any PSR-11-compliant library (e.g., logging, caching).
- Flexibility: Swap containers later if needed (e.g., for performance or framework changes).
- Testability: Easier mocking and isolation in unit tests.
How? Replace Laravel’s container with bnf/di in config/app.php and migrate bindings incrementally. Start with critical services (e.g., repositories, APIs) to validate the approach.
Risks? Minimal—we’re not losing Laravel integrations, just gaining standards compliance. If maintenance is a concern, we can fork or switch to php-di/php-di later."*
Key Ask: "Let’s pilot this in Module X to prove the value before full adoption."