More PR feedback

Author: jamesopstad

src/content/docs/workers/vite-plugin/cloudflare-environments.mdx

@@ -31,14 +31,24 @@ vars = { MY_VAR = "Production var" }
 
 </WranglerConfig>
 
-If you run `CLOUDFLARE_ENV=production vite build` then the output `wrangler.json` file generated by the build will be a flattened configuration for the 'production' Cloudflare environment.
-This combines [top-level only](/workers/wrangler/configuration/#top-level-only-keys), [inheritable](/workers/wrangler/configuration/#inheritable-keys), and [non-inheritable](/workers/wrangler/configuration/#non-inheritable-keys) keys.
-The value of `MY_VAR` will therefore be `'Production var'`.
-The name of the Worker will be `'my-worker-production'` because the environment name is automatically appended to the top-level Worker name.
+If you run `CLOUDFLARE_ENV=production vite build` then the output `wrangler.json` file generated by the build will be a flattened configuration for the 'production' Cloudflare environment, as shown in the following example:
+
+```json
+{
+	"name": "my-worker",
+	"compatibility_date": "2024-12-30",
+	"main": "index.js",
+	"vars": { "MY_VAR": "Production var" }
+}
+```
+
+Notice that the value of `MY_VAR` is `Production var`.
+This flattened configuration combines [top-level only](/workers/wrangler/configuration/#top-level-only-keys), [inheritable](/workers/wrangler/configuration/#inheritable-keys), and [non-inheritable](/workers/wrangler/configuration/#non-inheritable-keys) keys.
 
 :::note
 The default Vite environment name for a Worker is always the top-level Worker name.
 This enables you to reference the Worker consistently in your Vite config when using multiple Cloudflare environments.
+See [Vite Environments](/workers/vite-plugin/vite-environments/) for more information.
 :::
 
 Cloudflare environments can also be used in development.

src/content/docs/workers/vite-plugin/migrating-from-wrangler-dev.mdx

@@ -15,7 +15,7 @@ There are a few key differences to highlight:
 With the Cloudflare Vite plugin, your Worker config file (for example, `wrangler.jsonc`) is the input configuration and a separate output configuration is created as part of the build.
 This output file is a snapshot of your configuration at the time of the build and is modified to reference your build artifacts.
 It is the configuration that is used for preview and deployment.
-Once you have run `vite build`, running `wrangler deploy` will automatically locate this output configuration file.
+Once you have run `vite build`, running `wrangler deploy` or `vite preview` will automatically locate this output configuration file.
 
 ### Cloudflare Environments
 
@@ -30,7 +30,7 @@ If these options are provided, then warnings will be printed to the console with
 Examples where the Vite configuration should be used instead include `alias` and `define`.
 See [Vite Environments](/workers/vite-plugin/vite-environments/) for more information about configuring your Worker environments in Vite.
 
-### Local only data during local development
+### No remote mode
 
 The Vite plugin does not support [remote mode](/workers/local-development/#develop-using-remote-resources-and-bindings).
 We will be adding support for accessing remote resources in local development in a future update.

src/content/docs/workers/vite-plugin/secrets.mdx

@@ -9,7 +9,11 @@ description: Using secrets with the Vite plugin
 
 import { PackageManagers, WranglerConfig } from "~/components";
 
-Secrets can be provided to your Worker in local development using a [`.dev.vars`](/workers/configuration/secrets/#local-development-with-secrets) file.
+Secrets are typically used for storing sensitive information like API keys an auth tokens.
+For deployed Workers, they are set via the dashboard or Wrangler CLI.
+See [Secrets](/workers/configuration/secrets/) for more information.
+
+In local development, secrets can be provided to your Worker by using a [`.dev.vars`](/workers/configuration/secrets/#local-development-with-secrets) file.
 If you are using [Cloudflare Environments](/workers/vite-plugin/cloudflare-environments/) then the relevant `.dev.vars` file will be selected.
 For example, `CLOUDFLARE_ENV=staging vite dev` will load `.dev.vars.staging` if it exists and fall back to `.dev.vars`.
 

src/content/docs/workers/vite-plugin/static-assets.mdx

@@ -16,7 +16,7 @@ For more information about using static assets in Vite, refer to [Static Asset H
 The Vite plugin does not require that you provide the `assets` field in order to enable assets and instead determines whether assets should be included based on whether the `client` environment has been built.
 By default, the `client` environment is built if there is an `index.html` file in the root of your project or if `build.rollupOptions.input` is specified in the Vite config.
 
-On running `vite build`, an output `wrangler.json` configuration file is included as part of the build output.
+On running `vite build`, an output `wrangler.json` configuration file is generated as part of the build output.
 The `assets.directory` field in this file is automatically populated with the path to your `client` build output.
 It is therefore not necessary to provide the `assets.directory` field in your input Worker configuration.
 

src/content/docs/workers/vite-plugin/vite-environments.mdx

@@ -21,6 +21,11 @@ By default, when you add a Worker using the Cloudflare Vite plugin, an additiona
 Its name is derived from the Worker name, with any dashes replaced with underscores.
 This name can be used to reference the environment in your Vite config in order to apply environment specific configuration.
 
+:::note
+The default Vite environment name for a Worker is always the top-level Worker name.
+This enables you to reference the Worker consistently in your Vite config when using multiple [Cloudflare Environments](/workers/vite-plugin/cloudflare-environments/).
+:::
+
 ### Environment configuration
 
 In the following example we have a Worker named `my-worker` that is associated with a Vite environment named `my_worker`.