Container Laravel Package

Product Decisions This Supports

• Adoption of Dependency Injection (DI) in PHP/Laravel projects to decouple components, improve testability, and enforce loose coupling.
• Migration from manual instantiation to managed DI for new or legacy codebases, reducing boilerplate and improving maintainability.
• Roadmap for modular architecture by enabling service providers, event-driven extensions, and attribute-based resolution (e.g., #[Inject]).
• Build vs. Buy: Avoid reinventing a DI container (e.g., rolling your own PSR-11 implementation) when this package offers batteries-included features (events, attribute support, PSR compliance).
• Use Cases:
  • Laravel plugins/add-ons: Standardize DI across extensions.
  • Microservices: Decouple service layers with tagged dependencies.
  • Legacy refactoring: Gradually introduce DI without rewriting core logic.
  • Testing: Mock dependencies via container overrides or event listeners.

When to Consider This Package

• Adopt if:

  • Your project uses PHP 8.1+ and needs a lightweight, PSR-11-compliant DI container.
  • You require event-driven extensions (e.g., intercepting dependency resolution, post-processing).
  • You want attribute-based DI (#[Inject], #[Resolve]) without heavy frameworks like Symfony DI.
  • You’re building a Laravel-compatible package and need a container that integrates with Laravel’s ecosystem (e.g., service providers, tags).
  • You need fine-grained control over shared vs. non-shared instances or delegate containers.

• Look elsewhere if:

  • You’re using PHP < 8.1 (minimum requirement).
  • You need auto-wiring for union types (explicitly unsupported).
  • Your team prefers Symfony’s DI (more features but heavier).
  • You require advanced features like circular reference detection (this package throws exceptions by default).
  • You’re in a JavaScript/TypeScript environment (this is PHP-only).

How to Pitch It (Stakeholders)

For Executives: "This package lets us standardize how our PHP services are created and managed, reducing bugs from manual instantiation and making it easier to swap components (e.g., for testing or feature flags). It’s lightweight, widely used in the Laravel ecosystem, and supports modern PHP features like attributes. Adopting it aligns with our tech debt reduction goals and future-proofs our architecture for modular services."

For Engineering: *"league/container is a battle-tested, PSR-11-compliant DI container with:

• Event system: Hook into resolution lifecycle (e.g., logging, metrics, or modifying dependencies dynamically).
• Attribute support: Annotate classes with #[Inject] to auto-wire dependencies (reduces boilerplate).
• Service providers: Organize dependencies by feature (like Laravel’s ServiceProvider).
• Tagging: Group services (e.g., @database.driver) for flexible retrieval.
• Laravel-friendly: Works alongside Laravel’s container but offers more control than the default.

Why not Symfony DI? It’s heavier and overkill for most projects. This gives us 80% of the power with 20% of the complexity.

Migration Path:

1. Start by wrapping manual new calls with container->get().
2. Use service providers to group related dependencies.
3. Gradually adopt attributes/events for advanced use cases.

ROI:

• Faster development: Less boilerplate for dependency management.
• Easier testing: Override dependencies via the container.
• Scalability: Supports microservices and plugins via tags/delegates."*