Symfony Console Bridge Laravel Package

Product Decisions This Supports

• Build vs. buy vs. don't adopt. Because this is an archived bridge with 19 stars and zero dependents, the decision it informs most is whether to introduce a dead dependency. Default: no. If the capability is needed, reimplement the thin glue (translating Hoa\Console commands/services into Symfony's console pipeline) in-house — it is a small, bounded amount of code.
• Legacy modernization / deprecation tracking. If it surfaces in a dependency audit (SBOM or composer.lock review), treat that as a signal to scope a migration off the Hoa ecosystem. It belongs on a technical-debt backlog, not on a feature roadmap.
• Roadmap: no new investment. Nothing here should block a roadmap item or appear as a "buy" line item. It delivers no user-facing capability; it is plumbing between two console abstractions.
• Use-case triage. The only coherent use case is "an existing Symfony app that already hard-depends on Hoa\Console and wants its console services registered as a bundle." In a Laravel context this is close to irrelevant — Artisan already sits on Symfony Console, so the bridge is a layer on a layer.
• Ecosystem-health benchmarking. A package at this score (0.09) with zero dependents and archived status is a useful calibration point in a dependency-vetting rubric: it marks the "do not intake" end of the scale.

When to Consider This Package

Consider it only if all of the following hold:

• You maintain a legacy Symfony application (typically Symfony 2.x-era, PHP 5.x/7.0) that already uses hoa/console directly in production code.
• You specifically need Hoa\Console's services (streams, readline, ANSI/color handling, prompts) wired through the Symfony container rather than invoked ad hoc.
• You are not planning a Symfony or PHP upgrade in the next release cycle — an archived package almost certainly will not track current versions.

Look elsewhere in nearly every other case:

• New builds: depend on symfony/console directly. It provides interactive questions, autocomplete, progress bars, tables, styled output, and a modern terminal component covering what Hoa\Console offered a decade ago.
• Laravel projects: use Artisan and symfony/console primitives; this bridge adds a dependency without adding capability.
• You genuinely want Hoa\Console: depend on hoa/console itself, pinned and locked knowingly, rather than a Symfony bundle shim.
• You need maintained CLI tooling: archived status means no security patches, no issue triage, and no PHP 8.x / Symfony 6–7 compatibility guarantees.

How to Pitch It (Stakeholders)

To executives (30 seconds): This is an archived, low-usage adapter that glues an old PHP console library to Symfony. It solves a compatibility problem, not a customer problem. Recommendation: do not adopt. If it is already in our codebase, it represents small, contained technical debt and should be scheduled for removal — not treated as a strategic dependency.

To engineering leads: It is a thin, unmaintained bridge — 19 stars, zero dependents, archived upstream. There is no support, no security response, and no real compatibility story for current Symfony or PHP versions. Replacing Hoa\Console calls with native symfony/console (or Artisan, in Laravel) is the low-risk path, and the bridge itself is small enough to reimplement if some Hoa-specific behavior is genuinely required. Budget it as a cleanup task, not a project.

To product: No user-visible impact either way. It should not appear in roadmap discussions, vendor evaluations, or build-vs-buy decisions. Treat it as an infrastructure hygiene item.