Remember Query Strings Laravel Package

Getting Started

This package is a small helper for controlling redirects after a request — most likely a middleware or trait that decides whether the response should be redirected (e.g. back to a form) or passed through untouched.

Minimal setup:

1. Install it with composer require and check composer.json for the supported Laravel/PHP versions — at v0.1.x expect tight coupling to recent Laravel releases.
2. Look first at the package's service provider (src/*ServiceProvider.php) to see whether the behaviour is auto-registered or must be opted into. At this version, assume nothing is automatic.
3. Read the middleware/trait class itself — it is likely under 100 lines, and the whole contract is visible there. Pay attention to where it reads session()->get('errors') and where it returns a RedirectResponse.
4. Register the middleware in app/Http/Kernel.php (or bootstrap/app.php on Laravel 11+) in the web group, after StartSession and ShareErrorsFromSession, since the new behaviour depends on the error bag being populated.
5. First use case: a controller that validates input and returns back()->withErrors($validator). With v0.1.2 the package leaves that response alone instead of hijacking it with its own redirect.

If you are upgrading from v0.1.0/v0.1.1, the only change is the guard on session errors — no API changes, no config changes.

Implementation Patterns

Validation-first controllers. The intended workflow is: validate, and let failures reach the session error bag. The package now checks $errors->any() (or the session's errors key) before redirecting, so a failed FormRequest produces the normal 302-back-with-errors instead of a package-driven redirect that would discard them.

Middleware placement matters. Because the guard reads the session, the middleware must run after the session is started and after the error bag is shared. In the web group, append it rather than prepend it. If you register it as global middleware, the session may not be available yet and the error check will always evaluate false — meaning it redirects as it did pre-v0.1.2.

Defensive controller returns. For endpoints that mix successful and failing paths, keep returning the validator explicitly:

$request->validate([...]); // throws ValidationException on failure

return redirect()->route('dashboard.index');

The package should now stay out of the way of the first path and act only on the second.

Testing the guard. In feature tests, assert both branches: a request with no errors yields the package's redirect, and a request that fails validation yields a redirect back with assertSessionHasErrors() plus assertRedirect() to the previous URL — not to the package's destination. This is the regression the release fixes, so pin it with a test.

Integration tip. If you compose the package with Inertia, remember Inertia converts validation errors into a 303 back-response automatically. Since the package now declines to redirect when errors exist, Inertia's own handling wins — verify you are not double-redirecting.

Gotchas and Tips

• The error check is a behaviour change, not a bug fix you can ignore. Any test asserting "always redirects" will break. Audit tests that assert a redirect without also asserting session state.
• $errors may be an empty ViewErrorBag rather than null. A guard written as if (session()->has('errors')) would fire even when the bag is empty. If you are extending or overriding the class, check $errors->any() instead, and confirm which form the upstream implementation uses.
• The default error bag. Errors flashed under a named bag (errors->contactform) still populate the shared bag, but if the package inspects a specific bag name it may miss them. Test with a named bag if you use $request->validateWithBag().
• API/JSON requests are a separate path. The session guard is only meaningful for web requests. If the middleware is applied broadly, confirm expectsJson() requests aren't redirected at all — a JSON client receiving a 302 to an HTML page is a classic debugging trap.
• Debugging: Log::info(session()->get('errors')) at the top of the middleware is the fastest way to see whether the guard is evaluated against a populated bag. A null here almost always means the middleware is running before StartSession.
• Version pinning. At v0.1.x, pin to ^0.1.2 rather than ^0.1 if you depend on the new guard — 0.1.0 and 0.1.1 will still redirect over validation errors.
• Extension point: if the redirect target or the error-check condition needs to vary per route, prefer wrapping the call in your own middleware that delegates to the package, rather than editing the package's class — there is no published config at this version, so anything you customise lives in vendor/ until upstream exposes it.