feat: environment api config options rework

[patak-dev]

Description

Building on top of:

• feat: environment.getTopLevelConfig() #17753

For reference, before #17753, we had:

• environment.config is the top level config (i.e. environment.config.root)
• environment.options is the ResolvedEnvironmentOptions, equivalent to environment.config.environments[environment.name] (i.e. environment.options.resolve.conditions)

The motivation for #17753 is that environment.config being the top level config (the shared config instance that has the default values) is error prone environment.config.resolve.conditions should never be used. We discussed deprecating these defaults from ResolvedConfig and then removing them but that will take a while. We could make the type of environment.config more strict even if the default options are in the object, but there are other issues.

Having the top level config as environment.getTopLevelConfig() brought two things to the spotlight:

• Most of the access for the config is for root and base. It would be good to have a more ergonomic way to access these instead of environment.getTopLevelConfig().root
• We may make other config options per-environment in the future. Every time we do it, users will need to move from config.flag to environment.options.flag

This PR leaves environment.getTopLevelConfig() for when the shared instance is needed, and removes environment.options in favor of environment.config that has type ResolvedConfig & ResolvedEnvironmentOptions (maybe the type could be improved). It is currently implemented as:

    this.config = new Proxy(
      options as ResolvedConfig & ResolvedEnvironmentOptions,
      {
        get: (target, prop: keyof ResolvedConfig) => {
          if (prop === 'logger') {
            return this.logger
          }
          if (prop in target) {
            return this._options[prop as keyof ResolvedEnvironmentOptions]
          }
          return this._topLevelConfig[prop]
        },
      },
    )

This solves the two issues above and avoids confusion. environment.config always returns the configuration for this environment (it doesn't matter if the options are per-environment or shared). There are no longer issues with users accessing the defaults by mistake.

Notes: The PR also changes the ssr flag for EnvironmentOptions introduced at 90185f7 because it collides with the ssr object in ResolvedConfig. This was confusing in that commit already but I couldn't came up with a better name. We discussed with @sheremet-va and settled down on renaming it to consumer: 'client' | 'server' for now.

[stackblitz]

Run & review this pull request in StackBlitz Codeflow.

[hi-ogawa]

Proxy looks good to me. If environment.config.xxx would suffice for most of the cases, when would users need to go environment.getTopLevelConfig().xxx?

[patak-dev]

Proxy looks good to me. If environment.config.xxx would suffice for most of the cases, when would users need to go environment.getTopLevelConfig().xxx?

We still have many internal APIs that take a ResolvedConfig instead of an environment. So in that cases you can use environment.getTopLevelConfig() to get the shared instance. I think a lot of these APIs did that just because it was a more comfortable way to access root and base though, and probably later on they could be reworked. We have some other cases were we use the config as the key of a cache (the fs tree cache for example).

environment.getTopLevelConfig().xxx would not be a pattern we see used.

[hi-ogawa]

We have some other cases were we use the config as the key of a cache (the fs tree cache for example).

Yeah, I was thinking Vite needs to use getTopLevelConfig for those occasions, but I was wondering if end users (frameowrk/plugin authors) would need to consider choosing whether environment.getTopLevelConfig() or environment.config.