react-router

Adds so a tab that's been open across a deploy notices it's talking to a newer server. Discussion: #15517. Draft because I'm not sure the flag belongs where I put it; the "Things I'm unsure about" section says why. The gap Route discovery compares build versions, but only when it fetches the manifest, and it skips that fetch for paths the tab already knows: So: tab opens, we deploy, user clicks a link to a route they've already visited. The tab fetches from the new server and hands it to old components. Nothing compared anything. That bit us when a loader field got renamed. The API kept both names for a release, but our zod schema on the new server dropped the old one, and tabs that had been sitting open threw on . RSC doesn't have this problem — has compared the build version on every data fetch since #15318. What I did stamps when the flag is on. The client compares it on arrival and hands off to . That function already reloads the document and carries the guard against reload loops. I put the comparison after the redirect branches, matching what RSC does. Get that wrong and an action redirect reloads the URL you're leaving instead of the one you're going to. I had it backwards in the first pass. With the flag off the server sends no header and the client has nothing to compare. The new parameter on is optional, so existing callers are unaffected. It's also forced off in dev, where the manifest version changes every time you edit a route's exports; leaving it on there turns every HMR edit into a full reload. It's opt-in because reloading the document throws away whatever's half-typed in a form. And if you keep old builds addressable, you never hit the skew at all. Things I'm unsure about The flag lives in , and that's the part I'd most like you to weigh in on. Putting it there meant making the framework's extend the router's. That relationship was already implicit — the framework passes its future object straight into — but nobody had written it down, and I'd rather you decide whether writing it down is right. ended up as a top-level option instead, so there's precedent for the other shape. The header name is the other thing. Everything else in single fetch is . I didn't want to add to a prefix you're presumably moving away from, but starts a second family, and I don't know which of those you'd rather live with. I also put the version in a header rather than the payload, where RSC puts it. Prerendered files are written from the response body, so a version baked into that body freezes at build time and mismatches forever after the next deploy. A header isn't written into the prerendered file at all, so the client finds nothing to compare and detection stays off, which is the right failure for a static file. Testing covers four cases: a response from a different build reloads the document, matching versions don't, an action redirect lands on its target, and no header goes out with the flag off. I checked the first and third by deleting the version comparison, then the redirect ordering; each test fails on its own deletion. The other two pin the flag-off path, where there's no code to delete. and still pass — 97 tests across the two. Change files are in both and .