Laravel Zero Self Update Laravel Package

Getting Started

This package targets both full Laravel apps and Laravel Zero (standalone console) applications — its only declared framework surface is illuminate/console, so everything it offers is reached through Artisan commands rather than HTTP routes or Blade views.

1. Install into the right host. composer require <vendor>/<package> from a Laravel app root or a Laravel Zero project root. Laravel Zero projects have no artisan in the usual sense — the binary is ./<app-name> — so substitute accordingly in every command below.
2. Check what got auto-registered. php artisan list (or ./app list) first. Console-only packages typically register a service provider via package discovery and expose one or more commands immediately; if you see nothing new, discovery is disabled or the provider is manual-only.
3. Look for publishable config. php artisan vendor:publish --provider="Vendor\Package\PackageServiceProvider" and inspect config/ for a new file. Config is the first place to look when behaviour differs from the README.
4. First real use case: run the package's primary command in a dry-run or --verbose mode against a scratch copy of your project, with -vvv on, before pointing it at anything real. Console packages mutate files and state; a --dry-run/--pretend flag (if offered) is worth finding first.
5. Verify the version you actually resolved. This release only widened constraints; if you installed before v1.1.0 and your lockfile is pinned, run composer update <vendor>/<package> --with-dependencies to actually pull the widened range in. composer show <vendor>/<package> confirms which tag you're running.

Implementation Patterns

Invoke from code, not just the terminal. Artisan::call('package:command', ['--flag' => true]) and $this->call('package:command') from inside your own commands are the two workhorses. In Laravel Zero, Artisan::call() works identically once the console kernel is booted — useful for chaining the package's command into your app's own workflows.

Wrap it in your own command for stable glue. Rather than spreading raw Artisan::call() strings across the codebase, define a thin command that reads your config, maps it to the package's options, and delegates. This keeps the package's option names in exactly one place when they change between minor versions.

Schedule it. Console-first packages are usually batch jobs. $schedule->command('package:command')->daily()->withoutOverlapping() in routes/console.php / a service provider covers Laravel; Laravel Zero uses the same scheduler via its own schedule entry point, so the pattern transfers — but confirm the scheduler is actually installed in the Zero build (composer show | grep schedule), since Zero is opt-in per component.

CI and non-interactive contexts. Always pass --no-interaction in CI and any time you call the command programmatically. Console packages love $this->confirm() and $this->choice(); without the flag they hang or silently default. Pair with --quiet in build logs and rely on the exit code (0/1) for gating.

Test around it, not through it. Use $this->artisan('package:command')->expectsOutput(...)->assertExitCode(0) for smoke coverage, and ->expectsQuestion() where prompts exist. For anything that touches the filesystem or an external service, prefer Http::fake() / Storage::fake() at the boundary plus an integration test that runs the real command once — the command layer is usually too coarse to test meaningfully in isolation.

Multi-environment config. Read the package config through config() in your own code rather than editing the published file directly; publish once, commit, and override per environment via .env values referenced inside it. This survives vendor:publish --force and package upgrades.

Gotchas and Tips

• The v1.1.0 change is a constraint widening, not a feature. illuminate/console and laravel-zero/framework ranges were broadened to admit Laravel Zero 13. Practical consequences: (a) if you're on Laravel Zero 12 or earlier, nothing breaks — the old range is still satisfied; (b) if you're on Laravel Zero 13, this is the first version that will install at all, so pin ^1.1 as your floor if you're upgrading Zero; (c) Composer won't move you automatically — a stale lockfile keeps you on the old tag while Zero 13 sits uninstalled or resolution silently picks a different package version. Update explicitly.
• Laravel Zero 13 implies a specific Illuminate major. Widening a constraint does not mean the package is tested across every version in the new range. Run the package's commands once after upgrading Zero, particularly anything touching the console output helpers — $this->components->* and output-formatting APIs have churned across Illuminate majors and degrade subtly (missing color, collapsed tables) rather than erroring.
• Service provider registration. Laravel Zero has no bootstrap/providers.php in the same shape as Laravel 11+; providers go in config/app.php providers or via the package's own discovery. A package that works in Laravel can appear "installed but inert" in Zero purely because of this.
• Signature collisions. Console-only packages register global command names. If list shows a command you don't recognise or your own command vanished, you have a name clash — php artisan list twice, once with the package removed, is the fastest diagnosis.
• Silent config defaults. Published config is a snapshot; new keys added in later versions are not merged into your existing published file. When bumping the package, diff the vendor copy of the config against yours (diff vendor/<vendor>/<package>/config/... config/...) before assuming a new option is inert.
• Exit codes are the contract. If you're gating deploys or CI on the command, verify the failure path actually returns non-zero — Artisan::call() returns the exit code, but code that swallows it (Artisan::call(...); return 0;) is a common and quiet bug.
• Extension points, in order of preference: config values → subclassing the package command and overriding handle() (register yours instead of the package's) → publishing and editing stubs/views. Avoid editing vendor/ for anything you'll need again; a composer install on a clean CI runner will erase it and nobody will notice until deploy.
• Debugging trick: -vvv plus --no-interaction together gives you the fullest non-blocking trace. If output is truncated, check whether the command is writing through Laravel's output buffering ($this->output) versus raw echo/dump — the latter bypasses test assertions and CI log capture entirely.