test(rsc): HMR e2e for a route component co-located with a server fn (canary for #7618 / vitejs/vite-plugin-react#1248)

[sreetamdas]

Description

Adds a dev-mode HMR e2e for a TanStack Start RSC route whose file co-locates a createServerFn with the route component, asserting the component Fast Refreshes on edit (and preserves local state).

This is intentionally opened as a draft / CI canary: the test fails on main today because it reproduces a real bug — editing such a route component emits only an (rsc) hmr update …?tss-serverfn-split with no client update, so the DOM never changes. It will go green once the upstream @vitejs/plugin-rsc fix lands and the dependency is bumped. So the PR's CI status is a direct signal for "is the issue resolved yet?".

• Bug + analysis: TanStack Start (RSC): route component does not HMR when its file has a co-located createServerFn #7618
• Standalone minimal repro: https://github.com/sreetamdas/tanstack-rsc-hmr-co-located-serverfn-repro
• Root cause + proposed upstream fix: fix(rsc): keep client HMR for client modules co-located with rsc-graph code vitejs/vite-plugin-react#1248 (the client hotUpdate guard returns [] for any file in the rsc graph that isn't a "use client" boundary — which wrongly catches a genuine client route component co-located with a server fn).

What's here

• e2e/react-start/rsc/src/routes/rsc-hmr-serverfn.tsx — fixture: createServerFn + route component (marker + counter) in one file.
• e2e/react-start/rsc/tests-hmr/rsc-hmr.spec.ts — edits the marker, asserts it updates and the counter survives (HMR, not reload).
• e2e/react-start/rsc/playwright.hmr.config.ts — a dev-mode Playwright lane (the existing rsc e2e runs the built/prod server, which can't exercise HMR), plus a test:e2e:hmr script.

Needs guidance
The new lane isn't wired into the nx/CI e2e matrix yet — HMR needs a dev server, and the existing dev-mode hmr e2e is non-RSC. Happy to integrate it wherever you'd prefer (extend the hmr suite to RSC, or register this as its own CI e2e project). Flagging since it won't run in CI as-is.

[coderabbitai]

Important

Review skipped

Draft detected.

Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Pro

Run ID: 64494c33-03c3-4cc9-aea7-48389c14b370

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

• 🔍 Trigger review

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[schiller-manuel]

hmr is notorously hard to test in CI, so please check out how the e2e/react-start/hmr ensures that CI env with low compute and high latencies still passes.. we might just create a new e2e/react-start/rsc-hmr project for this

would be best if you create multiple routes, one with css modules, one without any css, etc.
just to ensure a broad coverage of possible scenarios

also please configure this to run in both vite and rsbuild so we ensure both build tool adapters work as expected

[sreetamdas]

@schiller-manuel thank you for the response! I'll see how the test can be updated - in the meantime, I wanted to clarify that the real fix here is vitejs/vite-plugin-react#1248, this PR is really just to highlight the current breakage.

Once the fix is merged upstream, the idea is to see the test here turn green — hope that makes sense!

btw I checked locally on the rsbuild setup, and rsbuild doesn't seem to have this issue