- What is cerbero/command-validator and what problem does it solve?
- It is a small Laravel package that brings Laravel's validator to Artisan console commands. Instead of hand-writing if (! is_numeric($this->argument('id'))) checks inside handle(), you declare a $rules property covering your command's arguments and options and let the package validate input before the command body runs. It is a thin decorator over Illuminate\Console\Command and the validation factory, so it reuses the rule strings, rule objects, messages and attribute names you already know. The result is CLI tools that fail fast with clear errors instead of crashing halfway through.
- How do I install cerbero/command-validator with Composer?
- Install it as a dev-or-runtime dependency with composer require cerbero/command-validator, then confirm the version constraint resolves against your application's Laravel major. Because the package targets the console lifecycle and service-provider auto-discovery, no manual provider registration is normally required. After installing, run your test suite or a single command with --help to confirm nothing in the container wiring changed.
- How do I define validation rules for an Artisan command's arguments and options?
- You add a $rules property to the command class, keyed by argument or option name, exactly as you would in a FormRequest. Arguments and options are then resolved through Laravel's validator before handle() executes, so your command body can assume clean, typed input. Start with one command, keep your existing manual checks in place until parity is proven in tests, then delete the redundant checks. This keeps adoption additive and reversible.
- Does it handle array options, negatable flags and variadic arguments correctly?
- These are exactly the edge cases worth testing before rollout, because they are where validation semantics can diverge from what Artisan actually passes. Array options such as --tag=*, negatable boolean flags and variadic arguments need explicit coverage in your own tests against the pinned version. Write a small feature test per shape and assert both the pass and fail paths. If a case misbehaves, the package is small enough to patch or fork at negligible cost.
- Which Laravel and PHP versions does cerbero/command-validator support?
- Check the composer.json require and require-dev constraints in the repository, and cross-reference them with the matrix actually exercised in CI. Because service-provider auto-discovery and the console lifecycle have been stable since Laravel 5.5, the code is likely forward-portable even if the manifest looks stale, but confirm rather than assume. Pin the version in composer.json and re-check the constraint on every Laravel major upgrade.
- Does a validation failure return a non-zero exit code in CI and deploy pipelines?
- It must, or scripts relying on Artisan return codes will silently continue after bad input. Verify this explicitly by running a command with invalid input in a shell and echoing $?, and repeat inside your pipeline definition. Also confirm that error output goes to stderr rather than stdout so log parsing stays reliable. Treat exit-code behaviour as a release gate for any command invoked by automation.
- Does validation run when a command is dispatched programmatically with Artisan::call() or the scheduler?
- Programmatic dispatch is a distinct code path from a shell invocation, so do not assume identical treatment. Test Artisan::call() and a scheduled invocation directly and assert that invalid input is rejected the same way it is from the terminal. If validation only fires on the interactive path, wrap programmatic callers with your own guard or dispatch through a validated entry point. This is a one-day test that prevents a common production surprise.
- Can I use custom rule objects, Rule::in and Rule::enum, or only string rules?
- Since the package delegates to Laravel's validation factory, rule objects and the fluent Rule helpers should work wherever the underlying Laravel version supports them. Confirm it in a test using a custom Rule implementation and Rule::enum on an option before standardising the pattern across your commands. Sticking to plain string rules is the safest lowest-common-denominator choice if you need to support older Laravel versions.
- How are validation errors displayed, and can I customise messages and attribute names?
- Errors are surfaced through Laravel's standard validation output, so your existing custom messages and attribute names carry over unchanged. Human-readable output is the primary format; if you need machine-parseable errors for automation, check whether JSON-style output is supported or format your own from the validator's message bag. Also consider how behaviour changes with --no-interaction so interactive prompts never block a CI run.
- How does it compare to manual validation, and what is the exit strategy if the package is abandoned?
- Manual checks work but scatter the same logic across every command, which is precisely what a declarative $rules property removes. The package has a small audited surface, an MIT licence and zero dependents, so treat it as a local standard on internal tooling rather than a company-wide mandate. The credible exit strategy is to vendor it: copy the trait into app/Console/Concerns and drop the dependency if upstream goes quiet. Document that escape hatch up front so a Laravel major bump without an upstream release is an inconvenience, not a blocker.