Laravel Action Command Laravel Package

Getting Started

• composer require frankliniwobi/laravel-action-command:^1.0 — package auto-discovery should register the service provider; there is no manual config/app.php entry needed on Laravel 5.5+.
• Look here first: vendor/frankliniwobi/laravel-action-command/src/ — at 1.0.x the surface area is small (a service provider plus the command/action class(es)). Read the provider before anything else; it tells you exactly what is registered, what is publishable, and what the make-command stub looks like.
• Run php artisan list and grep for the package's namespace to confirm the command is registered, and php artisan vendor:publish --provider="Frankliniwobi\...\ActionCommandServiceProvider" to see if stubs/config are publishable.
• First use case: wrap a single operational task (backfill a column, sync a third-party feed, prune stale records) in an action command, then call the same action class from a controller, job, or test. That dual entry point — CLI for ops, plain PHP for code — is the whole value proposition; wire one real task end-to-end before adopting it widely.
• Pin to ^1.0 and commit composer.lock. 1.0.1 is a dependency bump only, so behaviour should be identical to 1.0.0, but see the gotchas below.

Implementation Patterns

• Thin command, fat action. Keep the artisan $signature, argument parsing, and output formatting in the command class; put the actual work in an invokable action class with a typed __invoke()/handle(). This is what makes the action testable and reusable outside the console.
• Call the action, not Artisan::call(). From controllers, jobs, or other commands, resolve and invoke the action class directly. Reserve Artisan::call('your:command', [...]) for cases where you genuinely need console semantics (output buffering, exit codes, --force style flags).
• Testing. Unit-test the action in isolation with dependencies mocked/faked; use $this->artisan('your:command')->assertExitCode(0) for the command wrapper. If the command writes output, prefer expectsOutput() over asserting on a buffer.
• Scheduling. Schedule the command in routes/console.php/Kernel::schedule(), not the action — you keep withoutOverlapping(), onOneServer(), and runInBackground() for free. Let the command delegate to the action as usual.
• Queues. If the action is slow, dispatch a job from the command rather than marking the command itself queueable; cron and CI stay synchronous and observable.
• Return structured data. Have actions return arrays/DTOs/result objects and let the command decide how to print them. This makes actions composable (chain two actions, or feed one's result into another) and keeps them snapshot-testable.
• Stub customisation. If the package publishes a stub, publish it into stubs/ and edit there — never patch vendor/. That keeps composer update safe and gives you a house style for new actions (strict types, readonly DTOs, etc.).

Gotchas and Tips

• Early-stage package. 1.0.x, single maintainer, and 1.0.1 is this contributor's first PR. Treat the API as unstable until there's a docs site and a 1.1+ history; keep usage concentrated behind a small internal wrapper (e.g. a base Action class you own) so a rename upstream is a one-file fix.
• The 1.0.1 diff is only a dependency bump — but that still matters. Relaxed or tightened illuminate/* constraints can change which framework version Composer resolves. Update on a branch, diff composer.lock, and run the suite before merging. Don't assume "no changelog entry, no risk".
• Commands missing from php artisan list? Run php artisan optimize:clear (config and compiled caches hide newly discovered providers), and on Lumen register the provider manually in bootstrap/app.php.
• Output side effects. Actions that echo directly are painful to call from HTTP handlers and tests. Route all user-facing output through the command ($this->components->info(), $this->line()) and keep the action silent except for its return value.
• Exit codes. Return an int from the command's handle() — non-zero on failure — so cron, CI, and Artisan::call() callers can detect failure rather than parsing strings.
• Name collisions. Prefix signatures (e.g. ops:sync-feed) so they don't clash with framework or other packages' commands; Artisan::call() resolves by name and collisions fail at runtime, not boot.
• Debugging. php artisan <command> -vvv gives the exception trace; if an action is swallowed inside Artisan::call(), wrap with $this->artisan(...)->run() in a test or temporarily call the action directly to surface the real error.
• Extension points are thin. Realistically: the service provider (binding overrides), the published stub, and subclassing the generated command. There's no event/hook layer to lean on at 1.0.x, so don't design an architecture that depends on one.
• Version matrix. Verify the package against the exact PHP and Laravel versions you deploy (composer why-not frankliniwobi/laravel-action-command is your friend) — for a pre-1.1 package the constraints are the most likely source of surprise, and 1.0.1 changed exactly those.