docs: tweak wordings in Environment API doc

resolved #1072

guide/api-environment-frameworks.md

@@ -92,7 +92,7 @@ app.use('*', async (req, res, next) => {
 })
 ```
 
-## Runtime agnostic SSR
+## Runtime Agnostic SSR
 
 Since the `RunnableDevEnvironment` can only be used to run the code in the same runtime as the Vite server, it requires a runtime that can run the Vite Server (a runtime that is compatible with Node.js). This means that you will need to use the raw `DevEnvironment` to make it runtime agnostic.
 
@@ -264,7 +264,7 @@ export function createHandler(input) {
 }
 ```
 
-## Environments during build
+## Environments During Build
 
 In the CLI, calling `vite build` and `vite build --ssr` will still build the client only and ssr only environments for backward compatibility.
 
@@ -283,6 +283,6 @@ export default {
 }
 ```
 
-## Environment agnostic code
+## Environment Agnostic Code
 
 Most of the time, the current `environment` instance will be available as part of the context of the code being run so the need to access them through `server.environments` should be rare. For example, inside plugin hooks the environment is exposed as part of the `PluginContext`, so it can be accessed using `this.environment`. See [Environment API for Plugins](./api-environment-plugins.md) to learn about how to build environment aware plugins.

guide/api-environment-instances.md

@@ -1,4 +1,4 @@
-# Using `Environment` instances
+# Using `Environment` Instances
 
 :::warning Experimental
 Environment API is experimental. We'll keep the APIs stable during Vite 6 to let the ecosystem experiment and build on top of it. We're planning to stabilize these new APIs with potential breaking changes in Vite 7.
@@ -11,7 +11,7 @@ Resources:
 Please share your feedback with us.
 :::
 
-## Accessing the environments
+## Accessing the Environments
 
 During dev, the available environments in a dev server can be accessed using `server.environments`:
 
@@ -118,7 +118,7 @@ An environment instance in the Vite server lets you process a URL using the `env
 We are using `transformRequest(url)` and `warmupRequest(url)` in the current version of this proposal so it is easier to discuss and understand for users used to Vite's current API. Before releasing, we can take the opportunity to review these names too. For example, it could be named `environment.processModule(url)` or `environment.loadModule(url)` taking a page from Rollup's `context.load(id)` in plugin hooks. For the moment, we think keeping the current names and delaying this discussion is better.
 :::
 
-## Separate module graphs
+## Separate Module Graphs
 
 Each environment has an isolated module graph. All module graphs have the same signature, so generic algorithms can be implemented to crawl or query the graph without depending on the environment. `hotUpdate` is a good example. When a file is modified, the module graph of each environment will be used to discover the affected modules and perform HMR for each environment independently.
 

guide/api-environment-plugins.md

@@ -11,7 +11,7 @@ Resources:
 Please share your feedback with us.
 :::
 
-## Accessing the current environment in hooks
+## Accessing the Current Environment in Hooks
 
 Given that there were only two Environments until Vite 6 (`client` and `ssr`), a `ssr` boolean was enough to identify the current environment in Vite APIs. Plugin Hooks received a `ssr` boolean in the last options parameter, and several APIs expected an optional last `ssr` parameter to properly associate modules to the correct environment (for example `server.moduleGraph.getModuleByUrl(url, { ssr })`).
 
@@ -27,7 +27,7 @@ A plugin could use the `environment` instance to change how a module is processe
   }
 ```
 
-## Registering new environments using hooks
+## Registering New Environments Using Hooks
 
 Plugins can add new environments in the `config` hook (for example to have a separate module graph for [RSC](https://react.dev/blog/2023/03/22/react-labs-what-we-have-been-working-on-march-2023#react-server-components)):
 
@@ -39,7 +39,7 @@ Plugins can add new environments in the `config` hook (for example to have a sep
 
 An empty object is enough to register the environment, default values from the root level environment config.
 
-## Configuring environment using hooks
+## Configuring Environment Using Hooks
 
 While the `config` hook is running, the complete list of environments isn't yet known and the environments can be affected by both the default values from the root level environment config or explicitly through the `config.environments` record.
 Plugins should set default values using the `config` hook. To configure each environment, they can use the new `configEnvironment` hook. This hook is called for each environment with its partially resolved config including resolution of final defaults.
@@ -50,7 +50,7 @@ Plugins should set default values using the `config` hook. To configure each env
       options.resolve.conditions = // ...
 ```
 
