- How do I install claudiodekker/laravel-auth in a Laravel app?
- Install the package with Composer and use its Artisan-driven installation flow to publish the authentication scaffolding into your application. The package is designed to publish controllers, routes, configuration, and Blade views so you can customize them directly. On v0.2.0, first confirm whether your application should require the aggregate laravel-auth package or the underlying laravel-auth-core and laravel-auth-bladebones packages. Run the setup in a non-production environment before applying it to an existing app.
- Which Laravel and PHP versions does claudiodekker/laravel-auth support?
- The v0.2.0 release confirms support for PHP 8.2 and Laravel 10. The available release information does not evidence Laravel 11 or Laravel 12 support, so treat those versions as unsupported until you validate them in a spike. Pin exact Composer versions and commit your lockfile before deploying.
- What authentication flows are included out of the box?
- The package provides registration, login, logout, password confirmation, and password reset flows. It also supports optional email verification, configurable guards, redirects, and view styling. Because the controllers, routes, and Blade views are publishable, you can adapt each flow to your application instead of being locked into package-owned code.
- Should I require laravel-auth or laravel-auth-core directly?
- The v0.2.0 monorepo splits the package into laravel-auth-core and the Blade UI layer laravel-auth-bladebones, so the intended production dependency must be confirmed for your use case. Teams that do not need package-provided views can evaluate laravel-auth-core alone, while teams wanting the full scaffold may require the aggregate package. Use composer why claudiodekker/laravel-auth-core and composer why claudiodekker/laravel-auth-bladebones to inspect what is actually installed. Avoid mixing duplicate or conflicting auth packages during the transition.
- Can I customize the controllers, routes, and Blade views?
- Yes. The package publishes authentication controllers, routes, and Blade views into your application so they remain fully editable. After upgrading the package, diff any overridden files against upstream before re-publishing so you do not silently lose local changes or overwrite important customizations.
- Does claudiodekker/laravel-auth support Laravel 11 or Laravel 12?
- There is no evidence in the v0.2.0 baseline that Laravel 11 or Laravel 12 is supported. Confirmed compatibility is PHP 8.2 with Laravel 10, so newer Laravel versions should be treated as unvalidated. If you need Laravel 11 or 12, run a dedicated compatibility spike before committing to this package.
- How should I upgrade from v0.1.x to v0.2.0 safely?
- Update Composer constraints deliberately and inspect the split-package dependency changes with composer why for laravel-auth-core and laravel-auth-bladebones. Diff any published views and configuration against upstream before re-publishing overrides. Run migrations and authentication smoke tests in a disposable environment, including login, logout, registration, password reset, and email verification. Pin the prior lockfile and keep a database backup so you can roll back if needed.
- Is claudiodekker/laravel-auth safe for production authentication?
- Authentication is security-sensitive, and this is a pre-1.0 community package, so production use requires internal review rather than automatic adoption. Pin exact versions, assign an internal owner for auth dependency and security review, and maintain a fork or exit plan. Validate the package against your application's guards, password reset, email verification, session, and authorization requirements before rollout.
- How do I test the authentication flows before deploying?
- Start with a non-production spike using the exact Laravel and PHP versions you plan to run in production. Run your existing application test suite plus dedicated auth tests for login, logout, registration, password reset, email verification, remember-me, rate limiting, session invalidation, and authorization gates. Only after those pass should you move the change to staging and plan a phased production rollout with rollback via a pinned Composer lockfile.
- When should I avoid claudiodekker/laravel-auth and consider alternatives?
- Avoid it when you need confirmed Laravel 11 or Laravel 12 support, strong vendor backing, or a documented security advisory process, because the available baseline only confirms PHP 8.2 and Laravel 10. It fits Laravel 10 applications that want package-managed but publishable authentication scaffolding. If your requirements include MFA or other flows not covered by the package, compare it against maintained Laravel auth options and validate the chosen path with your own security review.