SolidJS•3w ago

vxini seems to be packaging and shipping all server code to the client

I'm trying to upgrade from solid-start 0.3.11 to the latest @solidjs/start. My smallest page load went from 1MB to 63MB. Under the browser's source tab, I can see that vinxi dev seams to be sending every JavaScript file in my project, probably even code accessed only from "use server" functions (although I can't be 100% sure yet). I understand I should wrap code in isServer conditions which, prior, I only used when necessary and I'm confused why there is such big change to cause so much code to load. This is all in one page load as well. Adding more isServer functions for tree-shaking will be a lot of changes, I would like to know a bit about what is going on first and make sure I'm doing everything I can using app.config.js. The first thing that raised a red flag was all the rollup warnings about externalizing many node packages which mostly went away when I added rollupOptions.external: [/^node:/] .. How did solid-start 0.3.11 know not to import all of the node packages without this external pattern? Is there something I can do or something I can disable to get things running more like solid-start 0.3.11 so I can slowly transition into more of a isServer tree-shaking approach? It seams that 0.3.11 was doing a better job, although I'm sure there are good reasons for changing this. But with 0.3.11 I never encountered any issues with missing client-side code. Thank you for any insight that would help me better navigate how to tackle this one!

25 Replies

peerreynders•3w ago

Are you by any chance using "use server" at the top level of a module?

slim (jamesc)OP•3w ago

peerreynders•3w ago

In any case: The organization style that seems to work best for bundling: - just keep server code in purely server side modules, e.g. server.ts - keep your querys and actions in a client side module, e.g. client-api.ts. querys and actions wrap a function with "use server" and the code under that only references dependencies imported from server.ts, etc

slim (jamesc)OP•3w ago

What do you mean by module? I have linked libraries that are used by other server processes but have code (like runtime type checking) that is imported and needed on the client as well. module = package.json?

peerreynders•3w ago

https://developer.mozilla.org/en-US/docs/Web/JavaScript/Guide/Modules

MDN Web Docs

JavaScript modules - JavaScript | MDN

This guide gives you all you need to get started with JavaScript module syntax.

peerreynders•3w ago

Example: - client side module api.ts. 'use server' only occurs inside the function wrapped by query or action while the code under it only uses dependencies imported from pure server modules like repo.ts, session.ts.

that is imported and needed on the client as well.

Packages would typically publish separate server and client modules unless the code can universally run on any javascript runtime.

slim (jamesc)OP•3w ago

I used server folders to help with this. I have not yet found a way to mark an entire folder server-only though. That is more of a safe-guard.. So, under no circumstances the client should package something from server/** .. that would be nice

peerreynders•3w ago

In terms of a mental model: "use server" appears in client code and is replaced with an RPC call to the server. So the code under "use server" is server code but it's gone after it has been replaced with the RPC call. At that point it is incredibly easy for the bundler to eliminate the server-only imports leaving only a client side module with RPC calls. Now if you accidentally reference that server dependency in a client module but without "use server" that import won't be tree shaken and will cause all sorts of problems. In general I don't think isServer is actually used that often. It's typically useful when you need to do things differently during SSR vs CSR.

rollupOptions.external: [/^node:/]

That just tells the bundler that it is not responsible for importing those dependencies-the client code will still depend on those dependencies.

bigmistqke•3w ago

Question remains tho why solidjs/start@latest is bundling server code that solid-start 0.3.11 was turning into an rpc call. Did something change on the api side from 0.3.11 to >1.0.0 regarding how "use server" functions should be consumed?

peerreynders•3w ago

0.3.x didn't support "use server"

bigmistqke•3w ago

O, it was with the hook still?

peerreynders•3w ago

https://github.com/solidjs/solid-start/blob/0.3.x/docs/api/server.md

GitHub

solid-start/docs/api/server.md at 0.3.x · solidjs/solid-start

SolidStart, the Solid app framework. Contribute to solidjs/solid-start development by creating an account on GitHub.

slim (jamesc)OP•3w ago

Yes, when I started and 0.3.11, createServerData$(()=> {/*server code*/}) worked.. Looks like the shortened the name. I simply replaced those with a server function passed to createResource so it would all work the same. Without looking under the hood, it does not seam to change any dependancies on the imports. I wonder if Ryan came up with something generic to handle things but, since generic may fall short, this changed.

peerreynders•3w ago

That has been entirely replaced with the @solidjs/router's Data API. And with Solid 2.x createAsync will move from @solidjds/router to core and createResource becomes a legacy “solid-primitives” package.

createAsync - SolidDocs

Documentation for SolidJS, the signals-powered UI framework

bigmistqke•3w ago

Aa yes seems like so long ago rn... Do you know mb about a migration guide from the hooks to the directives?

