Service Provider Laravel Package

Technical Evaluation

Architecture Fit

• PSR/Container Version Alignment: The update to support PSR/Container ^2.0 (from likely ^1.1) aligns with modern Laravel (10+) and PHP ecosystem standards. This reduces friction with newer Laravel versions and third-party packages adopting PSR-20.
• Backward Compatibility: The change is non-breaking for Laravel users, as PSR-20 is a superset of PSR-11. Existing code using PSR-11 will continue to work without modification.
• Laravel Synergy: Laravel 10+ already uses PSR-20-compliant containers under the hood (via Illuminate\Contracts\Container\Container), so this update future-proofs integration.
• Use Case Expansion:
  • Enables seamless integration with Symfony 6.3+ and other PSR-20 adopters.
  • Reduces need for custom shims when mixing Laravel with PSR-20 containers.

Integration Feasibility

• Zero-Coupling Risk: The PSR-20 update does not affect the ContainerInterop\ServiceProvider contract, so existing Laravel service providers remain unaffected.
• Testing Impact:
  • No changes required for unit tests using PSR-11 mocks (PSR-20 is backward-compatible).
  • May need updates if tests explicitly check for PSR-11 methods (e.g., get() vs. PSR-20’s has()/get()).
• Dependency Conflicts:
  • Low risk: PSR-20 is a standard, and Laravel’s container already supports it.
  • Potential conflict if another package pins PSR/Container to v1.1 (unlikely in modern stacks).

Technical Risk

Key Questions

1. Should we upgrade Laravel to 10+ to leverage PSR-20 natively?
   • If yes, this package becomes redundant for basic DI (Laravel’s container already handles PSR-20).
2. Are we integrating with Symfony 6.3+ or other PSR-20 ecosystems?
   • If yes, this update simplifies cross-framework sharing.
3. Do we need to enforce PSR-20 in CI/CD?
   • Example: Add phpstan/extension-installer to validate PSR-20 compliance.
4. Will this affect our current interop migration strategy?
   • No, but it future-proofs the approach.
5. Are there Laravel-specific PSR-20 extensions we should adopt?
   • Example: Illuminate\Contracts\Container\Container may expose additional methods.

Integration Approach

Stack Fit

• Laravel 10+: Full compatibility with PSR-20 (native support).
• Laravel <10: Partial compatibility (may require container-interop/polyfill).
• PHP Version: Requires PHP 8.0+ (unchanged).
• Ecosystem Synergy:
  • Symfony 6.3+: Native PSR-20 support.
  • Laminas: PSR-20 compatible via laminas/laminas-diactoros.
• Anti-Patterns:
  • Avoid mixing PSR-11/PSR-20 implementations unless necessary (adds complexity).

Migration Path

1. Assessment Phase:
   • Audit for PSR-11-only dependencies (e.g., php-di/php-di).
   • Verify Laravel version supports PSR-20 (10+ does; 9.x may need polyfills).
2. Incremental Adoption:
   • Step 1: Update composer.json to allow PSR-Container ^2.0:

     "require": {
         "psr/container": "^2.0"
     }
     

   • Step 2: Replace psr/container:^1.1 in third-party packages with ^2.0 where possible.
   • Step 3: Update tests to use PSR-20 methods (e.g., has() instead of get() checks).
3. Full Migration:
   • If using ContainerInterop\Container, update to the latest version (likely PSR-20 compliant).
   • For Laravel <10, add:

     composer require container-interop/polyfill
     

Compatibility

Sequencing

1. Pre-Integration:
   • Update composer.json to allow PSR-Container ^2.0.
   • Add PSR-20 validation to CI (e.g., PHPStan rules).
2. Core Integration:
   • Replace psr/container:1.1 with ^2.0 in dependencies.
   • Update ContainerInterop\Container to the latest version (if used).
3. Post-Integration:
   • Deprecate PSR-11-only patterns via deprecation notices.
   • Benchmark DI resolution time (PSR-20 should have negligible impact).

Operational Impact

Maintenance

• Pros:
  • Future-proofing: Aligns with Laravel 10+ and modern PHP ecosystems.
  • Reduced polyfill needs: Fewer custom shims required for cross-framework DI.
• Cons:
  • Minimal impact: PSR-20 is backward-compatible, so no breaking changes.
  • Documentation update: Clarify PSR-20 support in internal guides.
• Tooling:
  • Use PHPStan’s container extension to enforce PSR-20 compliance.
  • Example rule:

    rules:
      ContainerInterface:
        psr-20: true
    

Support

• Debugging Complexity:
  • Unchanged: PSR-20 errors will mirror PSR-11 (e.g., NotFoundException).
  • Example: If a service is missing, the stack trace will point to the same resolution logic.
• Community Resources:
  • Improved: PSR-20 is widely adopted; more community support available.
• Fallback Plan:
  • Downgrade psr/container to ^1.1 if a critical package fails (but this is unlikely).

Scaling

• Performance:
  • No impact: PSR-20 adds no runtime overhead; Laravel’s container already optimizes DI.
  • Benchmark with:

    composer require laravel/bench
    vendor/bin/bench run
    

• Horizontal Scaling:
  • None: DI resolution is per-request and unchanged.
• Cold Starts:
  • None: PSR-20 does not affect autoloading or container initialization.

Failure Modes

Ramp-Up

• Onboarding Time:
  • Negligible: PSR-20 is a superset; no new concepts for Laravel devs.
  • 1 hour for teams to update composer.json and CI.
• Training Needs:
  • Focus on:
    • PSR-20 vs. PSR-11 differences (e.g., has()