Event Laravel Package

Technical Evaluation

Architecture fit: Laravel's built-in event system (Symfony-based) handles synchronous, queue-driven workflows natively. sabre/event provides low-level async primitives (event loop, promises, coroutines) that only align with niche use cases like custom WebSocket servers or non-HTTP async tasks. It's redundant for standard Laravel applications where queue workers or Horizon handle async needs.
Integration feasibility: Composer installation is trivial, but conflicts may arise if attempting to use sabre's event loop within Laravel's HTTP request lifecycle (which is synchronous by default). The package can coexist but requires strict isolation (e.g., only in CLI tools or dedicated workers).
Technical risk: High risk of blocking HTTP requests if event loop is improperly invoked. Type declaration changes in v6+ (e.g., strict parameter types) may break existing extended classes. 0 dependents indicate limited real-world validation in Laravel ecosystems.
Key questions: How will the event loop interact with Laravel's queue workers? Should we run separate processes for sabre-based async tasks? How to handle promise rejections without disrupting Laravel's exception handling? Is there a clear path to deprecate sabre if adoption fails?

Integration Approach

Stack fit: Only suitable for isolated async use cases outside Laravel's core HTTP stack—e.g., CLI tools processing external APIs via promises, or custom long-running workers. Not compatible with standard Laravel controllers/middleware.
Migration path: Incremental adoption: Start with a dedicated CLI command using EventLoop for async I/O. Avoid modifying existing event listeners. Use Promise\all() for parallel HTTP calls in a non-blocking manner, but ensure EventLoop::run() is explicitly called in the command.
Compatibility: Requires PHP 7.4+ (v6+), which aligns with Laravel 10+. No direct conflicts with Laravel