The goal of this project?

[dai-shi]

I just noticed that providing reusable plugin is no longer the short term goal of this project.
I was hoping this project to provide vite specific solutions that our project can use.
dai-shi/waku#21

If it isn't happening some time soon. We would need to look for some solutions on our end.

[brillout]

From my side, this is still very much the goal of this project.

Although I haven't had the time to contribute. I think the bottleneck is precisley that: everyone is busy.

So any contribution is more than welcome.

[dai-shi]

https://github.com/cyco130/vite-rsc/tree/3877fb799dcdbaee11e1232cbdc1150e6bb8be19/packages
vite-rsc package looked promising as a building block, but it's gone.

https://github.com/cyco130/vite-rsc/tree/2e3d0ad9915e57c4b2eaa3ea24b46c1b477a4cce/packages
fully-react sounds like it's trying to be a full featured framework, rather than a vite plugin or package.

This project seems very active from the commit counts and changes. It looks like the goal is to become a reference implementation of RSC and so on.

[cyco130]

The situation is that, @nksaraf is into replicating everything that Next does with Vite. I haven't been able to contribute much after the initial start (I changed jobs and I moved from Istanbul to Lisbon, I haven't fully settled yet). But he found it easier to have everything in a package so he could move faster and it makes sense to me too. I'm still committed to extracting the reusable parts into a Vite plugin and a maybe a support library to go with it as soon as I find some free time. The plugin is still there, it's just not in its own package at the moment but it will be.

In summary, my goal is to have a generic Vite RSC plugin and a bunch of utilities to go with it. Nikhil is also interested in a full reference implementation, I'm less so. He has already forked this repo but we'll keep working together.

And of course I'd personally be delighted if you could help (or maybe lead) towards that goal.

[dai-shi]

Thanks for the updates. My problem is my understanding of vite plugins is limited. I think I need to play with something and learn more.

[nksaraf]

Yeah it's very much of a goal of mine. The only reason I put things together is I need to be able to build a package and try it outside the development repo. And can't have to too many moving parts. I think I'll probably split it out soon again after I figure out where the seams are. As I started adding routing and another worker got involved the earlier vite plug-in on its own wasn't enough. So I had to rediscover the seams. Getting close to that. My fork is so that I could experiment with my companies products in there. I will mostly be up streaming everything.

[dai-shi]

Looking forward to it!
As a note, what I need is to build module graph for client and server for both dev and prd. Given that, my focus would be rendering part for RSC, mutations, routing, SSR and state management integrations.

[nksaraf]

Yeah I think when all the parts get involved a more integrated solution is needed but I think there is a way to provide higher level helpers that you can integrate with. maybe a package like react-server-dom-vite

[nksaraf]

Looking forward to it!

As a note, what I need is to build module graph for client and server for both dev and prd. Given that, my focus would be rendering part for RSC, mutations, routing, SSR and state management integrations.

I have this working .. separate module graphs for client and server both dev and prod.. in dev it's a separate node Worker. In prod it's all in one after bundling.

[dai-shi]

For now, I'm using vite for client bundling (for both dev and prod). For server, react-server-dom-webpack is being used with hacks without bundling (no module graph analysis). So, react-server-dom-vite would be something I really need.

I have this working .. separate module graphs for client and server both dev and prod.. in dev it's a separate node Worker. In prod it's all in one after bundling.

Meanwhile, should I do the same in my repo too?

[nksaraf]

Yeah I would say that a big goal is to have the pieces so that vite based frameworks don't have to redo the pieces.. so for example rakkas, impala, vite-plugin-ssr each of them should be able to use those pieces without duplicating.