Auth Laravel Package

Technical Evaluation

Architecture fit. grafite/auth is a stub-publishing scaffold, not a runtime dependency. It republishes Laravel UI–derived auth controllers, traits, and Blade views into the host application, after which the package has no ongoing presence in the request path. For a TPM this is the single most important architectural fact: the code we ship is code we own, and the package is effectively a one-time template. That is an appropriate shape for an opinionated Blade/session monolith on the stock Eloquent guard, and the wrong shape for anything API-first, SPA, mobile, or Inertia-driven, where Sanctum, Passport, or Fortify are the correct primitives. It presupposes a Blade view layer and the conventional users schema; multi-tenant systems with custom guards should not attempt to bend it.

Integration feasibility. Mechanically trivial — composer require, vendor:publish, and a route/middleware wiring pass. The genuine feasibility question is version currency. Forks of Laravel UI are tightly coupled to a specific Laravel major: controller namespaces, RouteServiceProvider conventions, Blade component syntax, and the password_resets → password_reset_tokens migration all shifted between Laravel 8 and 11. A fork that has not tracked those changes either fails to install or, more dangerously, installs cleanly and generates subtly outdated auth code. Feasibility must be proven by a pinned-version spike, not by reading the README.

Technical risk. High, on three axes. Surface area: registration, login, password reset, email verification, and remember-me handling are the highest-consequence code in any application, and this is an unvetted fork of exactly that code. Provenance: zero stars and zero dependents means no evidence of production use, no issue history to mine, and no community review of the diff against upstream Laravel UI. Patch channel: because stubs are copied into the app, upstream security fixes never reach us automatically — we inherit the full patch obligation without inheriting upstream's review process. The opportunity score of 29.6 correctly reflects a crowded field: laravel/ui, Breeze, Fortify, and Jetstream are first-party, actively maintained, and cover more ground.

Key questions. Which Laravel and PHP versions are supported, and when was composer.json last touched? What is the precise diff from Laravel UI, and does it add or remove anything security-relevant? Does it include login throttling, email verification, password confirmation, and 2FA, or are those left to the adopter? Is it publish-only, or does it register a runtime service provider? What is the maintainer model and release cadence behind Grafite? Are there tests, and do any exercise the reset-token and session-invalidation paths?

Integration Approach

Stack fit. Adopt only for a Laravel monolith using Blade, session-based auth, and the default User model, and ideally only where the team already sits inside the Grafite ecosystem (admin panels, CRUD generators) — where stylistic consistency across many small apps is a real, quantified saving. Outside that context there is no fit argument. If requirements touch SPA, mobile, SSO, MFA, or API tokens, the package is the wrong shape and the effort to force it exceeds writing the controllers directly on Breeze or Fortify.

Migration path. From laravel/ui, treat this as a stub re-publish with a line-by-line diff, not a package upgrade. From hand-rolled auth, sequence as: freeze current controllers on a branch; publish this package's stubs alongside rather than over them; reconcile the route table; then cut over one flow at a time (login → reset → registration → verification). Keep the legacy route registration behind a config flag so rollback is a one-line change rather than a revert commit. For prototypes and agency starter kits, the recommended end state is fork-and-drop: publish the stubs, then remove the composer dependency and carry the code in-repo, eliminating the phantom expectation of upstream updates.

Compatibility. Verify four things before any code lands: composer.json Laravel/PHP constraints against the target app's actual lockfile; whether published migrations collide with existing users and password-reset tables; whether the Blade stubs assume Tailwind or Bootstrap scaffolding the app does not have; and whether middleware aliases and guard names match config/auth.php. Any mismatch here is a rewrite, not an adjustment — each is a go/no-go gate.

Sequencing. Timebox a one-day spike in a throwaway application pinned to the target Laravel version. Diff the published output against both the app's existing auth code and current Laravel UI. Run a security review focused on reset and session paths. Pilot in a single low-risk internal application. Only then decide on broader adoption — and be prepared for the honest outcome to be "reject, use Breeze or Fortify," which is the cheapest possible result given the spike cost.

Operational Impact

Maintenance. The published stubs become the team's code from day one. Upstream fixes do not propagate; we own every future patch to login, reset, and token handling. This is a recurring line item, not a one-time integration cost, and it should be budgeted and owned explicitly — not left to whichever developer last touched the auth folder.

Support. Bus factor is effectively one. There is no SLA, no triage queue, no Stack Overflow corpus, and no vendor escalation path. When a Laravel major lands and the stubs break, we debug it alone. This is the dominant operational risk and it does not diminish with time; it compounds.

Scaling. Auth throughput is rarely the bottleneck and this package does nothing to change that. The real levers — session store choice, rate limiting on login and reset endpoints, an index on email, queue-backed verification mail — are all application-side and must be implemented regardless. The stubs may actively omit throttling, so scaling work is additive on top of adoption, not delivered by it.

Failure modes. Watch for silent breakage on Laravel upgrades where stubs still compile but no longer match framework expectations; user enumeration via differentiated login error messages; open redirect through unvalidated intended URLs; reset-token handling that predates current hashing practice; Blade view collisions with the app's design system; and guard/session misconfiguration producing logout loops that surface as infrastructure incidents. Because the code is local, none of these appear as a dependency advisory — they appear as production bugs after the composer audit comes back clean.

Ramp-up. A mid-level Laravel developer can install and wire this in half a day. Auditing the four core flows to an authentication-appropriate standard, plus writing the integration tests the package does not ship, is one to two weeks. That audit is non-negotiable for any customer-facing use and should be priced into the adoption decision up front — at which point total cost typically exceeds simply adopting a first-party option. Position the package as an internal prototyping accelerator under a "fork, don't depend" rule, with no customer-facing authentication placed on it absent a security review and a named owner.