Inconsistent basename behavior between Components and Middleware in Framework Mode

[KimotoYanke]

Hi.

My team is developing a project using Framework mode with a basename configured in the URL. We're running into an issue where basename is handled inconsistently depending on context.

Reproduction repository: https://github.com/KimotoYanke/react-router-basename-test (basename is set to /base/)

Current Behavior

In components, basename is handled automatically and transparently. For example, a <Link> or navigate() call targeting the login page can be written simply as /login, and React Router correctly resolves it to /base/login.

However, in middleware, throw redirect("/login") does not apply the basename — it redirects to /login instead of /base/login, resulting in a not-found error. As a workaround, we have to write throw redirect(joinURL(import.meta.env.BASE_URL, "login"))

Questions

1. Is this the intended behavior? In other words, is it by design that middleware does not automatically prepend basename to redirect paths?
2. Is there any plan to make middleware behavior consistent with component behavior regarding basename handling?

I'd appreciate any clarification. Thank you!

[aniruddhaadak80]

@KimotoYanke Your observation is reasonable: basename-aware URL generation in components and explicit middleware redirects are not always symmetrical by default.

A practical pattern is to centralize redirect URL creation (for example a helper that prefixes import.meta.env.BASE_URL), and use that helper consistently in middleware. That avoids drift between component routing and middleware behavior.

So yes, your workaround style is generally the right defensive approach until middleware basename behavior is unified.

Sources:

• https://reactrouter.com/start/framework/routing
• https://reactrouter.com/api/utils/redirect

[MILLERMARRU]

This is intended behavior, and it comes from redirect() and route resolution being two genuinely separate code paths, not from middleware specifically ignoring basename.

<Link>/navigate() go through the router's own path resolution, which is basename-aware: internally the router strips basename off the URL for matching and re-applies it whenever it turns a to prop into a real href. redirect(), on the other hand, is documented as a plain Response constructor: it takes whatever string you give it and puts it straight into the Location header. It has no access to the router instance, so it has no way to know what basename is configured. That's true whether the redirect() call happens in a loader, an action, or middleware, the asymmetry isn't middleware-specific, you'd see the same thing throwing a raw redirect("/login") from a loader with a basename set.

Given that, your joinURL(import.meta.env.BASE_URL, "login") workaround isn't really a workaround, it's the correct pattern: anywhere you construct a redirect() target by hand (as opposed to letting <Link>/navigate resolve it), you're responsible for prefixing basename yourself. The only thing I'd change is centralizing it instead of inlining joinURL(...) at each call site:

// app/lib/redirect-with-basename.ts
import { redirect } from "react-router";

export function redirectTo(path: string, init?: number | ResponseInit) {
  return redirect(`${import.meta.env.BASE_URL}${path}`, init);
}

and using redirectTo("/login") everywhere instead, so if basename ever changes there's exactly one place to touch. I wouldn't expect this to get "unified" with component behavior the way the discussion title hopes for. redirect() being basename-agnostic is what lets it behave identically whether it's called from a route with a basename configured or from a plain createMemoryRouter test harness with none. Unifying the two would mean redirect() needs a router instance to call, which would change its signature for everyone, not just you.

[latent-9]

This is by design rather than a bug. Client-side navigation (<Link>, navigate()) resolves paths through the router, so it applies basename for you. A redirect() from a loader, action, or middleware only returns a Response with a raw Location header, and the router forwards that value as-is without rewriting it, so the basename is not prepended.

So redirect targets have to include the base already. Your workaround is the idiomatic fix. Centralizing it in a small helper keeps it consistent:

const BASENAME = "/your-base"; // the same value you pass to the router

const withBase = (path: string) => `${BASENAME}${path}`;

throw redirect(withBase("/login"));

If you set basename from an env var, reuse that same variable here so the two never drift. Whether redirects should auto-apply basename is a maintainer call, but the current behavior is intentional.