- How do I install spresnac/laravel-create-user-cli?
- Install it with composer require spresnac/laravel-create-user-cli. The package registers its Artisan command through a service provider using Laravel package auto-discovery, so there is no config file to publish and no migration to run. Realistic time to first user is under an hour, mostly spent verifying the command against your user model.
- Which Laravel and PHP versions does it support?
- The package overview does not list explicit Laravel or PHP version constraints, so check the composer.json for illuminate/console and illuminate/support requirements before adopting it. Because it is a thin, single-maintainer utility, Laravel major-version drift can strand it quickly. Verify it against your target Laravel version in a scratch branch, including service-provider discovery under config:cache.
- Does the command hash the password before saving the user?
- The package description states that it hashes the password and saves the new user through Eloquent. That said, password entry on the command line invites exposure through shell history, process listings, and CI logs if passed as an argument. Prefer a hidden prompt where possible and avoid putting real passwords in scripts or pipeline logs.
- Does it use my custom User model or hardcode App\Models\User?
- The external documentation does not state whether the command resolves the user model from config/auth.php providers or assumes App\Models\User. If you use a custom auth model, UUID or ULID keys, a nonstandard table, or guarded fields, verify the behavior before relying on it. Where your domain deviates, treat the package as a template to copy rather than a dependency to install.
- Is there a guardrail against running it in production?
- There is no documented environment check, confirmation prompt, or idempotency guard against production use. The command writes directly to the users table, so an accidental run could create a real account with whatever password was supplied. If you adopt it, wrap it with your own confirmation or restrict it to local and staging environments.
- Can it assign roles, teams, or tenant membership when creating a user?
- No. The command is effectively a fixed three-field insert for name, email, and password, and it does not cover roles, tenant assignment, email-verification state, or extra profile fields. In multi-tenant or team-scoped applications it will create structurally incomplete users unless you add your own wrapper logic. For those cases, a dedicated provisioning action or an admin UI is a better fit.
- What happens if the email address already exists?
- There is no documented idempotency handling, so a duplicate email will most likely surface as a unique-constraint database error rather than being skipped gracefully. If you need repeatable runs, wrap the command in your own firstOrCreate-style logic or handle the exception. This matters most in setup scripts that may execute more than once.
- Is this a good alternative to php artisan tinker or database seeders?
- It is a convenience for interactive bootstrapping, such as creating a first admin locally without opening tinker or writing a one-off script. Database seeders remain better for repeatable, version-controlled test data, and Breeze, Fortify, or Jetstream registration actions remain better for application-level account creation. Adopting this package is a decision to standardize on one convenience path, not to fill a missing capability.
- How do I use it safely in CI or ephemeral containers?
- Avoid passing plaintext passwords through CI logs or shell history, and prefer environment-driven wrappers or a dedicated seeder for automated pipelines. Verify that the command still registers when the container is read-only or ephemeral and when config:cache has been run. Also check for Artisan command-name collisions with any existing commands in your application.
- How do I remove it, and is the package actively maintained?
- Removal is straightforward: composer remove spresnac/laravel-create-user-cli plus deleting any wrapper you layered on top, with no schema changes or data backfill to undo. Lock-in is effectively zero, which argues for treating it as a stopgap rather than a platform decision. Maintenance evidence is thin, with around 23 stars and a single maintainer, so review release cadence and issue-response history before depending on it.