Replies: 1 comment 8 replies
-
|
@brillout I see that you started this discussion two years ago. Any ideas on how to process static assets imported by the server? I'm building an app using Hono. All of my pages are rendered server-side on each request, MPA-style, using Hono's JSX renderer as templates. I have a layout template that defines my CSS It would be awesome if there were a way to transform those CSS files using PostCSS, add hashes to the filenames, etc., and for the server to somehow know which file paths to reference in the build output. It would be even more amazing if there were a way to add CSS modules to the whole thing so that I could import a CSS module server side and magically make sure that the appropriate style tags were added to head on render. Right now, I'm using Hono's I wonder if @yusukebe has any ideas. Not sure how much of this would be Hono-specific vs. Vite-specific. |
Beta Was this translation helpful? Give feedback.
-
|
@yusukebe @hi-ogawa @brillout I whipped up a demo: https://github.com/ersinakinci/vite-server-build-demo |
Beta Was this translation helpful? Give feedback.
-
|
Nice, thanks for putting together the demo! I haven't gone through all your code or comments so far, but your purely vite ssr only approach might be actually somewhat rare, so maybe this hasn't been explored much. For example, for css code splitting, one probably common thing is to have js code-splitting at client routes level. With this approach, you can collect js/css dependencies for each route js chunk from client vite manifest. Then, this information can be used to inject css depending on which path users visits. Something I remember from Remix looks like this https://github.com/remix-run/remix/blob/6ad886145bd35298accf04d43bd6ef69833567e2/packages/remix-dev/vite/plugin.ts#L350-L379 The code-splitting happens somewhat automatically by just using dynamic import |
Beta Was this translation helpful? Give feedback.
-
|
Wow, dynamic imports...brilliant hack! I hadn't thought about that since everything in my setup is pure server and there isn't any need for dynamic importing, but it does the trick. It's nicer than my approach in a way because it affords finer control over when the chunking happens. I just tried it out on a header template that imports a CSS module in one of my projects, like so: const Header = (await import("~/components/Header")).default;Vite generated the separate CSS file for the header chunk, which contained my CSS module. That said, it would be ideal in a pure server-side environment to be able to do a static import. I don't know if there are any real performance implications, but it's kinda awkward having to resolve a promise just to get some chunked CSS. I haven't played around with Remix before; does the plugin you linked to allow them to basically get the same effect as dynamic import chunking with static imports? I think the bigger problem for me is how to map each chunk's file path in the manifest to the routes in my app. There's also the side mystery of how to get the manifest to still map my entrypoint to my global |
Beta Was this translation helpful? Give feedback.
-
For a framework with a heavy client js (and that's basically a normal use case of Vite), it's critical to minimize client js to send as users need. As a point of splits, it's probably natural to choose url routes since that's minimal block of how users interact an app. In the case of Remix, the simplified picture is something like: they crawl file system to collect Probably using Even for SSR only app, dynamic import might still look more natural if your hono app is (hypothetically) structured like this: app.get("/path1", (c) => (await import("./routes/path1.tsx")).render());
app.get("/path2", (c) => (await import("./routes/path2.tsx")).render()); |
Beta Was this translation helpful? Give feedback.
-
|
Had a similar use case which lead me to build stack54 |
Beta Was this translation helpful? Give feedback.
-
This not the same discussion as #9496 - Should
$ vite buildalso build SSR? which was about the CLI.Regardless of the CLI, and from a technical point of view, separating the client-side and server-side build steps is asking for trouble: fundamentally, we cannot and should not assume that we can build the server-side and client-side in complete isolation from each other.
For example, static assets blur the line between the client and the server. Other techniques such as React Server Components also further blur the line.
A concrete problematic situation is #10082.
Another concrete example is https://vite-plugin-ssr.com/includeAssetsImportedByServer which is a brittle workaround.
I'm creating this ticket as a place to discuss this. (I'm super busy at the moment, maybe I'll find time at some point to further elaborate why React Server Components blurs the line.)
Also CC @aleclarson which I can see to agree with that.
Beta Was this translation helpful? Give feedback.
All reactions