Cli Parser Laravel Package

Product Decisions This Supports

• Build vs. buy for narrow CLI parsing. This makes the "buy" case only for a specific slice: standalone PHP scripts, build/deploy hooks, and internal tooling that need to turn $_SERVER['argv'] into structured options without adopting Symfony Console. It does not support a build-vs-buy decision for anything inside Artisan, where the answer is already "use what Laravel ships."
• Deprecating homegrown argv parsing. The strongest roadmap case is consolidation: replacing ad-hoc argv/getopt() handling in legacy scripts with a small, tested, MIT/BSD-licensed dependency extracted from PHPUnit. That is a low-effort reliability win with a defensible "proven in production at scale" argument.
• Scoping the CLI roadmap. This package pushes a clear boundary: it is a parser, not a framework. It does not support product commitments around --help generation, subcommands, interactive prompts, argument validation, or option dependency rules. Teams that need those should plan for Symfony Console or Laravel Zero, and this evaluation should be recorded as "explicitly out of scope" so the gap isn't rediscovered later.
• Sequencing tooling investments. For a Laravel shop, the reasonable portfolio decision is: Artisan/Symfony Console for anything a user or another team will run; this package, if at all, for throwaway or single-purpose scripts that must not boot the framework. That keeps the CLI surface area small and avoids two competing parsing conventions.
• Risk posture on dependency count. It is a small, dependency-free library, so the marginal dependency cost is negligible — the decision hinges entirely on fit, not weight. The relevant risk is lifecycle: this is a PHPUnit-internal component with effectively zero external dependents, so its release cadence follows PHPUnit's needs, not ours.

When to Consider This Package

Adopt when:

• The parsing target is a standalone script or non-Artisan tool — deploy hooks, data migration utilities, CI helper scripts, codegen shims — where bootstrapping Laravel or Symfony Console is unjustified.
• You need predictable, no-magic parsing of flags and value options and are willing to own validation and help text yourself.
• You are replacing bespoke argv handling and want a maintained, tested implementation rather than in-house code.
• Your runtime is pinned appropriately: v5.x requires PHP newer than 8.3, so Laravel apps on PHP 8.2/8.3 must pin v4.x. This is a per-project constraint to check before adoption, not a footnote.

Look elsewhere when:

• The command lives in Artisan. Laravel already provides Symfony Console with command registration, input/output helpers, validation, help generation, and container integration. Adding this package creates a second parsing convention for no product benefit.
• The tool is user-facing or cross-team. Anything needing --help, subcommands, array options, interactive prompts, or typed validation belongs on Symfony Console or Laravel Zero.
• Your team would need to hand-roll error messaging and validation — that is recurring product and support cost disguised as a small dependency.
• You need assurance of forward compatibility. With no external dependents, breaking changes and PHP floor bumps arrive with PHPUnit's schedule, not yours. If the tool is business-critical, that is a disqualifier.
• You are evaluating it as a general CLI framework. It is not one, and treating it as such will surface as rework within a quarter.

How to Pitch It (Stakeholders)

For executives: This is a small, low-risk utility, not a platform bet. It lets us clean up one-off internal scripts — the kind that run migrations or shuffle data — with a parser that has effectively been in production inside PHPUnit for years, without pulling a full CLI framework into places it doesn't belong. The upside is modest and concrete: fewer fragile custom scripts, faster delivery of internal tooling, negligible dependency cost. The trade-off is equally concrete: it deliberately lacks the conveniences of a real CLI framework, so we will not use it for anything customers or other teams touch. Recommendation: allow it as an approved utility for internal scripts, and keep Artisan as the standard for everything else.

For engineering leads: Treat this as a scalpel. It parses argv into options and arguments and stops there — no help generation, no subcommands, no validation, no container awareness. Use it for standalone scripts where booting Symfony Console is disproportionate; do not use it inside Artisan, where it duplicates existing behavior and risks inconsistent error handling. Two operational notes to carry into the decision: it has essentially no external dependents, so its release cadence tracks PHPUnit rather than our roadmap, and its major versions move the PHP floor (v5.x requires newer than PHP 8.3; v4.x is the fallback for 8.2/8.3). If the tool matters to the business, budget for owning the surrounding validation and help text ourselves.

For developers: One job done well — turn $argv into structured options without a framework. Install with composer require --dev sebastian/cli-parser, pass your option spec to the parser, and handle validation and --help yourself. Reach for it when you'd otherwise be hand-rolling argv parsing in a standalone script; reach for Symfony Console or Laravel Zero the moment you need subcommands, arrays, or prompts.