Dispatcher Laravel Package

Product Decisions This Supports

• Framework boundary / build-vs-buy for the request layer. The core decision this package informs is whether dispatch (route → controller → action → response) is a commodity we inherit from Laravel or an abstraction we bring in. Laravel already ships this as Illuminate\Routing (Router, ControllerDispatcher, middleware pipeline); hoa/dispatcher is a parallel, non-Laravel implementation of the same idea.
• Dependency intake policy. With 12 stars, 0 dependents, and no release since May 2017, this is a useful calibration case for a "should we take this dependency?" checklist: maintenance status, downstream adoption, security response, PHP-version support, and exit cost all fail.
• Architecture reference, not a runtime dependency. If we are designing an internal micro-framework, CLI command dispatcher, or plugin/hook system, its model — resolve controller + action from the route, instantiate, invoke, return the result for the caller to render, with a "kit" injecting router/view/data — is a compact pattern reference. Most of that pattern is already subsumed by Laravel's container, middleware, and route model binding.
• Legacy/inheritance triage. If we ever acquire or inherit a codebase built on the Hoa stack, this tells us what the dispatch contract looks like and how much of the request path must be rewritten to move onto Laravel.
• Roadmap impact: none beyond a time-boxed spike. There is no migration plan, upgrade path, or version cadence to track. It should not appear on a roadmap as an integration.

When to Consider This Package

Consider it only when all of the following hold:

• You are already standardized on the Hoa component family (Hoa\Router, Hoa\View, etc.) and need the matching dispatcher for an existing, working application.
• You need a minimal, framework-free dispatch layer for a small PHP 7-era service and are prepared to fork and own it, including security patching.
• The goal is education or pattern evaluation — reading the source to inform our own conventions, not installing it.

Look elsewhere when:

• You are on Laravel. Use Illuminate\Routing — it gives you routing, controller dispatch, middleware, route model binding, DI, and a supported upgrade path. Wiring in an external dispatcher means re-implementing the request lifecycle and losing middleware, auth, and testing ergonomics.
• You need modern PHP or standards alignment. PSR-7/PSR-15 middleware, PHP 8.2+, static analysis, and typed signatures are not served by a 2017-era package.
• You need support, docs, hiring familiarity, or security advisories. Zero dependents and a dormant release cadence mean no community backstop and no patch stream; onboarding cost is entirely yours.
• Blast radius matters. Replacing a dispatch layer later means touching every route and controller — the exit cost is high even though the entry cost looks trivial.

How to Pitch It (Stakeholders)

To executives: We evaluated hoa/dispatcher and recommend a no-go. It is an unmaintained 2017-era dispatch component with negligible adoption (12 stars, no dependent packages) and no security or version support. Laravel already provides this capability natively and with vendor backing, so adopting it would add maintenance liability and future rewrite risk in exchange for zero product capability. The cost of saying no is effectively zero; the cost of saying yes shows up later, in the most-traveled code path we have.

To engineering: It solves a problem we've already solved — mapping a route to a controller action and invoking it. Laravel's router and controller dispatcher cover this with middleware, DI, and testing built in. Treat hoa/dispatcher as a design reference for dispatch semantics if we build an internal command/plugin dispatcher, but keep it out of the dependency graph; if someone wants to study it, time-box a spike in a scratch branch.

Bottom line: Read it, don't ship it. Decision: no adoption; keep dispatch on Laravel's native primitives.