Inertia Routes Laravel Package

Product Decisions This Supports

• Build vs. buy for form plumbing. This package owns the fiddly parts of form submission — per-call vs. configured visit options, reset semantics, callback ordering, and hydration defaults. Every release like this one reduces the code we'd otherwise re-implement (and re-debug) in an in-house composable per project.
• Roadmap sequencing. v4.5.6 is pure correctness: no new features, no deprecations, no breaking changes. That signals the API is settling around a stable surface, so we can commit to it in upcoming features rather than betting on a rewrite.
• Feature feasibility for "reset after success," draft flows, and multi-step forms. The clarified guarantees are directly design-enabling: onSuccess now receives the page, is awaited, and runs before resetOnSuccess clears the form. That unblocks UX such as "toast the submitted value," "seed an optimistic UI," or "chain a follow-up request from the success handler" — all previously fragile.
• Upgrade risk call. Bug-fix-only patch with no migrations. Decision is a routine dependency bump, not a project.
• Incident triage and support load. Several fixes address silent misbehavior: per-call options leaking into later submits, an extra onSuccess wrapper stacking on every submit (repeated resets, repeated callbacks), and caller-supplied option objects being mutated. These produce "it only breaks sometimes" QA tickets — worth checking against any open bug reports before we build workarounds.
• Scope decision on our own wrapper layer. Because onSuccess now composes (configured first, then per-call) instead of replacing, any internal wrapper that relied on override-to-suppress must be re-validated. That directly informs keep-wrapper vs. vendor-the-pattern.
• Dynamic/repeater form UI. The array-default fix for prefix-colliding field names (items vs. items_count) matters for repeater-style builders where names share stems.

When to Consider This Package

Adopt when:

• You're on Laravel with the matching client-side form composable (note: the API surface exercised here — form.post(), visitOptions, autoHydrate, data as a function — is front-end JavaScript, so the value is concentrated in Laravel + Inertia-style stacks, not server-side PHP alone).
• You have more than a handful of forms; the payoff compounds with form count.
• You need submit-time behaviors — reset on success, per-call headers, onError, preserveScroll — that otherwise get copy-pasted per component.
• Your forms hydrate from server data via a meta request and derive defaults from a function; those paths are first-class here.
• You'd rather depend on a maintained package than own an in-house composable's edge cases.

Look elsewhere or proceed with caution when:

• Your front end isn't the supported Inertia/Vue-style stack — a server-side Laravel validation/action package covers a different need and this won't replace it.
• You have two or three static forms; abstraction cost exceeds the payoff.
• You need hard guarantees on submission lifecycle ordering. The ordering behaviors (success-before-reset, awaited callbacks) are exactly what shifted in this release: pin the version and test the assertions.
• You require formal LTS or vendor support commitments; active patch cadence is evident, enterprise support is not.
• You're on an earlier 4.5.x and share option objects across calls — upgrade first, since per-call leakage and option mutation are fixed here.

How to Pitch It (Stakeholders)

To executives: A low-risk dependency update to our Laravel form-handling layer — bug fixes only, no breaking changes, no migration cost. It eliminates a recurring class of front-end defects (form options bleeding between submissions, resets firing repeatedly, success callbacks firing after the data is already cleared) that surface as inconsistent form behavior in QA and support. The package is versioned, actively maintained, and improving incrementally.

To engineering: v4.5.6 is a correctness release with three behavior changes to note. (1) Callback composition is now additive: visitOptions.onSuccess from the composable runs first, then the per-call handler — code relying on replacement must be updated. (2) onSuccess now receives page, is awaited, and runs before resetOnSuccess clears state, so success handlers can read submitted data. (3) Per-call options are isolated and caller-supplied option objects are no longer mutated. Also fixed: reset no longer stacks wrapper callbacks, reset snapshots no longer share nested arrays/objects with the live form, reset falls back to form defaults when no hydrated snapshot exists, and array defaults resolve correctly for prefix-colliding names. Action: bump the patch, then re-run tests that assert callback overwrite or depend on caller option-object mutation — those assumptions are now invalid. No API changes required.