Breeze Svelte Laravel Package

Product Decisions This Supports

• Auth as a checkbox, not a differentiator. This package delivers Laravel Breeze's baseline auth flow (register, login, password reset, email verification, profile update) with Svelte components on Tailwind. For products where authentication is table stakes, it lets the team skip 1–2 sprints of plumbing and spend that scope on the differentiating feature.
• Stack commitment: Laravel + Inertia + Svelte. It is only relevant if Svelte is already the chosen frontend. It is a concrete enabler for that choice — without a Breeze Svelte stack, teams either hand-roll scaffolding or default to React/Vue for convenience. This is a "keep the stack we want" decision, not a net-new capability.
• Build vs. buy (vs. fork). The honest framing is build vs. copy: MIT license, ~a handful of Svelte pages and Laravel auth controllers. The rational move is to vendor the code into the repo on day one and treat it as a starter template, not a dependency. That converts an ongoing maintenance liability into a one-time, bounded adoption cost. v1.2.0 reinforces this: the repo is a mirror of upstream Breeze with the Svelte stack added, so the deliverable is a snapshot, not a service.
• Roadmap sequencing for MVP / internal tools. Appropriate for prototype → validation phases, internal dashboards, admin back offices, and hackathon-style builds where speed to a demo outweighs long-term dependency hygiene.
• Reference implementation. Even if not adopted, it is a useful worked example of what Breeze scaffolding looks like outside the officially supported stacks — useful input to a "do we fork Breeze or write our own?" spike. v1.2.0 makes this role sharper: the maintainer now keeps Blade and Vue alongside Svelte specifically to track upstream UI and JavaScript changes, which is the sync mechanism a hand-rolled fork would have to reinvent.
• Scope narrowing as a signal. v1.2.0 removes the API and React stacks. Two decisions follow: the decoupled-SPA path is no longer available from this package (go to first-party Breeze for that), and the surface you vendor shrinks — less code to own, less to keep in sync, fewer places for the mirror to drift. For a "copy it and own it" artifact, a smaller package is a better package.
• Vendor-risk precedent. Zero dependents, a single maintainer, and a release history with a multi-year gap ending in a small dependency-trimming release make this a useful data point in establishing the team's adoption bar for community packages (e.g., "no unvendored dependency without a release in 12 months"). The decision this supports may be "adopt the pattern, not the package."

When to Consider This Package

Consider it when:

• The team has committed to Laravel + Inertia + Svelte and wants Breeze's conventional auth structure rather than a bespoke one.
• Requirements are limited to standard email/password auth, verification, reset, and profile management — no SSO, MFA, passkeys, social login, roles, or multi-tenancy.
• The product is short-lived, internal, or pre-validation, where the cost of a stale scaffold is low and the cost of delay is high.
• You are willing to fork/vendor the code (MIT permits it) and own it — which is the sensible default here, and is now cheaper given the reduced surface area in v1.2.0.
• You need a fast reference for how Breeze translates to a Svelte stack before committing engineering time, or you want a working example of how to keep a Breeze fork in sync with upstream.

Look elsewhere when:

• You need capabilities beyond baseline auth: Laravel Fortify (headless, MFA, passkeys) or Jetstream (teams, 2FA, profile management) are the maintained first-party paths.
• The architecture is a decoupled SvelteKit SPA against a Laravel API — use first-party Breeze's API stack with Sanctum, or Fortify. This package no longer ships the API stack as of v1.2.0, so this route is now explicitly out of scope rather than merely discouraged.
• You want an officially supported frontend stack — Breeze ships Blade, React, and Vue. Choosing React or Vue buys a maintained, documented path at the cost of stack preference. (Note: v1.2.0 dropped React from this repo, so if React is the fallback plan, it comes from Breeze directly.)
• The product is long-lived and customer-facing with a security posture to defend: zero dependents and a single maintainer mean no patch cadence, no CVE response path, and no issue SLA. A single v1.2.0 after a long dormancy is evidence of a maintainer, not evidence of a cadence — that remains disqualifying for an unvendored dependency in anything with a compliance obligation (SOC 2, HIPAA, PCI).
• You need social login or enterprise identity — Socialite, WorkOS, Auth0, or Clerk are the correct layer, and this package adds nothing there.

How to Pitch It (Stakeholders)

For executives — the one-paragraph version: This is a free, MIT-licensed starter kit that gives a Laravel + Svelte application its login, registration, password reset, and email verification screens out of the box. It removes roughly one to two sprints of undifferentiated work from an MVP and lets the team spend that time on the product. The risk is deliberately small: the code is small enough to copy into our repository and own outright, so we are not betting on a third party to maintain it. The recent v1.2.0 release trimmed unused stacks, which makes the thing we'd copy smaller and easier to own — but it is also the first release in a long while, so read it as a maintainer tidying a project, not as a project picking up momentum. Recommended use is as scaffolding at project start — not as a long-term dependency.

For engineering — the honest caveats: Zero dependents, single maintainer. v1.2.0 is a maintenance release: it deletes the API and React stacks to make upstream syncing tractable, and keeps Blade and Vue purely as canaries for UI and JS changes upstream. Nothing in the auth flow changed, so there is no breaking change for anyone using the Svelte stack — but if you had planned on the API or React routes from this repo, they are gone; get those from first-party Breeze. Treat it as starter code, not infrastructure. Vendor it, pin it, and expect to own every future change. If the roadmap includes MFA, SSO, passkeys, or team management, skip this and start on Fortify or Jetstream — retrofitting those onto a community scaffold costs more than starting correctly. Because Breeze's conventions are standard, migrating later is a contained refactor of the auth controllers and Svelte pages, not an architectural change — the exit cost is real but bounded, and that is what makes the trade acceptable at MVP stage.