Laravel Artisan Commands Laravel Package

Getting Started

Install pinned, then discover. The package is zero-config through auto-discovery, which is exactly why you should not float the constraint — 5.1.1 shipped with empty release notes, so pin the exact version and read the diff before you ever bump:

composer require novius/laravel-artisan-commands:5.1.1
composer show novius/laravel-artisan-commands   # record constraints + PHP/Laravel matrix
php artisan list | grep -i novius               # this is your actual API surface

Where to look first. There is no config file to publish and no facade to learn. The entire public surface is the command signatures registered by the service provider, so php artisan list filtered to the package namespace is the documentation. Follow up with php artisan <command> --help for each one — argument/option definitions are the only contract you get from an undocumented package, and they tell you whether a command is read-only or destructive.

First use case. Pick one read-only command (a listing/inspection command if the package ships one) and run it against a throwaway local database clone, not your dev DB. The goal of the first session is not utility — it's to confirm three things: the commands register under cached config, they run under the PHP version your app actually deploys with, and none of them mutate state you care about. Only after that do you promote anything to a deploy hook or the scheduler.

Implementation Patterns

Treat these as operational tooling, not application code. The value of a grab-bag command package is in deploy scripts, CI and cron — not in app/. Keep every invocation outside your domain layer so that if the package is abandoned or a major release breaks, you delete a shell script line rather than refactor a service class.

Wrap in application-owned commands when you need composition. If you find yourself chaining several package commands, or you need them to run under a --dry-run flag your team controls, wrap them:

class AppMaintenance extends Command
{
    protected $signature = 'app:maintenance {--dry-run : Show what would happen}';

    public function handle(): int
    {
        $exit = Artisan::call('novius:some-command', [
            '--dry-run' => $this->option('dry-run'),
        ]);

        $this->line(Artisan::output());

        return $exit; // propagate — do not swallow
    }
}

This gives you one stable internal command name, a single place to swap in a fork, and a boolean you control if the upstream command changes its flag name.

Automation contract: exit codes, not output. For CI and deploy hooks, branch on $? only. Human-readable Artisan output is not an API and can change in a patch release:

if ! php artisan novius:some-command --no-interaction; then
  echo "pre-deploy check failed" >&2
  exit 1
fi

Always pass --no-interaction in non-TTY contexts, otherwise a confirmation prompt will block a pipeline until it times out.

Scheduler integration. If a command is meant to recur, register it in routes/console.php rather than in system crontab — you inherit Laravel's mutex, logging and environment handling:

Schedule::command('novius:some-command')
    ->dailyAt('03:15')
    ->withoutOverlapping()
    ->onOneServer();

Post-deploy ordering. In a deploy that ships a new release, run php artisan package:discover (or let optimize do it) before invoking any package command, so the cached bootstrap/cache/packages.php reflects the new provider list. If you run commands from a deploy user different from the web user, confirm file permissions on any path the command writes.

Gotchas and Tips

• Empty changelog is the real risk, not the code. Diff 5.1.0→5.1.1 in the repo (git log --oneline v5.1.0..v5.1.1 --stat) to recover what the release notes omitted. A patch touching a command you depend on is a behavioral change even if the version number says otherwise. Keep the pin until you've read it.
• Destructive commands hide in utility packages. Before running anything new against a non-local database, take a dump. A command that looks like an inspector can carry a --force/--flush style flag. Read --help on every command in the package once, up front, and write down which ones write.
• Discovery cache bites on deploy and in tests. After composer require, if the command "doesn't exist," run php artisan package:discover and check bootstrap/cache/ isn't stale. In CI, composer install alone does not always refresh it — add the explicit call.
• Container/user mismatch. php artisan under a deploy user can create files the FPM user cannot later read (or vice versa). If a command writes logs, caches or exports, verify ownership after the first production run.
• Memory and timeout on long-running commands. Utility commands that touch the whole DB will hit memory_limit or the scheduler's timeout. Run from CLI where you can set php -d memory_limit=-1, not through an HTTP-triggered path, and set ->timeout()/->withoutOverlapping() on scheduled variants.
• Don't call package commands from composer install scripts. Post-autoload hooks run before the application is in a known-good state (env may be missing, DB unreachable). Keep invocation in an explicit deploy step.
• Debug with -vvv and log the exit code. php artisan some:command -vvv gives you a stack trace on failure; pair it with echo $? so you're not guessing whether a silent run succeeded.
• Extension point is your own provider, not theirs. Register your wrapper commands in AppServiceProvider (or a dedicated ConsoleServiceProvider) and leave the vendor tree untouched — a composer update must never be able to delete your customizations.
• Keep a rollback line ready. Because the package owns no migrations, reverting is a composer require back to the previous pin plus a package:discover. Confirm that's true for 5.1.1 before you rely on it — check the diff for migration or table-owning code.