Turbine Ui Core Laravel Package

Product Decisions This Supports

• Build vs. buy for auth/profile UI scaffolding. The package owns the Breeze-compatible profile views and publish templates. That is exactly the kind of low-differentiation surface where maintaining an in-house fork costs more than it returns. This release reinforces the "buy/consume" side of that decision by keeping the scaffolding on a current framework baseline.
• Framework upgrade roadmap. Laravel 13 support is a roadmap unblocker: teams that pinned this package as the reason to defer a framework upgrade can now fold both into the same planning cycle. Treat "does the dependency support L13?" as a resolved gate rather than an open risk.
• Release/deploy process hardening. Moving publish templates into stubs so production view caching works cleanly is an operational fix, not a cosmetic one. It means php artisan view:cache can be enabled in the build pipeline without the published-view path breaking — a deploy-time reliability decision that previously had to be worked around or skipped.
• Feature scope for profile/account self-service. Confirms the package as the right home for profile edit flows in Breeze-based apps; new profile work should be scoped as configuration and view overrides rather than new internal components.
• Vendor-risk tracking. A release that lands both framework-version support and a production-path fix in one minor bump is a positive maintenance signal — useful input when scoring this dependency against alternatives in a build-vs-buy or dependency-review pass.

When to Consider This Package

Adopt when:

• The app is on Laravel and already uses (or plans to use) Breeze conventions for auth/profile screens, so the templates drop into an existing structure rather than introducing a second design language.
• You are planning or actively executing a Laravel upgrade and need dependencies that will not block you at the framework-version boundary.
• You serve production traffic and want view:cache enabled in your deploy pipeline — the stub change is the specific reason this package no longer fights that.
• You want profile screens maintained by an upstream package rather than by your own team, and the customization you need is view-level, not domain-level.

Look elsewhere when:

• The front end is Jetstream, Filament, Inertia/React or Vue, or a bespoke design system — the published Breeze-shaped templates are the wrong starting point and you would be rewriting them immediately.
• You need profile/identity behavior beyond presentation: SSO/SAML, multi-tenant identity switching, complex RBAC, audit requirements, or account-deletion/compliance workflows. Those belong in a dedicated identity solution, not a view-scaffolding package.
• Your policy requires documented long-term support windows or a formal security disclosure process that a small package cannot evidence.
• You have already heavily customized the previously published templates. The move to stubs changes where the templates live; if you have local edits to published views, plan a reconciliation step rather than a blind update.

Migration note to raise before upgrading: because publish templates moved into stubs, anyone who previously published and then edited those views should diff their published copies against the new stubs and confirm the deploy pipeline still resolves the correct view path. Confirm the changelog calls this out as a deliberate relocation; if not, treat it as a potential minor-break for customized installs and verify in a staging build before rollout.

How to Pitch It (Stakeholders)

For executives (one paragraph): This is a routine, low-risk maintenance release for a small UI-scaffolding dependency that provides our account and profile screens. It does two things that matter to us commercially: it keeps us able to upgrade our framework on schedule instead of being held back by a lagging dependency, and it fixes a production deployment constraint so we can turn on a standard performance optimization we had been leaving off. There is no new surface area to staff or support, and the upgrade is contained to a version bump plus a short verification pass. Recommended action: approve the upgrade in the next maintenance window.

For engineering leads: Two changes to plan around. First, Laravel 13 is now supported — fold this into the upgrade track and re-run your compatibility matrix rather than tracking it as an open blocker. Second, publish templates are now shipped as stubs so that view caching works in production; that is the win, but it means the publish path changed. Before merging, check for locally modified published views, re-publish or diff as needed, and add a view:cache step to CI so the fix is actually realized rather than just available. Verify in a staging deploy that cached views render correctly, including the profile screens.

For the product/design side: No user-facing changes. Profile screens look and behave as they do today; this release is about where the source templates live and which framework versions we can run. Any in-flight design work on account screens is unaffected.