Artisan Shortcuts Laravel Package

Getting Started

Install the package (it is not Laravel-auto-discovered-critical, but check the constraint — see Gotchas):

composer require sven/artisan-shortcuts

Register your first shortcut in the boot method of AppServiceProvider (or a dedicated ShortcutsServiceProvider, which is cleaner as the map grows):

use Sven\ArtisanShortcuts\Facades\ArtisanShortcuts; // facade/hook name varies by version — see Gotchas

public function boot(): void
{
    ArtisanShortcuts::register([
        'fresh' => 'migrate:fresh --seed',
    ]);
}

Run it:

php artisan fresh
# equivalent to: php artisan migrate:fresh --seed

Where to look first: the package is a thin alias layer — there is almost no runtime behaviour beyond "map a name to a command string and register it with the console kernel". Read the package's single service provider and command-registration class first; there is nothing hidden.

First use case: replace the long, flag-heavy commands a team types every day (migrate:fresh --seed, queue:retry all --queue=default, cache:clear && config:clear && route:clear && view:clear) with short, memorable, documented names. The value is onboarding and muscle memory, not functionality.

Implementation Patterns

Pure alias map. The core pattern is a declarative array of shortcut => real command. Keep it in one place so it is reviewable in a PR:

ArtisanShortcuts::register([
    'fresh'   => 'migrate:fresh --seed',
    'demo'    => 'migrate:fresh --seed --seeder=DemoSeeder',
    'reset'   => 'migrate:reset --seed',
    'reload'  => 'queue:restart',
]);

Environment-scoped shortcuts. Never expose destructive aliases in production. Guard registration:

public function boot(): void
{
    if (app()->isLocal() || app()->environment('testing')) {
        ArtisanShortcuts::register([...]);
    }
}

Alternatively register always but rely on Artisan's own production confirmation prompts (which are preserved — the shortcut is just an alias, so migrate:fresh still asks "Application In Production!"). Do not rely on this alone; combine both.

Team onboarding workflow. Maintain a small, stable set of canonical shortcuts and document them in README/CONTRIBUTING:

This is the highest-leverage use: a new developer runs two commands, not six.

CI and scripts. Because shortcuts are real console commands, they work anywhere Artisan runs — CI steps, Docker entrypoints, Makefile targets, Envoy tasks. Add --no-interaction at the call site; the alias forwards flags to the underlying command.

php artisan demo --no-interaction

Layering with other packages. Shortcuts compose with seeding, queue, and cache-clearing packages because they execute the same command line you would have typed. Ordering caveat: an alias is a single command, so "clear cache, then migrate, then seed" needs either multiple shortcuts invoked in sequence (php artisan cache:clear && php artisan demo) or a purpose-built command with Artisan::call() — see Gotchas.

Naming discipline. Adopt a namespace prefix for anything app-specific (app:setup, app:demo) so you never shadow a framework command and so php artisan list stays readable. Built-ins are usually not prefixed, so collisions are easy to reintroduce.

Testing. Treat shortcuts as part of the app contract:

$this->artisan('demo')->assertExitCode(0);

This catches typos in the command string — the most common failure mode.

Gotchas and Tips

• The registration API is version-dependent. The repo's last release was 2020 (Laravel 6/7/8 era), and the public hook has changed between versions (facade call vs. a HasShortcuts trait with a shortcuts() method returning the array). Confirm the exact import against the installed version's README before writing the provider; guessing is the #1 source of "class not found" on install.
• Laravel 9+ compatibility. A 2020 package may pin illuminate/support / illuminate/console to ^6|^7|^8, so composer require can fail on modern Laravel. Options, in order of preference: (1) fork and widen the constraint, (2) add --ignore-platform-reqs only as a stopgap (risky — the package touches console internals), (3) skip the dependency and register aliases yourself with Artisan::command() closures, which is ~10 lines and future-proof. Verify with composer why-not sven/artisan-shortcuts before fighting it.
• Collisions silently shadow. Registering a shortcut whose name matches an existing command can produce confusing output in php artisan list or make one unreachable. Inspect with php artisan list after adding anything, and grep the codebase for the name.
• Argument quoting. Flags with spaces or = (--seeder=Demo\\Seeder) go into the command string exactly as you would type them in a shell. If quoting is inconsistent, the alias will fail with an "option does not exist" error that points at the underlying command and sends people debugging the wrong layer.
• Exit codes propagate, but not output buffering tricks. If you need to capture or post-process output, an alias is the wrong tool. Use Artisan::call('...') from a real command closure and manipulate Artisan::output().
• Multi-step workflows don't belong here. A shortcut maps to one command. For "clear caches, migrate, seed, then dump the DB", write a proper command (ideally with $this->call() per step so failures surface with the right exit code and message) rather than stringing aliases together with && in a shell script that no one can find later.
• Boot-order surprises. If you register shortcuts in a late-loaded provider, they may not appear until after the console kernel's command discovery. If php artisan list doesn't show them, register from a provider that is definitely booted (a dedicated one listed in app.providers / auto-discovery), or move the call into register()/boot() earlier.
• php artisan list is your debugger. If a shortcut is missing, it was never registered (provider not booted, environment guard tripped, or an exception swallowed in boot()); if it appears but fails, the string is wrong. There is no deeper debugging surface.
• Extension point: don't fight the package. It is deliberately thin. The right escalation path is Artisan::command('name', ...), then a dedicated Command class. Reach for the package only for pure, static rewrites of existing commands — anything conditional, interactive, or multi-step belongs in native Artisan.
• Pinning and abandonment risk. With 55 stars, 0 dependents, and no release since 2020, assume it is unmaintained. Pin the version in composer.json, and prefer vendoring the ~30-line implementation into your own service provider if you rely on it — you get the same ergonomics with no compatibility tax on the next Laravel upgrade.