Filament Accounts Auth Laravel Package

Technical Evaluation

What shipped: v5.0.0 is a version realignment release, not an incremental patch. The package (a Filament auth-scaffolding plugin that registers login/register/2FA pages plus a /auth/setup/* wizard) now targets Filament 5, Livewire 4 (Volt 1.10+), Laravel 12/13 and PHP 8.2+, and depends on tomatophp/filament-accounts 5.

Architecture fit: The design boundaries are sound and worth endorsing in review:

• Auth runtime is delegated to the host app's guards and account model rather than owning user storage — the package stays a presentation/orchestration layer over Laravel's auth primitives.
• The setup wizard is separated from runtime pages by an environment check plus a viewAuthSetup gate, which is the correct pattern for a scaffold-generating UI.
• Assets are prebuilt and published to public/auth/build rather than compiled through the host's Vite pipeline — this removes build-time coupling but transfers asset provenance and staleness risk to the package release.

Integration feasibility: Feasible for greenfield and for teams already on tomatophp/filament-accounts, but the release declares a composer conflict with devdojo/auth because both claim the Devdojo\Auth namespace. This is decisive: the package is a replacement for devdojo/auth, not a complement. Any existing install makes this a clean-room swap with a hard cutover, not a version bump.

Technical risk (ranked):

1. Hard dependency conflict — cannot be evaluated alongside the incumbent; migration must be atomic per app.
2. Two majors in the blast radius — Filament 5 and Livewire 4 affect far more than auth pages; the package upgrade cannot be validated in isolation.
3. Guard/model coupling for 2FA — the challenge logs in on the accounts guard with the configured account model; a misconfigured guard is a user-lockout class of failure, not a cosmetic one.
4. Support-matrix ambiguity — the notes only state that the 1.x line stays on the v3 branch, so teams on Filament 4 / Laravel 11 have no clearly stated home.
5. Published asset drift — public/auth/build is release-managed; upgrades that change the build without re-publishing degrade silently (font fallback masks it partially).
6. Quality signals are positive but unscoped — Pest suite, PHPStan and a Laravel 12/13 CI matrix indicate discipline; coverage breadth and PHPStan level are unknown.

Key questions for the maintainer/vendor:

• Which Filament/Laravel combination does the 1.x v3 branch actually cover, and is there a supported path for Filament 4 / Laravel 11?
• Is viewAuthSetup registered by the package, and is it denied by default outside local?
• Which guard and model does the 2FA challenge resolve when the app has multiple guards?
• Are the published assets versioned/hashed so we can detect stale builds?
• What is the security-patch policy across the v5 and v1.x/v3 lines?

Integration Approach

Stack fit: Appropriate only for apps standardizing on Filament 5 + Livewire 4 + Laravel 12/13 on PHP 8.2+. For anyone mid-migration, this package becomes a downstream consequence of the framework upgrade, not a driver of it.

Migration path (brownfield, from devdojo/auth):

1. Inventory current auth surface: routes under /auth/*, published views/config, language files, 2FA enrollment data, and which guard/model backs it.
2. Retire devdojo/auth: remove the package, its service provider registrations and any published views that collide with Devdojo\Auth.
3. Install and pin tomatophp/filament-accounts 5 first, then this package; publish assets to public/auth/build as a deployment artifact.
4. Port language strings to the package's language config with per-locale overrides (note the corrected phone label on register as an example of string-level drift you inherit).
5. Re-verify 2FA: guard name, account model, and continuity of existing secrets/challenge flows.
6. Register/confirm the viewAuthSetup gate and confirm setup pages 404/403 outside local.

Compatibility gates: PHP 8.2+, Laravel 12/13, Livewire 4 + Volt 1.10+, Filament 5, filament-accounts 5. Check each against the host's composer.json before committing to a sprint; the conflict is detected at dependency resolution, so a one-hour spike answers feasibility.

Sequencing: Upgrade Laravel → Livewire/Volt → Filament → filament-accounts → this package. Do auth last; it is the surface with the lowest tolerance for a partial state. Run it behind a feature flag or on a preview environment before touching production login routes.

Operational Impact

Maintenance: Expect two live support lines (v5 for Filament 5; 1.x on v3 for the older stack). That doubles the upgrade-watch surface and means the team must track which line receives security fixes. Published assets must be re-published on every upgrade; add it to the upgrade checklist or it will be forgotten.

Support: Auth is high-blast-radius user-facing surface. Expect tickets on setup-wizard access, 2FA challenge failures, and localized copy drift. The gate/env guard means the loudest failure mode (setup pages exposed in production) is opt-in rather than default — good, but it must be verified, not assumed.

Scaling: Negligible runtime cost — these are standard Livewire page renders on existing infrastructure, no new services, queues, or storage. The real scaling concern is organizational: more apps sharing one auth surface means a single bad release affects all of them.

Failure modes to instrument:

• Composer resolution failure from the devdojo/auth conflict (loud, safe).
• Missing/stale public/auth/build assets — degrades to system font, then to broken pages.
• 2FA challenge resolving the wrong guard/model — silent lockout.
• Livewire 4 breaking host components outside auth — misattributed to this package.
• Test suite behavior change from no longer replacing the host Blade Icons factory — suites that implicitly depended on the override may now assert differently.
• Setup gate left open in a shared staging environment.

Ramp-up: Low for developers already fluent in Filament panel conventions (roughly a day to read the config and language layers); moderate for the migration owner, who must understand both the incumbent and the replacement auth flows. Budget explicit time for the devdojo/auth cutover rehearsal and a rollback plan, since the two packages cannot coexist on one codebase.