refactor: use builder in build

[sapphi-red]

Description

Alternative to #18028

• Removes builder.entireApp and use builder: {} / builder: undefined (this one can be discussed separately if needed)
• Introduce a internal concept of legacy builder that just works like build and use that from the CLI

This makes the createBuilder a bit complicated but the overall code size is smaller and improves CLI-JS API symmetry.

Migration Plans

This PR does not change any behavior. Later on we make builder: { sharedConfigBuild: true } to be the default and remove the codes related to the legacy builder.

• For CSR only apps: no migration needed
• For CSR + SSR apps using vite CLI
  1. No change is needed for Vite 6, but can opt-in to using builder by passing --app or setting builder: {} in the config
  2. When the legacy builder is removed, users can remove --app but that change is not necessary (we should just ignore the flag)
• For CSR + SSR apps using build command
  1. No change is needed for Vite 6, but can opt-in to using builder by using createBuilder
  2. When the legacy builder is removed, users need to migrate to createBuilder from build

[sapphi-red]

@patak-dev @bluwy What do you think about this one?

[patak-cat]

Maybe this would be more clear with a condition out of the for loop:

  function setupEnvironment(environmentName, environmentConfig) {
    const environment = await environmentConfig.build.createEnvironment(
      environmentName,
      environmentConfig,
    )
    await environment.init()
    environments[environmentName] = environment
  }

  if (selectedEnvironmentName) {
    setupEnvironment(selectedEnvironmentName, config)
  }
  else {
    // ... current for loop using setupEnvironment(environmentName, environmentConfig)
  }

[patak-cat]

This approach looks good to me! Thanks Sapphi for exploring this option.

I was thinking we could move some props later on from build to builder, for example copyPublicDir, but we can delay this until everyone is using buildApp. This, thinking in a future where nobody wants to use Vite to build a single environment (and if they want, they just configure it with a single environment, but there is no more build() a part).
If we don't think that will ever be possible, maybe we could use { builder: { entireApp: true }} for the option, but using the implementation proposed here.

[bluwy]

I like this approach too, so IIUC the programmatic API to reflect vite build and vite build --app would be createBuilder({}, null).buildApp()? It's a little clunky, but I think it's fine since it's only a stop gap for this major.

Once createBuilder() stabilizes, would we phase out build()?

[sapphi-red]

so IIUC the programmatic API to reflect vite build and vite build --app would be createBuilder({}, null).buildApp()?

Yes.

Once createBuilder() stabilizes, would we phase out build()?

I think yes.

[patak-cat]

Thanks again Sapphi! I prefer this option to just removing entireApp. Just a note again that if we go with this one, we are already deciding that at one point we would like to remove build() and being able to "build a part of an app". Or we can still change our mind and accept a small breaking change for people that used builder: {} if we need to introduce entireApp. I'm fine with this.