Command Laravel Package

Technical Evaluation

Package identity and architecture fit. hyperf/command is the console component of the Hyperf framework — a coroutine-native PHP runtime built on Swoole/Swow — not a Laravel package. It sits on top of symfony/console, which is the same substrate Laravel's Artisan uses, so there is superficial familiarity (command classes, input/output, exit codes). The architectural fit is nonetheless poor for a Laravel application: the component expects Hyperf's DI container, hyperf/contract bindings, and in several code paths a coroutine context. Those assumptions do not hold inside a standard Laravel request/console lifecycle. The realistic leverage for a TPM is therefore not "adopt in Laravel" but "evaluate as a sibling runtime" or "mine for patterns."

Release signal quality (the actual finding). The v3.2.0 notes contain only an auto-generated compare link to v3.1.56. There is no changelog body, no stated feature list, no deprecation notice, and no breaking-change callout. A jump from a 56-patch line to a new minor is exactly where Hyperf has historically landed behavior changes (PHP floor raises, symfony/console major bumps, container signature changes). We cannot confirm or rule out any of that from the artifact provided. Treating this release as "additive because minor" would be an unsupported inference. This is the gating risk: the release is undiffed. No adoption decision should be made until the compare diff and the composer.json constraint delta are read.

Integration feasibility. Technically installable via Composer, but it drags in hyperf/di, hyperf/support, hyperf/contract, and PSR-11 expectations. Two command kernels (Artisan's and Hyperf's) in one process means two containers with overlapping singleton semantics — a known source of silent resolution bugs. Feasible only if Hyperf runs as a separate service/worker and the boundary is a network or queue call, not a shared process.

Technical risk. (1) Container duality if co-hosted. (2) Coroutine-only APIs surfaced in the new minor that no-op or fault outside a coroutine scheduler. (3) Version-floor drift — a PHP or symfony/console raise would cascade into our Laravel version support matrix. (4) Lock-in to a fast-moving single-vendor minor line.

Key questions for the maintainers.

• What is the diff between v3.1.56 and v3.2.0, and which items are additive vs. behavioral?
• Did the minimum PHP version or symfony/console constraint change in v3.2.0?
• Does any new public API require a coroutine context?
• Are there deprecations that signal removal in v4?
• Is v3.1.x still receiving security patches, and for how long?

Integration Approach

Stack fit. Weak for direct Laravel consumption; strong only if we already operate Hyperf services. The honest TPM framing to stakeholders: this is not a Laravel dependency we add — it is a different runtime we would be standardizing on. That is a platform decision, not a library decision.

Migration path. No direct migration. Three viable postures, in ascending cost:

1. Reference only — read the command/definition abstractions for design ideas; ship nothing.
2. Isolated service — run a Hyperf worker alongside the Laravel estate, communicating over HTTP/queue; Laravel keeps Artisan entirely.
3. Shared console layer — only if we are already committed to Hyperf elsewhere; otherwise reject.

Compatibility. Must be verified, not assumed: PHP minor, psr/container version, symfony/console major, and whether hyperf/di collides with illuminate/container in a combined composer.json. Run a throwaway install with composer why-not hyperf/command 3.2.0 against the actual project constraints before any design work.

Sequencing.

1. Retrieve the v3.1.56→v3.2.0 diff and composer.json delta (owner: platform eng; this is the blocker).
2. Classify each change: additive / behavioral / breaking / deprecation.
3. Throwaway-branch constraint resolution spike — no application code.
4. Single-command proof-of-concept, isolated process only.
5. Go/no-go memo with the diff appended as evidence.

Explicit non-goal: do not introduce this into a Laravel application's composer.json during this cycle.

Operational Impact

Maintenance. 56 patch releases in the 3.1 line indicates high cadence and correspondingly high surface churn. Budget for a routine upgrade treadmill, not a pin-and-forget dependency. The absence of a written changelog for a minor release is itself an operational cost — every upgrade requires diff review, which is human time we must staff.

Support. Community-maintained (GitHub issues, Hyperf Slack/QQ channels), no default commercial SLA. Escalation path for a production incident is maintainer goodwill and, for runtime-level faults, the Swoole/Swow layer — a second vendor with its own support posture. Escalation depth is one layer deeper than a typical Laravel dependency.

Scaling. The coroutine model is the point and also the hazard: long-running workers mean state leaks, unreset static caches, and connection-pool exhaustion become systemic rather than per-request. Laravel's bootstrap-per-command lifecycle is forgiving by comparison; Hyperf's is not. Any capacity planning must account for worker count and memory ceilings, not request throughput alone.

Failure modes to instrument for.

• Container collision — services resolving from the wrong kernel; presents as subtle, intermittent DI errors.
• Coroutine-context faults — APIs that appear to work in the happy path and fail under load.
• Silent PHP/constraint drift — a routine composer update pulling a transitive floor raise.
• Memory growth in long-lived workers under command loops.
• Upgrade blindness — undocumented minor releases shipping behavioral change; the direct consequence of the current changelog gap.

Ramp-up. Our team's console mental model is Artisan: bootstrap, execute, tear down. Hyperf's is: boot once, run many commands, stay coroutine-safe. That inversion is the dominant training cost — roughly a sprint for a senior engineer to be productive, longer to be trustworthy in production. Documentation is primarily Chinese-first community material, which adds friction for some team members.

Recommendation. No adoption based on v3.2.0 as documented. The release note is a link, not evidence. Request the changelog and diff from maintainers, then re-assess; until then this stays a monitored dependency, not a planned one.