fix(rsc): fix server css hmr with cssLinkPrecedence: false

[jantimon]

I saw a bug in CSS HMR when trying out RSC in Tan Stack start https://tanstack.com/blog/react-server-components

Actually I wanted to see if RSC works well in TanStack and allows the css of next-yak static css-in-js plugin to be hot reloaded: DigitecGalaxus/next-yak#529

It seems that a server component whose module lives only in the rsc Vite environment (not in the client bundle) is rendered through a nested RSC Flight stream.

What the bug does

Editing a CSS file that is only imported from a Server Component rendered through a nested RSC Flight stream does not reliably update the page. The first edit in a dev session often appears to work (via a Vite side-effect), but any subsequent edit in the same session is silently ignored. So every HMR message after that sits behind a hung promise on the client. Users see the page stuck on edit‑1 CSS until a full page reload or dev-server restart.

Scope / who is affected

• Frameworks that set cssLinkPrecedence: false e.g TanStack Start.
• Frameworks that render RSC through nested Flight streams (createServerFn + renderServerComponent, etc.).
• The default path (cssLinkPrecedence: true, React 19 Float-managed) is unaffected — the fix is narrowly gated so it does not change that path.

The three-part fix (in plugin-rsc/src/plugin.ts)

1. Invalidate the derived CSS virtual in hotUpdate (rsc env). Walk the importer chain from the changed CSS and invalidate only the \0virtual:vite-rsc/css?type=rsc&… modules. JS importers (inner.tsx, server.tsx, root.tsx) are intentionally left untouched to avoid regressing the Float-managed default path
2. Cache-bust the emitted <link href> in collectCss. Only when cssLinkPrecedence: false and the consumer isn't already client, append ?t=<lastHMRTimestamp>. The default Float path stays bare-href so Vite's in-place <link> swap keeps working
3. Skip Vite client CSS HMR for RSC-only CSS in the client env's hotUpdate. When cssLinkPrecedence: false and the changed CSS has no client-side JS importer, return []. This is what prevents Vite's Promise.all from hanging on a React-owned <link> that gets unmounted mid-swap.. and that hang was the reason only the first edit ever appeared to work

[hi-ogawa]

Hey thanks for digging.
Is this reproducible only with cssLinkPrecedence: false? That's added for tanstack for their need as experimental so we don't test on our side nor haven't properly reviewed how it works. cc @schiller-manuel

Also, if you have a fix, please feel free to push here to verify the fix.

[jantimon]

This pr fixes the bug in vite-plugin-react rsc for cssLinkPrecedence: false:

vite-hmr.mp4

However it introduces a new issue for the tanstack integration where we will need the help of @schiller-manuel to find the best approach. The problem is that it does not fix the removal of css props as old css styles now stay in DOM because of the cache busting ?t=...

[pkg-pr-new]

Open in StackBlitz

npm i https://pkg.pr.new/@vitejs/plugin-react@1188

npm i https://pkg.pr.new/@vitejs/plugin-rsc@1188

npm i https://pkg.pr.new/@vitejs/plugin-react-swc@1188

commit: 380f3cb

[hi-ogawa]

I should've triggered this sooner, but the preview release is available in #1188 (comment) Please test it out with tasntack router integration.

I get the idea of changes, but need more time to review. Also will push some changes to test some ideas.

[hi-ogawa]

This looks similar to what we had before moving to addWatchFile in rsc:css-virtual #847.

vite-plugin-react/packages/plugin-rsc/src/plugin.ts

Lines 2446 to 2449 in a7b26f5

	// invalidate virtual module on js file changes to reflect added/deleted css import
	for (const file of [mod.file, ...result.visitedFiles]) {
	this.addWatchFile(file)
	}

This logic can be naturally subsumed there by adding collected to visitedFiles. Currently missing but it seems like that was an oversight.

[hi-ogawa]

Oops, relying on addWatchFile broke the CI ba6c1c2

[hi-ogawa]

So, we can drive css swap only for non float case, but the same technique won't be applicable for float case?

Based on my previous comment, it looks like float css would keep appending instead of swapping but not sure if I verified that properly and I might have confused with Vite side css behavior.

[hi-ogawa]

it looks like float css would keep appending instead of swapping

Okay, I think I verified locally just in case. I feel like this means that we've been relying on somewhat not-so-well-defined behavior of float css not re-inserting the original css that get removed by vite.

Probably had the same conclusion when I was writing that comment, but just iterating for the record. Will probably polish the comment accordinglly.

[hi-ogawa]

Thanks for PR and analysis! Merging.