Extra Artisan Commands Laravel Package

Getting Started

Install as a dev dependency — these are local/ops conveniences, not runtime code:

composer require --dev justinbyrne/extra-artisan-commands

No manual service-provider registration is required; Laravel package discovery registers the commands automatically. Confirm they are available and note the exact signatures, since they are the source of truth over any blog post:

php artisan list | grep -i extra
# or browse vendor/justinbyrne/extra-artisan-commands/src/Commands

The first realistic use case is standing up a fresh local environment in one pass:

php artisan db:create     # create the DB from your .env credentials
php artisan migrate --seed
php artisan db:reset      # drop + recreate + migrate + seed
php artisan make:user     # interactive: create a login to poke the app

If your app uses the default users table and standard password hashing, make:user will save you the php artisan tinker dance every time you reset the DB — that is the single highest-value command here on day one.

Implementation Patterns

Daily reset loop for local work. Wire the destructive commands into a Composer script so you do not retype them:

"scripts": {
  "fresh": [
    "@php artisan db:reset --force",
    "@php artisan logs:clear"
  ]
}

Now composer fresh is your reproducible "give me a clean DB and an empty log" button.

Seeded fixtures from real data. make:seeder-from-table (or however the command is named in your installed version) is the fastest way to turn a populated staging table into a seeder class. Typical workflow: pull a trimmed table down locally, generate the seeder, then hand-edit the result to remove PII and hard-code volatile IDs/FKs before committing.

Creating users non-interactively in scripts. The make:user command is interactive by default. For automation, inspect the command definition first:

php artisan make:user --help   # check for --name/--email/--password flags

If flags exist, you can run it as a one-liner (e.g. a Makefile target or a setup.sh for new devs). If it only reads $this->ask(), wrap it in expect or fall back to php artisan tinker --execute — do not assume flags exist.

Ordering matters in CI. Do not drop these commands into a CI job wholesale. db:create / db:drop assume a live MySQL/Postgres server with credentials in .env; in CI you usually want migrate --force against an ephemeral DB. Reserve the destructive commands for the "developer sandbox" job only.

Composing with existing Artisan. Because these are ordinary commands, they chain naturally with Laravel's own:

php artisan db:reset --force && php artisan make:user --help
php artisan logs:clear && php artisan optimize:clear

Use --force in any non-TTY context; without it, db:drop/db:reset will block waiting for confirmation.

Gotchas and Tips

• Destructive by nature. db:drop and db:reset act on whatever database your current .env points at. Before running, verify DB_DATABASE with php artisan tinker --execute="echo config('database.connections.'.config('database.default').'.database');". Add a shell-level guard ([[ $APP_ENV == production ]] && exit 1) in any wrapper script.
• No production guard is promised. Unlike framework commands such as migrate (which refuses to run in production without --force), a small community package may not check app()->isProduction(). Treat every command here as production-unsafe unless you have read the source.
• Unmaintained since mid-2023. The last release predates recent Laravel majors. On Laravel 11/12 you may hit deprecations, @return signature mismatches, or commands that simply do not auto-register. Test in a branch, and pin the version in composer.json rather than floating.
• Seeder generation leaks data. Generated seeders embed literal row values. Always scrub emails, names, tokens, and password hashes before committing, and truncate large tables first — otherwise your seeder class balloons into an unreviewable blob.
• Password hashing in make:user. Confirm the command runs the password through Hash::make() (check the source) rather than storing plaintext. If it uses the model's $casts/mutators, fine; if it writes raw, do not use it on shared environments.
• Package discovery off? If php artisan list does not show the commands in a minimal app, your bootstrap/cache/packages.php may be stale. Run php artisan package:discover and re-check.
• Log clearing scope. If a logs:clear command exists, verify which files it deletes — some implementations glob storage/logs/*.log and will remove rotated archives you wanted to keep. Back up before the first run in staging.
• Extension point. Commands are plain Artisan classes extending Illuminate\Console\Command. If you need different defaults (e.g. your own user fields), extend or override the class in app/Console/Commands and register it — do not fork the vendor directory.
• Verify names before memorizing them. This package is small (28 ★, single maintainer). Command names and flags have drifted across its history. Keep php artisan list as your reference and rely on --help output rather than copied snippets.