Event Laravel Package

Technical Evaluation

Verdict: do not adopt. This is an archived, standalone event-bus component from the Hoa project — not a Laravel package. It offers nothing Laravel does not already own natively, and it carries permanent maintenance liability.

Architecture fit

• hoa/event is a framework-agnostic observer/event-bus implementation built around string event IDs, channels, and Bucket/Listener/Source/Listenable abstractions. It has no service provider, facade, config, publishable assets, queue integration, or broadcasting support.
• Laravel already ships Illuminate\Events: dispatcher, listeners, subscribers, queued listeners, model events, broadcasting, and testing helpers. The wider PHP ecosystem has standardized on PSR-14 (symfony/event-dispatcher, league/event).
• Adopting this package means running a second, parallel event model with different semantics (hoa://Event/... identifiers, buckets, channels) alongside the framework's. Fit is poor; the only defensible use is inside a legacy Hoa-derived codebase where it is already a transitive dependency.
• Registry signals agree: 321 stars, 0 dependents, archived, last release 2017-08-30, internal score 1.27 with opportunity 32.93.

Integration feasibility

• Composer-installable in principle, but the declared constraints target the PHP 5.5–7.x era and were never validated against PHP 8.1/8.2/8.3. Transitive siblings (hoa/consistency, hoa/stream, hoa/protocol) carry the same staleness and are the likeliest source of hard failures.
• No package discovery, no Laravel conventions. Integration requires manual container wiring plus an adapter to bridge Hoa listeners into Laravel's dispatcher — bespoke glue for a commodity capability.
• No modern-PHP CI signal and no dependent ecosystem means no community-validated upgrade path.

Technical risk

• High and asymmetric. Abandoned upstream, no security response channel, no PHP 8 guarantees, weak typing/static-analysis story, and an event-ID protocol documented only inside the Hoa ecosystem.
• Semantic mismatch risk: two dispatch paths invite ordering ambiguity, duplicate handling, and inconsistent exception propagation.
• Upside is near zero — the capability is already in-framework.

Key questions

• Is hoa/event already in our dependency graph, and which package drags it in?
• What capability does it provide that Illuminate\Events or a PSR-14 dispatcher does not?
• What is the target PHP runtime, and has anyone actually executed it there?
• Are we willing to fork and own this library indefinitely if an issue appears?
• Does the business case survive framing the cost as "we maintain it forever"?

Integration Approach

Stack fit: Poor. Laravel's dispatcher is the idiomatic bus; hoa/event is a foreign abstraction. Treat direct adoption as an anti-pattern and constrain it to a legacy island if it must exist at all.

Migration path (if already present):

1. Inventory — run composer why hoa/event; map every event ID and listener registration to the owning package or team.
2. Freeze — pin the exact version, lock it in composer.lock, and add an architecture rule (deptrac/PHPStan) banning new Hoa\Event imports.
3. Bridge — a thin adapter registering Hoa listeners into Laravel's dispatcher so there is exactly one dispatch path and one ordering story.
4. Replace — port listeners to Laravel events or PSR-14, delete the adapter, then composer remove hoa/event and its Hoa siblings.
5. Verify — regression tests for event ordering, idempotency, and failure handling before removal.

Compatibility: Assume a PHP 7.4 ceiling until proven otherwise. Run a timeboxed spike on the actual target runtime first, specifically probing for each()/create_function usage and Hoa\Consistency bootstrapping failures.

Sequencing: Discovery/inventory (1 sprint) → runtime spike (days) → adapter if legacy must keep functioning → per-listener migration behind feature flags → dependency removal. Do not schedule adoption work; schedule removal work.

Alternatives to standardize on: Illuminate\Events for Laravel-native needs; any PSR-14 implementation (symfony/event-dispatcher) if framework-agnostic decoupling is the real requirement; league/event for a lightweight standalone bus.

Operational Impact

Maintenance: Effectively owner-less. No upstream releases since 2017, repository archived, no triage, no advisories. Any maintenance is ours by default — a permanent tax on a capability we already have for free.

Support: No vendor, no SLA, no community of scale (0 dependents). Internal expertise will be thin and will decay with attrition. Onboarding cost is high relative to value: engineers must learn a bespoke event-ID protocol with no transferable benefit.

Scaling: In-process and synchronous — no queue, no broadcasting, no worker integration. Horizontal scale is entirely a function of our wiring, and any real async or throughput requirement forces a rewrite onto Laravel's queue-aware dispatcher anyway. It also scales poorly organizationally: every team touching events must learn two models.

Failure modes

• Highest likelihood: silent fatal breakage on a PHP upgrade inside Hoa\Consistency or stream/protocol bootstrapping.
• Listener-ordering divergence between the Hoa and Laravel dispatch paths producing intermittent, hard-to-reproduce behavior.
• Listener exceptions propagating differently than the framework expects, breaking request or queue semantics.
• Supply-chain/compliance exposure: an archived transitive dependency with no patching path becomes an audit finding at the next review.
• Abandonment surprise: when it breaks, no fix arrives, because there is no upstream.

Ramp-up: 1–3 days for a mid-level engineer to be productive with the API itself, but weeks of accumulated context to understand the legacy event graph. The dominant cost is organizational — a second event model doubles the mental model for every engineer who touches it.

Recommendation: Reject for new work. If already present, log it as technical debt with an explicit removal ticket, a named owner, and a target quarter.