Laravel Legacy Ui Laravel Package

Product Decisions This Supports

• Legacy Laravel upgrade path (7 → 8/9): Decides whether an existing app keeps its current Blade/Bootstrap auth screens during a framework upgrade, instead of forcing a UX rewrite onto Breeze (Tailwind) or Jetstream (Livewire/Inertia). This is the primary use case and the lowest-friction option when auth views are already customized.
• Build vs. buy vs. fork, for auth scaffolding only: Auth screens (login, register, password reset, email verification, password confirmation) are pure commodity work — roughly 1–2 weeks of design + engineering + QA per app. This package reduces that to a composer require plus ui:auth publish. The real decision is not "build or buy" but "adopt a community fork, adopt first-party Breeze/Fortify, or keep our existing scaffold."
• Front-end stack alignment: Commits the product to a Bootstrap/Blade-era presentation layer (with Vue 2/React presets). That is a stack decision, not a package decision, and it will constrain design system choices for as long as those screens live.
• Roadmap sequencing for auth-adjacent features: Anything requiring 2FA, passkeys, SSO/SAML, social login, or modern session/device management is out of scope here. If those are on the 2–4 quarter roadmap, choosing this package adds a migration step later; choosing Fortify now avoids it.
• Internal tools and admin back-offices: Where auth is a means to an end and no customer ever sees the login page, this is a legitimate time-saver with near-zero brand or UX cost.
• Technical-debt register entry: Adopting it is a conscious decision to carry an unmaintained, 55-star fork. That should be logged with an owner and a migration trigger, not silently absorbed.

When to Consider This Package

Consider it when:

• The app is pinned to Laravel 8 or 9 and will stay there for the planning horizon.
• The product already ships Blade + Bootstrap (or Vue 2 / React presets) and design consistency matters more than modern auth UX.
• Auth screens are internal-facing or low-stakes, and there is no near-term 2FA/SSO/passkey requirement.
• You need speed over longevity — a prototype, an internal admin tool, a proof of concept, or a time-boxed client deliverable.
• You want a familiar codebase: this is a thin continuation of first-party laravel/ui, so the generated code is well-understood, auditable, and easy to hand-edit.

Look elsewhere when:

• You are on Laravel 10/11+. The last release is Feb 2022; there is no evidence of compatibility with current framework versions. Do not assume it works.
• The surface is customer-facing or security-sensitive (payments, health, PII). An unmaintained auth package means no upstream security patches; you are the maintainer whether you plan to be or not.
• You need 2FA, passkeys, SSO, social login, or API tokens — use Laravel Fortify (headless, first-party, actively maintained) with your own views, or Breeze for a maintained full-stack starting point.
• Your org requires supported dependencies, SBOM/provenance, or a security response SLA. A 55-star repo with a two-year-old release will not clear procurement.
• You need laravel/ui's own remaining functionality at scale — the first-party package is the safer reference even if you fork.

Mitigating detail worth knowing: this is a scaffolder, not a runtime dependency. ui:auth publishes controllers, routes, and views into your repository, so at runtime you own and can patch every line. Supply-chain exposure is therefore much lower than the star count suggests — the risk is "no one will fix bugs for you," not "a hostile package executes in production." MIT license plus a first-party lineage means forking and self-maintaining is genuinely cheap if you decide the Bootstrap look is worth keeping.

How to Pitch It (Stakeholders)

To executives: This is a small, free, MIT-licensed tool that generates the standard login/registration/password-reset screens for Laravel apps. It saves roughly one to two weeks of engineering and design time per application and keeps our existing Bootstrap interface unchanged, so no retraining, no QA re-baselining, no user disruption. It is not a platform bet — it is a shortcut for a commodity feature.

The honest caveat, stated plainly: it is a community-maintained fork with a small user base and no release since early 2022. We should treat it as a tactical accelerator with a known expiry, not a strategic dependency. Because it generates code into our repo rather than running inside our app, the downside is bounded: if it stops serving us, we keep the code we already have and maintain it ourselves, or migrate to Laravel's first-party Fortify/Breeze — an estimated one to two weeks of work whenever we choose to spend it.

To engineering: adopt it only for Laravel 8/9 apps that are already Bootstrap/Blade. Pin the exact version, vendor-lock the generated output, review the published auth controllers against current OWASP guidance (rate limiting, password rules, session regeneration), and add an ADR recording the adoption plus the migration trigger — for example, "revisit at the Laravel 10 upgrade" or "revisit if 2FA enters the roadmap." Do not extend it, do not patch it upstream expecting turnaround, and do not let it spread to greenfield services.

Recommendation: approve for internal tools and legacy upgrade continuity; block for new customer-facing products, where Breeze or Fortify costs the same and carries active maintenance.