diff --git a/src/content/docs/workers/static-assets/index.mdx b/src/content/docs/workers/static-assets/index.mdx index f9060d13184c52b..35e1fbfa4f290bc 100644 --- a/src/content/docs/workers/static-assets/index.mdx +++ b/src/content/docs/workers/static-assets/index.mdx @@ -59,6 +59,10 @@ The **assets directory** specified in your [Wrangler configuration file](/worker +:::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} diff --git a/src/content/docs/workers/wrangler/commands.mdx b/src/content/docs/workers/wrangler/commands.mdx index f923b08d479ef23..2928ae791c87ff9 100644 --- a/src/content/docs/workers/wrangler/commands.mdx +++ b/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` - Perform on a specific environment. + - `--outdir` - Path to directory where Wrangler will write the bundled Worker files. - `--compatibility-date` @@ -1415,6 +1416,9 @@ wrangler versions upload [OPTIONS] - Add a version message. Accepts empty string. - `--name` - Perform on a specific Worker rather than inheriting from the [Wrangler configuration file](/workers/wrangler/configuration/). +- `--env` + - Perform on a specific environment. + diff --git a/src/content/docs/workers/wrangler/configuration.mdx b/src/content/docs/workers/wrangler/configuration.mdx index 4841af1240518ea..be52754d94a5c2b 100644 --- a/src/content/docs/workers/wrangler/configuration.mdx +++ b/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. + + ## 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` - 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` - Path to a custom `tsconfig`. + - Not applicable if you're using the [Cloudflare Vite plugin](/workers/vite-plugin/). - `triggers` @@ -137,14 +141,17 @@ At a minimum, the `name`, `main` and `compatibility_date` keys are required to d - `rules` - 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` - 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` - 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` @@ -152,20 +159,24 @@ At a minimum, the `name`, `main` and `compatibility_date` keys are required to d 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` - 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` - 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` - 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` @@ -189,6 +200,7 @@ Non-inheritable keys are configurable at the top-level, but cannot be inherited - `define` - 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` @@ -369,6 +381,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` @@ -985,9 +1001,10 @@ You can only configure one collection of assets per Worker. The following options are available under the `assets` key. -- `directory` +- `directory` - 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` @@ -1017,6 +1034,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. @@ -1074,6 +1095,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` @@ -1117,6 +1142,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: @@ -1277,6 +1306,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. diff --git a/src/content/docs/workers/wrangler/environments.mdx b/src/content/docs/workers/wrangler/environments.mdx index 3b4fa02624c2606..4e118875a586bed 100644 --- a/src/content/docs/workers/wrangler/environments.mdx +++ b/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 `-`. 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: + 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.]` section. - + -```json -{ - "name": "my-worker", - "env": { - "": { - // environment-specific configuration goes here - } - } -} -``` + ```json + { + "name": "my-worker", + "env": { + "": { + // environment-specific configuration goes here + } + } + } + ``` + - +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. + -For example, to set a different route for a Worker in the `dev` environment: + ```toml + name = "your-worker" + route = "example.com" - + [env.dev] + route = "dev.example.com" + ``` -```toml -name = "your-worker" -route = "example.com" + -[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`. - -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`. + -:::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). -::: + ## Non-inheritable keys and environments diff --git a/src/content/partials/workers/vite-environments.mdx b/src/content/partials/workers/vite-environments.mdx new file mode 100644 index 000000000000000..60b61e224b8298d --- /dev/null +++ b/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/). +::: diff --git a/src/content/partials/workers/workers-assets-routing-summary.mdx b/src/content/partials/workers/workers-assets-routing-summary.mdx index 0054a38e6a99684..5707edc5c7395a4 100644 --- a/src/content/partials/workers/workers-assets-routing-summary.mdx +++ b/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. diff --git a/src/content/partials/workers/workers_sites.mdx b/src/content/partials/workers/workers_sites.mdx index 0c32b6f127ba498..369db209e37b707 100644 --- a/src/content/partials/workers/workers_sites.mdx +++ b/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. :::