General improvements

Author: jamesopstad

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

@@ -34,8 +34,7 @@ vars = { MY_VAR = "Production var" }
 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'`.
-This is because the environment name is automatically appended to the top-level Worker name.
+The name of the Worker will be `'my-worker-production'` because the environment name is automatically appended to the top-level Worker name.
 
 :::note
 The default Vite environment name for a Worker is always the top-level Worker name.
@@ -48,7 +47,6 @@ It is common to use the default top-level environment as the development environ
 
 :::note
 Running `vite dev` or `vite build` without providing `CLOUDFLARE_ENV` will use the default top-level Cloudflare environment.
-The value of `MY_VAR` in the example above would therefore be `'Top-level var'`.
 As Cloudflare environments are applied at dev and build time, specifying `CLOUDFLARE_ENV` when running `vite preview` or `wrangler deploy` will have no effect.
 :::
 
@@ -98,4 +96,5 @@ Since the `.env.production` file contains `CLOUDFLARE_ENV=production`, the Cloud
 The value of `MY_VAR` will therefore be `'Production var'`.
 If you run `vite build --mode staging` then the 'staging' Vite mode will be used and the 'staging' Cloudflare environment will be selected.
 The value of `MY_VAR` will therefore be `'Staging var'`.
+
 For more information about using `.env` files with Vite, see the [relevant documentation](https://vite.dev/guide/env-and-mode#env-files).

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

@@ -13,7 +13,7 @@ There are two recommended methods for debugging your Workers during local develo
 
 ### DevTools
 
-When running `vite dev` or `vite preview`, a `/__debug` route is added that provides access to [Cloudflare's implementation](/packages/chrome-devtools-patches) of [Chrome's DevTools](https://developer.chrome.com/docs/devtools/overview).
+When running `vite dev` or `vite preview`, a `/__debug` route is added that provides access to [Cloudflare's implementation](https://github.com/cloudflare/workers-sdk/tree/main/packages/chrome-devtools-patches) of [Chrome's DevTools](https://developer.chrome.com/docs/devtools/overview).
 Navigating to this route will open a DevTools tab for each of the Workers in your application.
 
 Once the tab(s) are open, you can make a request to your application and start debugging your Worker code.
@@ -24,7 +24,7 @@ When debugging multiple Workers, you may need to allow your browser to open pop-
 
 ### VS Code
 
-To set up VS Code to support breakpoint debugging in your application, you should create a `.vscode/launch.json` file that contains the following configuration:
+To set up [VS Code](https://code.visualstudio.com/) to support breakpoint debugging in your application, you should create a `.vscode/launch.json` file that contains the following configuration:
 
 ```json
 {
@@ -54,7 +54,7 @@ Here, `<NAME_OF_WORKER>` indicates the name of the Worker as specified in your W
 If you have used the `inspectorPort` option to set a custom port then this should be the value provided in the `websocketaddress` field.
 
 :::note
-If you have more than one Worker in your application, you need to add a configuration in the `configurations` field for each and include the configuration name in the `compounds` `configurations` array.
+If you have more than one Worker in your application, you should add a configuration in the `configurations` field for each and include the configuration name in the `compounds` `configurations` array.
 :::
 
 With this set up, you can run `vite dev` or `vite preview` and then select **Debug Workers** at the top of the **Run & Debug** panel to start debugging.

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

@@ -7,17 +7,30 @@ sidebar:
 description: Migrating from wrangler dev to the Vite plugin
 ---
 
-Migrating from `wrangler dev` is a simple process and you can follow the instructions in [Get started](../get-started/).
+In most cases, migrating from `wrangler dev` is straightforward and you can follow the instructions in [Get started](../get-started/).
 There are a few key differences to highlight:
 
 ### Input and output Worker config files
 
-In the Vite integration, your Worker config file (for example, `wrangler.toml`) is the input configuration and a separate output configuration is created as part of the build.
+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.
+
+### Cloudflare Environments
+
+With the Cloudflare Vite plugin, Cloudflare environments are applied at dev and build time.
+Running `wrangler deploy --env some-env` is therefore not applicable and the environment to deploy should instead be set by running `CLOUDFLARE_ENV=some-env vite build`.
+See [Cloudflare Environments](../cloudflare-environments/) for more information.
 
 ### Redundant fields in the Wrangler config file
 
 There are various options in the Worker config file that are ignored when using Vite, as they are either no longer applicable or are replaced by Vite equivalents.
 If these options are provided, then warnings will be printed to the console with suggestions for how to proceed.
 Examples where the Vite configuration should be used instead include `alias` and `define`.
+See [Vite Environments](../vite-environments/) for more information about configuring your Worker environments in Vite.
+
+### Local only data during local development
+
+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 the future.

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

@@ -9,8 +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. If you are using [Cloudflare Environments](../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`.
+Secrets can be provided to your Worker in local development using a [`.dev.vars`](/workers/configuration/secrets/#local-development-with-secrets) file.
+If you are using [Cloudflare Environments](../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`.
 
 :::note
-The `vite build` command copies the relevant `.dev.vars[.env-name]` file to the output directory. This is only used when running `vite preview` and is not deployed with your Worker.
+The `vite build` command copies the relevant `.dev.vars` file to the output directory.
+This is only used when running `vite preview` and is not deployed with your Worker.
 :::

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

@@ -3,15 +3,36 @@ pcx_content_type: reference
 title: Static Assets
 head: []
 sidebar:
-  order: 3
+  order: 4
 description: Static assets with the Vite plugin
 ---
 
-When using the Cloudflare Vite plugin, it is the `client` environment that is deployed as your static assets.
-This will typically include files such as static HTML, front-end JavaScript, CSS, images and fonts.
+import { WranglerConfig } from "~/components";
+
+When using the Cloudflare Vite plugin, the `client` environment is deployed as your static assets.
+This typically includes files such as static HTML, front-end JavaScript, CSS, images and fonts.
+For more information about using static assets in Vite, refer to [Static Asset Handling](https://vite.dev/guide/assets).
+
+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.
 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.
 
-For more information about using static assets in Vite, see [Static Asset Handling](https://vite.dev/guide/assets).
+The `assets` configuration should be used, however, if you wish to set [routing configuration](/workers/static-assets/routing/#routing-configuration) or enable the [assets binding](/workers/static-assets/binding/#binding).
+The following example configures the `not_found_handling` for a single-page application so that the fallback will always be the root `index.html` file.
+
+<WranglerConfig>
+
+```toml
+assets = { not_found_handling = "single-page-application" }
+```
+
+</WranglerConfig>
+
+:::note
+The Cloudflare Vite plugin does not support [run_worker_first](/workers/static-assets/binding/#run_worker_first).
+:::
+
+{/* Add docs for _headers and _redirects */}

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

@@ -3,7 +3,7 @@ pcx_content_type: reference
 title: Vite Environments
 head: []
 sidebar:
-  order: 4
+  order: 3
 description: Vite environments and the Vite plugin
 ---
 
@@ -15,12 +15,14 @@ It is not necessary to understand all the intricacies of the Environment API as
 ### Default behavior
 
 Vite creates two environments by default: `client` and `ssr`.
-A front-end only application uses just the `client` environment, whereas a full-stack application created with a framework typically uses the `client` environment for front-end code and the `ssr` environment for server-side rendering.
+A front-end only application uses the `client` environment, whereas a full-stack application created with a framework typically uses the `client` environment for front-end code and the `ssr` environment for server-side rendering.
 
 By default, when you add a Worker using the Cloudflare Vite plugin, an additional environment is created.
 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.
 
+### Environment configuration
+
 In the following example we have a Worker named `my-worker` that is associated with a Vite environment named `my_worker`.
 We use the Vite config to set global constant replacements for this environment:
 
@@ -54,7 +56,7 @@ export default defineConfig({
 
 For more information about Vite's configuration options, see [Configuring Vite](https://vite.dev/config/).
 
-The default behavior of using the Worker name as the environment name is appropriate when you have a standalone Worker, such as an API that is accessed from your front-end application, or an [auxiliary Worker](../api#interface-pluginconfig) that is accessed via service bindings.
+The default behavior of using the Worker name as the environment name is appropriate when you have a standalone Worker, such as an API that is accessed from your front-end application, or an [auxiliary Worker](../api/#interface-pluginconfig) that is accessed via service bindings.
 
 ### React Router v7
 
@@ -73,4 +75,4 @@ export default defineConfig({
 });
 ```
 
-This merges the configuration with the framework's SSR configuration and ensures that the Worker is included as part of the framework's build output.
+This merges the Worker's environment configuration with the framework's SSR configuration and ensures that the Worker is included as part of the framework's build output.