Should $ vite build also build SSR?

[brillout]

Both SvelteKit and vite-plugin-ssr use a writeBundle()/closeBundle() hook in order to make $ vite build also build SSR code.

Question: should Vite have built-in support for making $ vite build also build SSR code?

From @aleclarson:

The build command can be reframed as producing the output for one application instead of one bundle.

From @benmccann:

Having SvelteKit have it's own CLI doesn't solve any of these problems unless you also want SvelteKit to no longer use vite.config.js and have its own configuration format in which case we'd lose all compatibility with the Vite ecosystem, which would be terrible for users.

Also, I'd argue that one vite.config.js should correspond to one $ vite build call: as a user, anything else seems confusing, I think.

As for vite-plugin-ssr, I think it's neat to re-use Vite's CLI instead of having a vite-plugin-ssr CLI just for fixing $ vite build. Vite's CLI can be used seamlessly with vite-plugin-ssr which I think is neat: https://github.com/brillout/vite-plugin-ssr/blob/ff0cb6b7caebf8d797670a68aac7f761cf7e10d4/examples/vue-full/package.json#L3-L5. Actually, thanks to the writeBundle() trick and the configureServer() hooks, vite-plugin-ssr does not have any CLI: it just extends Vite's CLI.

There is a push back from @bluwy and @antfu.

[ydcjeff]

For me, no. I find it confusing since a normal Vite app by create-vite only builds for SPA. And, for people migrating their SPA apps to SSR (w/ vite-plugin-ssr), they would also find confusing as the initial vite build doesn't have ssr flag, but their apps are building for SSR, contradicting to what the Vite docs tells.

[brillout]

In my experience, users don't think like that: what they primarily want (and therefore expect) when they run $ vite build is their app to be built. Most users don't care what exactly $ vite build does. They don't care whether it builds only the client-side or as well the server-side code. What they want is the build step to just work. They don't care about these low-level details.

The fact that the build step in split into two $ vite build runs is more confusing than anything else to users that are new to Vite. Users new to Vite expect $ vite build to just work.

Now it's true that expert Vite uses like ourselves will be thrown off by that change. You're right on that. But I think it's worth it.

[bluwy]

My response to the two quotes are at https://github.com/vitejs/vite/discussions/9442#discussioncomment-3287233 and https://github.com/vitejs/vite/discussions/9442#discussioncomment-3289064 for reference.

Also, I'd argue that one vite.config.js should correspond to one $ vite build call: as a user, anything else seems confusing, I think.

