Core Laravel Package

Technical Evaluation

What the package actually is. hoa/core is the bootstrap and utility layer of the Hoa project — a modular, non-framework PHP library suite that peaked around 2014–2015. In the 2.x line it shipped the Hoa\Core singleton (autoloader registration, error/exception handler installation, shutdown hooks), Hoa\Core\Consistency (assertion/contract checking), Hoa\Core\Event (a source/bucket/listener event bus), Hoa\Core\Parameter, Hoa\Core\Prototype, and the hoa:// stream-wrapper/protocol resolver. It is not a Laravel package, has no service provider, no facade, no config publishing, and no awareness of the framework's container or lifecycle. It predates PSR-11, PSR-15, and effectively predates modern Laravel.

Architecture fit — poor, and structurally so, not incidentally. Every capability in hoa/core is duplicated by something Laravel already owns and has owned for years: the event bus maps to Illuminate\Events\Dispatcher, the parameter bag to symfony/options-resolver or config, autoloading to Composer, error/exception handling to App\Exceptions\Handler, and the hoa:// protocol to Flysystem or a purpose-built stream wrapper. Adopting it means running a parallel runtime alongside Laravel's: a second autoloader, a second global error handler, a second shutdown function stack, and a second event dispatcher. That is not integration, it is cohabitation, and cohabitation between two bootstrap layers is where the failure modes live.

Integration feasibility — technically possible, practically unjustifiable. There is no maintained Laravel bridge, and with 35 stars, zero tracked dependents, and an archive date of November 2015, there is no community to lean on. Any integration is a bespoke fork owned entirely by your team. The realistic feasibility question is not "can we wire it in" (a service provider could be written in an afternoon) but "what does wiring it in buy us that three maintained Composer packages do not" — and the honest answer is nothing.

Technical risk — high and unhedged.

• Runtime compatibility. Last release 2015-11-09 targets PHP 5.4/5.5-era idioms. The global error handler, shutdown function registration, and assertion semantics are exactly the surfaces that changed most aggressively in PHP 7.x and 8.x. Expect deprecation noise at minimum and hard fatals at worst; this must be proven on your exact PHP version before anything else is discussed.
• Handler collision. Hoa\Core installs process-wide error and exception handlers. If it wins the race against Laravel's handler, you lose framework error reporting, Whoops/Ignition pages, and structured logging for the whole application — a blast radius far larger than the feature you wanted.
• Supply chain. Archived, unmaintained, no security response process. Any CVE-adjacent issue in the code or its transitive tree is yours to patch, forever.
• Signal quality. The score (0.37) and opportunity (18.29) corroborate the qualitative read: this is a legacy artifact, not a candidate.

Key questions to put to the requesting engineer. (1) Which specific symbol from hoa/core do you actually need — Consistency, Event, Protocol, or the bootstrap? (2) What is the maintained equivalent you have already rejected, and why? (3) If the need is a stream wrapper or an assertion library, can we scope it to a 200-line internal package instead of a 2015 framework core? (4) Is this a direct dependency or a transitive one pulled in by an older package? If transitive, that package is the real conversation.

Integration Approach

Stack fit. Treat hoa/core as incompatible by default with a modern Laravel application. It was designed for the Hoa suite's own bootstrap, where it is the first and only thing that runs. Laravel's public/index.php → bootstrap/app.php → kernel → provider boot sequence already occupies that position. Two bootstrap owners in one process is the single clearest architectural anti-pattern here, and no amount of adapter code makes it clean.

Migration path — replace, do not integrate. The correct sequencing is capability-by-capability substitution, and it should be framed to stakeholders as a de-risking exercise, not a feature delivery:

1. Inventory. Run composer why hoa/core and composer depends hoa/core to establish whether this is direct or transitive. Grep for Hoa\Core, hoa://, Consistency::, and Hoa\Core\Event usage. Quantify call sites — this is almost certainly a small number.
2. Map each symbol to a maintained target. Consistency → webmozart/assert or native assertions plus PHPStan; Hoa\Core\Event → Illuminate\Events\Dispatcher; Parameter → symfony/options-resolver; hoa:// → Flysystem or an in-house streamWrapper class; bootstrap/autoloader → delete outright, Composer and Laravel already do it.
3. Isolate before removing. If any call site is genuinely load-bearing, vendor the ~100 lines of the specific class into App\Support\Legacy\ under your namespace, strip the global handler registrations, and add characterization tests around its behavior. This preserves behavior while eliminating the process-wide side effects.
4. Remove the dependency. Drop from composer.json, run the full suite, and confirm the global handler and shutdown stacks are back to a single owner.

Compatibility. Do not attempt this on PHP 8.x without a spike first — and expect the spike to fail. If a hard blocker emerges (legacy package deep in the tree requires hoa/core), the pragmatic move is to pin the surrounding package rather than to patch the archived one, or to fork it explicitly and accept the maintenance burden with eyes open. Composer's replace directive is the cleanest lever if you need to satisfy a transitive constraint with your own vendored shim.

Sequencing. Blocking prerequisite is the dependency inventory — nothing else should start until you know direct vs. transitive. Then substitution in a branch, then a canary deploy behind a feature flag if any user-facing behavior (event dispatch ordering, error page rendering) could shift, then removal. Reserve the removal step for a quiet change window; error-handler changes are the kind of thing that only reveals itself on the first production exception.

Operational Impact

Maintenance. Total. There is no upstream. Archived repositories do not receive PHP-version compatibility patches, security fixes, or bug fixes, and the Hoa project's documentation site is itself unreliable. Every future PHP upgrade (8.1 → 8.2 → 8.3 → …) becomes a manual audit of code nobody on the team wrote and nobody wants to own. This is a permanent, compounding tax on a dependency that delivers no differentiated value.

Support. No vendor, no maintainer, no issue tracker with a pulse, no Stack Overflow gravity. Internal support means whoever integrated it becomes a single point of knowledge, and that person will leave. This is the dominant hidden cost and it does not appear on any estimate.

Scaling. The package is not a throughput concern — it is small, synchronous, and cheap. The scaling risk is organizational: the number of engineers who can safely modify a bootstrapped global error handler is small, and that number does not grow with headcount. The event system, if used, also introduces a second dispatch path that will not appear in Laravel's event tooling, degrading observability exactly when you are debugging at scale.

Failure modes. Ranked by expected pain:

• Silent handler capture. Hoa\Core's error/exception handler intercepts before or instead of Laravel's, producing blank 500s, missing log entries, and error pages that bypass Ignition — the worst possible debugging experience, and it presents as "Laravel is broken."
• Shutdown-order nondeterminism. Registered shutdown functions execute in registration order; mixing Hoa's with Laravel's can mask fatal errors or emit output after the response is flushed.
• PHP upgrade fatals. Hard failures on minor PHP bumps, discovered at deploy time.
• Double autoloading and class-map drift. Two autoloaders racing over the same namespace is a class of bug that reproduces once a week and never on demand.
• Event double-dispatch. If both buses are wired, listeners fire twice — idempotency bugs that corrupt data quietly.

Ramp-up. Superficially trivial — the API surface is small and the docs, where they survive, are readable. In practice, ramp-up cost is dominated not by learning the library but by learning its interactions with Laravel's bootstrap, which are undocumented, version-specific, and discovered through production incidents. Budget for the substitution work described above instead; it is smaller, bounded, and leaves the codebase in a state a new hire can reason about.

Recommendation. Do not adopt. If found transitively, schedule removal within the current quarter and treat it as tech debt with a named owner. The 2015 archive date, zero dependents, and 0.37 score are not incidental — they are the assessment.