Hmvc Laravel Package

Technical Evaluation

Architecture fit. The core issue is categorical: zeus/hmvc is not a Laravel package, it is a competing full-stack PHP framework (own kernel, ORM, request layer, template engine, Elasticsearch integration). Laravel has no native HMVC — controller-as-subrequest module composition is a genuine gap — so there is a superficial pull toward this repo. But adopting it means replacing the Illuminate stack, not extending it. The 0.33 score is consistent with that reading: the package name (zeus/hmvc) and the repository (diloabininyeri/dilovel) do not correspond, which alone signals packaging/provenance immaturity.

Integration feasibility. No evidence of a Laravel service provider, facade, or container bridge. Coexistence would mean two kernels, two containers, and namespace collisions across Illuminate\* boundaries. A bridge is theoretically constructible but would be bespoke code we own against an upstream we do not control. The only low-risk integration shape is an isolated satellite service or a throwaway spike, never an in-process dependency of the monolith.

Technical risk.

• Adoption risk (high): 36 stars, 0 dependents, single-maintainer signal — no production validation anywhere.
• Supply-chain risk (high): package/repo name mismatch, unknown license hygiene, unknown release history.
• Maintenance risk (high): patch cadence for PHP minor versions and CVEs is unevidenced.
• Quality-signal risk (medium-high): the description duplicates "template engine," makes unfalsifiable claims ("like linux operating system"), and omits PHP version matrix, CI status, and test coverage.
• Lock-in risk (high): the ORM and template engine are framework-internal; any code written against them is not portable back to Eloquent/Blade.

Key questions for the maintainer / spike.

1. Is there a Laravel/Lumen service provider or any documented interoperability path?
2. Supported PHP version matrix, CI status, and measured test coverage?
3. Release history: tagged semver releases, last commit date, issue/PR response times?
4. License and CLA — can we fork and patch commercially?
5. Does the ORM sit on top of Doctrine DBAL/PDO, and can it be swapped for Eloquent?
6. What exactly does the HMVC dispatch do — in-process subrequests, or HTTP loopback? (Latency and recursion implications differ by an order of magnitude.)
7. Which of our actual requirements (module composition, widget nesting, multi-tenant modules) is not already served by nwidart/laravel-modules + Laravel subrequest dispatch?

Integration Approach

Stack fit. Poor against an existing Laravel codebase: the only alignment is the PHP language and a shared interest in Elasticsearch. Treat stack fit as zero until a Laravel bridge is proven to exist in code, not in prose.

Migration path. There is none in either direction. If we proceed at all, the plan must be API-bounded: the satellite exposes HTTP/JSON, the Laravel monolith talks to it through a thin client interface we define. That interface is the real deliverable — it makes a future swap to a Laravel-native implementation a drop-in, and caps sunk cost.

Compatibility. Unknown PHP matrix versus our runtime; Composer will almost certainly conflict with illuminate/* version constraints if installed into the same application. Verify by attempting composer require in a scratch project before any design work — a 30-minute check that can close the whole evaluation.

Sequencing.

1. Gate 0 (0.5 day): Composer install test + read the kernel/HMVC dispatch source. Fail fast here.
2. Gate 1 (1 week, timeboxed): Spike the specific HMVC pattern (nested module rendering, shared request context) in an isolated container. Success criterion is the pattern, not the framework.
3. Gate 2: Head-to-head against nwidart/laravel-modules + Laravel subrequest dispatch + Livewire components. Default decision: build the pattern in Laravel, do not adopt the framework.
4. Gate 3 (only if 1–2 pass decisively): Deploy as a satellite service behind our client interface, out of the critical request path, with an explicit exit plan and a named internal owner.

Operational Impact

Maintenance. Effectively bus factor 1. With 0 dependents there is no downstream community applying pressure to keep it patched — we would become the de facto maintainer of a fork. Budget for that explicitly or do not adopt.

Support. No vendor, no SLA, negligible community surface at 36 stars. Internal SME required; if that engineer leaves, the service is orphaned. Any production use requires a documented runbook and a fork-and-patch capability before launch.

Scaling. No published benchmarks. HMVC's characteristic cost is in-process call depth: nested dispatches multiply memory and latency and can mask N+1 behavior behind a clean API. The bundled Elasticsearch component is an additional stateful dependency we would have to operate, monitor, and version independently of the app.

Failure modes to instrument.

• Composer resolution failure on the next PHP or dependency upgrade — highest-probability, near-certain over a 24-month horizon.
• Unpatched CVE in an abandoned upstream, discoverable only by our own scanning.
• ORM behavioral divergence from Eloquent producing silent data-layer rework.
• Subrequest recursion or context leakage under nested module composition.
• Elasticsearch cluster drift if the framework's client version lags our cluster version.

Ramp-up. Two to four weeks per engineer to reach productivity in an unfamiliar framework idiom (new ORM, new templating, new request lifecycle), versus hours for a Laravel-native HMVC pattern. Hiring pool for this framework is effectively zero, which converts every future backfill into a training project.

Recommendation. Do not adopt. Fund the one-week spike only to extract the HMVC design pattern, and default to implementing it with Laravel-native primitives. Revisit only if the maintainer demonstrates a Laravel service provider, CI-backed test coverage, tagged releases, and at least one independent production dependent.