- Is hoa/event a Laravel package?
- No. hoa/event is a framework-agnostic event bus from the Hoa project with no service provider, facade, config file, publishable assets, or Laravel conventions of any kind. It ships Bucket, Listener, Source, and Listenable abstractions built around hoa:// event identifiers, which are foreign to Laravel. For Laravel applications, Illuminate\Events already provides the equivalent capability natively.
- Does hoa/event support Laravel 10 or Laravel 11?
- There is no official Laravel support. The last release was 2017-08-30, the repository is archived, and the declared constraints target the PHP 5.5 to 7.x era. It has never been validated against modern Laravel versions or PHP 8.1, 8.2, or 8.3. Any integration would require manual container wiring plus a custom adapter.
- Is hoa/event still maintained?
- No. The repository is archived, the last tagged release dates to August 2017, and it has zero dependents in the registry signals. Its transitive siblings such as hoa/consistency, hoa/stream, and hoa/protocol carry the same staleness. Treat it as abandoned software with no security response channel and no community-validated upgrade path.
- hoa/event vs the Laravel event dispatcher — which should I use?
- Use Illuminate\Events. Laravel's dispatcher already gives you named events, listeners, subscribers, queued listeners, model events, broadcasting, and testing helpers like Event::fake(). hoa/event offers a parallel, semantically different model based on string event IDs, channels, and buckets, so adopting it means maintaining two dispatch paths with inconsistent ordering and exception behavior.
- How do I install hoa/event with Composer?
- You can run composer require hoa/event, but it is a plain library with no package discovery, so nothing registers automatically inside a Laravel app. You would need to write a service provider and an adapter to bridge Hoa listeners into Laravel's dispatcher. Given the capability is already in-framework, deliberate installation is not recommended.
- Does hoa/event work on PHP 8?
- There are no guarantees. The declared constraints target PHP 5.5 through 7.x, there is no modern-PHP CI signal, and the Hoa siblings it depends on are the likeliest source of bootstrapping failures. Run a timeboxed spike on your actual runtime that probes for removed functions and Hoa\Consistency failures. Assume a PHP 7.4 ceiling until you have proven otherwise.
- How do I migrate from hoa/event to Laravel events?
- Start with inventory: run composer why hoa/event and map every event ID and listener registration to its owning package or team. Freeze the exact version in composer.lock and add an architecture rule via deptrac or PHPStan that bans new Hoa\Event imports. Introduce a thin adapter so Hoa listeners flow through Laravel's dispatcher with a single ordering story, port listeners behind feature flags, then delete the adapter and remove the dependency. Add regression tests for event ordering, idempotency, and failure handling before removal.
- What are the production risks of using hoa/event?
- Abandoned upstream, no security response channel, unvalidated on PHP 8, a weak typing and static-analysis story, and an event-ID protocol documented only inside the Hoa ecosystem. Running two dispatch paths invites ordering ambiguity, duplicate handling, and inconsistent exception propagation. The upside is near zero because the capability already exists in the framework.
- Is hoa/event a good PSR-14 replacement?
- No. hoa/event predates PSR-14 and does not implement it, so it will not interoperate with listeners written against the standard interface. If you need a framework-agnostic bus, standardize on PSR-14 implementations such as symfony/event-dispatcher or league/event. Inside Laravel, Illuminate\Events remains the idiomatic choice.
- How do I check whether hoa/event is already in my project?
- Run composer why hoa/event or composer depends hoa/event to see which package drags it in. If it is a transitive dependency of a legacy Hoa-derived library, pin the exact version in composer.lock and isolate it rather than adopting it deliberately. Then schedule removal work alongside the upgrade of the owning package.