Release v0.5.104 · teylabs/kit

Run kit:update plan|apply for core (re-pinned sha256:b293e91e…74f4 → sha256:174d42c2…a230) and session-ui (sha256:19cdf4c2…a360 → sha256:561e7a1d…8854): Kit/Form/PasswordInput.vue follows its form's reset, and Auth/Login, Auth/ForgotPassword, Auth/ResetPassword, Auth/ConfirmPassword and Auth/VerifyEmail take the two fixes below.

A rate-limited auth submit no longer opens Inertia's error modal. The guest auth pages handed their 429 handler to <Form> as @http-exception, but <Form> before Inertia 3.8 has no onHttpException prop: the listener was never called, so Laravel's 429 page (from throttle:) still opened in Inertia's modal. The pages now pass it as the visit option (:options="{ onHttpException }"), which every Inertia 3 <Form> honours, and the in-card "Too many requests" alert shows. The browser checks now run these pages on the real @inertiajs/vue3 (3.7.1) and shadcn-vue Input, answering each submit with Laravel's 429 HTML or an Inertia response with errors.
A failed sign-in, reset or confirmation really clears the password. reset-on-error resets the input in the DOM only, and PasswordInput kept its own value, so the next re-render (showing the password, an error appearing) wrote the old password back. The pages now hold their password fields (v-model) and clear them on an error or a 429, and PasswordInput follows its form's reset event (a native reset, or Inertia's whole-form reset), so a host form's reset clears it too.

What's Changed

Keep a 429 out of Inertia's modal and clear auth passwords for real (0.5.x) by @jaspertey in #477
Release v0.5.104 by @jaspertey in #481

Full Changelog: v0.5.103...v0.5.104