Vite RSC support feedback

[hi-ogawa]

Important

@hiogawa/vite-rsc is now maintained as Vite's official package @vitejs/plugin-rsc. Please provide further feedback on the new repository.

Please read https://github.com/hi-ogawa/vite-plugins/tree/main/packages/rsc for the documentation.

• Roadmap #1108

Goals

This package @hiogawa/vite-rsc explores the desired RSC API surface on Vite. It starts as a plugin, but if we find features required at core level, then we will provide a feedback to Vite and implement it.

Note for framework authors

I would appreciate any feedback, especially for following points:

• plugin API usability
  • is the provided API general enough?
  • does plugin's implicit inner working break some expectation? (e.g. builder.sharedPlugins: true and builder.buildApp)
• react-server-dom API and manifest integration
  • do you have a different react-server-dom API usages than shown in ./examples/starter/src/framework?
• css features / bugs
  • is the concept/abstraction usable? (code splitting at client boundary + import.meta.viteRsc.loadCss helper)
  • is there any edge case to be aware of?
• hmr features / bugs
  • is there any edge case to be aware of?

Regarding the issues of complicated "use client" usages inside node_modules (as in https://github.com/hi-ogawa/rsc-tests), this is a known issue and I'm not seeking a complete solution at this point. However the simple case (such as "use client" written at the top of main package entry of react-server) is expected to work.

Note on react-server-dom-vite

Currently this package bundles [email protected] and the downstream project can install only @hiogawa/vite-rsc (see also #968). The point is that I couldn't find a way to design react-server-dom-vite so that it makes something not possible on react-server-dom-webpack to be possible on react-server-dom-vite and vice versa.

However, bundling specific build of react-server-dom is not ideal as it prevents, for example, swapping dependencies with experimental channel, so I will likely switch it to unbundle it at @hiogawa/vite-rsc level #945.

Through the (short) conversation on react-server-dom-vite PR facebook/react#33152, I think React team seems generally welcoming whatever needed for Vite, but they don't of course have Vite-specific knowledge and don't provide particular technical insights for us. The expectation and responsibility on bundler/framework side are still to fully understand react-server-dom API surfaces on our own. Given this, for the time being I hold off trying to land react-server-dom-vite in React repo. Instead, I'll publish react-server-dom-vite from my fork (see #946) and iterate anything we need there without involving React team.

[pawelblaszczyk5]

Hello 👋

Not having too much feedback yet (just starting out building some stuff based on this, so I'll gladly provide some feedback soon(ish)). Mostly wanted to say - huge, huge, huge thank you for all the work. I've already built some internal stuff with RSC but it was mostly experimental due to how inconvenient it was to build with "raw" react-server-dom-webpack. Integrations like Parcel one is a game changer, but I love Vite so I wasn't fully satisfied haha. Can't thank enough on how much I appreciate the work here to make RSC more available to developers.

The API and abstractions look really good at first glance and while I started playing it felt similarly to Parcel RSC integration. It's at the same time - pretty easy to start and if someone knows basics about RSC it feels similarly to just using plain Vite, and pretty powerful and allowing for e.g. building frameworks on top (what I'm a bit going to do 😄).

One thing that I immediately see super useful, the switching to canary/experimental that you mentioned as not yet possible. Stuff like ViewTransition, Activity for prefetching and/or BFCache in RSC world, the improved debugging capabilities with performance tracks are really good when building on top of RSC.

Also wondering - the thing that was discussed briefly at React PR - the Vite client-side manifest being sent with the entry - do you think it's something possible to overcome with current Vite architecture, or something not worth the hassle/not possible? While I don't think it's a huge pain - I'm mostly wondering about limitations/architecture and I a bit like the thing that Sebastian mentioned in your React PR (harder to find stuff that's not yet publicly available by malicious users).

[hi-ogawa]

Thanks for getting into so fast and providing the feedback!

One thing that I immediately see super useful, the switching to canary/experimental that you mentioned as not yet possible. Stuff like ViewTransition, Activity for prefetching and/or BFCache in RSC world, the improved debugging capabilities with performance tracks are really good when building on top of RSC.

That's good to know! I'm not entirely sure how I go about this yet, but for now, you can try the pkg.pr.new package published on #961.

Also wondering - the thing that was discussed briefly at React PR - the Vite client-side manifest being sent with the entry - do you think it's something possible to overcome with current Vite architecture, or something not worth the hassle/not possible?

Yes, this is possible (even on react-server-dom-webpack 😄). I haven't included it yet but it's basically here #891. This change shouldn't affect any API surface and only a bundler level internal change. As written in the PR description, while it makes sense for browser usage, I found that applying the same principle for server build can be quite limiting and unexpected for downstream usages (and not applying the same for the server feels odd asymmetry), so that's one reason I'm holding it off.

[pawelblaszczyk5]

Yes, this is possible (even on react-server-dom-webpack 😄). I haven't included it yet but it's basically here #891.

Oh, that's nice to hear - completely missed this PR while observing your work here, thanks a lot.

Also out of curiosity about your perspective - do you think there's a scenario in the future where trying to land react-server-dom-vite makes sense? Does the future bundled mode with Rolldown changes the equation here?

[dai-shi]

Looks promising. Our goal is to keep all Waku capabilities while delegating vite related things to this package.

[hi-ogawa]

I've moved the plugin to https://github.com/vitejs/vite-plugin-react/tree/main/packages/plugin-rsc and it's now published as @vitejs/pluginrsc. Please provide feedback on the new repository. Thanks!