Laravel Create User Cli Laravel Package

Getting Started

This package adds an Artisan command that walks you through creating a User record from the terminal — handy for seeding a fresh install, spinning up test accounts, or provisioning admins on servers where you don't want to click through a registration form.

Install

composer require spresnac/laravel-create-user-cli

Laravel's package auto-discovery should register the service provider automatically. If not, add it manually to config/app.php:

'providers' => [
    // ...
    Spresnac\LaravelCreateUserCli\ServiceProvider::class,
],

Verify and run

php artisan list | grep -i user    # confirm the command is registered
php artisan user:create            # typical invocation — check the package README for the exact signature

Where to look first

1. Read the package's README.md — the command signature and options are the whole API surface here.
2. Look inside vendor/spresnac/laravel-create-user-cli/src/ for the command class. That's the file you'll extend if you need to add fields.
3. Check its default behavior against your users table migration — field names and nullable columns matter (see Gotchas).

First use case

Reset a local database and immediately create a login you can use:

php artisan migrate:fresh --seed
php artisan user:create

The command will typically prompt for name, email, and password, then hash and insert the record through your User model.

Implementation Patterns

Interactive creation (default workflow).

Run the command and answer the prompts. This is the intended path — it lets you type a real password without it landing in shell history, and it usually confirms before writing.

php artisan user:create
# Name: Jane Doe
# Email: [email protected]
# Password: ********
# User created successfully.

Scripted / non-interactive creation.

If the command exposes flags (check the README for exact names — commonly --name, --email, --password), you can wire it into provisioning scripts:

php artisan user:create \
  --name="Deploy Bot" \
  --email="[email protected]" \
  --password="$(openssl rand -base64 16)"

Pipe it into a Makefile or a deploy.sh step so staging environments always get an admin account.

Seeding alternative for local dev.

Rather than polluting your DatabaseSeeder with a hard-coded user, call the command from a demo seeder or a composer run script:

{
  "scripts": {
    "dev:user": "php artisan user:create"
  }
}

Then composer dev:user from any shell.

Custom fields on the users table.

If your users table has extra columns (role, tenant_id, is_admin), the stock command won't know about them. Two patterns work well:

• Post-create update: create the user, then set extra fields via artisan tinker or a tiny follow-up command.
• Extend the command: copy the command class into app/Console/Commands/CreateUser.php, add your own $this->ask(...) calls, and register it in Kernel.php. Point the original user:create name at your subclass so tooling keeps working.

class CreateUser extends \Spresnac\LaravelCreateUserCli\Commands\CreateUser
{
    protected $signature = 'user:create';

    public function handle()
    {
        parent::handle();

        $user = User::where('email', $this->argument('email'))->first();
        $user->update(['role' => $this->choice('Role', ['admin', 'editor', 'viewer'])]);
    }
}

Pairing with migrate:fresh in a test harness.

In a Pest/PHPUnit setUp() or a CI bootstrap step, invoke the command programmatically when you need a real persisted user:

$this->artisan('user:create', [
    '--email' => '[email protected]',
    '--password' => 'password',
]);

This is cleaner than User::factory()->create() when you want to exercise the same code path an operator would use.

Gotchas and Tips

Field names must match your model. The command writes to whatever columns it ships with (name, email, password by default). If you renamed name to full_name, or added a NOT NULL column without a default, the insert will fail with a SQL constraint error. Fix the migration or extend the command — don't paper over it with a post-update hook if the column is non-nullable.

Password hashing. The command should call Hash::make() (or rely on the model's hashed cast). If you're hand-rolling an override, never insert the raw password — Laravel 10+ models with a 'password' => 'hashed' cast handle this automatically, but older versions need an explicit hash.

Email uniqueness. Most implementations hit the users.email unique index and throw a QueryException if the address already exists. If you're scripting, either check first or swallow the specific error. A firstOrCreate variant is a common enhancement if you re-run provisioning scripts.

Confirm the command name. The repo is small (23 stars) so signatures aren't guaranteed across versions. Always run php artisan list after installing rather than assuming user:create — some versions use create:user or make:user.

Interactive prompts in CI. Commands that use $this->ask() will hang in a non-TTY context (CI, Docker entrypoint). Verify your package version exposes non-interactive flags; if not, pass --no-interaction and expect defaults, or extend the command to read from env().

Extension point. The cleanest long-term approach for anything beyond a vanilla user is to subclass the command (as shown above) rather than editing vendor/. That survives composer update and keeps your customizations in version control.

Debugging silent failures. If the command exits 0 but no user appears, check: (a) you're connected to the intended database (php artisan tinker → DB::connection()->getDatabaseName()), (b) a global scope or observer on User is rejecting the insert, (c) APP_DEBUG=true is on so the exception surfaces. Wrap the invocation in php artisan user:create -vvv for maximum verbosity.

Don't ship it as your auth flow. This is a dev/ops convenience tool. It bypasses email verification, password policies, and rate limiting — none of which are appropriate for production self-service signup.