Command Line Laravel Package

Product Decisions This Supports

• Build vs. buy for internal tooling. If the roadmap includes CLIs (data backfills, tenant provisioning, report generators, migration/ETL scripts), this package is a "buy" for the boilerplate layer: option/argument parsing, validation, --help generation, and error formatting. That's typically 1–3 days of engineering per tool that you don't spend, and it's the kind of work engineers quietly deprioritize.
• Scoping a CLI surface for a customer-facing product. If a feature request is "give us a command to do X," this clarifies how cheap the thin slice can be — a single PHP script promoted to a real command with validated flags — which helps you size epics and decide whether a CLI is a viable v1 instead of a full UI.
• Reducing dependency surface on small, standalone scripts. The real product argument versus the default choice is footprint: it's a small, focused parser rather than pulling the full Symfony Console stack. Relevant if you ship a distributable tool (a PHAR, a client-side utility, a container image where size/startup matters) rather than an app that already has a framework.
• Tooling for non-engineers. Auto-generated help and readable error messages mean ops/support staff can run tools without a written runbook. That's a support-cost decision, not just a code decision.
• Roadmap sequencing input. Cheap CLI scaffolding lowers the cost of "ops-facing" roadmap items, which often compete poorly against user-facing features. Quantifying that as near-zero marginal cost changes prioritization conversations.
• Not a differentiator. Nothing here is customer-visible in a normal web product. Treat it as infrastructure hygiene, not a roadmap line item — don't let it consume a planning cycle.

When to Consider This Package

Consider it when all of the following hold:

• You need CLI tools that live outside or beside a Laravel application — standalone scripts, a distributable binary/PHAR, a batch job in a slim container, or a polyglot repo where only part is PHP.
• You want a small dependency and are comfortable with a minimal, non-framework API rather than a full command bus (no DI container, no event dispatcher, no command registration/lifecycle beyond parsing).
• Your CLI needs are simple and stable: flags, positional args, subcommands, help text, ANSI color that disables when piped. That's genuinely most internal tools.
• Your team already knows or is willing to learn the Nette idiom — this is an ecosystem-specific library, not a Laravel-native one.

Look elsewhere (specifically, stay with Laravel Artisan / Symfony Console) when:

• You're building inside a Laravel app. Artisan already gives you this plus scheduling, DI, output helpers, testing utilities, and interactive prompts — adding a second CLI parser creates two conventions for the same job. This is the dominant case for a Laravel shop, and it makes the honest answer "no" most of the time.
• You need interactive prompts, progress bars, table rendering, or a command lifecycle — this package is deliberately narrow.
• Licensing matters. The metadata reports NOASSERTION, meaning the license could not be automatically identified. For anything shipped to customers or embedded in a distributed artifact, that is a hard gate: legal review before adoption, no exceptions. An unclear license on a 37-star dependency is a poor risk/effort trade.
• Health and longevity matter more than the code. 37 stars is very low signal. Low stars isn't disqualifying for a small, finished utility — but combined with an unverifiable license and release metadata that looks inconsistent (a release dated in the future should be treated as a data error until confirmed), this fails the "can I afford to maintain this myself if it's abandoned?" test for teams that can't.
• You need a broad hiring/pooling argument — Symfony Console skills are ubiquitous; Nette-specific knowledge is not.

Recommendation shape: do not adopt for the Laravel product; pilot on one non-critical standalone internal tool if the license clears, with a one-day timebox and a documented fallback to Symfony Console. Measure whether it saved real time before standardizing on anything.

How to Pitch It (Stakeholders)

To executives (one paragraph): Small PHP library that turns a plain script into a proper command-line tool — it handles flags, arguments, validation, help text, and error messages so engineers don't hand-roll them. The business value is speed and consistency on internal/ops tooling, not customer-facing capability. The main caveat is governance, not technology: its license isn't clearly identified and the project is low-profile, so I'm recommending we validate it on one internal tool before any broader use — and note that our Laravel apps already include an equivalent, better-supported tool, so this is only for standalone scripts.

To engineering (the ask): Use this only where Artisan/Symfony Console isn't already in the stack. One-day spike on a real internal script; report back on API friction and whether we'd be comfortable owning it if upstream stalls. Before the spike, legal confirms the license (metadata says NOASSERTION) and someone verifies the release/tag situation — the reported last-release date looks wrong.

Framing to use: "small, focused, cheap to try, cheap to abandon" — plus an explicit statement that the default answer inside Laravel remains the framework's own console, and this is a targeted exception for lightweight standalone tooling.