Laravel Users Laravel Package

Getting Started

jeremykenedy/laravel-users is a drop-in user management scaffold: user CRUD, account and settings screens, and public account confirmation pages, shipped with Bootstrap 4 (default) and Bootstrap 5 styling.

composer require jeremykenedy/laravel-users:^6.0.1 -W
php artisan laravelusers:update --unattended
php artisan config:clear && php artisan view:clear

Where to look first, in order:

1. config/laravelusers.php (after publishing) — the framework/UI selection and feature gates live here. Bootstrap 4 is the default; switch to Bootstrap 5 only if your host app actually ships Bootstrap 5, otherwise you get mismatched container widths.
2. docs/upgrading.md and docs/integrations.md in the package — the integration doc is the fastest way to understand which optional packages change behavior.
3. The published views directory — this is where you will spend most of your time; treat the package output as a starting scaffold, not a black box.

Migrations are opt-in per feature. Run only the migration tags for features you actually enable; there is no users-table change in 6.0.1.

First use case: install, visit /users as an authenticated user with the right role, confirm the CRUD table renders inside your layout, then hit /account and /settings and preview a notification. If those four screens align, the install is sound.

Implementation Patterns

Publish-then-own. Publish views, config, and assets, then customize the copies. The package's laravelusers:update command deliberately preserves your published views — it will not replace them. That makes the update a two-step mental model: run the command to pull in non-view changes, then manually diff and merge view-level changes (see Gotchas).

Deploy pipeline. Put the update sequence in your release script rather than running it ad hoc:

composer install --no-dev -o
php artisan laravelusers:update --unattended
php artisan config:clear
php artisan view:clear

--unattended matters in CI — it prevents an interactive prompt from hanging a deploy. Follow it with config:clear and view:clear every time; stale compiled views are the most common source of "the fix didn't apply" reports.

Feature gating over forking. Rather than ripping out routes you don't want, disable features through config and skip the corresponding migrations. This keeps you on the upgrade path for the next patch release instead of maintaining a fork.

Notification preview as a UX contract. The preview endpoints must render unsaved options without persisting them and without moving the page. If you wrap or restyle the settings card, preserve its height during preview — the 6.0.1 fix exists precisely because preview toggling used to shift scroll position and card layout. When both alert and toast previews are enabled and Toast is positioned at the top, the alert preview anchors to the bottom edge so both close controls stay clickable; don't "fix" that by moving it back to the top.

Integrations are opt-in wiring, not dependencies. Laravel Toast, Roles, UI Kit, Darkmode Toggle, IP Capture, and Seedster each play a distinct role (notifications UI, permissions, styling primitives, theme persistence, request metadata, seeding). Laravel Notifications is a companion package documented separately — it is not pulled in automatically, so add it explicitly if you want its behavior. Any integration that performs Composer operations needs the documented filesystem permissions and a running queue worker; without a worker those jobs will sit in the queue silently.

Gotchas and Tips

• The update command will not touch your views. After 6.0.1, manually merge the notification JavaScript/CSS changes and the Bootstrap 5 container rules into any copies you maintain. If you skip this, you keep the old preview-movement bug while believing you're patched.
• Verify at two widths, not one. Post-deploy, check Users, Account, Settings, and a public account confirmation page for container alignment, then preview notifications at desktop and mobile widths with unsaved options. Confirm scroll position holds, the card doesn't jump, and nothing is saved.
• Bootstrap 5 container sizing now survives a missing host stylesheet, but that fallback is a safety net, not a license to run Bootstrap 5 pages without Bootstrap 5 loaded. Public confirmation pages follow the same bounds — check them, they're easy to forget.
• -W on composer require is required when you want the root constraint actually updated; omitting it can leave you pinned and confused about why 6.0.1 "isn't installing."
• Rollback is manual. Restore the prior composer.lock and your backed-up published views/assets, reinstall, then config:clear and view:clear. There's no schema to reverse in this patch, but published asset drift is real — back them up before every update, not just major ones.
• No new config keys, no new migrations, no new dependencies in 6.0.1. If someone claims an upgrade step beyond the documented sequence, they're inventing work. Existing framework selection and saved settings carry over untouched.
• Runtime floor is PHP 8.1 / Laravel 8. Confirm your CI matrix before bumping; 6.0.0's full breaking-change guidance matters only if you're coming from 5.x or earlier.
• Notification colors use the notification package's presets. There is no color picker — if a stakeholder asks for brand colors, that's a custom override in your published views, not a config toggle, and it's another thing you'll merge by hand later.
• Other CSS frameworks are still roadmap-only. If the project assumes Tailwind or Bulma support, that assumption is unshipped; plan for Bootstrap 4 or 5 or plan for custom work.
• Extension point of last resort: published views. Everything else — config gates, the update command, integrations — is designed to be upgraded in place. The more logic you bury in view overrides, the more merge debt each patch release creates.