-## The `hotUpdate` hook
+## The `hotUpdate` Hook
 
 - **Type:** `(this: { environment: DevEnvironment }, options: HotUpdateOptions) => Array<EnvironmentModuleNode> | void | Promise<Array<EnvironmentModuleNode> | void>`
 - **See also:** [HMR API](./api-hmr)
@@ -135,7 +135,7 @@ const UnoCssPlugin = () => {
   // shared global state
   return {
     buildStart() {
-      // init per environment state with WeakMap<Environment,Data>
+      // init per-environment state with WeakMap<Environment,Data>
       // using this.environment
     },
     configureServer() {
@@ -184,12 +184,12 @@ export default defineConfig({
 })
 ```
 
-## Environment in build hooks
+## Environment in Build Hooks
 
 In the same way as during dev, plugin hooks also receive the environment instance during build, replacing the `ssr` boolean.
 This also works for `renderChunk`, `generateBundle`, and other build only hooks.
 
-## Shared plugins during build
+## Shared Plugins During Build
 
 Before Vite 6, the plugins pipelines worked in a different way during dev and build:
 
@@ -204,7 +204,7 @@ In a future major (Vite 7 or 8), we aim to have complete alignment:
 
 There will also be a single `ResolvedConfig` instance shared during build, allowing for caching at entire app build process level in the same way as we have been doing with `WeakMap<ResolvedConfig, CachedData>` during dev.
 
-For Vite 6, we need to do a smaller step to keep backward compatibility. Ecosystem plugins are currently using `config.build` instead of `environment.config.build` to access configuration, so we need to create a new `ResolvedConfig` per environment by default. A project can opt-in into sharing the full config and plugins pipeline setting `builder.sharedConfigBuild` to `true`.
+For Vite 6, we need to do a smaller step to keep backward compatibility. Ecosystem plugins are currently using `config.build` instead of `environment.config.build` to access configuration, so we need to create a new `ResolvedConfig` per-environment by default. A project can opt-in into sharing the full config and plugins pipeline setting `builder.sharedConfigBuild` to `true`.
 
 This option would only work of a small subset of projects at first, so plugin authors can opt-in for a particular plugin to be shared by setting the `sharedDuringBuild` flag to `true`. This allows for easily sharing state both for regular plugins:
 

guide/api-environment-runtimes.md

@@ -11,7 +11,7 @@ Resources:
 Please share your feedback with us.
 :::
 
-## Environment factories
+## Environment Factories
 
 Environments factories are intended to be implemented by Environment providers like Cloudflare, and not by end users. Environment factories return a `EnvironmentOptions` for the most common case of using the target runtime for both dev and build environments. The default environment options can also be set so the user doesn't need to do it.
 
@@ -72,7 +72,7 @@ and frameworks can use an environment with the workerd runtime to do SSR using:
 const ssrEnvironment = server.environments.ssr
 ```
 
-## Creating a new environment factory
+## Creating a New Environment Factory
 
 A Vite dev server exposes two environments by default: a `client` environment and an `ssr` environment. The client environment is a browser environment by default, and the module runner is implemented by importing the virtual module `/@vite/client` to client apps. The SSR environment runs in the same Node runtime as the Vite server by default and allows application servers to be used to render requests during dev with full HMR support.
 

guide/api-environment.md

@@ -15,11 +15,11 @@ Please share your feedback with us.
 
 Vite 6 formalizes the concept of Environments. Until Vite 5, there were two implicit Environments (`client`, and optionally `ssr`). The new Environment API allows users and framework authors to create as many environments as needed to map the way their apps work in production. This new capability required a big internal refactoring, but a lot of effort has been placed on backward compatibility. The initial goal of Vite 6 is to move the ecosystem to the new major as smoothly as possible, delaying the adoption of these new experimental APIs until enough users have migrated and frameworks and plugin authors have validated the new design.
 
-## Closing the gap between build and dev
+## Closing the Gap Between Build and Dev
 
 For a simple SPA/MPA, no new APIs around environments are exposed to the config. Internally, Vite will apply the options to a `client` environment, but it's not necessary to know of this concept when configuring Vite. The config and behavior from Vite 5 should work seamlessly here.
 
-When we move to a typical server side rendered (SSR) app, we'll have two environments:
+When we move to a typical server-side rendered (SSR) app, we'll have two environments:
 
 - `client`: runs the app in the browser.
 - `server`: runs the app in node (or other server runtimes) which renders pages before sending them to the browser.
@@ -68,7 +68,7 @@ export default {
 }
 ```
 
-When not explicitly documented, environment inherit the configured top-level config options (for example, the new `server` and `edge` environments will inherit the `build.sourcemap: false` option). A small number of top-level options, like `optimizeDeps`, only apply to the `client` environment, as they don't work well when applied as a default to server environments. The `client` environment can also be configured explicitly through `environments.client`, but we recommend to do it with the top-level options so the client config remains unchanged when adding new environments.
+When not explicitly documented, environment inherits the configured top-level config options (for example, the new `server` and `edge` environments will inherit the `build.sourcemap: false` option). A small number of top-level options, like `optimizeDeps`, only apply to the `client` environment, as they don't work well when applied as a default to server environments. The `client` environment can also be configured explicitly through `environments.client`, but we recommend to do it with the top-level options so the client config remains unchanged when adding new environments.
 
 The `EnvironmentOptions` interface exposes all the per-environment options. There are environment options that apply to both `build` and `dev`, like `resolve`. And there are `DevEnvironmentOptions` and `BuildEnvironmentOptions` for dev and build specific options (like `dev.warmup` or `build.outDir`). Some options like `optimizeDeps` only applies to dev, but is kept as top level instead of nested in `dev` for backward compatibility.
 
@@ -83,7 +83,7 @@ interface EnvironmentOptions {
 }
 ```
 
-The `UserConfig` interface extends from the `EnvironmentOptions` interface, allowing to configure the client and defaults for other environments, configured through the `environments` option. The `client` and a server environment named `ssr` are always present during dev. This allows backward compatibility with `server.ssrLoadModule(url)` and `server.moduleGraph`. During build, the `client` environment is always present, and the `ssr` environment is only present if it is explicitly configured (using `environments.ssr` or for backward compatibility `build.ssr`). An app doesn't need to use the `ssr` name for their SSR environment, it could name it `server` for example.
+The `UserConfig` interface extends from the `EnvironmentOptions` interface, allowing to configure the client and defaults for other environments, configured through the `environments` option. The `client` and a server environment named `ssr` are always present during dev. This allows backward compatibility with `server.ssrLoadModule(url)` and `server.moduleGraph`. During build, the `client` environment is always present, and the `ssr` environment is only present if it is explicitly configured (using `environments.ssr` or for backward compatibility `build.ssr`). An app doesn't need to use the `ssr` name for its SSR environment, it could name it `server` for example.
 
 ```ts
 interface UserConfig extends EnvironmentOptions {
@@ -94,7 +94,7 @@ interface UserConfig extends EnvironmentOptions {
 
 Note that the `ssr` top-level property is going to be deprecated once the Environment API is stable. This option has the same role as `environments`, but for the default `ssr` environment and only allowed configuring of a small set of options.
 
-## Custom environment instances
+## Custom Environment Instances
 
 Low level configuration APIs are available so runtime providers can provide environments with proper defaults for their runtimes. These environments can also spawn other processes or threads to run the modules during dev in a closer runtime to the production environment.
 
@@ -129,7 +129,7 @@ We don't recommend switching to Environment API yet. We are aiming for a good po
 - [SSR using `ModuleRunner` API](/changes/ssr-using-modulerunner)
 - [Shared plugins during build](/changes/shared-plugins-during-build)
 
-## Target users
+## Target Users
 
 This guide provides the basic concepts about environments for end users.