fix: remove `builder.entireApp`

[bluwy]

Description

The idea I had for https://github.com/vitejs/vite/pull/16471#discussion_r1740172660. Feel free to let me know too if this is a bad idea

What I'm thinking is that build.entireApp currently has a different meaning:

1. If set by the user or plugins, the CLI is able to dynamically call build() or createBuilder()
2. But from a programmatic API pov, frameworks can't do the same as they need to decide early on which API to use. Perhaps the framework could support both depending on whether the user sets the config, but they can't emulate the behaviour like the CLI.

With this PR, I removed the build.entireApp option entirely and let frameworks manage them themselves.

1. If they only support --app, they should call createBuilder or ensure the vite CLI is called with --app
2. If they only support the normal build API, they should call build() (same as before, not changed)
3. If they support both, users can choose via --app, or frameworks can expose an option to pick between both.

[bolt-new-by-stackblitz[bot]]

Run & review this pull request in StackBlitz Codeflow.

[patak-dev]

Let's discuss about this one after we merge the PR. We can point to main after that.

[sapphi-red]

I like this.

1. ... ensure the vite CLI is called with --app

I have one question about this one. Is it easily possible to detect whether it was called with --app?

[bluwy]

I guess you could check process.argv.includes('--app') to check that.

[sapphi-red]

@patak-dev Do you have any thoughts here?

[bluwy]

I personally don't think it should be a blocker since SvelteKit often has a migration script to handle that. And I think --app being a visual cue is nice and implies it's building the entire thing, which vite build alone wasn't meant to have worked before.

I'll ping them though if they have thoughts about this, but I also agree that if we add this later on it can be a feature.

[dominikg]

suddenly requiring to add --app to what previously was just vite build seems like an arbitrary breaking change for not much benefit.

If at all i'd say let vite build run everything and vite build --environment=xxx can pick a subset to build, could be a repeatable key to allow picking 2 out of 5. Might need topological sorting if one env depends on another tho

[bluwy]

It's not required to add --app unless you want Vite to build the environments for you, and you'd have to restructure the build process slightly to opt-in in the first place. And I think the distinction here upholds our intent that vite build was only meant to do a single build, which I think is valuable to have.

IIUC the builder API is also experimental (I heard it was but we don't mark it as experimental 🤔), so pushing for vite build as "build all environments" feels too early. Not to mention it'll break many existing Vite setups v6 and below.

[patak-dev]

My take here is that we will still need something like what we are removing in this PR, or SvelteKit will keep using the writeBundle hack and ignore buildApp. This API was specifically targeted at SvelteKit, so I'll push for vite build to build the entire app in the future.

[bluwy]

For me, if we do want vite build to build an app based on a config option, as long as it can be replicated with the build() JS API (without needing to decide beforehand either createBuilder() and build() because that defeats the config option purpose), I'd be fine with it.

The CLI and JS API symmetry feels more important to me, than whether --app is needed or as a default or not.

[patak-dev]

We decided to go with #18432, that would allow SvelteKit and others to keep using vite build if they want to experiment with the new buildApp API instead of the writeBundle hack