Auth For Laravel Laravel Package

Product Decisions This Supports

• Build vs. buy for authentication. Multi-persona auth (separate guards for admins, customers, partners) is table stakes but easy to get subtly wrong — schema drift, guard misconfiguration, model/factory mismatches. Adopting this package keeps engineering effort on differentiators instead of re-deriving auth scaffolding. 1.2.2 doesn't change that calculus; it reduces the ongoing cost of ownership.
• Roadmap: separate login surfaces per persona. The authenticationColumns() schema macro plus the authentication:guard migration generator make each new guard a repeatable, reviewable artifact. This supports sequencing (e.g., ship customer auth in Q3, partner auth in Q4) without forking the users table or hand-writing migrations per environment.
• White-label / multi-tenant and custom-model initiatives. The factory fix — factories now build the configured model when a host swaps it — matters for any workstream using a custom User subclass or tenant-scoped auth model. Previously this was a silent test-fidelity gap that could turn into a late-stage defect; now test fixtures track the real model, de-risking those initiatives.
• Quality-gate decision: keep Larastan/PHPStan at a high level in CI. 1.2.2 ships a PHPStan extension (auto-loaded via phpstan/extension-installer through extra.phpstan.includes) so static analysis understands the schema macro. This is a CI-friction decision: without it, migrations calling the macro can fail analysis with "Call to an undefined method" in Testbench, dont-discover, or hand-registered-provider setups. It lets us keep analysis strict rather than suppressing rules.
• Upgrade decision: 1.2.2 is a patch, non-breaking. Adopt in the normal maintenance window; no migration guide, no API changes. Worth doing promptly if we run static analysis in CI or swap the auth model, since both fixes remove false negatives.

When to Consider This Package

Consider it when:

• You're implementing or extending Laravel authentication and need more than one guard/persona, or want generated, consistent auth migrations rather than bespoke ones.
• You subclass or swap the auth model (tenant-scoped users, white-label deployments) — the 1.2.2 factory fix directly addresses this.
• You run Larastan/PHPStan in CI. Budget one line of config: rely on phpstan/extension-installer, or explicitly include vendor/roundly-consulting/auth-for-laravel/extension.neon. Also verify the provider is booted during analysis in package-development/Testbench or dont-discover setups.
• You want auth schema evolution to be declarative and reviewable across services and environments.

Look elsewhere when:

• You need only single-guard, stock users-table auth — Laravel Breeze/Jetstream/Fortify cover that with less surface area.
• You need OAuth/social, SSO/SAML, passkeys, or MFA as first-class out-of-the-box features; this package is schema/guard scaffolding, not an identity provider.
• Your auth schema is heavily customized away from the macro's shape — you'd be fighting the generator.
• Vendor-risk tolerance is low. Single-vendor package: pin versions, keep guard configuration behind a thin internal abstraction, and keep an upgrade/exit test. 1.2.2's active maintenance is a positive signal, but not a substitute for that mitigation.
• You're on a Laravel version outside the package's supported matrix, or your CI can't load the PHPStan extension and you can't accept the manual include.

How to Pitch It (Stakeholders)

For executives (one paragraph): We're standardizing how we add new login audiences — customers, partners, internal admins — on a small, actively maintained Laravel package rather than building auth scaffolding ourselves. The alternative is weeks of engineering plus permanent maintenance for something that isn't our differentiator. Release 1.2.2 is a routine patch: it fixes test factories when we use a customized user model, and it teaches our static-analysis tooling about the package's schema helper so CI stops producing false failures. No breaking changes, no migration work, no user-visible impact. Recommendation: approve the patch bump and treat the package as an approved dependency for the multi-persona auth roadmap.

For engineering: Low-risk patch, drop-in. Two things land: (1) factories now build the configured model when a host app swaps it — this closes a test-fidelity hole for tenant-scoped and custom user models; (2) a PHPStan extension ships in extra.phpstan.includes, auto-loaded by phpstan/extension-installer, that resolves the $table->authenticationColumns(): void macro during analysis. If you don't use the installer, add vendor/roundly-consulting/auth-for-laravel/extension.neon to your config; if the provider isn't booted during analysis (Testbench package development, dont-discover, manual provider registration), you were exposed to a "Call to an undefined method" failure in migrations — this removes it. Upgrade in the next maintenance window; no code changes expected.

Ask: approve the patch-level dependency bump, add the static-analysis include note to onboarding docs, and confirm the package stays behind our guard-configuration abstraction so an exit remains cheap.