- How do I install dyrynda/laravel-make-user?
- Install it with composer require dyrynda/laravel-make-user. The package ships as a service provider with Laravel auto-discovery, so there is no configuration file to publish and no migrations to run for the package itself. Once installed, the Artisan command is available immediately in your console kernel.
- What does the laravel-make-user command actually scaffold?
- It generates a User model, migration, and factory, along with routes, controllers, and Blade views covering registration, login, email verification, and password resets. The goal is to give a fresh Laravel app working authentication scaffolding from a single command. It is intended for prototyping and bootstrapping new projects rather than for production identity architecture.
- Which Laravel and PHP versions does dyrynda/laravel-make-user support?
- Compatibility is declared in the package's composer.json and README, and the last tagged release was 2025-02-26. Because the repository is archived, there is no forward-compatibility guarantee for Laravel 12+ or future changes to Illuminate\Console and password hashing defaults. Check the constraints yourself and run it against your target version before committing to it.
- Is dyrynda/laravel-make-user still maintained?
- No. The GitHub repository is archived, meaning the last release is effectively a terminal state with no further fixes or Laravel version tracking. It is MIT licensed and has no dependents, so there is no community pressure to patch breakage. Treat it as a readable reference implementation rather than a long-lived dependency.
- Does it work with a custom User model, UUID keys, or a non-standard users schema?
- The command assumes a conventional App\Models\User with name, email, and password attributes. Applications using UUID or ULID keys, separate first_name and last_name columns, multi-tenant scoping, SSO-only accounts, or mandatory role assignment will need to fork or override the command. There is no indication that the user model is resolved through config or the container, so plan for a copy-and-adapt approach.
- How is dyrynda/laravel-make-user different from Laravel Breeze, Jetstream, or laravel/ui?
- Breeze, Jetstream, and laravel/ui are starter kits that install a full frontend and authentication stack as a dependency. This package is a single Artisan command that writes scaffolding files into your application, so it stays out of your runtime once the files exist. It is much lighter but also far less maintained, so compare it against Breeze if you want ongoing Laravel version support.
- Can I run the make-user command non-interactively in CI or seeders?
- The command is prompt-driven, so it is not designed as a provisioning or operations primitive. There is no documented --no-interaction path suitable for CI, and prompted passwords are a poor fit for automated pipelines. For seeding and tests, prefer Laravel factories and seeders instead of invoking this command.
- Does the created user fire domain events, get roles assigned, or respect Password::defaults()?
- No. A generic user-creation command will not dispatch your Registered event, assign roles, provision tenants, or enforce your password policy. Users it creates can be structurally valid but semantically wrong, which is worse than a loud failure. If you need those behaviors, reimplement the command internally and wire them in explicitly.
- Is it safe to use dyrynda/laravel-make-user in production?
- Leaving a command that mints accounts with prompted passwords enabled outside local or staging environments is an operator footgun. Restrict it to development, or better, replace the prompt-based flow with factories and seeders. The package is a developer-ergonomics tool for demos and bootstrapping, not part of a provisioning workflow.
- Should I depend on this package or reimplement it in my own app?
- Because the repository is archived, adoption by reimplementation is the safer path. The command source is small and MIT licensed, so you can read it as a specification for prompts and validation order and rebuild it as app/Console/Commands/CreateUser.php with your own model resolution, password policy, role assignment, and events. If speed matters, require it, pin the exact version, and open a ticket to replace it before your next major Laravel upgrade; vendoring the single class into your app is a middle ground that removes the dependency without a rewrite.