Console Laravel Package

Product Decisions This Supports

• Platform baseline for webman services. This package supplies the webman CLI entrypoint (command discovery, IO, argument parsing via Symfony Console) plus generators and phar packaging. It is the console layer the webman skeleton expects, so the real decision it supports is "are we standardizing on webman for worker-based PHP services?" — and if yes, this is a near-mandatory dev dependency rather than a per-project evaluation.
• Build vs. buy. It answers "buy" for CLI plumbing: the team spends time on domain commands (backfills, cache warmups, data migrations, health checks) instead of re-implementing command registration and output formatting for every service.
• Roadmap / standardization. A single, documented webman <command> surface is a governance decision: it replaces tribal-knowledge shell scripts and per-repo scripts/ folders with named, discoverable commands across the fleet.
• Delivery and operations. build:phar supports artifact-based deployment; custom commands support one-off and scheduled operational jobs. Both are recurring needs, not one-offs, which is what justifies formalizing them.
• Onboarding and DX. Predictable scaffolding (make:*) shortens ramp-up and reduces "how do I run this locally?" support load on the platform team.

When to Consider This Package

Consider it when:

• The application is a webman (Workerman-based) PHP service, or webman is a candidate framework for new services. Here it is effectively table stakes.
• You operate more than one PHP service and want a shared CLI convention for scaffolding, maintenance tasks, and phar-based releases.
• You want to avoid hand-rolling console plumbing on top of Symfony Console per project.

Look elsewhere when:

• The stack is Laravel — use Artisan. Despite the "PHP package" framing, this is webman-specific and does not apply. Same for Symfony apps (use Symfony Console directly) or plain PSR/Slim apps that don't need a console kernel.
• You need an opinionated, batteries-included command framework (first-class DI, scheduling, rich interactive prompts). This is a thin integration over Symfony Console, not a toolkit.
• Your deployment doesn't use phar or long-running worker processes — the packaging value largely evaporates.

Risk notes to weigh (not blockers): The 26 stars and zero listed dependents are misleading signals — this is typically a dev/transitive dependency pulled in by the webman skeleton, so public metrics understate real usage. Maintenance looks active (recent release), but the project is small and effectively single-vendor: pin versions, keep custom commands in our own namespace, and be prepared to vendor if upstream stalls. Smoke-test the command surface on framework upgrades.

How to Pitch It (Stakeholders)

Executives: This is low-cost plumbing, not a product bet. It is the standard command-line toolkit for webman PHP services — roughly what Artisan is to Laravel. Adopting it costs a dependency and buys every service a consistent way to scaffold code, run maintenance jobs, and produce deployable artifacts. The strategic decision it rides on is the framework choice (webman), not this package; if we are on webman, treat it as part of the platform baseline and move on.

Engineering: It wraps Symfony Console and gives us one webman entrypoint with generators, phar builds, and room for custom commands. That means less bespoke scripting, fewer snowflake runbooks, and an obvious home for operational tooling. Caveats: it is a thin package from a small team — pin it, keep our commands in our own namespace so a swap stays cheap, and expect nothing beyond what Symfony Console offers. If we are not on webman, skip it and invest in the equivalent for our actual stack.