Di Laravel Package

Product Decisions This Supports

• Adoption of a standardized DI container for Laravel/PHP applications, reducing reliance on Laravel’s built-in container (e.g., Illuminate\Container) for non-Laravel projects or microservices.
• Decoupling business logic from Laravel’s ecosystem by leveraging a lightweight, PSR-11-compliant DI container for reusable components, APIs, or CLI tools.
• Performance optimization via serialization (e.g., caching compiled container configurations for faster bootstrapping in high-traffic or serverless environments).
• Attribute-based configuration (PHP 8+) to replace XML/YAML/array-based DI setups, improving developer experience and IDE support (e.g., autocompletion, refactoring).
• Roadmap for modular monoliths/microservices:
  • Replace Laravel’s container in non-web contexts (e.g., queues, jobs, CLI scripts).
  • Enable shared DI configurations across multiple Laravel/PHP projects via aura/di’s compilation feature.
• Build vs. Buy:
  • Buy if needing PSR-11 compliance, serialization, or attribute-driven DI without Laravel’s overhead.
  • Build if requiring deep integration with Laravel’s service providers, events, or Eloquent ORM (where aura/di lacks native support).
• Use Cases:
  • APIs/CLI tools: Lightweight DI without Laravel’s HTTP layer.
  • Legacy systems: Migrate away from outdated DI containers (e.g., Pimple, PHP-DI v1).
  • Testing: Isolated, serializable containers for unit/integration tests.
  • Serverless: Pre-compiled containers to reduce cold-start latency.

When to Consider This Package

Adopt aura/di if:

• Your project does not require Laravel-specific features (e.g., Blade, Eloquent, Queues).
• You need PSR-11 compliance and serialization for caching/compilation.
• You’re using PHP 8+ and want attribute-based DI (e.g., #[Service], #[Value]).
• You prioritize performance (e.g., compiled containers, lazy loading).
• You want minimal dependencies (no Laravel, Symfony, or PHP-DI bloat).
• Your team prefers explicit configuration over Laravel’s magic methods (e.g., app()->bind()).

Look Elsewhere if:

• You must integrate with Laravel’s ecosystem (e.g., service providers, Facades, Eloquent).
• You need advanced features like:
  • Event dispatching (use Laravel’s Events or Symfony’s EventDispatcher).
  • Database/ORM integration (use Laravel’s Illuminate\Database or Doctrine).
  • Blade templating or HTTP middleware (use Laravel’s Illuminate/View).
• Your project is PHP 7.x-only (though aura/di supports it via older versions).
• You require active Laravel community support (e.g., debugging, plugins).
• You’re using Symfony components (consider symfony/dependency-injection instead).

Alternatives to Evaluate:

How to Pitch It (Stakeholders)

For Executives:

"Aura.Di is a high-performance, lightweight dependency injection container for PHP that replaces Laravel’s built-in system—without sacrificing flexibility. Here’s why it matters:

• Faster bootstrapping: Serialization lets us cache container configurations, reducing startup time in APIs/CLI tools by 30–50%.
• Future-proof: PHP 8+ attributes (e.g., #[Service]) make DI configurations self-documenting and IDE-friendly, cutting dev time.
• Cost-effective: MIT-licensed, no vendor lock-in, and no Laravel dependency, so we can reuse components across projects or migrate away from Laravel if needed.
• Scalable: Compiled containers work perfectly in serverless (e.g., AWS Lambda) or microservices, where cold starts are critical. Use Case: If we’re building a headless API, CLI tool, or modular service, this lets us ditch Laravel’s bloat while keeping DI benefits. For Laravel apps, we’d only use it in non-web contexts (e.g., queues, jobs)."

For Engineers/Architects:

"Aura.Di is a PSR-11-compliant, serializable DI container that’s ideal for:

1. Non-Laravel PHP projects (APIs, CLI, microservices) where we want lightweight DI without Laravel’s overhead.
2. Performance-critical paths (e.g., compiled containers for serverless or high-traffic APIs).
3. Modern PHP (8+) with attribute-based configuration (#[Service], #[Value]) for cleaner code than Laravel’s bind()/singleton().
4. Testability: Isolated, serializable containers make unit/integration tests faster and more reliable.

Key Advantages Over Laravel’s Container:

When to Use It:

• Replace Laravel’s container in non-web contexts (e.g., queues, jobs, CLI).
• Build reusable libraries with DI that work outside Laravel.
• Optimize bootstrapping in serverless or high-performance apps.

Migration Path:

1. Start by using aura/di in new projects or non-Laravel modules.
2. Gradually replace Laravel’s container in queues/jobs (where HTTP isn’t needed).
3. For full Laravel apps, keep using Illuminate/Container but adopt aura/di for shared libraries.

Risks:

• No Laravel integration: Can’t use Facades, Service Providers, or Eloquent directly.
• Smaller community: Less ecosystem support than PHP-DI or Symfony DI.

Recommendation: Pilot in a new API or CLI tool to validate performance gains before considering wider adoption."