Admin Laravel Package

Product Decisions This Supports

• Build vs. buy for admin/back-office surfaces: v0.7.0 moves authentication into the package — panel logout, the signed-in user object, and an admin:install --auth flow that publishes sign-in and password-reset pages from package base pages. That shifts the buy side of the ledger: auth UI, session/logout wiring, and password reset are now scaffolding we don't hand-roll, so the "build" estimate for a new admin panel drops by the cost of those screens plus their test surface.
• Time-to-first-demo / internal tooling roadmap: if we have internal dashboards or ops panels queued, this release is what makes them cheap to stand up — install command plus published auth pages means a demo-able, gated panel in a sprint rather than a quarter.
• Scope negotiation with design and security: we inherit opinionated default auth pages. That is a product decision in itself — adopting means accepting the package's sign-in and reset UX unless we override the published views. Worth an explicit call rather than discovering it mid-build.
• Lockfile and upgrade policy: the AuthPage::url() → currentUrl() rename lands in 0.7.0. If any prototype or spike used the old method, that is a small, known migration cost. It also signals the package is still pre-1.0 and willing to rename public API — relevant to how much we invest before pinning.
• Vendor-risk posture: a single-maintainer package owning our auth flow is a different risk class than owning our table sorters. Auth is the one area where "convenient dependency" needs a second look before it becomes load-bearing.

When to Consider This Package

Consider adopting when:

• We need a Laravel admin/back-office panel and want auth screens, logout, and the current-user accessor supplied rather than written.
• We are comfortable on Laravel's native auth primitives — this rides on them rather than replacing them, so no parallel identity system to reconcile.
• The panel is internal, low-blast-radius, or behind SSO at the edge; the package's default auth pages are acceptable as shipped, or we're happy to own the published views.
• We can pin an exact version and absorb a rename between minor releases — pre-1.0 means the public surface can still move.

Look elsewhere when:

• The product is customer-facing with bespoke sign-in, MFA, social login, or complex password policy. Published base pages are a starting point, not a strategy.
• Compliance or audit obligations require us to own the full auth code path and its review trail.
• We need a stable public API contract with deprecation windows — a rename folded into the same minor release, without a deprecation cycle, tells you what the next upgrade may look like.
• We are on 0.6.x in anything shared: treat 0.7.0 as a breaking-ish bump, audit for AuthPage::url() call sites, and schedule it deliberately.

Open questions before committing: how much of the auth surface is genuinely package-owned vs. thin Laravel wrapper, what the override story looks like for the published views, and whether the maintainer load is supportable for an auth-adjacent dependency.

How to Pitch It (Stakeholders)

To executives: this release closes a real gap. Authentication for an admin panel — sign-in, password reset, logout, current-user — used to be work we scheduled; it is now installation and configuration. That compresses the cost of any internal panel on our roadmap and removes a category of "we'll get to auth later" debt. The caveat is maturity: the package is pre-1.0 and just renamed a public method inside a minor release, so the honest framing is fast-moving dependency, adopt with a pinned version, not platform commitment. Recommend a scoped pilot on one internal panel, not a standard.

To engineering: 0.7.0 ships panel logout, the signed-in user, and an admin:install --auth path that publishes sign-in and password-reset pages from package base pages. That means auth is now a package concern and our job is integration, view overrides, and tests around the publish step. Note AuthPage::url() is now currentUrl() — grep for it, it's cheap now and awkward later. Pin the version, and treat upgrade PRs as reviewable diffs rather than routine dependency bumps, because pre-1.0 renames are evidently in scope for minor releases.