refactor: top level keys for environments (and .environments array)

[patak-dev]

Description

Inspired by Nuxt $production/$development top level keys. See environment overrides.

Instead of:

export default defineConfig({
  environments: {
    client: {},
    ssr: {},
    edge: {},
  }
})

this changes the API to use top level keys prefixed by $

export default defineConfig({
  $client: {},
  $ssr: {},
  $edge: {},
})

The idea is avoiding the extra nesting as config options become to verbose:

config.environments.client.dev.sourcemap
// vs
config.$client.dev.sourcemap

The same environment top level keys are mapped to ResolvedConfig, ViteDevServer, ViteBuilder

const { render } = await vite.environments.ssr.import(url)
// vs
const { render } = await vite.$ssr.import(url)
// making it closer to
const { render } = await vite.ssrLoadModule(url)

resolvedConfig.environments, viteDevServer.environments, builder.environments is now a Env[] instead of a Record<string,Env>. The object form is no longer needed now that we have access at the top level, and the list simplifies iteration (no need for Object.values(), Object.keys()). For example:

buildApp: async (builder) => {
  return Promise.all(
    builder.environments.map((environment) => builder.build(environment)),
  )
},
// vs
buildApp: async (builder) => {
  return Promise.all(
    Object.values(builder.environments).map((environment) => builder.build(environment)),
  )
},

Built on top of #18426 but moving .environments to be an array. It is generally a lot easier to use. A lot of Object.values() are removed.

Proposal triggered by this discussion #18415 (comment)

[sapphi-red]

Looks nice. The only worry I have is forgetting to sync environments and $foos.

[sapphi-red]

I think the name should be passed from the argument.

[patak-dev]

The name here is a dummy value for defaults. I don't think it would help to pass it from the two places where this function is called. Ideally, it shouldn't be there, but I don't want to make it nullable.

[patak-dev]

The only worry I have is forgetting to sync environments and $foos.

This is the same as in #18426, no? And at least right now environments are only created on server and builder init, so it shouldn't be a problem (except for fixing the issue you saw with the prev server having ghost environments at root). Or do you see some other problems?

[sapphi-red]

Ah, yeah it is. I think it's fine. Just that we have to be careful not to forget to call environments.push when assigning $env.

[bluwy]

If the majority is onboard, I'm happy with this change too 👍

[bluwy]

Maybe we should also disallow naming environments with just $, but I think we can think about this later.

[patak-dev]

Closing as one of the main reasons for this exploration is gone after merging:

• refactor: optimizeDeps back to top level #18465

Even without this change, we got a lot of feedback that mixing environments and other config props wasn't worth removing the environments extra nested level. I think it was still good that we checked it with a PR to see how it works.

For later reference, we also asked for feedback about vite.envs vs vite.environments and not using the full word wasn't well received.