Laravel Auth Laravel Package

Product Decisions This Supports

• Build vs. buy for authentication. The package bundles two things in one monorepo: laravel-auth-core (the authentication logic) and laravel-auth-bladebones (a Blade-based scaffolding generator). That lets a PM frame one decision — "do we hand-roll auth screens and flows, or generate them?" — instead of two separate evaluations.
• Laravel 10 / PHP 8.2 upgrade planning. v0.2.0 is primarily a compatibility release. It confirms the package is viable on current framework versions, which is the gate for including it in a modernization roadmap rather than flagging it as legacy.
• MVP and internal-tool scoping. Generator-based scaffolding is a real schedule lever for CRUD apps, admin panels, and internal tools where a standard session-based login is sufficient and differentiated auth is not a product differentiator.
• Consolidation / dependency-footprint decisions. Moving both packages into a single monorepo, and repointing Bladebones at laravel-auth-core, reduces the number of distinct dependencies and version-skew combinations engineering must track. That is a modest but genuine maintenance-cost input.
• What this release does not unlock. There are no new authentication capabilities here — no MFA, no passkeys, no SSO/SAML/OIDC, no new flows. Any roadmap item that depends on those is unaffected by v0.2.0 and should not be justified by it.

When to Consider This Package

Consider it when:

• You are on Laravel 10 and PHP 8.2 (or 8.1+) and need conventional, session-based authentication with Blade-rendered views — not a headless API-only setup.
• You want generated, ownable scaffolding you can edit in-repo, rather than a runtime dependency whose views you override.
• The product is an internal tool, MVP, or back-office app where auth is commodity functionality and time-to-first-screen dominates.
• Your team is comfortable reading and patching auth code, and accepts pre-1.0 API instability (v0.2.0 implies the surface can still change).
• You are willing to treat it as a starting point, with a documented exit ramp to Laravel Breeze, Jetstream, or Fortify.

Look elsewhere when:

• You need enterprise identity: SAML, OIDC, SCIM provisioning, social login (Socialite territory), or multi-tenant SSO. This package is not that.
• You need MFA, passkeys/WebAuthn, or step-up authentication — no evidence of support in this release.
• Your security posture requires actively audited dependencies with broad maintainer coverage. This is a small, effectively single-maintainer project at v0.x; that is a supply-chain and bus-factor risk you must price in.
• You want a headless auth backend for SPA/mobile clients — Fortify is the more natural fit.
• You need API-stable, semver-guaranteed primitives. Pre-1.0 means breaking changes are permitted at any minor bump.
• You require long-term vendor support or SLAs. None exist here.

How to Pitch It (Stakeholders)

To executives: Authentication is a solved problem we should not be paying engineers to reinvent, but it is also a security-sensitive one we should not improvise. This package is a low-cost accelerator: it generates standard login/registration scaffolding for Laravel 10 on PHP 8.2, which is the current release train. The v0.2.0 update is a maintenance and compatibility release — it keeps the library current with the framework, consolidates two previously separate packages into one repository, and improves test quality. It adds no new authentication features. Recommendation: adopt as a prototyping and internal-tooling accelerator, not as the foundation of customer-facing identity. Budget a spike, not a commitment, and keep a known migration path to Laravel's first-party options.

To engineering: v0.2.0 is housekeeping plus compatibility — PHP 8.2 and Laravel 10 support landed in a single PR (#23), the core and Bladebones packages were merged into one monorepo, Bladebones now depends on laravel-auth-core instead of the umbrella package, generator styling was normalized to Laravel Pint, and core tests were tightened to assert against translations rather than literal strings (with a timing-related regression fixed). Net effect: fewer moving parts, cleaner test signals, no migration burden beyond the dependency rename if you consumed Bladebones directly. Two caveats to carry into the evaluation: the project is pre-1.0, so pin versions and expect breaking changes; and it is a small-maintainer dependency in a security-critical path, so review the code you adopt rather than treating it as a black box. Proposed next step: a time-boxed spike comparing this generator against Breeze on the same skeleton app, scored on generated-code readability, test coverage, and how cleanly either can be replaced later.