Where is the divide between Rolldown and Vite?

[jamesopstad]

I am interested in how the team define the architectural divide between Rolldown and Vite and if this could change in future. Now that both are developed together, there is the potential for Vite to become a thinner layer on top of Rolldown.

This is relevant to the Environment API discussions because it raises the question of whether environments should be a Vite only concept or implemented in Rolldown. As we look at build scenarios that require cross-environment data, such as RSCs and importing client assets on the server, there may be a case for environments being a first-class Rolldown feature.

[sapphi-red]

The boundary I'm currently have in mind is whether multiple separate bundles are needed. If the feature doesn't interact with other bundles, it should likely be in Rolldown, and vise versa.

I'm not sticked to this, but I think it's the best line for now for the following reasons:

• It will be easier to work in parallel as the codebase is separate
• Iterating with JS / TS is easier than with Rust as it's more loose and is familiar for the meta-framework / plugin authors
• I didn't come up with any major improvements that requires the concept to be on Rolldown side. Sharing the transformed module won't work because there are environment-specific transforms. The same can be said for module resolutions. Although, for module resolutions there are some parts that can be reused. But if it's for this reason, I think it's better to make it possible to output / input the resolution cache instead.

[jamesopstad]

Thanks, that helps. I think with that boundary we can frame Vite as being a "development server and build orchestrator for Rolldown".

With this framing it would be good to reconsider having rolldownOptions tucked away inside the build config. A lot of the existing complexity in the Vite config comes from needing to separate out dev, build and shared config options. This should change once full-bundle mode is stabilised. Could the Rolldown options then be flattened into the environment options so that Rolldown's resolve, define etc. can be used directly? I find it quite hard to reason about the current relationship between Vite and Rolldown's options where they overlap so this would simplify things.

We could also potentially move the environment.build.input config to environment.input so that it is considered the source of truth for dev and build (some already treat it like this because there isn't a built-in concept of a dev input).

[sapphi-red]

This should change once full-bundle mode is stabilised. Could the Rolldown options then be flattened into the environment options so that Rolldown's resolve, define etc. can be used directly? I find it quite hard to reason about the current relationship between Vite and Rolldown's options where they overlap so this would simplify things.

Yeah, I've been thinking about that. The difficult part is that the behavior is slightly different between Vite and Rolldown and we need to consolidate it first.

We could also potentially move the environment.build.input config to environment.input so that it is considered the source of truth for dev and build (some already treat it like this because there isn't a built-in concept of a dev input).

We haven't added the top level input option yet, but we've discussed about the need multiple times and definitely thinking of adding it.

[brillout]

The boundary I'm currently have in mind is whether multiple separate bundles are needed.

A case might also be made for accuracy: assets referenced only on the server-side should land in the client bundle — the hard split between client and server seems to be an inherent flaw that causes issues.

Examples:

• Duplicated CSS vikejs/vike#1815
• Inconsistent cssTarget value, leading to duplicated CSS vite#20505
• Stabilizing `build.ssrEmitAssets` vite#13808 (while build.ssrEmitAssets improved the situation, handling assets is still hard)

[sapphi-red]

I think #5 is the way to solve that.