vinxi: "use server" chunks are duplicated in build

Okay 😃. I tried to write a proof-of-concept PR for solid-start, adding id and name to the request context and exporting a getRpcInfo helper function from @solid/start/server.

I don’t know why, but using getRequestEvent in @solid/start/server breaks the vite dev server, it crashes with no useful error message. vite build on the other hand works fine, with a warning that makes zero sense to me 😂: "getRpcInfo" is imported from external module "h3" but never used in "node_modules/.pnpm/vinxi@0.0.61/node_modules/vinxi/runtime/server.js"

I created a WIP PR in solid-start anyways and would love your feedback -> https://github.com/solidjs/solid-start/pull/1203

This doesn’t even need to be vinxi level. This createServerReference is created by solid-start, vinxi is runtime independent. createServerReference can expose anything it wants. and you can also create the url system you want. Vinxi does come with a default createServerReference, but its meant to be overriden with your own specific one.

I agree the duplication and execution is not ideal.

I think this is a nice hack. globalThis is actually your best bet for truly deduped instances of things. Because both HMR and different builds can be fixed with that.

it is meant to be, so if it doesn’t probably a bug, probably need to optimizeDeps.exclude those dependencies that might have use server in them

Feel free to write up any ideas you have here, or questions about the current process.

I would do it regardless, if I can find a safe, not too much slower way of doing it, I agree that its worth pursuing, just not top priority right now.

actually the assumptions one should make while writing a Vinxi app (or apps designed for the serverless world) is that the JS global namespace is not as meaningful. Most like everything is running on different instances. This could later be scaled to different routes on different serverless functions, or ssr/server-functions on different lambda functions.

To make room for these optimizations later, I want people to break the impression that they should assume that there is some identity of these functions as a normal JS functions. For both the server and the client, you should treat as special remote code.

But regardless, yesss always looking for help in coming up with better bundling strategies. I will probably to have to write about the current strategy then.

Yeah there are some of these inefficiencies in the bundling right now but that’s because I have kept correctness the priority. Its there in someRoute because it could be called from the Component itself, so its part of that server’s bundle. It’s part of node-server.mjs because it can be called from the internet as well as a server function request.

Right now the way the builds work, the individual parts of the app ((ssr + server functions)) are built first (thus can have duplicated parts). Then the main server build takes the output of the individual parts and bundles them together. By that time its usually too late to dedupe.

We will work on better bundling strategies, but for now this is a decent compromise for the simplicity in the build process it enables. And since the output is for the server, the effect’s usually not that large because the library code is not duplicated.