Perhaps it is, but then having vite build equal running Rollup twice is also confusing IMO. It breaks the concept of 1 build = 1 bundle, in which Anthony had proposed something like vite pack to cover it (but I'm not sure if Vite should be responsible of that). More info at #5936 (comment)

[brillout]

Are you suggesting that users would need to maintain two different vite.config.js files? That's a subpar DX, wouldn't you agree?

Most users don't really care about these details, see my reply above. Most users want to add their plugins to vite.config.js and call it a day. Most users don't care about the distinction between client-side and server-side code.

I agree that ideally there should be only one Rollup build that takes care of both the client-side and server-side build. I'm not sure here but I guess it's a Rollup limitation we have to live with for the time being. So, while I agree it's not perfect, I still think $ vite build doing it all makes sense from a high-level user perspective.

CC @antfu

[bluwy]

Are you suggesting that users would need to maintain two different vite.config.js files? That's a subpar DX, wouldn't you agree?

No, they can use one vite.config.js that's used for client build and SSR build. The Vite config is rather isomorphic for those cases, and also has the ssrBuild flag for defineConfig for special conditions.

Most users don't really care about these details, see my reply above. Most users want to add their plugins to vite.config.js and call it a day. Most users don't care about the distinction between client-side and server-side code.

Since there would only be one vite.config.js, they can add their plugins at one spot and have it working for both client and SSR build. Though if you mean running vite build and vite build --ssr being tedious, I still think a wrapper CLI that runs both would still be the best, or vite pack. I feel like the main push for having them combined is because of frameworks that tries to be just a Vite plugin, which the team are against of in several discussions.

[antfu]

My cents are - we'd recommend providing your custom CLI for that instead. But after the object-style hooks, there is nothing preventing you from doing that if you insist. Just take your own risk and be cautious about plugin compatibility and side effects.

Similar to vite preview (configurePreviewServer hook), from our previous team discussions, IIRC, our position is that we offer the functionality for minimal usage and recommend integrations to provide their own cli for higher-level features. /cc @patak-dev might be able to phrase better than me.

[brillout]

The way I see this is that it's a broken DX to start with: having to run $ vite build && vite build --ssr is weird to begin with. Webpack-level weird. It may make sense for Vite internal reasons, but from a high-level perspective (which 99% of users have) I don't see why this would make sense.

What users want is their app to be built. They don't care that Rollup is being run once or twice.

The cleanest way to go about this would be to run Rollup only once, I guess we can agree on that? (Despite the fact that it's probably not possible for the time being.)

Vite-plugin-ssr users can use $ vite build to build their whole app. Not a single user has complained about this. That speaks volumes of what $ vite build should do.

It's also for folks who use Vite's native SSR API. I think it's not ideal for them as well.

In a nutshell, it's what Alec said: we should reframe $ vite build to mean "it builds your app". That's what users want and expect.

I do agree that we should limit what "it builds your app" means. But running both the server-side as well as the client-side code should definitely be part of "it builds your app".

Personally, I'm fine with the status quo as we can use the writeBundle() trick anyways. But I think if the opportunity arises then we should fix $ vite build to build the entire app and not only half of it.

[patak-dev]

The position of the Vite team has been as @antfu explained, to push for the creation of custom CLIs and use Vite JS API. It is a more flexible approach for frameworks, as they don't need changes in Vite Core to implement their own ideas.

I personally see the value of using Vite as the CLI though, it forces the framework to use the exact same options and the output is consistent across projects for different frameworks. And for what I saw so far, the requests to the core from the frameworks starting to go with the framework-as-a-plugin approach are for things that are actually helpful for everybody and there hasn't been much friction with the exception of the meaning of vite build. For the benefits of several frameworks using Vite to materialize, vite build should mean the same across them. If astro build, vitepress build, and vite build in SvelteKit, vite-plugin-ssr, all have the meaning of building everything, we may want to review in Core what vite build means. I don't like the writeBundle() hack that is spreading, but if we do nothing it seems that several projects will run with it.
I also see value in being able to build just the frontend or just the ssr entry. So it may be something like:

vite build --client
vite build --ssr
vite build

vite build should run first build --client, and then --ssr. How SSG enters on this picture? Or deploy adapters?
If we go here, how do we do it without disruption? vite build should probably start to warn users that they need to change their scripts to vite build --client because vite build is going to change (only if SSR is configured).

This is not an endorsement to go in this direction, just trying to organize my ideas. I still don't know what is best moving forward.

[aleclarson]

I also see value in being able to build just the frontend or just the ssr entry.

In all my time with Vite SSR, I've never wanted to build one of those in isolation. That's just asking for bugs.

[patak-dev]

Fair point @aleclarson, if something changes in the code you want both to be rebuild. Only if the change is in the config specific to the client or SSR, you may want to avoid rebuilding the other one, but then this could be something that some incremental build feature may do better to avoid bugs 🤔

[antfu]

Here is a recap of today's team meeting regards on this topic (sorry we forgot to record it)

The Vite team stands in the position that we don't recommend such usage.

vite build is designed to run a single build in mind. CLI flags like --ssr and --watch also only make sense for a single build. Vite only offers low-level SSR support and is not targeted to be an SSR meta-framework. We also lean to have a clear and simple definition of what vite build is doing for integrations to compose and innovate (e.g. not every integration uses SSR, and some integrations do more than SSR on build).

That said, it is still technically possible to do so after #9634. Thus, we consider it non-blocking and out-of-scope of Vite core. This means we are drawing the line that we won't provide future support and guarantee on such usage.

We recommend higher-level integrations to provide their own CLI to fit various needs. For example, a framework could proxy other Vite subcommands but only provide custom logic for its build command.

Thanks for bringing this discussion up.

[brillout]

Thanks for the update. Which makes a lot of sense from a technical point of view. Edit: I actually do think that this decision is a mistake also from a technical point of view, see #10097.

Thanks for the discussion.

[benmccann]

Kicking off builds from within hooks is something basically the whole ecosystem relies on to build service workers. I had always thought that was the officially encouraged way of doing things up until the past week or two since your own vite-plugin-pwa does it. So this is saying that vite-plugin-pwa is officially relying on an unsupported and discouraged method of building then by kicking off a new build in a plugin hook? Is Vite saying it will never support service worker builds? Or should the --ssr flag be changed to something like --build=client, --build=ssr, --build=service-worker so that then people who want to build service workers can create a new build from their custom CLI which includes vite-plugin-pwa without having to kick off a new build from a hook?

[antfu]

From my understanding, it's not we are not recommending using hooks to do something (#9634 is to address the capability of doing that), but we are suggesting not altering the behavior of vite build, the CLI.