update wrangler config docs to include vite plugin (#21137)

* aliasing as example

* note when not applicable to vite plugin

* fixups

* revert notice about upload_source_maps

* shorten asset routing summary

* some assets updates

* update links and env notes

* Apply suggestions from code review

* update routing summary

* Update src/content/docs/workers/static-assets/index.mdx

Co-authored-by: James Opstad <[email protected]>

* Apply suggestions from code review

Co-authored-by: James Opstad <[email protected]>

---------

Co-authored-by: James Opstad <[email protected]>

Author: emily-shen

src/content/docs/workers/static-assets/index.mdx

@@ -59,6 +59,10 @@ The **assets directory** specified in your [Wrangler configuration file](/worker
 
 </WranglerConfig>
 
+:::note
+If you are using the [Cloudflare Vite plugin](/workers/vite-plugin/), you do not need to specify `assets.directory`. For more information about using static assets with the Vite plugin, refer to the [plugin documentation](/workers/vite-plugin/reference/static-assets/).
+:::
+
 By adding an [**assets binding**](/workers/static-assets/binding/#binding), you can directly fetch and serve assets within your Worker code.
 
 ```js {13}

src/content/docs/workers/wrangler/commands.mdx

@@ -515,6 +515,7 @@ None of the options for this command are required. Also, many can be set in your
   - Skip Wrangler's build steps. Particularly useful when using custom builds. Refer to [Bundling](https://developers.cloudflare.com/workers/wrangler/bundling/) for more information.
 - `--env` <Type text="string" /> <MetaInfo text="optional" />
   - Perform on a specific environment.
+    <Render file="vite-environments" />
 - `--outdir` <Type text="string" /> <MetaInfo text="optional" />
   - Path to directory where Wrangler will write the bundled Worker files.
 - `--compatibility-date` <Type text="string" /> <MetaInfo text="optional" />
@@ -1415,6 +1416,9 @@ wrangler versions upload [OPTIONS]
   - Add a version message. Accepts empty string.
 - `--name` <Type text="string" /> <MetaInfo text="optional" />
   - Perform on a specific Worker rather than inheriting from the [Wrangler configuration file](/workers/wrangler/configuration/).
+- `--env` <Type text="string" /> <MetaInfo text="optional" />
+  - Perform on a specific environment.
+    <Render file="vite-environments" />
 
 <Render file="wrangler-commands/global-flags" product="workers" />
 

src/content/docs/workers/wrangler/configuration.mdx

@@ -61,6 +61,8 @@ The majority of keys are inheritable, meaning that top-level configuration can b
 
 Further, there are a few keys that can _only_ appear at the top-level.
 
+<Render file="vite-environments" />
+
 ## Top-level only keys
 
 Top-level keys apply to the Worker as a whole (and therefore all environments). They cannot be defined within named environments.
@@ -80,6 +82,7 @@ Top-level keys apply to the Worker as a whole (and therefore all environments).
 - `site` <Type text="object" /> <MetaInfo text="optional deprecated" />
 
   - See the [Workers Sites](#workers-sites) section below for more information. Cloudflare Pages and Workers Assets is preferred over this approach.
+  - This is not supported by the [Cloudflare Vite plugin](/workers/vite-plugin/).
 
 ## Inheritable keys
 
@@ -129,6 +132,7 @@ At a minimum, the `name`, `main` and `compatibility_date` keys are required to d
 - `tsconfig` <Type text="string" /> <MetaInfo text="optional" />
 
   - Path to a custom `tsconfig`.
+  - Not applicable if you're using the [Cloudflare Vite plugin](/workers/vite-plugin/).
 
 - `triggers` <Type text="object" /> <MetaInfo text="optional" />
 
@@ -137,35 +141,42 @@ At a minimum, the `name`, `main` and `compatibility_date` keys are required to d
 - `rules` <Type text="Rule" /> <MetaInfo text="optional" />
 
   - An ordered list of rules that define which modules to import, and what type to import them as. You will need to specify rules to use `Text`, `Data` and `CompiledWasm` modules, or when you wish to have a `.js` file be treated as an `ESModule` instead of `CommonJS`.
+  - Not applicable if you're using the [Cloudflare Vite plugin](/workers/vite-plugin/).
 
 - `build` <Type text="Build" /> <MetaInfo text="optional" />
 
   - Configures a custom build step to be run by Wrangler when building your Worker. Refer to [Custom builds](#custom-builds).
+  - Not applicable if you're using the [Cloudflare Vite plugin](/workers/vite-plugin/).
 
 - `no_bundle` <Type text="boolean" /> <MetaInfo text="optional" />
 
   - Skip internal build steps and directly deploy your Worker script. You must have a plain JavaScript Worker with no dependencies.
+  - Not applicable if you're using the [Cloudflare Vite plugin](/workers/vite-plugin/).
 
 - `find_additional_modules` <Type text="boolean" /> <MetaInfo text="optional" />
 
   - If true then Wrangler will traverse the file tree below `base_dir`.
     Any files that match `rules` will be included in the deployed Worker.
     Defaults to true if `no_bundle` is true, otherwise false.
     Can only be used with Module format Workers (not Service Worker format).
+  - Not applicable if you're using the [Cloudflare Vite plugin](/workers/vite-plugin/).
 
 - `base_dir` <Type text="string" /> <MetaInfo text="optional" />
 
   - The directory in which module "rules" should be evaluated when including additional files (via `find_additional_modules`) into a Worker deployment. Defaults to the directory containing the `main` entry point of the Worker if not specified.
+  - Not applicable if you're using the [Cloudflare Vite plugin](/workers/vite-plugin/).
 
 - `preserve_file_names` <Type text="boolean" /> <MetaInfo text="optional" />
 
   - Determines whether Wrangler will preserve the file names of additional modules bundled with the Worker.
     The default is to prepend filenames with a content hash.
     For example, `34de60b44167af5c5a709e62a4e20c4f18c9e3b6-favicon.ico`.
+  - Not applicable if you're using the [Cloudflare Vite plugin](/workers/vite-plugin/).
 
 - `minify` <Type text="boolean" /> <MetaInfo text="optional" />
 
   - Minify the Worker script before uploading.
+  - If you're using the [Cloudflare Vite plugin](/workers/vite-plugin/), `minify` is replaced by Vite's [`build.minify`](https://vite.dev/config/build-options.html#build-minify).
 
 - `logpush` <Type text="boolean" /> <MetaInfo text="optional" />
 
@@ -192,6 +203,7 @@ Non-inheritable keys are configurable at the top-level, but cannot be inherited
 - `define` <Type text="Record<string, string>" /> <MetaInfo text="optional" />
 
   - A map of values to substitute when deploying your Worker.
+  - If you're using the [Cloudflare Vite plugin](/workers/vite-plugin/), `define` is replaced by Vite's [`define`](https://vite.dev/config/shared-options.html#define).
 
 - `vars` <Type text="object" /> <MetaInfo text="optional" />
 
@@ -372,6 +384,10 @@ head_sampling_rate = 0.1 # 10% of requests are logged
 
 ## Custom builds
 
+:::note
+Not applicable if you're using the [Cloudflare Vite plugin](/workers/vite-plugin/).
+:::
+
 You can configure a custom build step that will be run before your Worker is deployed. Refer to [Custom builds](/workers/wrangler/custom-builds/).
 
 - `command` <Type text="string" /> <MetaInfo text="optional" />
@@ -988,9 +1004,10 @@ You can only configure one collection of assets per Worker.
 
 The following options are available under the `assets` key.
 
-- `directory` <Type text="string" /> <MetaInfo text="required" />
+- `directory` <Type text="string" /> <MetaInfo text="optional" />
 
   - Folder of static assets to be served.
+  - Not required if you're using the [Cloudflare Vite plugin](/workers/vite-plugin/), which will automatically point to the client build output.
 
 - `binding` <Type text="string" /> <MetaInfo text="optional" />
 
@@ -1020,6 +1037,10 @@ assets = { directory = "./public", binding = "ASSETS", html_handling = "force-tr
 
 ## Bundling
 
+:::note
+Wrangler bundling is not applicable if you're using the [Cloudflare Vite plugin](/workers/vite-plugin/).
+:::
+
 Wrangler can operate in two modes: the default bundling mode and `--no-bundle` mode.
 In bundling mode, Wrangler will traverse all the imports of your code and generate a single JavaScript "entry-point" file.
 Imported source code is "inlined/bundled" into this entry-point file.
@@ -1077,6 +1098,10 @@ See https://developers.cloudflare.com/workers/wrangler/bundling/ for more detail
 
 ## Local development settings
 
+:::note
+If you're using the [Cloudflare Vite plugin](/workers/vite-plugin/), you should use Vite's [server options]](https://vite.dev/config/server-options.html) instead.
+:::
+
 You can configure various aspects of local development, such as the local protocol or port.
 
 - `ip` <Type text="string" /> <MetaInfo text="optional" />
@@ -1120,6 +1145,10 @@ local_protocol = "http"
 
 ## Module Aliasing
 
+:::note
+If you're using the [Cloudflare Vite plugin](/workers/vite-plugin/), `alias` is replaced Vite's [`resolve.alias`](https://vite.dev/config/shared-options.html#resolve-alias).
+:::
+
 You can configure Wrangler to replace all calls to import a particular package with a module of your choice, by configuring the `alias` field:
 
 <WranglerConfig>
@@ -1280,6 +1309,8 @@ This section describes a feature that can be implemented by frameworks and other
 
 It is unlikely that an application developer will need to use this feature, but it is documented here to help you understand when Wrangler is using a generated configuration rather than the original, user's configuration.
 
+For example, when using the [Cloudflare Vite plugin](/workers/vite-plugin/), an output Worker configuration file is generated as part of the build. This is then used for preview and deployment.
+
 :::
 
 Some framework tools, or custom pre-build processes, generate a modified Wrangler configuration to be used to deploy the Worker code.

src/content/docs/workers/wrangler/environments.mdx

@@ -5,52 +5,52 @@ head: []
 description: Use environments to create different configurations for the same Worker application.
 ---
 
-import { WranglerConfig } from "~/components";
+import { WranglerConfig, Render, Steps } from "~/components";
 
 Wrangler allows you to use environments to create different configurations for the same Worker application. Environments are configured in the Worker's [Wrangler configuration file](/workers/wrangler/configuration/).
-There is a default (top-level) environment and you can create named environments that provide environment-specific configuration.
+
+When you create an environment, Cloudflare effectively creates a new Worker with the name `<top-level-name>-<environment-name>`. For example, a Worker project named `my-worker` with an environment `dev` would deploy as a Worker named `my-worker-dev`.
 
 Review the following environments flow:
 
+<Steps>
 1. Create a Worker, named `my-worker` for example.
 2. Create an environment, for example `dev`, in the Worker's [Wrangler configuration file](/workers/wrangler/configuration/), by adding a `[env.<ENV_NAME>]` section.
 
-<WranglerConfig>
+    <WranglerConfig>
 
-```json
-{
-	"name": "my-worker",
-	"env": {
-		"<ENV_NAME>": {
-			// environment-specific configuration goes here
-		}
-	}
-}
-```
+    ```json
+    {
+    	"name": "my-worker",
+    	"env": {
+    		"<ENV_NAME>": {
+    			// environment-specific configuration goes here
+    		}
+    	}
+    }
+    ```
+    </WranglerConfig>
 
-</WranglerConfig>
+3.  You can configure the `dev` environment with different values to the top-level environment. Refer [here](/workers/wrangler/configuration/#environments) for how different options are inherited - or not inherited - between environments.
+    For example, to set a different route for a Worker in the `dev` environment:
 
-3. You can configure the `dev` environment with different values to the top-level environment. Refer [here](/workers/wrangler/configuration/#environments) for how different options are inherited - or not inherited - between environments.
+    <WranglerConfig>
 
-For example, to set a different route for a Worker in the `dev` environment:
+    ```toml
+    name = "your-worker"
+    route = "example.com"
 
-<WranglerConfig>
+    [env.dev]
+    route = "dev.example.com"
+    ```
 
-```toml
-name = "your-worker"
-route = "example.com"
+    </WranglerConfig>
 
-[env.dev]
-route = "dev.example.com"
-```
+4.  Environments are used with the `--env` or `-e` flag on Wrangler commands. For example, you can develop the Worker in the `dev` environment by running `npx wrangler dev -e=dev`, and deploy it with `npx wrangler deploy -e=dev`.
 
-</WranglerConfig>
-4. Environments are used with the `--env` or `-e` flag on Wrangler commands. For example, you can develop the Worker in the `dev` environment by running `npx wrangler dev -e=dev`, and deploy it with `npx wrangler deploy -e=dev`.
+        <Render file="vite-environments" />
 
-:::note
-
-Cloudflare effectively creates a new Worker for you when you create a Worker with an environment. Wrangler appends the environment name to the top-level name. For example, a Worker project named `my-worker` with an environment `dev` would deploy a Worker named `my-worker-dev`. You must use this name when referencing a Worker in a particular environment, for example in a [service binding](/workers/wrangler/configuration/#service-bindings).
-:::
+</Steps>
 
 ## Non-inheritable keys and environments
 

src/content/partials/workers/vite-environments.mdx

@@ -0,0 +1,7 @@
+---
+{}
+---
+
+:::note
+If you're using the [Cloudflare Vite plugin](/workers/vite-plugin/), you select the environment at dev or build time via the `CLOUDFLARE_ENV` environment variable rather than the `--env` flag. Otherwise, environments are defined in your Worker config file as usual. For more detail on using environments with the Cloudflare Vite plugin, refer to the [plugin documentation](/workers/vite-plugin/reference/cloudflare-environments/).
+:::

src/content/partials/workers/workers-assets-routing-summary.mdx

@@ -2,12 +2,6 @@
 {}
 ---
 
-When using Workers Assets, Cloudflare will first attempt to serve any static assets which match the incoming request.
+By default, Cloudflare first tries to match a request path against a static asset path, which is based on the file structure of the uploaded asset directory. This is either the directory specified by `assets.directory` in your Wrangler config or, in the case of the [Cloudflare Vite plugin](/workers/vite-plugin/), the output directory of the client build. Failing that, we invoke a Worker if one is present. If there is no Worker, or the Worker then uses the asset binding, Cloudflare will fallback to the behaviour set by [`not_found_handling`](/workers/static-assets/routing/#not_found_handling).
 
-For example, if you have requests for `/logo.png` and `/blog/hello-world.html` in your assets directory, and make requests for `/logo.png` and `/blog/hello-world`, those files will be served respectively. The [`html_handling`](/workers/static-assets/routing/#html_handling) option allows you to customize the serving of HTML files if you have specific needs around redirects and trailing slashes.
-
-If a request does not match a static asset, Cloudflare will then invoke your Worker script module, if one is present. This can be configured with the [`main`](/workers/wrangler/configuration/#inheritable-keys) property in the [Wrangler configuration file](/workers/wrangler/configuration/).
-
-Finally, if a request does not match any static assets, and either a Worker script module is not present, or from within that Worker script module, the [asset binding](/workers/static-assets/binding/)'s `fetch` method is called (e.g. `env.ASSETS.fetch(request)`), Cloudflare will fall back to evaluating the [`not_found_handling`](/workers/static-assets/routing/#not_found_handling) behavior. By default, it will serve a null-body 404-status response, but this can be configured to instead serve custom HTML 404 pages, or to serve a single-page application (SPA).
-
-At present, there is no way to customize this routing behavior beyond the `html_handling` and `not_found_handling` options. We plan to offer additional configuration controls, such as allowing you to always run the Worker script modules for certain paths, in the future.
+Refer to the [routing documentation](/workers/static-assets/routing/#routing-configuration) for more information about how routing works with static assets, and how to customize this behavior.

src/content/partials/workers/workers_sites.mdx

@@ -1,9 +1,8 @@
 ---
 {}
-
 ---
 
 :::caution[Use Workers Static Assets Instead]
 
-You should use [Workers Static Assets](/workers/static-assets/) to host full-stack applications instead of Workers Sites. Do not use Workers Sites for new projects.
+You should use [Workers Static Assets](/workers/static-assets/) to host full-stack applications instead of Workers Sites. It has been deprecated in Wrangler v4, and the [Cloudflare Vite plugin](/workers/vite-plugin/) does not support Workers Sites. Do not use Workers Sites for new projects.
 :::