peerreynders•3w ago

If there was one I'm not aware of it. When I “migrated” this I started with basic and moved things over bit by bit. I remember some support posts where It took a while to hunt down every last bit of pre-0.4.x code that was dragging server code into the client.

GitHub

GitHub - peerreynders/solid-start-notes-basic at f13872d001dc1680f8...

Basic client rendered notes app using SolidStart beta - GitHub - peerreynders/solid-start-notes-basic at f13872d001dc1680f84330337ac61c0fbe1db1e3

GitHub

solid-start/examples/basic at main · solidjs/solid-start

SolidStart, the Solid app framework. Contribute to solidjs/solid-start development by creating an account on GitHub.

Hussein•2w ago

// server.ts
"use server"

export const _getData = async () => {
  return { hello: "world" };
};

// index.ts
import { query } from "@solidjs/router";

export const getData = query(_getData, "data");

// server.ts
"use server"

export const _getData = async () => {
  return { hello: "world" };
};

// index.ts
import { query } from "@solidjs/router";

export const getData = query(_getData, "data");

basically, something like this server.ts only runs on the server, index.ts runs everywhere you need to force every function to be async so it works with createAsync then you use your getData with createAsync

peerreynders•2w ago

People seem to get themselves into bundling trouble with top level "use server". Seems this is less problematic:

// client-api.ts
import { something } from './server.ts';

export const getData = query(async () => {
  'use server';
  return something();
}, 'data');

// client-api.ts
import { something } from './server.ts';

export const getData = query(async () => {
  'use server';
  return something();
}, 'data');

slim (jamesc)OP•2w ago

Shouldn't "use server" work instead to tell the bundler that it is not responsible for importing? I have it issolated to one function call into another class that has "use server" in the destination function. I was hoping that "use server" would stop the "transforming" process from processing that file and generating warnings. I still see the warnings though.

peerreynders•2w ago

I'm not aware of the exact details but I treat "use server" as a marker for replacement with a client-side RPC call, while the code under it gets moved into some implicit "_server" module. If that's the case the "bundler" should only ever encounter the RPC call, not the server code.

Hussein•2w ago

this won't work if you use a server-only module like better-sqlite3 because it will leak to client

slim (jamesc)OP•2w ago

The dev environment does rule out unreferenced imports. I did see that working. But, it does NOT look into any function(s) using that import to see if the function is also unreferenced; it just does a light scan. So, if the "use server" code was moved and there are no non-"use server" functions referencing that import, then it should work. In my case, I'm in middleware.ts which should probably be assumed to be all server-code (not needing "use server"), but does not seem to be the case: I can comment out a key function call in a onRequest handler to a "use server" function in another file and I can get warning about "node:crypto" go away. Just for clearity: the build is way better at bundling so I'm not getting large page loads at all. It is just the dev environment that works differently. It was just alarming to see this in dev until I figured this out. I'm hoping to use those dev warnings to help me organize the code more, but I'm not so concerned about larger perhaps cached loads during dev.

peerreynders•2w ago

The bundler seems to be pretty good at tree shaking those imports out after the "use server" sections have been replaced but perhaps your experience was different.

I can comment out a key function call in a onRequest handler to a "use server" function in another file and I can get warning about "node:crypto" go away.

Yeah, that sounds fishy. "use server" shouldn't have any impact on the server bundle. But it does sound like you may be able to isolate that particular "use server" function better so that it is nowhere near that node:crypto import that seems to get pulled into the client bundle.

Cyber Grandma•2w ago

I have had similar problems every time I was trying to make route loaders in client code, even with all the proper "use server"s. It was happening whenever I imported my db object. Even though it was used only in the server side functions. What I found out is that because my db.ts file had exported my const db =... object directly, importing this file involves side effects. So the tree shaker assumes that even if db is not used in the client side, it should still try to load the db.ts file there. And because the db.ts also imported stuff like ORM, postgresjs and others, it crashed my whole app on the client side. If you have the same situation, you need to make something like a getDatabase() function instead of exporting the db singleton.

Hussein•2w ago

you're right, it worked, though hmr now does full reloads i did this and it worked without creating getDatabase():

import { query } from "@solidjs/router";
import { db } from "./server";

export const getData = query(async () => {
  "use server";
  return typeof db;
}, "data");

import { query } from "@solidjs/router";
import { db } from "./server";

export const getData = query(async () => {
  "use server";
  return typeof db;
}, "data");

this is server.ts:

import Database from "better-sqlite3";

export const db = new Database("db.sqlite");

import Database from "better-sqlite3";

export const db = new Database("db.sqlite");

Gaming

Programming

vxini seems to be packaging and shipping all server code to the client

Did you find this page helpful?