Laravel Cli Create User Laravel Package

Getting Started

This package is a small artisan-command wrapper around "make me a user right now" — no tinker, no factory, no seeder file. Three commands: create, list, remove.

Install

composer require boaideas/laravel-cli-create-user

Laravel 5.5+ auto-discovers the service provider. On older apps, register it manually in config/app.php. Then publish the config so you can point it at your own model:

php artisan vendor:publish   # pick the laravel-cli-create-user entry / tag from the menu

First thing to run

php artisan list | grep -i user

Do this before reading any docs. The package is from 2020, the last release was Sept 2020, and it has 16 stars and zero dependents — confirm the exact command names and option signatures on your installed version rather than trusting a README you found on the internet.

First use case

You've just cloned a project, php artisan migrate is done, but there's no seeded admin and the login page is a dead end:

php artisan user:create

It prompts for name, email, and password, hashes and saves an Eloquent user, and (optionally) emails the credentials. Then php artisan user:list to confirm, and you're logged in.

Where to look first

1. php artisan list — the real command surface.
2. The published config file in config/ — usually just the model class and maybe table/guard.
3. vendor/boaideas/laravel-cli-create-user/src/ — it's a handful of files; read them in five minutes. This is the highest-value step for a package this small and this old.

Implementation Patterns

Interactive local bootstrap. The natural fit: user:create right after migrate on a fresh clone. Keep it out of DatabaseSeeder — the whole point is human-in-the-loop, one named person, one password you choose.

Non-interactive / scripted creation. Interactive prompts are useless in a Docker entrypoint or CI. Pass the arguments explicitly and use --no-interaction:

php artisan user:create --name="CI Admin" [email protected] --password="$SEED_PASSWORD" --no-interaction

Verify the actual flag names against php artisan help user:create — some versions ask for the password twice, which changes how you script it.

Credential email as an onboarding flow. For staging and demo environments, let the package mail the password instead of you slacking it around:

php artisan user:create [email protected]

Set MAIL_MAILER=log locally and the "email" lands in storage/logs/laravel.log — perfect for verifying the flow without SMTP.

Pair it with factories, don't replace them. Factories/seeders create deterministic volume (50 fake users for pagination testing). This package creates one real account for a human. Mixing them up is the classic mistake: people try to faker their way to a known-credentials admin and give up.

Wrap it when you have custom fields. If your users table has role, tenant_id, is_admin, or a status enum, the raw command won't set them. Two options:

• Register your own thin command that calls the package's create logic then fills in the extras, or
• Use the package command, then immediately follow with php artisan tinker --execute="..." to patch fields — cheap and honest for dev-only work.

Cleanup pattern. user:list then user:remove is the fastest way to purge throwaway demo accounts created during a pairing session. Note that removal goes through Eloquent, so any cascadeOnDelete foreign keys on profiles, tokens, or audit rows will follow it down. That's usually what you want in dev and absolutely not what you want in prod.

Custom model. If you have App\Models\Member instead of App\Models\User, or a multi-guard setup, set the model class in the published config. This is the primary — arguably only — extension point the package offers.

Gotchas and Tips

It is effectively unmaintained. Last release September 2020, 16 stars, 0 dependents. It targets the Laravel 5.5–7 era. On Laravel 9/10/11 the composer constraints may block install, and even if it installs, the password handling predates the hashed cast. Pin the version in composer.json and expect to either fork it or replace it with a 30-line custom command. Honestly: for most teams, "copy the command into app/Console/Commands" is the better long-term move than a dependency this thin.

Interactive prompts break in non-TTY contexts. docker exec without -it, CI runners, cron, and artisan called from PHP will hang or error on the password prompt. Always pass options + --no-interaction in automation.

Passwords on the command line leak. --password=... ends up in your shell history, in ps output, and in CI logs. For CI, prefer generating a random password and letting the package email it, or accept the tradeoff only in throwaway environments. Never in prod.

Guard/fillable mismatches. If password isn't in $fillable and the command uses create(), you get a silently password-less user — or an exception, depending on version. Check $fillable, and confirm the stored hash actually verifies: Hash::check('yourpassword', User::first()->password) in tinker. Hash mismatches (double-hashing when your model also has the hashed cast) are the single most likely failure here post-Laravel-9.

Schema assumptions. The command assumes a fairly standard users table. Missing email_verified_at, a non-nullable custom column with no default, or a name split into first_name/last_name will all bite you. Symptom: a SQL integrity constraint violation that mentions a column the package never asked about.

Mail failures can abort creation. If the credentials email is attempted inline and SMTP is unreachable, you may get an exception after the user row is committed. Re-running then fails on the unique email constraint. Know which state you're in before retrying — check user:list first.

Command not found after install? composer dump-autoload then php artisan package:discover. If you're cached, php artisan config:clear. Confirm discovery is working by checking bootstrap/cache/packages.php for the provider.

Name collisions. user:create is a popular name. If another package or a leftover app command registers it, the last one wins and you'll debug behavior from the wrong codebase. php artisan list shows one entry, not the conflict.

Production safety. Treat these commands as privilege escalation for anyone with shell access — they create accounts and email credentials. Gate them behind app()->environment('local', 'staging') in a wrapper command, or at minimum make sure your deploy tooling never invokes them.

Debugging tip: run with -vvv and read the package source in parallel. At this size, the source is the documentation, and it will answer questions no README will.