Di Laravel Package

Technical Evaluation

Architecture Fit

• Laravel’s Native DI vs. Nette/DI: Laravel’s built-in Service Container (PSR-11 compliant) is tightly integrated with its ecosystem (e.g., IoC bindings, service providers, facades). nette/di is a standalone, compiled DI container optimized for performance and explicit wiring, not designed for Laravel’s conventions (e.g., service providers, facades, or Laravel’s app() helper).

  • Conflict: Laravel’s container expects runtime resolution (e.g., resolve()), while nette/di compiles dependencies into static PHP code at build time. This creates a fundamental architectural mismatch—Laravel’s dynamic binding system cannot natively consume a pre-compiled container.
  • Opportunity: Could be used as a micro-service container for non-Laravel components (e.g., domain layers, background jobs) via PSR-11 adapters (e.g., league/container or custom wrappers).

• Key Laravel Features Unsupported:

  • Service Providers: nette/di lacks Laravel’s register()/boot() lifecycle hooks.
  • Contextual Binding: Laravel’s when()/needs() logic is incompatible with nette/di’s compiled autowiring.
  • Facades: nette/di does not integrate with Laravel’s facade system.
  • Tagging/Grouping: Laravel’s tag()/context() features are absent.

Integration Feasibility

• PSR-11 Compatibility: nette/di implements PSR-11 (ContainerInterface) but with non-standard extensions (e.g., compiled containers, Neon/YAML config). Laravel’s container is PSR-11-compliant but expects runtime flexibility, while nette/di is optimized for compile-time rigidity.

  • Workaround: Use a PSR-11 adapter (e.g., league/container) to bridge nette/di with Laravel, but this introduces performance overhead (runtime resolution vs. compiled code).

• Configuration Overlap:

  • Laravel uses PHP classes (AppServiceProvider) for bindings.
  • nette/di uses Neon/YAML or PHP-based definitions (e.g., services.neon).
  • Conflict: Merging these requires custom glue code (e.g., a ServiceProvider that loads nette/di definitions into Laravel’s container).

• Autowiring Differences:

  • Laravel’s autowiring is runtime-based (reflection at resolve() time).
  • nette/di compiles autowiring into static code (faster but less flexible).
  • Risk: Mixed autowiring (Laravel + nette/di) may lead to unpredictable resolution (e.g., circular dependencies handled differently).

Technical Risk

Key Questions for TPM

1. Why not use Laravel’s native container?

   • Is there a specific feature in nette/di (e.g., compiled performance, Neon config) that justifies the integration risk?
   • Could the need be met with Laravel’s existing tools (e.g., Illuminate\Container\Container, Illuminate\Foundation\Application)?

2. Scope of Integration:

   • Will nette/di replace all Laravel services, or only specific components (e.g., domain layer)?
   • If partial, how will cross-container dependencies (e.g., a nette/di-managed service calling a Laravel-managed service) be handled?

3. Performance Trade-offs:

   • Is the compile-time optimization of nette/di worth the runtime flexibility loss in Laravel’s container?
   • Will the team accept slower resolution if using a PSR-11 adapter?

4. Team Expertise:

   • Does the team have experience with Nette’s ecosystem (e.g., Neon config, Tracy debugging)?
   • Is there static analysis (PHPStan/Psalm) in the CI pipeline to leverage nette/di’s type safety?

5. Future-Proofing:

   • How will Laravel upgrades (e.g., new container features) interact with nette/di?
   • Is the team open to abandoning nette/di if Laravel’s container evolves to meet the same needs?

Integration Approach

Stack Fit

• Laravel’s Stack:

  • Primary Container: Illuminate\Container\Container (PSR-11 compliant).
  • Autowiring: Runtime reflection-based (no compilation).
  • Configuration: PHP classes (AppServiceProvider), config/ files.
  • Debugging: Laravel Debugbar, Tideways.
  • Performance: Optimized for dynamic resolution (e.g., facades, dynamic bindings).

• nette/di Stack:

  • Primary Container: Compiled PHP code (no runtime reflection).
  • Autowiring: Static analysis + compile-time resolution.
  • Configuration: Neon/YAML or PHP-based definitions.
  • Debugging: Tracy DI Panel (Latte-based).
  • Performance: Near-native speed (pre-generated code).

• Compatibility Matrix:

  Feature	Laravel Container	nette/di	Integration Feasibility
  PSR-11 Compliance	✅ Yes	✅ Yes	High (via adapter)
  Service Providers	✅ Yes	❌ No	Low (custom glue)
  Autowiring	✅ Runtime	✅ Compile	Medium (conflict)
  Facades	✅ Yes	❌ No	Low
  Neon/YAML Config	❌ No	✅ Yes	High (but redundant)
  Compiled Performance	❌ No	✅ Yes	High (but isolated)
  Tracy Debugging	❌ No	✅ Yes	Low (incompatible)
  PHP 8.5+ Features	✅ Yes	✅ Yes	High

Migration Path

Option 1: Isolated Usage (Recommended)

• Scope: Use nette/di only for non-Laravel components (e.g., domain layer, background jobs).

• Implementation:

  1. Create a PSR-11 Adapter:
     • Wrap nette/di’s Container in a class implementing Psr\Container\ContainerInterface.
     • Example:

       class NetteDiAdapter implements ContainerInterface {
           private Container $netteContainer;
       
           public function __construct(Container $container) {
               $this->netteContainer = $container;
           }
       
           public function get(string $id) {
               return $this->netteContainer->getService($id);
           }
       
           public function has(string $id): bool {
               return $this->netteContainer->hasService($id);
           }
       }
       

  2. Register Adapter in Laravel:

     $netteContainer = new Container();
     $netteContainer->loadFromFile(__DIR__.'/services.neon');
     
     $adapter = new NetteDiAdapter($netteContainer);
     app()->bind('nette', fn() => $adapter);
     

  3. Use Only for Targeted Services:
     • Annotate classes with #[Inject] and configure in services.neon.
     • Avoid mixing with Laravel’s autowiring.

• Pros:

  • Minimal risk to Laravel’s core.
  • Leverages nette/di’s strengths (