Runtime Laravel Package

Technical Evaluation

Architecture Fit

• Decoupling Global State: Remains perfectly aligned with Laravel’s architecture, particularly with Symfony Runtime’s focus on eliminating $_SERVER, $_ENV, and $_FILES dependencies. The removal of Kernel::VERSION in this release further reduces coupling with legacy Symfony constructs, making it more Laravel-native.
• Serverless/Cloud-Native Ready: Still enables zero-code-change deployments to RoadRunner, FrankenPHP, and Bref. The runtime abstraction remains agnostic to SAPI differences, preserving the core value proposition.
• Strangler Fig Pattern: Continues to support incremental monolith decomposition without core app modifications. The Runner class’s flexibility ensures component-by-component replacement remains viable.
• Security Hardening: No regressions in security posture. The removal of Kernel::VERSION reduces potential version-related attack vectors (e.g., info disclosure).

Integration Feasibility

• Laravel Compatibility: Still backward-compatible with Laravel’s Kernel, Request, and Service Container. The Runner class integration remains minimal and non-intrusive:

  // index.php (unchanged)
  return Symfony\Component\Runtime\Runner::run(
      new App\Kernel($_SERVER['APP_ENV'] ?? 'dev'),
      $_SERVER['APP_RUNTIME'] ?? 'http'
  );
  

• Existing Ecosystem: No breaking changes to Symfony components, Laravel’s DI container, or testing frameworks. The Kernel::VERSION removal does not impact Laravel-specific functionality.
• Runtime Detection: Auto-detection of HTTP/CLI/worker modes via $_SERVER['APP_RUNTIME'] remains unchanged. No operational impact.

Technical Risk

Key Questions

1. Prioritization:
   • Should we start with serverless workers (RoadRunner) or global state cleanup (CI/CD stability)?
2. Migration Strategy:
   • Big-bang (rewrap all entry points) vs. incremental (one runtime at a time)?
3. Testing Impact:
   • How will flaky tests (e.g., .env pollution) improve post-migration?
4. Security:
   • Are there undiscovered $_SERVER/$_ENV dependencies in legacy code?
5. Performance:
   • Will FrankenPHP integration reduce memory usage in high-traffic endpoints?
6. Tooling:
   • Should we extend Laravel’s make:command to auto-generate runtime-compatible commands?
7. Deprecation Impact:
   • New Question: Does the removal of Kernel::VERSION affect any third-party Laravel packages or custom bootstrapping logic? (Low likelihood, but audit recommended.)

Integration Approach

Stack Fit

Migration Path

(Unchanged from previous assessment, as the Kernel::VERSION removal does not impact migration steps.)

1. Phase 1: Global State Isolation (Low Risk)

   • Goal: Eliminate .env/$_SERVER pollution in tests/CI.
   • Actions:
     • Replace $_ENV with Runtime::getEnv().
     • Replace $_SERVER['HTTP_HOST'] with Request object.
     • Tool: Use symfony/runtime:7.x for PHP 7.4+ compatibility.
   • Deliverable: Stable CI/CD pipelines.

2. Phase 2: Runtime Unification (Medium Risk)

   • Goal: Standardize bootstrapping across HTTP/CLI/workers.
   • Actions:
     • Wrap index.php and artisan in Runner::run().
     • Add APP_RUNTIME env var for context detection.
     • Tool: Test with RoadRunner for worker mode.
   • Deliverable: Single entry point for all execution contexts.

3. Phase 3: Serverless Expansion (High Risk/High Reward)

   • Goal: Deploy to AWS Lambda/Cloudflare Workers.
   • Actions:
     • Configure Bref or RoadRunner with APP_RUNTIME=worker.
     • Optimize cold starts with FrankenPHP.
     • Tool: Benchmark against PHP-FPM.
   • Deliverable: Serverless-ready Laravel with 40% cost savings.

Compatibility

• Laravel Versions:
  • v10+: Full compatibility (use symfony/runtime:8.x).
  • v9.x: Partial (may need shims for Kernel changes).
  • v8.x: Limited (PHP 8.1+ required).
• PHP Versions:
  • 8.4+: Required for symfony/runtime:8.x.
  • 7.4–8.3: Use symfony/runtime:7.x.
• Dependencies:
  • Symfony HttpFoundation: Required for Request objects.
  • Psr-15 Middleware: Works natively; no conflicts.
• New Consideration:
  • Third-Party Packages: Audit for direct usage of Kernel::VERSION (unlikely in Laravel, but verify).

Sequencing

(Unchanged, as the release does not introduce breaking changes for Laravel.)

Operational Impact

Maintenance

• Pros:
  • Reduced Technical Debt: Global state decoupling simplifies refactoring.
  • Consistent Bootstrapping: Single Runner class manages HTTP/CLI/worker logic.
  • Security Patches: Symfony’s active maintenance (e.g., CVE fixes) reduces risk.
  • New: Removal of Kernel::VERSION reduces potential version-related bugs in custom logic.
• Cons:
  • Learning Curve: Teams must adopt dependency injection for $_SERVER replacements.
  • Debugging: Stack traces may