diff --git a/src/components/WranglerConfig.astro b/src/components/WranglerConfig.astro index 1a7e73936b4f5cf..2c671554010fb63 100644 --- a/src/components/WranglerConfig.astro +++ b/src/components/WranglerConfig.astro @@ -45,7 +45,7 @@ if (language === "toml") { --- - + diff --git a/src/content/changelogs-next/2025-01-26-worker-binding-methods.mdx b/src/content/changelogs-next/2025-01-26-worker-binding-methods.mdx index b2aca8abfe8569a..7d0f34f41c15e91 100644 --- a/src/content/changelogs-next/2025-01-26-worker-binding-methods.mdx +++ b/src/content/changelogs-next/2025-01-26-worker-binding-methods.mdx @@ -8,7 +8,7 @@ date: 2025-01-30T14:00:00Z We have released new [Workers bindings API methods](/ai-gateway/integrations/worker-binding-methods/), allowing you to connect Workers applications to AI Gateway directly. These methods simplify how Workers calls AI services behind your AI Gateway configurations, removing the need to use the REST API and manually authenticate. -To add an AI binding to your Worker, include the following in your `wrangler.toml` or `wrangler.json` file: +To add an AI binding to your Worker, include the following in your [Wrangler configuration file](/workers/wrangler/configuration/): ![Add an AI binding to your Worker.](~/assets/images/ai-gateway/add-binding.png) diff --git a/src/content/changelogs/queues.yaml b/src/content/changelogs/queues.yaml index 825169372613d86..981d1d5290edca2 100644 --- a/src/content/changelogs/queues.yaml +++ b/src/content/changelogs/queues.yaml @@ -64,7 +64,7 @@ entries: description: |- Queue consumers will soon automatically scale up concurrently as a queues' backlog grows in order to keep overall message processing latency down. Concurrency will be enabled on all existing queues by 2023-03-28. - **To opt-out, or to configure a fixed maximum concurrency**, set `max_concurrency = 1` in your `wrangler.toml / wrangler.json` file or via [the queues dashboard](https://dash.cloudflare.com/?to=/:account/queues). + **To opt-out, or to configure a fixed maximum concurrency**, set `max_concurrency = 1` in your [Wrangler configuration file](/workers/wrangler/configuration/) or via [the queues dashboard](https://dash.cloudflare.com/?to=/:account/queues). **To opt-in, you do not need to take any action**: your consumer will begin to scale out as needed to keep up with your message backlog. It will scale back down as the backlog shrinks, and/or if a consumer starts to generate a higher rate of errors. To learn more about how consumers scale, refer to the [consumer concurrency](/queues/configuration/consumer-concurrency/) documentation. - publish_date: "2023-03-02" diff --git a/src/content/docs/agents/capabilities/mcp-server.mdx b/src/content/docs/agents/capabilities/mcp-server.mdx index 3f88e7dde02e650..408f36f9c9007c8 100644 --- a/src/content/docs/agents/capabilities/mcp-server.mdx +++ b/src/content/docs/agents/capabilities/mcp-server.mdx @@ -99,7 +99,7 @@ This converts your Cloudflare Worker into an MCP server, enabling interactions w ### 5. Deploy the MCP Server -Update your wrangler.toml with the appropriate configuration then deploy your Worker: +Update your [Wrangler configuration file](/workers/wrangler/configuration/) with the appropriate configuration then deploy your Worker: ```bash wrangler deploy ``` diff --git a/src/content/docs/ai-gateway/integrations/aig-workers-ai-binding.mdx b/src/content/docs/ai-gateway/integrations/aig-workers-ai-binding.mdx index 882eb63cf433347..04ad7fdccf89bbd 100644 --- a/src/content/docs/ai-gateway/integrations/aig-workers-ai-binding.mdx +++ b/src/content/docs/ai-gateway/integrations/aig-workers-ai-binding.mdx @@ -35,7 +35,7 @@ Running `npm create cloudflare@latest` will prompt you to install the create-clo This will create a new `hello-ai` directory. Your new `hello-ai` directory will include: - A "Hello World" Worker at `src/index.ts`. -- A `wrangler.json` configuration file. +- A [Wrangler configuration file](/workers/wrangler/configuration/) Go to your application directory: @@ -47,7 +47,7 @@ cd hello-ai You must create an AI binding for your Worker to connect to Workers AI. Bindings allow your Workers to interact with resources, like Workers AI, on the Cloudflare Developer Platform. -To bind Workers AI to your Worker, add the following to the end of your `wrangler.json` file: +To bind Workers AI to your Worker, add the following to the end of your [Wrangler configuration file](/workers/wrangler/configuration/): @@ -70,7 +70,7 @@ Update the `index.ts` file in your `hello-ai` application directory with the fol ```typescript title="src/index.ts" {78-81} export interface Env { - // If you set another name in the `wrangler.toml / wrangler.json` file as the value for 'binding', + // If you set another name in the [Wrangler configuration file](/workers/wrangler/configuration/) as the value for 'binding', // replace "AI" with the variable name you defined. AI: Ai; } diff --git a/src/content/docs/ai-gateway/integrations/worker-binding-methods.mdx b/src/content/docs/ai-gateway/integrations/worker-binding-methods.mdx index ba107b2ae4a4f10..cda2f94e3263456 100644 --- a/src/content/docs/ai-gateway/integrations/worker-binding-methods.mdx +++ b/src/content/docs/ai-gateway/integrations/worker-binding-methods.mdx @@ -10,12 +10,11 @@ This guide provides an overview of how to use the latest Cloudflare Workers AI G ## Prerequisites -- Ensure your Worker project is configured with an AI Gateway binding in `wrangler.json`. - Install and use the `@cloudflare/workers-types` library, version `4.20250124.3` or above. ## 1. Add an AI Binding to your Worker -To connect your Worker to Workers AI, add the following to your `wrangler.toml` file: +To connect your Worker to Workers AI, add the following to your [Wrangler configuration file](/workers/wrangler/configuration/): import { WranglerConfig } from "~/components"; diff --git a/src/content/docs/analytics/analytics-engine/get-started.mdx b/src/content/docs/analytics/analytics-engine/get-started.mdx index a37dd476312dce9..6a7fcacdc8b463e 100644 --- a/src/content/docs/analytics/analytics-engine/get-started.mdx +++ b/src/content/docs/analytics/analytics-engine/get-started.mdx @@ -13,7 +13,7 @@ import { DirectoryListing, WranglerConfig } from "~/components" ## 1. Name your dataset and add it to your Worker -Add the following to your `wrangler.toml / wrangler.json` file to create a [binding](/workers/runtime-apis/bindings/) to a Workers Analytics Engine dataset. A dataset is like a table in SQL: the rows and columns should have consistent meaning. +Add the following to your [Wrangler configuration file](/workers/wrangler/configuration/) to create a [binding](/workers/runtime-apis/bindings/) to a Workers Analytics Engine dataset. A dataset is like a table in SQL: the rows and columns should have consistent meaning. diff --git a/src/content/docs/analytics/analytics-engine/worker-querying.mdx b/src/content/docs/analytics/analytics-engine/worker-querying.mdx index b45aaeaade67382..e2587510f338a4f 100644 --- a/src/content/docs/analytics/analytics-engine/worker-querying.mdx +++ b/src/content/docs/analytics/analytics-engine/worker-querying.mdx @@ -49,7 +49,7 @@ The following is a sample Worker which executes a query against a dataset of wea First the environment variables are set up with the account ID and API token. -The account ID is set in the `wrangler.toml / wrangler.json` file: +The account ID is set in the [Wrangler configuration file](/workers/wrangler/configuration/): diff --git a/src/content/docs/browser-rendering/get-started/browser-rendering-with-DO.mdx b/src/content/docs/browser-rendering/get-started/browser-rendering-with-DO.mdx index 6a40018be18649d..2468663d2116a48 100644 --- a/src/content/docs/browser-rendering/get-started/browser-rendering-with-DO.mdx +++ b/src/content/docs/browser-rendering/get-started/browser-rendering-with-DO.mdx @@ -71,9 +71,9 @@ After running the `list` command, you will see all bucket names, including the o ## 5. Configure your Wrangler configuration file -Configure your `browser-worker` project's [`wrangler.toml / wrangler.json` file](/workers/wrangler/configuration/) by adding a browser [binding](/workers/runtime-apis/bindings/) and a [Node.js compatibility flag](/workers/configuration/compatibility-flags/#nodejs-compatibility-flag). Browser bindings allow for communication between a Worker and a headless browser which allows you to do actions such as taking a screenshot, generating a PDF and more. +Configure your `browser-worker` project's [Wrangler configuration file](/workers/wrangler/configuration/) by adding a browser [binding](/workers/runtime-apis/bindings/) and a [Node.js compatibility flag](/workers/configuration/compatibility-flags/#nodejs-compatibility-flag). Browser bindings allow for communication between a Worker and a headless browser which allows you to do actions such as taking a screenshot, generating a PDF and more. -Update your `wrangler.toml / wrangler.json` file with the Browser Rendering API binding, the R2 bucket you created and a Durable Object: +Update your Wrangler configuration file with the Browser Rendering API binding, the R2 bucket you created and a Durable Object: diff --git a/src/content/docs/browser-rendering/get-started/reuse-sessions.mdx b/src/content/docs/browser-rendering/get-started/reuse-sessions.mdx index f6637b5678fb5f4..9c1f54f8d5ec77c 100644 --- a/src/content/docs/browser-rendering/get-started/reuse-sessions.mdx +++ b/src/content/docs/browser-rendering/get-started/reuse-sessions.mdx @@ -41,7 +41,7 @@ In your `browser-worker` directory, install Cloudflare's [fork of Puppeteer](/br npm install @cloudflare/puppeteer --save-dev ``` -## 3. Configure the `wrangler.toml / wrangler.json` file +## 3. Configure the [Wrangler configuration file](/workers/wrangler/configuration/) ```toml diff --git a/src/content/docs/browser-rendering/get-started/screenshots.mdx b/src/content/docs/browser-rendering/get-started/screenshots.mdx index 4f565bd92a68228..1c886af21d50499 100644 --- a/src/content/docs/browser-rendering/get-started/screenshots.mdx +++ b/src/content/docs/browser-rendering/get-started/screenshots.mdx @@ -56,11 +56,11 @@ npx wrangler kv:namespace create BROWSER_KV_DEMO --preview Take note of the IDs for the next step. -## 4. Configure the `wrangler.toml / wrangler.json` file +## 4. Configure the Wrangler configuration file -Configure your `browser-worker` project's [`wrangler.toml / wrangler.json` file](/workers/wrangler/configuration/) by adding a browser [binding](/workers/runtime-apis/bindings/) and a [Node.js compatibility flag](/workers/configuration/compatibility-flags/#nodejs-compatibility-flag). Bindings allow your Workers to interact with resources on the Cloudflare developer platform. Your browser `binding` name is set by you, this guide uses the name `MYBROWSER`. Browser bindings allow for communication between a Worker and a headless browser which allows you to do actions such as taking a screenshot, generating a PDF and more. +Configure your `browser-worker` project's [Wrangler configuration file](/workers/wrangler/configuration/) by adding a browser [binding](/workers/runtime-apis/bindings/) and a [Node.js compatibility flag](/workers/configuration/compatibility-flags/#nodejs-compatibility-flag). Bindings allow your Workers to interact with resources on the Cloudflare developer platform. Your browser `binding` name is set by you, this guide uses the name `MYBROWSER`. Browser bindings allow for communication between a Worker and a headless browser which allows you to do actions such as taking a screenshot, generating a PDF and more. -Update your `wrangler.toml / wrangler.json` file with the Browser Rendering API binding and the KV namespaces you created: +Update your [Wrangler configuration file](/workers/wrangler/configuration/) with the Browser Rendering API binding and the KV namespaces you created: diff --git a/src/content/docs/cloudflare-for-platforms/workers-for-platforms/configuration/outbound-workers.mdx b/src/content/docs/cloudflare-for-platforms/workers-for-platforms/configuration/outbound-workers.mdx index d3d86e065bef2bd..d78ba5d85db639e 100644 --- a/src/content/docs/cloudflare-for-platforms/workers-for-platforms/configuration/outbound-workers.mdx +++ b/src/content/docs/cloudflare-for-platforms/workers-for-platforms/configuration/outbound-workers.mdx @@ -23,7 +23,7 @@ Outbound Workers can be used to: To use Outbound Workers: 1. Create a Worker intended to serve as your Outbound Worker. -2. Outbound Worker can be specified as an optional parameter in the [dispatch namespaces](/cloudflare-for-platforms/workers-for-platforms/get-started/configuration/#2-create-a-dispatch-namespace) binding in a project's [wrangler.toml](/workers/wrangler/configuration/). Optionally, to pass data from your dynamic dispatch Worker to the Outbound Worker, the variable names can be specified under **parameters**. +2. Outbound Worker can be specified as an optional parameter in the [dispatch namespaces](/cloudflare-for-platforms/workers-for-platforms/get-started/configuration/#2-create-a-dispatch-namespace) binding in a project's [Wrangler configuration file](/workers/wrangler/configuration/). Optionally, to pass data from your dynamic dispatch Worker to the Outbound Worker, the variable names can be specified under **parameters**. Make sure that you have `wrangler@3.3.0` or later [installed](/workers/wrangler/install-and-update/). diff --git a/src/content/docs/cloudflare-for-platforms/workers-for-platforms/configuration/static-assets.mdx b/src/content/docs/cloudflare-for-platforms/workers-for-platforms/configuration/static-assets.mdx index 624df2b42564770..4412286ed8ff5e7 100644 --- a/src/content/docs/cloudflare-for-platforms/workers-for-platforms/configuration/static-assets.mdx +++ b/src/content/docs/cloudflare-for-platforms/workers-for-platforms/configuration/static-assets.mdx @@ -218,7 +218,11 @@ Once this PUT request succeeds, the files are served on the User Worker. Request If you prefer a CLI-based approach and your platform setup allows direct publishing, you can use Wrangler to deploy both your Worker code and static assets. Wrangler bundles and uploads static assets (from a specified directory) along with your Worker script, so you can manage everything in one place. -Create or update your `wrangler.toml` to specify where Wrangler should look for static files: +Create or update your [Wrangler configuration file](/workers/wrangler/configuration/) to specify where Wrangler should look for static files: + +import { WranglerConfig } from "~/components"; + + ```toml name = "my-static-site" @@ -230,6 +234,8 @@ directory = "./public" binding = "ASSETS" ``` + + * `directory`: The local folder containing your static files (for example, `./public`). * `binding`: The binding name used to reference these assets within your Worker code. diff --git a/src/content/docs/cloudflare-one/policies/access/external-evaluation.mdx b/src/content/docs/cloudflare-one/policies/access/external-evaluation.mdx index b5e3e1b6a0637e7..35a045c01022062 100644 --- a/src/content/docs/cloudflare-one/policies/access/external-evaluation.mdx +++ b/src/content/docs/cloudflare-one/policies/access/external-evaluation.mdx @@ -53,7 +53,7 @@ You can set up External Evaluation rules using any API service, but to get start id = "YOUR_KV_NAMESPACE_ID" ``` -4. Open the `wrangler.toml / wrangler.json` file in an editor and insert the following: +4. Open the [Wrangler configuration file](/workers/wrangler/configuration/) in an editor and insert the following: - `[[kv_namespaces]]`: Add the output generated in the previous step. - ``: your Cloudflare Zero Trust team name. @@ -139,7 +139,7 @@ To debug your External Evaluation rule: cd my-worker ``` -2. Open the `wrangler.toml / wrangler.json` file in an editor and set the `debug` variable to `TRUE`. +2. Open the [Wrangler configuration file](/workers/wrangler/configuration/) in an editor and set the `debug` variable to `TRUE`. 3. Deploy your changes. diff --git a/src/content/docs/cloudflare-one/tutorials/entra-id-risky-users.mdx b/src/content/docs/cloudflare-one/tutorials/entra-id-risky-users.mdx index 515c05a805c65de..72b43b1136efc23 100644 --- a/src/content/docs/cloudflare-one/tutorials/entra-id-risky-users.mdx +++ b/src/content/docs/cloudflare-one/tutorials/entra-id-risky-users.mdx @@ -80,7 +80,7 @@ To get started quickly, deploy our example Cloudflare Workers script by followin cd risky-users ``` -3. Modify the `wrangler.toml / wrangler.json` file to include the following values: +3. Modify the [Wrangler configuration file](/workers/wrangler/configuration/) to include the following values: - ``: your Cloudflare [account ID](/fundamentals/setup/find-account-and-zone-ids/). - ``: your Entra ID **Directory (tenant) ID**, obtained when [setting up Entra ID as an identity provider](#1-set-up-entra-id-as-an-identity-provider). diff --git a/src/content/docs/cloudflare-one/tutorials/extend-sso-with-workers.mdx b/src/content/docs/cloudflare-one/tutorials/extend-sso-with-workers.mdx index d917b8aa44e9af0..b0456fcefd2bfe5 100644 --- a/src/content/docs/cloudflare-one/tutorials/extend-sso-with-workers.mdx +++ b/src/content/docs/cloudflare-one/tutorials/extend-sso-with-workers.mdx @@ -185,7 +185,7 @@ Below is an example of a user identity that includes the `disk_encryption` and ` ## 3. Route the Worker to your application -In the `wrangler.toml / wrangler.json` file, [set up a route](/workers/configuration/routing/routes/) that maps the Worker to your Access application domain: +In the [Wrangler configuration file](/workers/wrangler/configuration/), [set up a route](/workers/configuration/routing/routes/) that maps the Worker to your Access application domain: diff --git a/src/content/docs/d1/best-practices/local-development.mdx b/src/content/docs/d1/best-practices/local-development.mdx index 98e2ed772a364cb..948ecee5bfe31c5 100644 --- a/src/content/docs/d1/best-practices/local-development.mdx +++ b/src/content/docs/d1/best-practices/local-development.mdx @@ -54,7 +54,7 @@ To start a local development session: [b] open a browser, [d] open Devtools, [l] turn off local mode, [c] clear console, [x] to exit ``` -In this example, the Worker has access to local-only D1 database. The corresponding D1 binding in your `wrangler.toml / wrangler.json` file would resemble the following: +In this example, the Worker has access to local-only D1 database. The corresponding D1 binding in your [Wrangler configuration file](/workers/wrangler/configuration/) would resemble the following: @@ -73,14 +73,14 @@ Refer to the [`wrangler dev` documentation](/workers/wrangler/commands/#dev) to ## Develop locally with Pages -You can only develop against a _local_ D1 database when using [Cloudflare Pages](/pages/) by creating a minimal `wrangler.toml / wrangler.json` file in the root of your Pages project. This can be useful when creating schemas, seeding data or otherwise managing a D1 database directly, without adding to your application logic. +You can only develop against a _local_ D1 database when using [Cloudflare Pages](/pages/) by creating a minimal [Wrangler configuration file](/workers/wrangler/configuration/) in the root of your Pages project. This can be useful when creating schemas, seeding data or otherwise managing a D1 database directly, without adding to your application logic. :::caution[Local development for remote databases] It is currently not possible to develop against a _remote_ D1 database when using [Cloudflare Pages](/pages/). ::: -your `wrangler.toml / wrangler.json` file should resemble the following: +Your [Wrangler configuration file](/workers/wrangler/configuration/) should resemble the following: diff --git a/src/content/docs/d1/configuration/environments.mdx b/src/content/docs/d1/configuration/environments.mdx index 18d9d451d4943d8..e3ec8ee00abbe92 100644 --- a/src/content/docs/d1/configuration/environments.mdx +++ b/src/content/docs/d1/configuration/environments.mdx @@ -34,7 +34,7 @@ In the code above, the `staging` environment is using a different database (`DAT ## Anatomy of Wrangler file -If you need to specify different D1 databases for different environments, your `wrangler.toml / wrangler.json` file may contain bindings that resemble the following: +If you need to specify different D1 databases for different environments, your [Wrangler configuration file](/workers/wrangler/configuration/) may contain bindings that resemble the following: diff --git a/src/content/docs/d1/examples/d1-and-hono.mdx b/src/content/docs/d1/examples/d1-and-hono.mdx index a77e6abc9dfed85..52fe30888509aa2 100644 --- a/src/content/docs/d1/examples/d1-and-hono.mdx +++ b/src/content/docs/d1/examples/d1-and-hono.mdx @@ -18,14 +18,14 @@ Hono is a fast web framework for building API-first applications, and it include When using Workers: -* Ensure you have configured your [`wrangler.toml / wrangler.json` file](/d1/get-started/#3-bind-your-worker-to-your-d1-database) to bind your D1 database to your Worker. +* Ensure you have configured your [Wrangler configuration file](/d1/get-started/#3-bind-your-worker-to-your-d1-database) to bind your D1 database to your Worker. * You can access your D1 databases via Hono's [`Context`](https://hono.dev/api/context) parameter: [bindings](https://hono.dev/getting-started/cloudflare-workers#bindings) are exposed on `context.env`. If you configured a [binding](/pages/functions/bindings/#d1-databases) named `DB`, then you would access [D1 Workers Binding API](/d1/worker-api/prepared-statements/) methods via `c.env.DB`. * Refer to the Hono documentation for [Cloudflare Workers](https://hono.dev/getting-started/cloudflare-workers). If you are using [Pages Functions](/pages/functions/): 1. Bind a D1 database to your [Pages Function](/pages/functions/bindings/#d1-databases). -2. Pass the `--d1 BINDING_NAME=DATABASE_ID` flag to `wrangler dev` when developing locally. `BINDING_NAME` should match what call in your code, and `DATABASE_ID` should match the `database_id` defined in your `wrangler.toml / wrangler.json` file: for example, `--d1 DB=xxxx-xxxx-xxxx-xxxx-xxxx`. +2. Pass the `--d1 BINDING_NAME=DATABASE_ID` flag to `wrangler dev` when developing locally. `BINDING_NAME` should match what call in your code, and `DATABASE_ID` should match the `database_id` defined in your Wrangler configuration file: for example, `--d1 DB=xxxx-xxxx-xxxx-xxxx-xxxx`. 3. Refer to the Hono guide for [Cloudflare Pages](https://hono.dev/getting-started/cloudflare-pages). The following examples show how to access a D1 database bound to `DB` from both a Workers script and a Pages Function: diff --git a/src/content/docs/d1/examples/d1-and-remix.mdx b/src/content/docs/d1/examples/d1-and-remix.mdx index bd706040910ea87..884afaad5fc09f4 100644 --- a/src/content/docs/d1/examples/d1-and-remix.mdx +++ b/src/content/docs/d1/examples/d1-and-remix.mdx @@ -20,7 +20,7 @@ To set up a new Remix site on Cloudflare Pages that can query D1: 1. **Refer to [the Remix guide](/pages/framework-guides/deploy-a-remix-site/)**. 2. Bind a D1 database to your [Pages Function](/pages/functions/bindings/#d1-databases). -3. Pass the `--d1 BINDING_NAME=DATABASE_ID` flag to `wrangler dev` when developing locally. `BINDING_NAME` should match what call in your code, and `DATABASE_ID` should match the `database_id` defined in your `wrangler.toml / wrangler.json` file: for example, `--d1 DB=xxxx-xxxx-xxxx-xxxx-xxxx`. +3. Pass the `--d1 BINDING_NAME=DATABASE_ID` flag to `wrangler dev` when developing locally. `BINDING_NAME` should match what call in your code, and `DATABASE_ID` should match the `database_id` defined in your [Wrangler configuration file](/workers/wrangler/configuration/): for example, `--d1 DB=xxxx-xxxx-xxxx-xxxx-xxxx`. The following example shows you how to define a Remix [`loader`](https://remix.run/docs/en/main/route/loader) that has a binding to a D1 database. diff --git a/src/content/docs/d1/examples/d1-and-sveltekit.mdx b/src/content/docs/d1/examples/d1-and-sveltekit.mdx index e2b9885736907b4..c7ae97a184f723c 100644 --- a/src/content/docs/d1/examples/d1-and-sveltekit.mdx +++ b/src/content/docs/d1/examples/d1-and-sveltekit.mdx @@ -22,7 +22,7 @@ To set up a new SvelteKit site on Cloudflare Pages that can query D1: 1. **Refer to [the SvelteKit guide](/pages/framework-guides/deploy-a-svelte-kit-site/) and Svelte's [Cloudflare adapter](https://kit.svelte.dev/docs/adapter-cloudflare)**. 2. Install the Cloudflare adapter within your SvelteKit project: `npm i -D @sveltejs/adapter-cloudflare`. 3. Bind a D1 database [to your Pages Function](/pages/functions/bindings/#d1-databases). -4. Pass the `--d1 BINDING_NAME=DATABASE_ID` flag to `wrangler dev` when developing locally. `BINDING_NAME` should match what call in your code, and `DATABASE_ID` should match the `database_id` defined in your `wrangler.toml / wrangler.json` file: for example, `--d1 DB=xxxx-xxxx-xxxx-xxxx-xxxx`. +4. Pass the `--d1 BINDING_NAME=DATABASE_ID` flag to `wrangler dev` when developing locally. `BINDING_NAME` should match what call in your code, and `DATABASE_ID` should match the `database_id` defined in your [Wrangler configuration file](/workers/wrangler/configuration/): for example, `--d1 DB=xxxx-xxxx-xxxx-xxxx-xxxx`. The following example shows you how to create a server endpoint configured to query D1. diff --git a/src/content/docs/d1/examples/query-d1-from-python-workers.mdx b/src/content/docs/d1/examples/query-d1-from-python-workers.mdx index a135c34270a1dd4..112aaebd81e5144 100644 --- a/src/content/docs/d1/examples/query-d1-from-python-workers.mdx +++ b/src/content/docs/d1/examples/query-d1-from-python-workers.mdx @@ -33,7 +33,7 @@ If you are new to Cloudflare Workers, refer to the [Get started guide](/workers/ ## Query from Python -This example assumes you have an existing D1 database. To allow your Python Worker to query your database, you first need to create a [binding](/workers/runtime-apis/bindings/) between your Worker and your D1 database and define this in your `wrangler.toml / wrangler.json` file. +This example assumes you have an existing D1 database. To allow your Python Worker to query your database, you first need to create a [binding](/workers/runtime-apis/bindings/) between your Worker and your D1 database and define this in your [Wrangler configuration file](/workers/wrangler/configuration/). You will need the `database_name` and `database_id` for a D1 database. You can use the `wrangler` CLI to create a new database or fetch the ID for an existing database as follows: @@ -119,8 +119,8 @@ Your Worker will be available at `https://python-and-d1.YOUR_SUBDOMAIN.workers.d If you receive an error deploying: -- Make sure you have configured your `wrangler.toml / wrangler.json` file with the `database_id` and `database_name` of a valid D1 database. -- Ensure `compatibility_flags = ["python_workers"]` is set in your `wrangler.toml / wrangler.json` file, which is required for Python. +- Make sure you have configured your [Wrangler configuration file](/workers/wrangler/configuration/) with the `database_id` and `database_name` of a valid D1 database. +- Ensure `compatibility_flags = ["python_workers"]` is set in your [Wrangler configuration file](/workers/wrangler/configuration/), which is required for Python. - Review the [list of error codes](/workers/observability/errors/), and ensure your code does not throw an uncaught exception. ## Next steps diff --git a/src/content/docs/d1/get-started.mdx b/src/content/docs/d1/get-started.mdx index db4a97528d73e45..7e11737a4f54a54 100644 --- a/src/content/docs/d1/get-started.mdx +++ b/src/content/docs/d1/get-started.mdx @@ -67,13 +67,13 @@ Create a new Worker as the means to query your database. - testconfig.json - vitest.config.mts - worker-configuration.d.ts - - **wrangler.json** + - **wrangler.jsonc** Your new `d1-tutorial` directory includes: - A `"Hello World"` [Worker](/workers/get-started/guide/#3-write-code) in `index.ts`. - - A [`wrangler.toml / wrangler.json` file](/workers/wrangler/configuration/). This file is how your `d1-tutorial` Worker accesses your D1 database. + - A [[Wrangler configuration file](/workers/wrangler/configuration/)](/workers/wrangler/configuration/). This file is how your `d1-tutorial` Worker accesses your D1 database. @@ -230,7 +230,7 @@ You create bindings by adding them to the Worker you have created. -After correctly preparing your `wrangler.toml / wrangler.json` file, set up your database. Use the example `schema.sql` file below to initialize your database. +After correctly preparing your [Wrangler configuration file](/workers/wrangler/configuration/), set up your database. Use the example `schema.sql` file below to initialize your database. 1. Copy the following code and save it as a `schema.sql` file in the `d1-tutorial` Worker directory you created in step 1: @@ -338,7 +338,7 @@ After you have set up your database, run an SQL query from within your Worker. In the code above, you: - 1. Define a binding to your D1 database in your TypeScript code. This binding matches the `binding` value you set in the `wrangler.toml / wrangler.json` file under `[[d1_databases]]`. + 1. Define a binding to your D1 database in your TypeScript code. This binding matches the `binding` value you set in the [Wrangler configuration file](/workers/wrangler/configuration/) under `[[d1_databases]]`. 2. Query your database using `env.DB.prepare` to issue a [prepared query](/d1/worker-api/d1-database/#prepare) with a placeholder (the `?` in the query). 3. Call `bind()` to safely and securely bind a value to that placeholder. In a real application, you would allow a user to define the `CompanyName` they want to list results for. Using `bind()` prevents users from executing arbitrary SQL (known as "SQL injection") against your application and deleting or otherwise modifying your database. 4. Execute the query by calling `all()` to return all rows (or none, if the query returns none). diff --git a/src/content/docs/d1/tutorials/build-a-comments-api/index.mdx b/src/content/docs/d1/tutorials/build-a-comments-api/index.mdx index aa97a6c69c271ab..68fcadf9e04de6a 100644 --- a/src/content/docs/d1/tutorials/build-a-comments-api/index.mdx +++ b/src/content/docs/d1/tutorials/build-a-comments-api/index.mdx @@ -88,7 +88,7 @@ You will now create a D1 database. In Wrangler v2, there is support for the `wra npx wrangler d1 create d1-example ``` -Reference your created database in your Worker code by creating a [binding](/workers/runtime-apis/bindings/) inside of your Wrangler file, Wrangler's configuration file. Bindings allow us to access Cloudflare resources, like D1 databases, KV namespaces, and R2 buckets, using a variable name in code. In the `wrangler.toml / wrangler.json` file, set up the binding `DB` and connect it to the `database_name` and `database_id`: +Reference your created database in your Worker code by creating a [binding](/workers/runtime-apis/bindings/) inside of your [Wrangler configuration file](/workers/wrangler/configuration/). Bindings allow us to access Cloudflare resources, like D1 databases, KV namespaces, and R2 buckets, using a variable name in code. In the Wrangler configuration file, set up the binding `DB` and connect it to the `database_name` and `database_id`: diff --git a/src/content/docs/d1/tutorials/build-a-staff-directory-app/index.mdx b/src/content/docs/d1/tutorials/build-a-staff-directory-app/index.mdx index ae25e1d87afd4a4..44a6aa5b53910a5 100644 --- a/src/content/docs/d1/tutorials/build-a-staff-directory-app/index.mdx +++ b/src/content/docs/d1/tutorials/build-a-staff-directory-app/index.mdx @@ -70,7 +70,7 @@ To create a database for your project, use the Cloudflare CLI tool, [Wrangler](/ npx wrangler d1 create staff-directory ``` -After creating your database, you will need to set up a [binding](/workers/runtime-apis/bindings/) in the `wrangler.toml / wrangler.json` file to integrate your database with your application. +After creating your database, you will need to set up a [binding](/workers/runtime-apis/bindings/) in the [Wrangler configuration file](/workers/wrangler/configuration/) to integrate your database with your application. This binding enables your application to interact with Cloudflare resources such as D1 databases, KV namespaces, and R2 buckets. To configure this, create a Wrangler file in your project's root directory and input the basic setup information: diff --git a/src/content/docs/d1/worker-api/d1-database.mdx b/src/content/docs/d1/worker-api/d1-database.mdx index 993939f1f33ce14..a870a5c2f94308b 100644 --- a/src/content/docs/d1/worker-api/d1-database.mdx +++ b/src/content/docs/d1/worker-api/d1-database.mdx @@ -11,7 +11,7 @@ To interact with your D1 database from your Worker, you need to access it throug ```js async fetch(request, env) { - // D1 database is 'env.DB', where "DB" is the binding name from the `wrangler.toml / wrangler.json` file. + // D1 database is 'env.DB', where "DB" is the binding name from the Wrangler configuration file. } ``` diff --git a/src/content/docs/developer-spotlight/tutorials/create-sitemap-from-sanity-cms.mdx b/src/content/docs/developer-spotlight/tutorials/create-sitemap-from-sanity-cms.mdx index 489c8529b48245e..64a764de0672514 100644 --- a/src/content/docs/developer-spotlight/tutorials/create-sitemap-from-sanity-cms.mdx +++ b/src/content/docs/developer-spotlight/tutorials/create-sitemap-from-sanity-cms.mdx @@ -74,11 +74,11 @@ yarn add @sanity/client ## Configure Wrangler -A default `wrangler.json` was generated in the previous step. +A default `wrangler.jsonc` was generated in the previous step. The Wrangler file is a configuration file used to specify project settings and deployment configurations in a structured format. -For this tutorial your `wrangler.toml / wrangler.json` file should be similar to the following: +For this tutorial your [Wrangler configuration file](/workers/wrangler/configuration/) should be similar to the following: @@ -102,7 +102,7 @@ You must update the `[vars]` section to match your needs. See the inline comment :::caution -Secrets do not belong in `wrangler.toml / wrangler.json` files. If you need to add secrets, use `.dev.vars` for local secrets and the `wranger secret put` command for deploying secrets. For more information, refer to [Secrets](/workers/configuration/secrets/). +Secrets do not belong in [Wrangler configuration file](/workers/wrangler/configuration/)s. If you need to add secrets, use `.dev.vars` for local secrets and the `wranger secret put` command for deploying secrets. For more information, refer to [Secrets](/workers/configuration/secrets/). ::: diff --git a/src/content/docs/developer-spotlight/tutorials/creating-a-recommendation-api.mdx b/src/content/docs/developer-spotlight/tutorials/creating-a-recommendation-api.mdx index 17fd82faf6b456f..2571d6548dd11e9 100644 --- a/src/content/docs/developer-spotlight/tutorials/creating-a-recommendation-api.mdx +++ b/src/content/docs/developer-spotlight/tutorials/creating-a-recommendation-api.mdx @@ -171,18 +171,18 @@ This API requires the use of Workers AI and Vectorize. To use these resources fr npx wrangler vectorize create stripe-products --dimensions=1024 --metric=cosine ``` -When this command executes successfully, you will see a message like the following. It provides the items you need to add to the `wrangler.toml / wrangler.json` file to bind the Vectorize index with your Worker application. Copy the three lines starting with `[[vectorize]]`. +When this command executes successfully, you will see a message like the following. It provides the items you need to add to the [Wrangler configuration file](/workers/wrangler/configuration/) to bind the Vectorize index with your Worker application. ```sh ✅ Successfully created a new Vectorize index: 'stripe-products' -📋 To start querying from a Worker, add the following binding configuration into 'wrangler.toml': +📋 To start querying from a Worker, add the following binding configuration into your Wrangler configuration file: [[vectorize]] binding = "VECTORIZE_INDEX" index_name = "stripe-products" ``` -To use the created Vectorize index from your Worker, let's add the binding. Open the `wrangler.toml / wrangler.json` file and add the copied lines. +To use the created Vectorize index from your Worker, let's add the binding. Open the [Wrangler configuration file](/workers/wrangler/configuration/) and add the copied lines. @@ -198,7 +198,7 @@ index_name = "stripe-products" -Additionally, let's add the configuration to use Workers AI in the `wrangler.toml / wrangler.json` file. +Additionally, let's add the configuration to use Workers AI in the [Wrangler configuration file](/workers/wrangler/configuration/). diff --git a/src/content/docs/developer-spotlight/tutorials/custom-access-control-for-files.mdx b/src/content/docs/developer-spotlight/tutorials/custom-access-control-for-files.mdx index 040332d4b8b92ee..06ff14a9b92c01e 100644 --- a/src/content/docs/developer-spotlight/tutorials/custom-access-control-for-files.mdx +++ b/src/content/docs/developer-spotlight/tutorials/custom-access-control-for-files.mdx @@ -110,7 +110,7 @@ bucket_name = "" Now that you have prepared the Wrangler configuration, you should update the `worker-configuration.d.ts` file to include the new bindings. This file will then provide TypeScript with the correct type definitions for the bindings, which allows for type checking and code completion in your editor. -You could either update it manually or run the following command in the directory of your project to update it automatically based on the `wrangler.toml / wrangler.json` file (recommended). +You could either update it manually or run the following command in the directory of your project to update it automatically based on the [Wrangler configuration file](/workers/wrangler/configuration/) (recommended). ```sh npm run cf-typegen diff --git a/src/content/docs/developer-spotlight/tutorials/fullstack-authentication-with-next-js-and-cloudflare-d1.mdx b/src/content/docs/developer-spotlight/tutorials/fullstack-authentication-with-next-js-and-cloudflare-d1.mdx index 228132595a51900..65196de17a89b35 100644 --- a/src/content/docs/developer-spotlight/tutorials/fullstack-authentication-with-next-js-and-cloudflare-d1.mdx +++ b/src/content/docs/developer-spotlight/tutorials/fullstack-authentication-with-next-js-and-cloudflare-d1.mdx @@ -130,7 +130,11 @@ Create a D1 database using the following command: npx wrangler d1 create auth-js-d1-example-db ``` -When finished you should see instructions to add the database binding to your `wrangler.toml`. Example binding: +When finished you should see instructions to add the database binding to your [Wrangler configuration file](/workers/wrangler/configuration/). Example binding: + +import { WranglerConfig} from "~/components"; + + ```toml title="wrangler.toml" [[d1_databases]] @@ -139,6 +143,8 @@ database_name = "auth-js-d1-example-db" database_id = "" ``` + + Now, within your `env.d.ts`, add your D1 binding, like: ```ts title="env.d.ts" diff --git a/src/content/docs/durable-objects/api/namespace.mdx b/src/content/docs/durable-objects/api/namespace.mdx index bafef513d287c3d..c7485363a6bf1ee 100644 --- a/src/content/docs/durable-objects/api/namespace.mdx +++ b/src/content/docs/durable-objects/api/namespace.mdx @@ -11,7 +11,7 @@ import { Render, Tabs, TabItem, GlossaryTooltip } from "~/components"; A Durable Object namespace is a set of Durable Objects that are backed by the same Durable Object class. There is only one Durable Object namespace per class. A Durable Object namespace can contain any number of Durable Objects. -The `DurableObjectNamespace` interface is used to obtain a reference to new or existing Durable Objects. The interface is accessible from the fetch handler on a Cloudflare Worker via the `env` parameter, which is the standard interface when referencing bindings declared in the `wrangler.toml / wrangler.json` file. +The `DurableObjectNamespace` interface is used to obtain a reference to new or existing Durable Objects. The interface is accessible from the fetch handler on a Cloudflare Worker via the `env` parameter, which is the standard interface when referencing bindings declared in the [Wrangler configuration file](/workers/wrangler/configuration/). This interface defines several [methods](/durable-objects/api/namespace/#methods) that can be used to create an ID for a Durable Object. Note that creating an ID for a Durable Object does not create the Durable Object. The Durable Object is created lazily after calling [`DurableObjectNamespace::get`](/durable-objects/api/namespace/#get) to create a [`DurableObjectStub`](/durable-objects/api/stub) from a `DurableObjectId`. This ensures that objects are not constructed until they are actually accessed. diff --git a/src/content/docs/durable-objects/api/webgpu.mdx b/src/content/docs/durable-objects/api/webgpu.mdx index 505513cddb5d397..8116272c01d2c14 100644 --- a/src/content/docs/durable-objects/api/webgpu.mdx +++ b/src/content/docs/durable-objects/api/webgpu.mdx @@ -15,7 +15,7 @@ The [WebGPU API](https://developer.mozilla.org/en-US/docs/Web/API/WebGPU_API) al The WebGPU API is only accessible from within [Durable Objects](/durable-objects/). You cannot use the WebGPU API from within Workers. -To use the WebGPU API in local development, enable the `experimental` and `webgpu` [compatibility flags](/workers/configuration/compatibility-flags/) in the [`wrangler.toml / wrangler.json` file](/workers/wrangler/configuration/) of your Durable Object. +To use the WebGPU API in local development, enable the `experimental` and `webgpu` [compatibility flags](/workers/configuration/compatibility-flags/) in the [Wrangler configuration file](/workers/wrangler/configuration/) of your Durable Object. ``` compatibility_flags = ["experimental", "webgpu"] diff --git a/src/content/docs/durable-objects/get-started/tutorial-with-sql-api.mdx b/src/content/docs/durable-objects/get-started/tutorial-with-sql-api.mdx index 4538c4c2fe25cef..d458fcbafcf88b1 100644 --- a/src/content/docs/durable-objects/get-started/tutorial-with-sql-api.mdx +++ b/src/content/docs/durable-objects/get-started/tutorial-with-sql-api.mdx @@ -58,7 +58,7 @@ Running `create cloudflare@latest` will install [Wrangler](/workers/wrangler/ins }} /> -This will create a new directory, which will include either a `src/index.js` or `src/index.ts` file to write your code and a [`wrangler.json`](/workers/wrangler/configuration/) configuration file. +This will create a new directory, which will include either a `src/index.js` or `src/index.ts` file to write your code and a [`wrangler.jsonc`](/workers/wrangler/configuration/) configuration file. Move into your new directory: @@ -203,7 +203,7 @@ Refer to [Access a Durable Object from a Worker](/durable-objects/best-practices ## 5. Configure Durable Object bindings -[Bindings](/workers/runtime-apis/bindings/) allow your Workers to interact with resources on the Cloudflare developer platform. The Durable Object bindings in your Worker project's `wrangler.toml / wrangler.json` file will include a binding name (for this guide, use `MY_DURABLE_OBJECT`) and the class name (`MyDurableObject`). +[Bindings](/workers/runtime-apis/bindings/) allow your Workers to interact with resources on the Cloudflare developer platform. The Durable Object bindings in your Worker project's [Wrangler configuration file](/workers/wrangler/configuration/) will include a binding name (for this guide, use `MY_DURABLE_OBJECT`) and the class name (`MyDurableObject`). diff --git a/src/content/docs/durable-objects/get-started/tutorial.mdx b/src/content/docs/durable-objects/get-started/tutorial.mdx index d45151975e4f623..8e6dc725af81c59 100644 --- a/src/content/docs/durable-objects/get-started/tutorial.mdx +++ b/src/content/docs/durable-objects/get-started/tutorial.mdx @@ -51,7 +51,7 @@ Running `create cloudflare@latest` will install [Wrangler](/workers/wrangler/ins }} /> -This will create a new directory, which will include either a `src/index.js` or `src/index.ts` file to write your code and a [`wrangler.json`](/workers/wrangler/configuration/) configuration file. +This will create a new directory, which will include either a `src/index.js` or `src/index.ts` file to write your code and a [`wrangler.jsonc`](/workers/wrangler/configuration/) configuration file. Move into your new directory: @@ -176,7 +176,7 @@ export default { ## 5. Configure Durable Object bindings -To allow a Worker to invoke methods on a Durable Object, the Worker must have a [Durable Object binding](/workers/runtime-apis/bindings/) in the project's [`wrangler.toml / wrangler.json` file](/workers/wrangler/configuration/#durable-objects). The binding is configured to use a particular Durable Object class. +To allow a Worker to invoke methods on a Durable Object, the Worker must have a [Durable Object binding](/workers/runtime-apis/bindings/) in the project's [Wrangler configuration file](/workers/wrangler/configuration/#durable-objects). The binding is configured to use a particular Durable Object class. diff --git a/src/content/docs/durable-objects/observability/troubleshooting.mdx b/src/content/docs/durable-objects/observability/troubleshooting.mdx index fc6b133c14130da..4b2ced33dbb8fad 100644 --- a/src/content/docs/durable-objects/observability/troubleshooting.mdx +++ b/src/content/docs/durable-objects/observability/troubleshooting.mdx @@ -21,7 +21,7 @@ In your Wrangler file, make sure the `dir` and `main` entries point to the corre ### Cannot apply `--delete-class` migration to class. -When deleting a migration using `npx wrangler deploy --delete-class `, you may encounter this error: `"Cannot apply --delete-class migration to class without also removing the binding that references it"`. You should remove the corresponding binding under `[durable_objects]` in the `wrangler.toml / wrangler.json` file before attempting to apply `--delete-class` again. +When deleting a migration using `npx wrangler deploy --delete-class `, you may encounter this error: `"Cannot apply --delete-class migration to class without also removing the binding that references it"`. You should remove the corresponding binding under `[durable_objects]` in the [Wrangler configuration file](/workers/wrangler/configuration/) before attempting to apply `--delete-class` again. ### Durable Object is overloaded. diff --git a/src/content/docs/durable-objects/tutorials/build-a-seat-booking-app/index.mdx b/src/content/docs/durable-objects/tutorials/build-a-seat-booking-app/index.mdx index bded7ea0797ab05..7c14d279427bc15 100644 --- a/src/content/docs/durable-objects/tutorials/build-a-seat-booking-app/index.mdx +++ b/src/content/docs/durable-objects/tutorials/build-a-seat-booking-app/index.mdx @@ -256,7 +256,7 @@ The frontend of the application is a simple HTML page that allows users to selec - It also uses a WebSocket connection to receive updates about the available seats. - When a user clicks on a seat, the `bookSeat()` function is called that prompts the user to enter their name and then makes a `POST` request to the `/book-seat` endpoint. -4. Update the bindings in the `wrangler.toml / wrangler.json` file to configure `assets` to serve the `public` directory. +4. Update the bindings in the [Wrangler configuration file](/workers/wrangler/configuration/) to configure `assets` to serve the `public` directory. @@ -281,9 +281,9 @@ npm run dev ## 3. Create table for each flight -The application already has the binding for the Durable Objects class configured in the `wrangler.toml / wrangler.json` file. If you update the name of the Durable Objects class in `src/index.ts`, make sure to also update the binding in the `wrangler.toml / wrangler.json` file. +The application already has the binding for the Durable Objects class configured in the [Wrangler configuration file](/workers/wrangler/configuration/). If you update the name of the Durable Objects class in `src/index.ts`, make sure to also update the binding in the [Wrangler configuration file](/workers/wrangler/configuration/). -1. Update the binding to use the SQLite storage in Durable Objects. In the `wrangler.toml / wrangler.json` file, replace `new_classes=["Flight"]` with `new_sqlite_classes=["Flight"]`, `name = "FLIGHT"` with `name = "FLIGHT"`, and `class_name = "MyDurableObject"` with `class_name = "Flight"`. your `wrangler.toml / wrangler.json` file should look like this: +1. Update the binding to use the SQLite storage in Durable Objects. In the [Wrangler configuration file](/workers/wrangler/configuration/), replace `new_classes=["Flight"]` with `new_sqlite_classes=["Flight"]`, `name = "FLIGHT"` with `name = "FLIGHT"`, and `class_name = "MyDurableObject"` with `class_name = "Flight"`. your [Wrangler configuration file](/workers/wrangler/configuration/) should look like this: diff --git a/src/content/docs/email-routing/email-workers/send-email-workers.mdx b/src/content/docs/email-routing/email-workers/send-email-workers.mdx index 76791896858b53d..8c7fca94cf5e4f0 100644 --- a/src/content/docs/email-routing/email-workers/send-email-workers.mdx +++ b/src/content/docs/email-routing/email-workers/send-email-workers.mdx @@ -8,7 +8,7 @@ sidebar: import { Render, WranglerConfig } from "~/components" - + diff --git a/src/content/docs/hyperdrive/configuration/connect-to-postgres.mdx b/src/content/docs/hyperdrive/configuration/connect-to-postgres.mdx index 8c1f1afe5ccc21e..f9f56a18fdf0364 100644 --- a/src/content/docs/hyperdrive/configuration/connect-to-postgres.mdx +++ b/src/content/docs/hyperdrive/configuration/connect-to-postgres.mdx @@ -26,7 +26,7 @@ When using wrangler, replace the placeholder value provided to `--connection-str npx wrangler hyperdrive create my-first-hyperdrive --connection-string="postgres://user:password@database.host.example.com:5432/databasenamehere" ``` -The command above will output the ID of your Hyperdrive, which you will need to set in the `wrangler.toml / wrangler.json` file for your Workers project: +The command above will output the ID of your Hyperdrive, which you will need to set in the [Wrangler configuration file](/workers/wrangler/configuration/) for your Workers project: @@ -108,7 +108,7 @@ Install the `node-postgres` driver: npm install pg ``` -**Ensure you have `compatibility_flags` and `compatibility_date` set in your `wrangler.toml / wrangler.json` file** as shown below: +**Ensure you have `compatibility_flags` and `compatibility_date` set in your [Wrangler configuration file](/workers/wrangler/configuration/)** as shown below: @@ -118,7 +118,7 @@ Create a new `Client` instance and pass the Hyperdrive parameters: import { Client } from "pg"; export interface Env { - // If you set another name in the `wrangler.toml / wrangler.json` file as the value for 'binding', + // If you set another name in the Wrangler configuration file as the value for 'binding', // replace "HYPERDRIVE" with the variable name you defined. HYPERDRIVE: Hyperdrive; } diff --git a/src/content/docs/hyperdrive/configuration/local-development.mdx b/src/content/docs/hyperdrive/configuration/local-development.mdx index 7f566e156f8bcc5..9ae649bed84d4e6 100644 --- a/src/content/docs/hyperdrive/configuration/local-development.mdx +++ b/src/content/docs/hyperdrive/configuration/local-development.mdx @@ -21,10 +21,10 @@ If you are new to Hyperdrive and/or Cloudflare Workers, refer to [Hyperdrive tut To specify a database to connect to when developing locally, you can: -- **Recommended** Create a `WRANGLER_HYPERDRIVE_LOCAL_CONNECTION_STRING_` environmental variable with the connection string of your database. `` is the name of the binding assigned to your Hyperdrive in your `wrangler.toml / wrangler.json` file or Pages configuration. This allows you to avoid committing potentially sensitive credentials to source control in your `wrangler.toml / wrangler.json` file, if your test/development database is not ephemeral. If you have configured multiple Hyperdrive bindings, replace `` with the unique binding name for each. -- Set `localConnectionString` in the `wrangler.toml / wrangler.json` file. +- **Recommended** Create a `WRANGLER_HYPERDRIVE_LOCAL_CONNECTION_STRING_` environmental variable with the connection string of your database. `` is the name of the binding assigned to your Hyperdrive in your [Wrangler configuration file](/workers/wrangler/configuration/) or Pages configuration. This allows you to avoid committing potentially sensitive credentials to source control in your Wrangler configuration file, if your test/development database is not ephemeral. If you have configured multiple Hyperdrive bindings, replace `` with the unique binding name for each. +- Set `localConnectionString` in the Wrangler configuration file. -If both the `WRANGLER_HYPERDRIVE_LOCAL_CONNECTION_STRING_` environmental variable and `localConnectionString` in the `wrangler.toml / wrangler.json` file are set, `wrangler dev` will use the environmental variable instead. Use `unset WRANGLER_HYPERDRIVE_LOCAL_CONNECTION_STRING_` to unset any existing environmental variables. +If both the `WRANGLER_HYPERDRIVE_LOCAL_CONNECTION_STRING_` environmental variable and `localConnectionString` in the Wrangler configuration file are set, `wrangler dev` will use the environmental variable instead. Use `unset WRANGLER_HYPERDRIVE_LOCAL_CONNECTION_STRING_` to unset any existing environmental variables. For example, to use the environmental variable, export the environmental variable before running `wrangler dev`: @@ -35,7 +35,7 @@ export WRANGLER_HYPERDRIVE_LOCAL_CONNECTION_STRING_TEST_DB="postgres://user:pass npx wrangler dev ``` -To configure a `localConnectionString` in the `wrangler.toml / wrangler.json` file, ensure your Hyperdrive bindings have a `localConnectionString` property set: +To configure a `localConnectionString` in the [Wrangler configuration file](/workers/wrangler/configuration/), ensure your Hyperdrive bindings have a `localConnectionString` property set: diff --git a/src/content/docs/hyperdrive/configuration/rotate-credentials.mdx b/src/content/docs/hyperdrive/configuration/rotate-credentials.mdx index 80c13884e0950c8..b4fe8345f20236d 100644 --- a/src/content/docs/hyperdrive/configuration/rotate-credentials.mdx +++ b/src/content/docs/hyperdrive/configuration/rotate-credentials.mdx @@ -23,7 +23,7 @@ To create a Hyperdrive configuration that connects to an existing PostgreSQL dat npx wrangler hyperdrive create my-updated-hyperdrive --connection-string="" ``` -The command above will output the ID of your Hyperdrive. Set this ID in the `wrangler.toml / wrangler.json` file for your Workers project: +The command above will output the ID of your Hyperdrive. Set this ID in the [Wrangler configuration file](/workers/wrangler/configuration/) for your Workers project: diff --git a/src/content/docs/hyperdrive/get-started.mdx b/src/content/docs/hyperdrive/get-started.mdx index 67e115acd617242..d16b4eda708978e 100644 --- a/src/content/docs/hyperdrive/get-started.mdx +++ b/src/content/docs/hyperdrive/get-started.mdx @@ -72,7 +72,7 @@ Create a new project named `hyperdrive-tutorial` by running: This will create a new `hyperdrive-tutorial` directory. Your new `hyperdrive-tutorial` directory will include: - A `"Hello World"` [Worker](/workers/get-started/guide/#3-write-code) at `src/index.ts`. -- A [`wrangler.json`](/workers/wrangler/configuration/) configuration file. `wrangler.json` is how your `hyperdrive-tutorial` Worker will connect to Hyperdrive. +- A [`wrangler.jsonc`](/workers/wrangler/configuration/) configuration file. `wrangler.jsonc` is how your `hyperdrive-tutorial` Worker will connect to Hyperdrive. ### Enable Node.js compatibility diff --git a/src/content/docs/kv/concepts/kv-bindings.mdx b/src/content/docs/kv/concepts/kv-bindings.mdx index f0998ba208a3ea2..7a1f5d4c4f8298b 100644 --- a/src/content/docs/kv/concepts/kv-bindings.mdx +++ b/src/content/docs/kv/concepts/kv-bindings.mdx @@ -9,7 +9,7 @@ import { WranglerConfig } from "~/components"; KV [bindings](/workers/runtime-apis/bindings/) allow for communication between a Worker and a KV namespace. -Configure KV bindings in the [wrangler.toml file](/workers/wrangler/configuration/). +Configure KV bindings in the [Wrangler configuration file](/workers/wrangler/configuration/). ## Access KV from Workers @@ -23,7 +23,7 @@ A KV namespace will have a name you choose (for example, `My tasks`), and an ass To execute your Worker, define the binding. -In the following example, the binding is called `TODO`. In the `kv_namespaces` portion of your Wrangler file, add: +In the following example, the binding is called `TODO`. In the `kv_namespaces` portion of your Wrangler configuration file, add: diff --git a/src/content/docs/kv/get-started.mdx b/src/content/docs/kv/get-started.mdx index e3e22e1a1852fd4..4fed2fe922e065b 100644 --- a/src/content/docs/kv/get-started.mdx +++ b/src/content/docs/kv/get-started.mdx @@ -61,13 +61,13 @@ Create a new Worker to read and write to your KV namespace. - testconfig.json - vitest.config.mts - worker-configuration.d.ts - - **wrangler.json** + - **wrangler.jsonc** Your new `kv-tutorial` directory includes: - A `"Hello World"` [Worker](/workers/get-started/guide/#3-write-code) in `index.ts`. - - A [`wrangler.json`](/workers/wrangler/configuration/) configuration file. `wrangler.json` is how your `kv-tutorial` Worker accesses your kv database. + - A [`wrangler.jsonc`](/workers/wrangler/configuration/) configuration file. `wrangler.jsonc` is how your `kv-tutorial` Worker accesses your kv database. 2. Change into the directory you just created for your Worker project: diff --git a/src/content/docs/learning-paths/workers/get-started/c3-and-wrangler.mdx b/src/content/docs/learning-paths/workers/get-started/c3-and-wrangler.mdx index 49ab962c55310ae..6a5472200ff9670 100644 --- a/src/content/docs/learning-paths/workers/get-started/c3-and-wrangler.mdx +++ b/src/content/docs/learning-paths/workers/get-started/c3-and-wrangler.mdx @@ -35,9 +35,9 @@ When you run C3 to create your project, C3 will install the latest version of Wr ## Source of truth -If you are building your Worker on the Cloudflare dashboard, you will set up your project configuration (such as environment variables, bindings, and routes) through the dashboard. If you are building your project programmatically using C3 and Wrangler, you will rely on a [`wrangler.toml / wrangler.json` file](/workers/wrangler/configuration/) to configure your Worker. +If you are building your Worker on the Cloudflare dashboard, you will set up your project configuration (such as environment variables, bindings, and routes) through the dashboard. If you are building your project programmatically using C3 and Wrangler, you will rely on a [Wrangler configuration file](/workers/wrangler/configuration/) to configure your Worker. -Cloudflare recommends choosing and using one [source of truth](/workers/wrangler/configuration/#source-of-truth), the dashboard or the `wrangler.toml / wrangler.json` file (for example, `wrangler.json` or `wrangler.toml`), to avoid errors in your project. +Cloudflare recommends choosing and using one [source of truth](/workers/wrangler/configuration/#source-of-truth), the dashboard or the [Wrangler configuration file](/workers/wrangler/configuration/), to avoid errors in your project. ## Summary diff --git a/src/content/docs/learning-paths/workers/get-started/first-worker.mdx b/src/content/docs/learning-paths/workers/get-started/first-worker.mdx index 95607ff6a881916..b7ce7227218c56d 100644 --- a/src/content/docs/learning-paths/workers/get-started/first-worker.mdx +++ b/src/content/docs/learning-paths/workers/get-started/first-worker.mdx @@ -53,7 +53,7 @@ Refer to [How to run Wrangler commands](/workers/wrangler/commands/#how-to-run-w In your Worker project directory, C3 has generated the following: -1. `wrangler.json`: Your [Wrangler](/workers/wrangler/configuration/#sample-wrangler-configuration) configuration file. +1. `wrangler.jsonc`: Your [Wrangler](/workers/wrangler/configuration/#sample-wrangler-configuration) configuration file. 2. `index.js` (in `/src`): A minimal `'Hello World!'` Worker written in [ES module](/workers/reference/migrate-to-module-workers/) syntax. 3. `package.json`: A minimal Node dependencies configuration file. 4. `package-lock.json`: Refer to [`npm` documentation on `package-lock.json`](https://docs.npmjs.com/cli/v9/configuring-npm/package-lock-json). diff --git a/src/content/docs/pages/framework-guides/deploy-a-nuxt-site.mdx b/src/content/docs/pages/framework-guides/deploy-a-nuxt-site.mdx index 49d97532ca141ab..cbe281566ed2223 100644 --- a/src/content/docs/pages/framework-guides/deploy-a-nuxt-site.mdx +++ b/src/content/docs/pages/framework-guides/deploy-a-nuxt-site.mdx @@ -107,7 +107,7 @@ export default defineNuxtConfig({ }); ``` -This module is powered by the [`getPlatformProxy` helper function](/workers/wrangler/api#getplatformproxy). `getPlatformProxy` will automatically detect any bindings defined in your project's Wrangler file and emulate those bindings in local development. Review [Wrangler configuration information on bindings](/workers/wrangler/configuration/#bindings) for more information on how to configure bindings in the `wrangler.toml / wrangler.json` file. +This module is powered by the [`getPlatformProxy` helper function](/workers/wrangler/api#getplatformproxy). `getPlatformProxy` will automatically detect any bindings defined in your project's Wrangler configuration file and emulate those bindings in local development. Review [Wrangler configuration information on bindings](/workers/wrangler/configuration/#bindings) for more information on how to configure bindings in the [Wrangler configuration file](/workers/wrangler/configuration/). :::note diff --git a/src/content/docs/pages/framework-guides/deploy-a-remix-site.mdx b/src/content/docs/pages/framework-guides/deploy-a-remix-site.mdx index 0cdf9866f6a49c3..b1e5bb506540528 100644 --- a/src/content/docs/pages/framework-guides/deploy-a-remix-site.mdx +++ b/src/content/docs/pages/framework-guides/deploy-a-remix-site.mdx @@ -96,7 +96,7 @@ export const loader = ({ context }: LoaderFunctionArgs) => { :::note[Correcting the env type] -You may have noticed that `context.cloudflare.env` is not typed correctly when you add additional bindings in the `wrangler.toml / wrangler.json` file. +You may have noticed that `context.cloudflare.env` is not typed correctly when you add additional bindings in the [Wrangler configuration file](/workers/wrangler/configuration/). To fix this, run `npm run typegen` to generate the missing types. This will update the `Env` interface defined in `worker-configuration.d.ts`. After running the command, you can access the bindings in your `loader` or `action` using `context.cloudflare.env` as shown above. diff --git a/src/content/docs/pages/framework-guides/deploy-an-analog-site.mdx b/src/content/docs/pages/framework-guides/deploy-an-analog-site.mdx index 3336165a25f0d36..25fc4ed68644297 100644 --- a/src/content/docs/pages/framework-guides/deploy-an-analog-site.mdx +++ b/src/content/docs/pages/framework-guides/deploy-an-analog-site.mdx @@ -104,7 +104,7 @@ export default defineNitroPlugin((nitroApp: NitroApp) => { In the code above, the `getPlatformProxy` helper function will automatically detect any bindings defined in your project's Wrangler file and emulate those bindings in local development. You may wish to refer to [Wrangler configuration information on bindings](/workers/wrangler/configuration/#bindings). -A new type definition for the `Env` type (used by `context.cloudflare.env`) can be generated from the `wrangler.toml / wrangler.json` file with the following command: +A new type definition for the `Env` type (used by `context.cloudflare.env`) can be generated from the [Wrangler configuration file](/workers/wrangler/configuration/) with the following command: ```sh npm run cf-typegen diff --git a/src/content/docs/pages/framework-guides/nextjs/ssr/bindings.mdx b/src/content/docs/pages/framework-guides/nextjs/ssr/bindings.mdx index b42f422b139da98..572423a57ad9729 100644 --- a/src/content/docs/pages/framework-guides/nextjs/ssr/bindings.mdx +++ b/src/content/docs/pages/framework-guides/nextjs/ssr/bindings.mdx @@ -26,7 +26,7 @@ export async function GET(request) { } ``` -Add bindings to your Pages project by [adding them to your `wrangler.toml / wrangler.json` file](/pages/functions/wrangler-configuration/). +Add bindings to your Pages project by adding them to your [Wrangler configuration file](/pages/functions/wrangler-configuration/). ## TypeScript type declarations for bindings diff --git a/src/content/docs/pages/framework-guides/nextjs/ssr/get-started.mdx b/src/content/docs/pages/framework-guides/nextjs/ssr/get-started.mdx index 87d20e861dce355..c67842aea210279 100644 --- a/src/content/docs/pages/framework-guides/nextjs/ssr/get-started.mdx +++ b/src/content/docs/pages/framework-guides/nextjs/ssr/get-started.mdx @@ -45,7 +45,7 @@ npm install --save-dev @cloudflare/next-on-pages ### 2. Add Wrangler file -Then, add a [`wrangler.toml / wrangler.json` file](/pages/functions/wrangler-configuration/) to the root directory of your Next.js app: +Then, add a [Wrangler configuration file](/pages/functions/wrangler-configuration/) to the root directory of your Next.js app: diff --git a/src/content/docs/pages/functions/bindings.mdx b/src/content/docs/pages/functions/bindings.mdx index 8aab6bf601c3a24..85593237fc3fc23 100644 --- a/src/content/docs/pages/functions/bindings.mdx +++ b/src/content/docs/pages/functions/bindings.mdx @@ -21,7 +21,7 @@ Pages Functions only support a subset of all [bindings](/workers/runtime-apis/bi [Workers KV](/kv/concepts/kv-namespaces/) is Cloudflare's key-value storage solution. -To bind your KV namespace to your Pages Function, you can configure a KV namespace binding in the [`wrangler.toml / wrangler.json` file](/pages/functions/wrangler-configuration/#kv-namespaces) or the Cloudflare dashboard. +To bind your KV namespace to your Pages Function, you can configure a KV namespace binding in the [Wrangler configuration file](/pages/functions/wrangler-configuration/#kv-namespaces) or the Cloudflare dashboard. To configure a KV namespace binding via the Cloudflare dashboard: @@ -80,7 +80,7 @@ npx wrangler pages dev --kv=TODO_LIST -To bind your Durable Object to your Pages Function, you can configure a Durable Object binding in the [`wrangler.toml / wrangler.json` file](/pages/functions/wrangler-configuration/#kv-namespaces) or the Cloudflare dashboard. +To bind your Durable Object to your Pages Function, you can configure a Durable Object binding in the [Wrangler configuration file](/pages/functions/wrangler-configuration/#kv-namespaces) or the Cloudflare dashboard. To configure a Durable Object binding via the Cloudflare dashboard: @@ -143,7 +143,7 @@ For example, if your Worker is called `do-worker` and it declares a Durable Obje [R2](/r2/) is Cloudflare's blob storage solution that allows developers to store large amounts of unstructured data without the egress fees. -To bind your R2 bucket to your Pages Function, you can configure a R2 bucket binding in the [`wrangler.toml / wrangler.json` file](/pages/functions/wrangler-configuration/#r2-buckets) or the Cloudflare dashboard. +To bind your R2 bucket to your Pages Function, you can configure a R2 bucket binding in the [Wrangler configuration file](/pages/functions/wrangler-configuration/#r2-buckets) or the Cloudflare dashboard. To configure a R2 bucket binding via the Cloudflare dashboard: @@ -214,7 +214,7 @@ Interact with this binding by using `context.env` (for example, `context.env.BUC [D1](/d1/) is Cloudflare’s native serverless database. -To bind your D1 database to your Pages Function, you can configure a D1 database binding in the [`wrangler.toml / wrangler.json` file](/pages/functions/wrangler-configuration/#d1-databases) or the Cloudflare dashboard. +To bind your D1 database to your Pages Function, you can configure a D1 database binding in the [Wrangler configuration file](/pages/functions/wrangler-configuration/#d1-databases) or the Cloudflare dashboard. To configure a D1 database binding via the Cloudflare dashboard: @@ -289,7 +289,7 @@ Refer to the [D1 Workers Binding API documentation](/d1/worker-api/) for the API [Vectorize](/vectorize/) is Cloudflare’s native vector database. -To bind your Vectorize index to your Pages Function, you can configure a Vectorize index binding in the [`wrangler.toml / wrangler.json` file](/pages/functions/wrangler-configuration/#vectorize-indexes) or the Cloudflare dashboard. +To bind your Vectorize index to your Pages Function, you can configure a Vectorize index binding in the [Wrangler configuration file](/pages/functions/wrangler-configuration/#vectorize-indexes) or the Cloudflare dashboard. To configure a Vectorize index binding via the Cloudflare dashboard: @@ -426,7 +426,7 @@ export const onRequest: PagesFunction = async (context) => { [Workers AI](/workers-ai/) allows you to run machine learning models, powered by serverless GPUs, on Cloudflare’s global network. -To bind Workers AI to your Pages Function, you can configure a Workers AI binding in the [`wrangler.toml / wrangler.json` file](/pages/functions/wrangler-configuration/#workers-ai) or the Cloudflare dashboard. +To bind Workers AI to your Pages Function, you can configure a Workers AI binding in the [Wrangler configuration file](/pages/functions/wrangler-configuration/#workers-ai) or the Cloudflare dashboard. When developing locally using Wrangler, you can define an AI binding using the `--ai` flag. Start Wrangler in development mode by running [`wrangler pages dev --ai AI`](/workers/wrangler/commands/#dev) to expose the `context.env.AI` binding. @@ -500,7 +500,7 @@ npx wrangler pages dev --ai= [Service bindings](/workers/runtime-apis/bindings/service-bindings/) enable you to call a Worker from within your Pages Function. -To bind your Pages Function to a Worker, configure a Service binding in your Pages Function using the [`wrangler.toml / wrangler.json` file](/pages/functions/wrangler-configuration/#service-bindings) or the Cloudflare dashboard. +To bind your Pages Function to a Worker, configure a Service binding in your Pages Function using the [Wrangler configuration file](/pages/functions/wrangler-configuration/#service-bindings) or the Cloudflare dashboard. To configure a Service binding via the Cloudflare dashboard: @@ -555,7 +555,7 @@ For example, to develop locally, if your Worker is called `my-worker`, run `npx [Queue Producers](/queues/configuration/javascript-apis/#producer) enable you to send messages into a queue within your Pages Function. -To bind a queue to your Pages Function, configure a queue producer binding in your Pages Function using the [`wrangler.toml / wrangler.json` file](/pages/functions/wrangler-configuration/#queues-producers) or the Cloudflare dashboard: +To bind a queue to your Pages Function, configure a queue producer binding in your Pages Function using the [Wrangler configuration file](/pages/functions/wrangler-configuration/#queues-producers) or the Cloudflare dashboard: To configure a queue producer binding via the Cloudflare dashboard: @@ -626,7 +626,7 @@ compatibility_date = "2024-09-23" [Hyperdrive](/hyperdrive/) is a service for connecting to your existing databases from Cloudflare Workers and Pages Functions. -To bind your Hyperdrive config to your Pages Function, you can configure a Hyperdrive binding in the [`wrangler.toml / wrangler.json` file](/pages/functions/wrangler-configuration/#hyperdrive) or the Cloudflare dashboard. +To bind your Hyperdrive config to your Pages Function, you can configure a Hyperdrive binding in the [Wrangler configuration file](/pages/functions/wrangler-configuration/#hyperdrive) or the Cloudflare dashboard. To configure a Hyperdrive binding via the Cloudflare dashboard: 1. Log in to the [Cloudflare dashboard](https://dash.cloudflare.com) and select your account. @@ -697,7 +697,7 @@ To interact with your Hyperdrive binding locally, you must provide a local conne The [Analytics Engine](/analytics/analytics-engine/) binding enables you to write analytics within your Pages Function. -To bind an Analytics Engine dataset to your Pages Function, you must configure an Analytics Engine binding using the [`wrangler.toml / wrangler.json` file](/pages/functions/wrangler-configuration/#analytics-engine-datasets) or the Cloudflare dashboard: +To bind an Analytics Engine dataset to your Pages Function, you must configure an Analytics Engine binding using the [Wrangler configuration file](/pages/functions/wrangler-configuration/#analytics-engine-datasets) or the Cloudflare dashboard: To configure an Analytics Engine binding via the Cloudflare dashboard: @@ -757,7 +757,7 @@ You cannot use an Analytics Engine binding locally. An [environment variable](/workers/configuration/environment-variables/) is an injected value that can be accessed by your Functions. Environment variables are a type of binding that allow you to attach text strings or JSON values to your Pages Function. It is stored as plain text. Set your environment variables directly within the Cloudflare dashboard for both your production and preview environments at runtime and build-time. -To add environment variables to your Pages project, you can use the [`wrangler.toml / wrangler.json` file](/pages/functions/wrangler-configuration/#environment-variables) or the Cloudflare dashboard. +To add environment variables to your Pages project, you can use the [Wrangler configuration file](/pages/functions/wrangler-configuration/#environment-variables) or the Cloudflare dashboard. To configure an environment variable via the Cloudflare dashboard: diff --git a/src/content/docs/pages/functions/local-development.mdx b/src/content/docs/pages/functions/local-development.mdx index 8c430386201310c..cf587570e9f7d8b 100644 --- a/src/content/docs/pages/functions/local-development.mdx +++ b/src/content/docs/pages/functions/local-development.mdx @@ -25,13 +25,13 @@ This will then start serving your Pages project. You can press `b` to open the b :::note -If you have a [`wrangler.toml / wrangler.json` file](/pages/functions/wrangler-configuration/) file configured for your Pages project, you can run [`wrangler pages dev`](/workers/wrangler/commands/#dev-1) without specifying a directory. +If you have a [Wrangler configuration file](/pages/functions/wrangler-configuration/) file configured for your Pages project, you can run [`wrangler pages dev`](/workers/wrangler/commands/#dev-1) without specifying a directory. ::: ### HTTPS support -To serve your local development server over HTTPS with a self-signed certificate, you can [set `local_protocol` via the `wrangler.toml / wrangler.json` file](/pages/functions/wrangler-configuration/#local-development-settings) or you can pass the `--local-protocol=https` argument to [`wrangler pages dev`](/workers/wrangler/commands/#dev-1): +To serve your local development server over HTTPS with a self-signed certificate, you can [set `local_protocol` via the [Wrangler configuration file](/pages/functions/wrangler-configuration/#local-development-settings) or you can pass the `--local-protocol=https` argument to [`wrangler pages dev`](/workers/wrangler/commands/#dev-1): ```sh npx wrangler pages dev --local-protocol=https diff --git a/src/content/docs/pages/functions/source-maps.mdx b/src/content/docs/pages/functions/source-maps.mdx index 1878e223f979ab9..50e442fe032d0e5 100644 --- a/src/content/docs/pages/functions/source-maps.mdx +++ b/src/content/docs/pages/functions/source-maps.mdx @@ -23,7 +23,7 @@ Support for uploading source maps for Pages is available now in open beta. Minim ## Source Maps -To enable source maps, provide the `--upload-source-maps` flag to [`wrangler pages deploy`](/workers/wrangler/commands/#deploy-1) or add the following to your Pages application's [`wrangler.toml / wrangler.json` file](/pages/functions/wrangler-configuration/) if you are using the Pages build environment: +To enable source maps, provide the `--upload-source-maps` flag to [`wrangler pages deploy`](/workers/wrangler/commands/#deploy-1) or add the following to your Pages application's [Wrangler configuration file](/pages/functions/wrangler-configuration/) if you are using the Pages build environment: diff --git a/src/content/docs/pages/functions/wrangler-configuration.mdx b/src/content/docs/pages/functions/wrangler-configuration.mdx index 00afd598fbf7441..bee663c7461a9e6 100644 --- a/src/content/docs/pages/functions/wrangler-configuration.mdx +++ b/src/content/docs/pages/functions/wrangler-configuration.mdx @@ -9,23 +9,23 @@ import { Render, TabItem, Tabs, Type, MetaInfo, WranglerConfig } from "~/compone :::caution -If your project contains an existing Wrangler file that you [previously used for local development](/pages/functions/local-development/), make sure you verify that it matches your project settings in the Cloudflare dashboard before opting-in to deploy your Pages project with the `wrangler.toml / wrangler.json` file. Instead of writing your Wrangler file by hand, Cloudflare recommends using `npx wrangler pages download config` to download your current project settings into a Wrangler file. +If your project contains an existing Wrangler file that you [previously used for local development](/pages/functions/local-development/), make sure you verify that it matches your project settings in the Cloudflare dashboard before opting-in to deploy your Pages project with the Wrangler configuration file. Instead of writing your Wrangler file by hand, Cloudflare recommends using `npx wrangler pages download config` to download your current project settings into a Wrangler file. ::: -Pages Functions can be configured two ways, either via the [Cloudflare dashboard](https://dash.cloudflare.com) or the `wrangler.toml / wrangler.json` file, a file used to customize the development and deployment setup for [Workers](/workers/) and Pages Functions. +:::note -This page serves as a reference on how to configure your Pages project via the `wrangler.toml / wrangler.json` file. +As of Wrangler v3.91.0, Wrangler supports both JSON (`wrangler.json` or `wrangler.jsonc`) and TOML (`wrangler.toml`) for its configuration file. Prior to that version, only `wrangler.toml` was supported. -If using a `wrangler.toml / wrangler.json` file, you must treat your file as the [source of truth](/pages/functions/wrangler-configuration/#source-of-truth) for your Pages project configuration. +::: -:::note[Configuration via the `wrangler.toml / wrangler.json` file is in open beta.] +Pages Functions can be configured two ways, either via the [Cloudflare dashboard](https://dash.cloudflare.com) or the Wrangler configuration file, a file used to customize the development and deployment setup for [Workers](/workers/) and Pages Functions. -Cloudflare welcomes your feedback. Join the #functions channel in the [Cloudflare Developers Discord](https://discord.com/invite/cloudflaredev) to report bugs and request features. +This page serves as a reference on how to configure your Pages project via the Wrangler configuration file. -::: +If using a Wrangler configuration file, you must treat your file as the [source of truth](/pages/functions/wrangler-configuration/#source-of-truth) for your Pages project configuration. -Using the `wrangler.toml / wrangler.json` file to configure your Pages project allows you to: +Using the Wrangler configuration file to configure your Pages project allows you to: - **Store your configuration file in source control:** Keep your configuration in your repository alongside the rest of your code. - **Edit your configuration via your code editor:** Remove the need to switch back and forth between interfaces. @@ -59,11 +59,11 @@ API_KEY = "1234567asdf" ### V2 build system -Pages Functions configuration via the `wrangler.toml / wrangler.json` file requires the [V2 build system](/pages/configuration/build-image/#v2-build-system) or later. To update from V1, refer to the [V2 build system migration instructions](/pages/configuration/build-image/#v1-to-v2-migration). +Pages Functions configuration via the Wrangler configuration file requires the [V2 build system](/pages/configuration/build-image/#v2-build-system) or later. To update from V1, refer to the [V2 build system migration instructions](/pages/configuration/build-image/#v1-to-v2-migration). ### Wrangler -You must have Wrangler version 3.45.0 or higher to use a `wrangler.toml / wrangler.json` file for your Pages project's configuration. To check your Wrangler version, update Wrangler or install Wrangler, refer to [Install/Update Wrangler](/workers/wrangler/install-and-update/). +You must have Wrangler version 3.45.0 or higher to use a Wrangler configuration file for your Pages project's configuration. To check your Wrangler version, update Wrangler or install Wrangler, refer to [Install/Update Wrangler](/workers/wrangler/install-and-update/). ## Migrate from dashboard configuration @@ -71,9 +71,9 @@ The migration instructions for Pages projects that do not have a Wrangler file c ### Projects with existing Wrangler file -Before you could use the `wrangler.toml / wrangler.json` file to define your preview and production configuration, it was possible to use the file to define which [bindings](/pages/functions/bindings/) should be available to your Pages project in local development. +Before you could use the Wrangler configuration file to define your preview and production configuration, it was possible to use the file to define which [bindings](/pages/functions/bindings/) should be available to your Pages project in local development. -If you have been using a `wrangler.toml / wrangler.json` file for local development, you may already have a file in your Pages project that looks like this: +If you have been using a Wrangler configuration file for local development, you may already have a file in your Pages project that looks like this: @@ -90,7 +90,7 @@ If you would like to use your existing Wrangler file for your Pages project conf 1. Add the `pages_build_output_dir` key with the appropriate value of your [build output directory](/pages/configuration/build-configuration/#build-commands-and-directories) (for example, `pages_build_output_dir = "./dist"`.) 2. Review your existing Wrangler configuration carefully to make sure it aligns with your desired project configuration before deploying. -If you add the `pages_build_output_dir` key to your `wrangler.toml / wrangler.json` file and deploy your Pages project, Pages will use whatever configuration was defined for local use, which is very likely to be non-production. Do not deploy until you are confident that your `wrangler.toml / wrangler.json` file is ready for production use. +If you add the `pages_build_output_dir` key to your Wrangler configuration file and deploy your Pages project, Pages will use whatever configuration was defined for local use, which is very likely to be non-production. Do not deploy until you are confident that your Wrangler configuration file is ready for production use. :::caution[Overwriting configuration] @@ -124,32 +124,32 @@ pnpm wrangler pages download config -Review your generated Wrangler file. To start using the `wrangler.toml / wrangler.json` file for your Pages project's configuration, create a new deployment, via [Git integration](/pages/get-started/git-integration/) or [Direct Upload](/pages/get-started/direct-upload/). +Review your generated Wrangler file. To start using the Wrangler configuration file for your Pages project's configuration, create a new deployment, via [Git integration](/pages/get-started/git-integration/) or [Direct Upload](/pages/get-started/direct-upload/). ### Handling compatibility dates set to "Latest" In the Cloudflare dashboard, you can set compatibility dates for preview deployments to "Latest". This will ensure your project is always using the latest compatibility date without the need to explicitly set it yourself. -If you download a `wrangler.toml / wrangler.json` file from a project configured with "Latest" using the `wrangler pages download` command, your `wrangler.toml / wrangler.json` file will have the latest compatibility date available at the time you downloaded the configuration file. Wrangler does not support the "Latest" functionality like the dashboard. Compatibility dates must be explicitly set when using a `wrangler.toml / wrangler.json` file. +If you download a Wrangler configuration file from a project configured with "Latest" using the `wrangler pages download` command, your Wrangler configuration file will have the latest compatibility date available at the time you downloaded the configuration file. Wrangler does not support the "Latest" functionality like the dashboard. Compatibility dates must be explicitly set when using a Wrangler configuration file. Refer to [this guide](/workers/configuration/compatibility-dates/) for more information on what compatibility dates are and how they work. ## Differences using a Wrangler configuration file for Pages Functions and Workers -If you have used [Workers](/workers), you may already be familiar with the [`wrangler.toml / wrangler.json` file](/workers/wrangler/configuration/). There are a few key differences to be aware of when using this file with your Pages Functions project: +If you have used [Workers](/workers), you may already be familiar with the [Wrangler configuration file](/workers/wrangler/configuration/). There are a few key differences to be aware of when using this file with your Pages Functions project: -- The configuration fields **do not match exactly** between Pages Functions Wrangler file and the Workers equivalent. For example, configuration keys like `main`, which are Workers specific, do not apply to a Pages Function's `wrangler.toml / wrangler.json` file. Some functionality supported by Workers, such as [module aliasing](/workers/wrangler/configuration/#module-aliasing) cannot yet be used by Cloudflare Pages projects. -- The Pages' `wrangler.toml / wrangler.json` file introduces a new key, `pages_build_output_dir`, which is only used for Pages projects. +- The configuration fields **do not match exactly** between Pages Functions Wrangler file and the Workers equivalent. For example, configuration keys like `main`, which are Workers specific, do not apply to a Pages Function's Wrangler configuration file. Some functionality supported by Workers, such as [module aliasing](/workers/wrangler/configuration/#module-aliasing) cannot yet be used by Cloudflare Pages projects. +- The Pages' Wrangler configuration file introduces a new key, `pages_build_output_dir`, which is only used for Pages projects. - The concept of [environments](/pages/functions/wrangler-configuration/#configure-environments) and configuration inheritance in this file **is not** the same as Workers. - This file becomes the [source of truth](/pages/functions/wrangler-configuration/#source-of-truth) when used, meaning that you **can not edit the same fields in the dashboard** once you are using this file. ## Configure environments -With a `wrangler.toml / wrangler.json` file, you can quickly set configuration across your local environment, preview deployments, and production. +With a Wrangler configuration file, you can quickly set configuration across your local environment, preview deployments, and production. ### Local development -`wrangler.toml / wrangler.json` file works locally when using `wrangler pages dev`. This means that you can test out configuration changes quickly without a need to login to the Cloudflare dashboard. Refer to the following config file for an example: +The Wrangler configuration file applies locally when using `wrangler pages dev`. This means that you can test out configuration changes quickly without a need to login to the Cloudflare dashboard. Refer to the following config file for an example: @@ -168,7 +168,7 @@ id = "" -This `wrangler.toml / wrangler.json` file adds the `nodejs_compat` compatibility flag and a KV namespace binding to your Pages project. Running `wrangler pages dev` in a Pages project directory with this `wrangler.toml / wrangler.json` file will apply the `nodejs_compat` compatibility flag locally, and expose the `KV` binding in your Pages Function code at `context.env.KV`. +This Wrangler configuration file adds the `nodejs_compat` compatibility flag and a KV namespace binding to your Pages project. Running `wrangler pages dev` in a Pages project directory with this Wrangler configuration file will apply the `nodejs_compat` compatibility flag locally, and expose the `KV` binding in your Pages Function code at `context.env.KV`. :::note @@ -216,7 +216,7 @@ Unlike [Workers Environments](/workers/wrangler/configuration/#environments), `p ::: -Refer to the following `wrangler.toml / wrangler.json` file for an example of how to override preview deployment configuration: +Refer to the following Wrangler configuration file for an example of how to override preview deployment configuration: @@ -446,7 +446,7 @@ When using Wrangler in the default local development mode, files will be written :::caution - Durable Object bindings configured in a Pages project's `wrangler.toml / wrangler.json` file require the `script_name` key. For Workers, the `script_name` key is optional. + Durable Object bindings configured in a Pages project's Wrangler configuration file require the `script_name` key. For Workers, the `script_name` key is optional. ::: @@ -543,4 +543,4 @@ The local development settings that you can configure are the same for Pages Fun When used in your Pages Functions projects, your Wrangler file is the source of truth. You will be able to see, but not edit, the same fields when you log into the Cloudflare dashboard. -If you decide that you do not want to use a `wrangler.toml / wrangler.json` file for configuration, you can safely delete it and create a new deployment. Configuration values from your last deployment will still apply and you will be able to edit them from the dashboard. +If you decide that you do not want to use a Wrangler configuration file for configuration, you can safely delete it and create a new deployment. Configuration values from your last deployment will still apply and you will be able to edit them from the dashboard. diff --git a/src/content/docs/pages/get-started/c3.mdx b/src/content/docs/pages/get-started/c3.mdx index 5f63e79c1710d6a..7d35ce4ad6d4309 100644 --- a/src/content/docs/pages/get-started/c3.mdx +++ b/src/content/docs/pages/get-started/c3.mdx @@ -164,8 +164,8 @@ pnpm create cloudflare@latest [--] [] [OPTIONS] [-- ] At a minimum, templates must contain the following: - `package.json` - - `wrangler.json` - - `src/` containing a worker script referenced from `wrangler.json` + - [Wrangler configuration file](/pages/functions/wrangler-configuration/) + - `src/` containing a worker script referenced from the Wrangler configuration file See the [templates folder](https://github.com/cloudflare/workers-sdk/tree/main/packages/create-cloudflare/templates) of this repo for more examples. diff --git a/src/content/docs/pages/how-to/add-custom-http-headers.mdx b/src/content/docs/pages/how-to/add-custom-http-headers.mdx index a5e50cfe196fce4..284a9faf704a492 100644 --- a/src/content/docs/pages/how-to/add-custom-http-headers.mdx +++ b/src/content/docs/pages/how-to/add-custom-http-headers.mdx @@ -83,7 +83,7 @@ zone_id = "FILL-IN-YOUR-ZONE-ID" If you do not know how to find your Account ID and Zone ID, refer to [our guide](/fundamentals/setup/find-account-and-zone-ids/). -Once you have configured your `wrangler.toml / wrangler.json` file, run `npx wrangler deploy` in your terminal to deploy your Worker: +Once you have configured your [Wrangler configuration file](/pages/functions/wrangler-configuration/) , run `npx wrangler deploy` in your terminal to deploy your Worker: ```sh npx wrangler deploy diff --git a/src/content/docs/pages/migrations/migrating-from-workers/index.mdx b/src/content/docs/pages/migrations/migrating-from-workers/index.mdx index ef891f3d21e1fcb..9092382180e995a 100644 --- a/src/content/docs/pages/migrations/migrating-from-workers/index.mdx +++ b/src/content/docs/pages/migrations/migrating-from-workers/index.mdx @@ -29,10 +29,10 @@ By migrating to Cloudflare Pages, you will be able to access features like [prev Workers Sites projects consist of the following pieces: 1. An application built with a [static site tool](/pages/how-to/) or a static collection of HTML, CSS and JavaScript files. -2. If using a static site tool, a build directory (called `bucket` in the `wrangler.toml / wrangler.json` file) where the static project builds your HTML, CSS, and JavaScript files. +2. If using a static site tool, a build directory (called `bucket` in the [Wrangler configuration file](/pages/functions/wrangler-configuration/)) where the static project builds your HTML, CSS, and JavaScript files. 3. A Worker application for serving that build directory. For most projects, this is likely to be the `workers-site` directory. -When moving to Cloudflare Pages, remove the Workers application and any associated `wrangler.toml / wrangler.json` files or build output. Instead, note and record your `build` command (if you have one), and the `bucket` field, or build directory, from the Wrangler file in your project's directory. +When moving to Cloudflare Pages, remove the Workers application and any associated Wrangler configuration files or build output. Instead, note and record your `build` command (if you have one), and the `bucket` field, or build directory, from the Wrangler file in your project's directory. ## Migrate headers and redirects diff --git a/src/content/docs/pages/tutorials/use-r2-as-static-asset-storage-for-pages/index.mdx b/src/content/docs/pages/tutorials/use-r2-as-static-asset-storage-for-pages/index.mdx index f016a6357a08c0b..61a67cd2aa23a28 100644 --- a/src/content/docs/pages/tutorials/use-r2-as-static-asset-storage-for-pages/index.mdx +++ b/src/content/docs/pages/tutorials/use-r2-as-static-asset-storage-for-pages/index.mdx @@ -69,7 +69,7 @@ npx wrangler r2 object put / -f To bind the R2 bucket we have created to the cat blog, we need to update the Wrangler configuration. -Open the `wrangler.toml / wrangler.json` file, and add the following binding to the file. `bucket_name` should be the exact name of the bucket created earlier, while `binding` can be any custom name referring to the R2 resource: +Open the [Wrangler configuration file](/pages/functions/wrangler-configuration/), and add the following binding to the file. `bucket_name` should be the exact name of the bucket created earlier, while `binding` can be any custom name referring to the R2 resource: @@ -86,7 +86,7 @@ bucket_name = "cat-media" Note: The keyword `ASSETS` is reserved and cannot be used as a resource binding. ::: -Save the `wrangler.toml / wrangler.json` file, and we are ready to move on to the last step. +Save the [Wrangler configuration file](/pages/functions/wrangler-configuration/), and we are ready to move on to the last step. Alternatively, you can add a binding to your Pages project on the dashboard by navigating to the project’s _Settings_ tab > _Functions_ > _R2 bucket bindings_. diff --git a/src/content/docs/pub-sub/learning/integrate-workers.mdx b/src/content/docs/pub-sub/learning/integrate-workers.mdx index 3ba068f47cbcb01..929730bb760ffc3 100644 --- a/src/content/docs/pub-sub/learning/integrate-workers.mdx +++ b/src/content/docs/pub-sub/learning/integrate-workers.mdx @@ -82,7 +82,7 @@ You should receive a success response that resembles the example below, with the ] ``` -Copy the array of public keys into your `wrangler.toml / wrangler.json` file as an environmental variable: +Copy the array of public keys into your [Wrangler configuration file](/workers/wrangler/configuration/) as an environmental variable: :::note diff --git a/src/content/docs/queues/configuration/batching-retries.mdx b/src/content/docs/queues/configuration/batching-retries.mdx index 3c2d77f61f7d740..ce4dcd616f40233 100644 --- a/src/content/docs/queues/configuration/batching-retries.mdx +++ b/src/content/docs/queues/configuration/batching-retries.mdx @@ -196,7 +196,7 @@ npx wrangler@latest queues consumer worker add $QUEUE-NAME $WORKER_SCRIPT_NAME - npx wrangler@latest queues consumer http add $QUEUE-NAME --retry-delay-secs=60 ``` -Delays can also be configured in the [`wrangler.toml / wrangler.json` file](/workers/wrangler/configuration/#queues) with the `delivery_delay` setting for producers (when sending) and/or the `retry_delay` (when retrying) per-consumer: +Delays can also be configured in the [Wrangler configuration file](/workers/wrangler/configuration/#queues) with the `delivery_delay` setting for producers (when sending) and/or the `retry_delay` (when retrying) per-consumer: @@ -213,7 +213,7 @@ Delays can also be configured in the [`wrangler.toml / wrangler.json` file](/wor -If you use both the `wrangler` CLI and the `wrangler.toml / wrangler.json` file to change the settings associated with a queue or a queue consumer, the most recent configuration change will take effect. +If you use both the `wrangler` CLI and the [Wrangler configuration file](/workers/wrangler/configuration/) to change the settings associated with a queue or a queue consumer, the most recent configuration change will take effect. Refer to the [Queues REST API documentation](/api/resources/queues/subresources/consumers/methods/get/) to learn how to configure message delays and retry delays programmatically. diff --git a/src/content/docs/queues/configuration/configure-queues.mdx b/src/content/docs/queues/configuration/configure-queues.mdx index d34bc6c12272539..9c6080c09364d8d 100644 --- a/src/content/docs/queues/configuration/configure-queues.mdx +++ b/src/content/docs/queues/configuration/configure-queues.mdx @@ -13,14 +13,14 @@ import { WranglerConfig } from "~/components"; Cloudflare Queues can be configured using [Wrangler](/workers/wrangler/install-and-update/), the command-line interface for Cloudflare's Developer Platform, which includes [Workers](/workers/), [R2](/r2/), and other developer products. -Each Worker has a `wrangler.toml / wrangler.json` file that specifies environment variables, triggers, and resources, such as a Queue. To enable Worker-to-resource communication, you must set up a [binding](/workers/runtime-apis/bindings/) in your Worker project's Wrangler file. +Each Worker has a [Wrangler configuration file](/workers/wrangler/configuration/) that specifies environment variables, triggers, and resources, such as a Queue. To enable Worker-to-resource communication, you must set up a [binding](/workers/runtime-apis/bindings/) in your Worker project's Wrangler file. Use the options below to configure your queue. :::note -Below are options for Queues, refer to the Wrangler documentation for a full reference of the [`wrangler.toml / wrangler.json` file](/workers/wrangler/configuration/). +Below are options for Queues, refer to the Wrangler documentation for a full reference of the [Wrangler configuration file](/workers/wrangler/configuration/). ::: diff --git a/src/content/docs/queues/configuration/consumer-concurrency.mdx b/src/content/docs/queues/configuration/consumer-concurrency.mdx index add633b7286c562..8e8a7f3294caabb 100644 --- a/src/content/docs/queues/configuration/consumer-concurrency.mdx +++ b/src/content/docs/queues/configuration/consumer-concurrency.mdx @@ -60,7 +60,7 @@ If you have a workflow that is limited by an upstream API and/or system, you may You can configure the concurrency of your consumer Worker in two ways: 1. Set concurrency settings in the Cloudflare dashboard -2. Set concurrency settings via the `wrangler.toml / wrangler.json` file +2. Set concurrency settings via the [Wrangler configuration file](/workers/wrangler/configuration/) ### Set concurrency settings in the Cloudflare dashboard @@ -76,7 +76,7 @@ To remove a fixed maximum value, select **auto (recommended)**. Note that if you are writing messages to a queue faster than you can process them, messages may eventually reach the [maximum retention period](/queues/platform/limits/) set for that queue. Individual messages that reach that limit will expire from the queue and be deleted. -### Set concurrency settings in the `wrangler.toml / wrangler.json` file +### Set concurrency settings in the [Wrangler configuration file](/workers/wrangler/configuration/) :::note diff --git a/src/content/docs/queues/configuration/pull-consumers.mdx b/src/content/docs/queues/configuration/pull-consumers.mdx index 2cd310b13beb745..69a6ef5c2c5a5a0 100644 --- a/src/content/docs/queues/configuration/pull-consumers.mdx +++ b/src/content/docs/queues/configuration/pull-consumers.mdx @@ -36,11 +36,11 @@ To configure a pull-based consumer and receive messages from a queue, you need t ## 1. Enable HTTP pull -You can enable HTTP pull or change a queue from push-based to pull-based via the `wrangler.toml / wrangler.json` file, the `wrangler` CLI, or via the [Cloudflare dashboard](https://dash.cloudflare.com/). +You can enable HTTP pull or change a queue from push-based to pull-based via the [Wrangler configuration file](/workers/wrangler/configuration/), the `wrangler` CLI, or via the [Cloudflare dashboard](https://dash.cloudflare.com/). ### Wrangler configuration file -A HTTP consumer can be configured in the `wrangler.toml / wrangler.json` file by setting `type = "http_pull"` in the consumer configuration: +A HTTP consumer can be configured in the [Wrangler configuration file](/workers/wrangler/configuration/) by setting `type = "http_pull"` in the consumer configuration: @@ -75,7 +75,7 @@ wrangler queues consumer worker remove $QUEUE-NAME $SCRIPT_NAME :::note -If you remove the Worker consumer with `wrangler` but do not delete the `[[queues.consumer]]` configuration from `wrangler.toml / wrangler.json` file, subsequent deployments of your Worker will fail when they attempt to add a conflicting consumer configuration. +If you remove the Worker consumer with `wrangler` but do not delete the `[[queues.consumer]]` configuration from your [Wrangler configuration file](/workers/wrangler/configuration/), subsequent deployments of your Worker will fail when they attempt to add a conflicting consumer configuration. Ensure you remove the consumer configuration first. diff --git a/src/content/docs/queues/get-started.mdx b/src/content/docs/queues/get-started.mdx index f1bd0fd93e310e0..d632a1895a1e140 100644 --- a/src/content/docs/queues/get-started.mdx +++ b/src/content/docs/queues/get-started.mdx @@ -40,7 +40,7 @@ To create a producer Worker, run: }} /> -This will create a new directory, which will include both a `src/index.ts` Worker script, and a [`wrangler.json`](/workers/wrangler/configuration/) configuration file. After you create your Worker, you will create a Queue to access. +This will create a new directory, which will include both a `src/index.ts` Worker script, and a [`wrangler.jsonc`](/workers/wrangler/configuration/) configuration file. After you create your Worker, you will create a Queue to access. Move into the newly created directory: @@ -68,7 +68,7 @@ You cannot change your queue name after you have set it. After you create your q To expose your queue to the code inside your Worker, you need to connect your queue to your Worker by creating a binding. [Bindings](/workers/runtime-apis/bindings/) allow your Worker to access resources, such as Queues, on the Cloudflare developer platform. -To create a binding, open your newly generated `wrangler.toml / wrangler.json` file and add the following: +To create a binding, open your newly generated `wrangler.jsonc` file and add the following: @@ -106,7 +106,7 @@ export default { } satisfies ExportedHandler; ``` -Replace `MY_QUEUE` with the name you have set for your binding from your `wrangler.toml / wrangler.json` file. +Replace `MY_QUEUE` with the name you have set for your binding from your `wrangler.jsonc` file. Also add the queue to `Env` interface in `index.ts`. @@ -172,7 +172,7 @@ export default { } satisfies ExportedHandler; ``` -Replace `MY_QUEUE` with the name you have set for your binding from your `wrangler.toml / wrangler.json` file. +Replace `MY_QUEUE` with the name you have set for your binding from your `wrangler.jsonc` file. Every time messages are published to the queue, your consumer Worker's `queue` handler (`async queue`) is called and it is passed one or more messages. diff --git a/src/content/docs/queues/reference/how-queues-works.mdx b/src/content/docs/queues/reference/how-queues-works.mdx index f9ffc0101018144..aedd0ac44263cfd 100644 --- a/src/content/docs/queues/reference/how-queues-works.mdx +++ b/src/content/docs/queues/reference/how-queues-works.mdx @@ -137,7 +137,7 @@ export default { }; ``` -You then connect that consumer to a queue with `wrangler queues consumer ` or by defining a `[[queues.consumers]]` configuration in your `wrangler.toml / wrangler.json` file manually: +You then connect that consumer to a queue with `wrangler queues consumer ` or by defining a `[[queues.consumers]]` configuration in your [Wrangler configuration file](/workers/wrangler/configuration/) manually: diff --git a/src/content/docs/queues/tutorials/handle-rate-limits/index.mdx b/src/content/docs/queues/tutorials/handle-rate-limits/index.mdx index 897469ac2462f2e..56a620c0323f2bf 100644 --- a/src/content/docs/queues/tutorials/handle-rate-limits/index.mdx +++ b/src/content/docs/queues/tutorials/handle-rate-limits/index.mdx @@ -73,7 +73,7 @@ Creating queue rate-limit-queue. Created queue rate-limit-queue. ``` -### Add Queue bindings to your `wrangler.toml / wrangler.json` file +### Add Queue bindings to your [Wrangler configuration file](/workers/wrangler/configuration/) In your Wrangler file, add the following: diff --git a/src/content/docs/queues/tutorials/web-crawler-with-browser-rendering/index.mdx b/src/content/docs/queues/tutorials/web-crawler-with-browser-rendering/index.mdx index ba1ba58ec583324..a58457d74210f64 100644 --- a/src/content/docs/queues/tutorials/web-crawler-with-browser-rendering/index.mdx +++ b/src/content/docs/queues/tutorials/web-crawler-with-browser-rendering/index.mdx @@ -82,7 +82,7 @@ binding = "crawler_screenshots" id = "" ``` -### Add KV bindings to the `wrangler.toml / wrangler.json` file +### Add KV bindings to the [Wrangler configuration file](/workers/wrangler/configuration/) Then, in your Wrangler file, add the following with the values generated in the terminal: diff --git a/src/content/docs/r2/api/s3/presigned-urls.mdx b/src/content/docs/r2/api/s3/presigned-urls.mdx index d089be4156fa9bf..8631546ca29b043 100644 --- a/src/content/docs/r2/api/s3/presigned-urls.mdx +++ b/src/content/docs/r2/api/s3/presigned-urls.mdx @@ -131,7 +131,7 @@ export default { } satisfies ExportedHandler; ``` -Notice the total absence of any configuration or token secrets present in the Worker code. Instead, you would create a `wrangler.toml / wrangler.json` file [binding](/r2/api/workers/workers-api-usage/#4-bind-your-bucket-to-a-worker) to whatever bucket represents the bucket you will upload to. Additionally, authorization is handled in-line with the upload which can reduce latency. +Notice the total absence of any configuration or token secrets present in the Worker code. Instead, in your [Wrangler configuration file](/workers/wrangler/configuration/), you would create a [binding](/r2/api/workers/workers-api-usage/#4-bind-your-bucket-to-a-worker) to whatever bucket represents the bucket you will upload to. Additionally, authorization is handled in-line with the upload which can reduce latency. In some cases, Workers lets you implement certain functionality more easily. For example, if you wanted to offer a write-once guarantee so that users can only upload to a path once, with pre-signed URLs, you would need to sign specific headers and require the sender to send them. You can modify the previous Worker to sign additional headers: diff --git a/src/content/docs/r2/reference/data-location.mdx b/src/content/docs/r2/reference/data-location.mdx index 4342a004ad4a1fc..237bd3785cd17e2 100644 --- a/src/content/docs/r2/reference/data-location.mdx +++ b/src/content/docs/r2/reference/data-location.mdx @@ -79,7 +79,7 @@ Use Jurisdictional Restrictions when you need to ensure data is stored and proce ### Using jurisdictions from Workers -To access R2 buckets that belong to a jurisdiction from [Workers](/workers/), you will need to specify the jurisdiction as well as the bucket name as part of your [bindings](/r2/api/workers/workers-api-usage/#3-bind-your-bucket-to-a-worker) in your `wrangler.toml / wrangler.json` file: +To access R2 buckets that belong to a jurisdiction from [Workers](/workers/), you will need to specify the jurisdiction as well as the bucket name as part of your [bindings](/r2/api/workers/workers-api-usage/#3-bind-your-bucket-to-a-worker) in your [Wrangler configuration file](/workers/wrangler/configuration/): diff --git a/src/content/docs/r2/tutorials/upload-logs-event-notifications.mdx b/src/content/docs/r2/tutorials/upload-logs-event-notifications.mdx index 85d6763ecd902af..17eae7b3a5f833e 100644 --- a/src/content/docs/r2/tutorials/upload-logs-event-notifications.mdx +++ b/src/content/docs/r2/tutorials/upload-logs-event-notifications.mdx @@ -85,7 +85,7 @@ cd consumer-worker ## 5. Configure your Worker -In your Worker project's [`wrangler.toml / wrangler.json` file](/workers/wrangler/configuration/), add a [queue consumer](/workers/wrangler/configuration/#queues) and [R2 bucket binding](/workers/wrangler/configuration/#r2-buckets). The queues consumer bindings will register your Worker as a consumer of your future event notifications and the R2 bucket bindings will allow your Worker to access your R2 bucket. +In your Worker project's [[Wrangler configuration file](/workers/wrangler/configuration/)](/workers/wrangler/configuration/), add a [queue consumer](/workers/wrangler/configuration/#queues) and [R2 bucket binding](/workers/wrangler/configuration/#r2-buckets). The queues consumer bindings will register your Worker as a consumer of your future event notifications and the R2 bucket bindings will allow your Worker to access your R2 bucket. diff --git a/src/content/docs/radar/investigate/bgp-anomalies.mdx b/src/content/docs/radar/investigate/bgp-anomalies.mdx index 3f537a2ab7eb950..1b66b1ecb18488b 100644 --- a/src/content/docs/radar/investigate/bgp-anomalies.mdx +++ b/src/content/docs/radar/investigate/bgp-anomalies.mdx @@ -370,7 +370,7 @@ The last step is to deploy the application with command `npx wrangler deploy` an If you have [Email Routing][email-routing] enabled for your domain, you can also send email alerts directly from Workers. Refer to [Send emails from Workers][email-workers-tutorial] to learn more. -For this alert to work, you will need to configure the proper email bindings in the [`wrangler.toml / wrangler.json` file][wrangler-send-email]. +For this alert to work, you will need to configure the proper email bindings in the [Wrangler configuration file][wrangler-send-email]. diff --git a/src/content/docs/style-guide/formatting/code-conventions-and-format.mdx b/src/content/docs/style-guide/formatting/code-conventions-and-format.mdx index 4a6065f78b675b7..2d7939559786410 100644 --- a/src/content/docs/style-guide/formatting/code-conventions-and-format.mdx +++ b/src/content/docs/style-guide/formatting/code-conventions-and-format.mdx @@ -107,7 +107,7 @@ Text in this font denotes text or characters that you should enter from the keyb | Enum (enumerator) names (depending on language) | `type ContentTypeMapElem` | | Environment variable names | `` | | Element names, including angle brackets (XML and HTML). | `
`, `
`, ``, `` | -| Filenames, filename extensions (if used), and paths | `wrangler.toml`, `wrangler.json` | +| Filenames, filename extensions (if used), and paths | `wrangler.toml`, `wrangler.jsonc` | | Folders and directories | `~/Downloads/Cloudflare_CA.crt` | | HTTP verbs | `POST`, `GET`, `HEAD`, `PUT`,`DELETE` | | HTTP status codes | `400`, `200`, `500`
However, error ranges using `x` placeholders should not be monospaced: 5xx, 1xxxx. | diff --git a/src/content/docs/turnstile/tutorials/protecting-your-payment-form-from-attackers-bots-using-turnstile.mdx b/src/content/docs/turnstile/tutorials/protecting-your-payment-form-from-attackers-bots-using-turnstile.mdx index d7e6cefe837216c..a5e10b2da8d484c 100644 --- a/src/content/docs/turnstile/tutorials/protecting-your-payment-form-from-attackers-bots-using-turnstile.mdx +++ b/src/content/docs/turnstile/tutorials/protecting-your-payment-form-from-attackers-bots-using-turnstile.mdx @@ -150,7 +150,7 @@ Since we will use JSX to dynamically create HTML, you will need to change `src/i mv src/index.ts src/index.tsx ``` -At the same time, change the filename specified in the `wrangler.toml / wrangler.json` file. +At the same time, change the filename specified in the [Wrangler configuration file](/workers/wrangler/configuration/). ```diff #:schema node_modules/wrangler/config-schema.json diff --git a/src/content/docs/vectorize/get-started/embeddings.mdx b/src/content/docs/vectorize/get-started/embeddings.mdx index 9a74850a867fde4..7e61b2162b4914e 100644 --- a/src/content/docs/vectorize/get-started/embeddings.mdx +++ b/src/content/docs/vectorize/get-started/embeddings.mdx @@ -57,7 +57,7 @@ Open your terminal and create a new project named `embeddings-tutorial` by runni This will create a new `embeddings-tutorial` directory. Your new `embeddings-tutorial` directory will include: - A `"Hello World"` [Worker](/workers/get-started/guide/#3-write-code) at `src/index.ts`. -- A [`wrangler.json`](/workers/wrangler/configuration/) configuration file. `wrangler.json` is how your `embeddings-tutorial` Worker will access your index. +- A [`wrangler.jsonc`](/workers/wrangler/configuration/) configuration file. `wrangler.jsonc` is how your `embeddings-tutorial` Worker will access your index. :::note diff --git a/src/content/docs/vectorize/get-started/intro.mdx b/src/content/docs/vectorize/get-started/intro.mdx index 882753ab081b4a1..6b2e9a53a78b743 100644 --- a/src/content/docs/vectorize/get-started/intro.mdx +++ b/src/content/docs/vectorize/get-started/intro.mdx @@ -62,7 +62,7 @@ Create a new project named `vectorize-tutorial` by running: This will create a new `vectorize-tutorial` directory. Your new `vectorize-tutorial` directory will include: - A `"Hello World"` [Worker](/workers/get-started/guide/#3-write-code) at `src/index.ts`. -- A [`wrangler.json`](/workers/wrangler/configuration/) configuration file. `wrangler.json` is how your `vectorize-tutorial` Worker will access your index. +- A [`wrangler.jsonc`](/workers/wrangler/configuration/) configuration file. `wrangler.jsonc` is how your `vectorize-tutorial` Worker will access your index. :::note @@ -272,7 +272,7 @@ export default { In the code above, you: -1. Define a binding to your Vectorize index from your Workers code. This binding matches the `binding` value you set in the `wrangler.toml / wrangler.json` file under `[[vectorize]]`. +1. Define a binding to your Vectorize index from your Workers code. This binding matches the `binding` value you set in the `wrangler.jsonc` file under the `"vectorise"` key. 2. Specify a set of example vectors that you will query against in the next step. 3. Insert those vectors into the index and confirm it was successful. diff --git a/src/content/docs/vectorize/reference/client-api.mdx b/src/content/docs/vectorize/reference/client-api.mdx index c0b20e5b4eba2cc..77a3555e9b3bc25 100644 --- a/src/content/docs/vectorize/reference/client-api.mdx +++ b/src/content/docs/vectorize/reference/client-api.mdx @@ -200,7 +200,7 @@ let vectorExample = { [Bindings](/workers/runtime-apis/bindings/) allow you to attach resources, including Vectorize indexes or R2 buckets, to your Worker. -Bindings are defined in either the [`wrangler.toml / wrangler.json` file](/workers/wrangler/configuration/) associated with your Workers project, or via the Cloudflare dashboard for your project. +Bindings are defined in either the [Wrangler configuration file](/workers/wrangler/configuration/) associated with your Workers project, or via the Cloudflare dashboard for your project. Vectorize indexes are bound by name. A binding for an index named `production-doc-search` would resemble the below: diff --git a/src/content/docs/workers-ai/get-started/workers-wrangler.mdx b/src/content/docs/workers-ai/get-started/workers-wrangler.mdx index f39f353d294ccd1..d12b191a22ec613 100644 --- a/src/content/docs/workers-ai/get-started/workers-wrangler.mdx +++ b/src/content/docs/workers-ai/get-started/workers-wrangler.mdx @@ -38,7 +38,7 @@ Running `npm create cloudflare@latest` will prompt you to install the [`create-c This will create a new `hello-ai` directory. Your new `hello-ai` directory will include: - A `"Hello World"` [Worker](/workers/get-started/guide/#3-write-code) at `src/index.ts`. -- A [`wrangler.json`](/workers/wrangler/configuration/) configuration file. +- A [`wrangler.jsonc`](/workers/wrangler/configuration/) configuration file. Go to your application directory: diff --git a/src/content/docs/workers-ai/tutorials/build-a-retrieval-augmented-generation-ai.mdx b/src/content/docs/workers-ai/tutorials/build-a-retrieval-augmented-generation-ai.mdx index 7c6ff29c7b5045e..f34031a808305fb 100644 --- a/src/content/docs/workers-ai/tutorials/build-a-retrieval-augmented-generation-ai.mdx +++ b/src/content/docs/workers-ai/tutorials/build-a-retrieval-augmented-generation-ai.mdx @@ -53,7 +53,7 @@ In your project directory, C3 has generated several files.
-1. `wrangler.json`: Your [Wrangler](/workers/wrangler/configuration/#sample-wrangler-configuration) configuration file. +1. `wrangler.jsonc`: Your [Wrangler](/workers/wrangler/configuration/#sample-wrangler-configuration) configuration file. 2. `worker.js` (in `/src`): A minimal `'Hello World!'` Worker written in [ES module](/workers/reference/migrate-to-module-workers/) syntax. 3. `package.json`: A minimal Node dependencies configuration file. 4. `package-lock.json`: Refer to [`npm` documentation on `package-lock.json`](https://docs.npmjs.com/cli/v9/configuring-npm/package-lock-json). @@ -89,7 +89,7 @@ You will now be able to go to [http://localhost:8787](http://localhost:8787) to ## 3. Adding the AI binding -To begin using Cloudflare's AI products, you can add the `ai` block to the `wrangler.toml / wrangler.json` file. This will set up a binding to Cloudflare's AI models in your code that you can use to interact with the available AI models on the platform. +To begin using Cloudflare's AI products, you can add the `ai` block to the [Wrangler configuration file](/workers/wrangler/configuration/). This will set up a binding to Cloudflare's AI models in your code that you can use to interact with the available AI models on the platform. This example features the [`@cf/meta/llama-3-8b-instruct` model](/workers-ai/models/llama-3-8b-instruct/), which generates text. @@ -144,7 +144,7 @@ To begin using Vectorize, create a new embeddings index using `wrangler`. This i npx wrangler vectorize create vector-index --dimensions=768 --metric=cosine ``` -Then, add the configuration details for your new Vectorize index to the `wrangler.toml / wrangler.json` file: +Then, add the configuration details for your new Vectorize index to the [Wrangler configuration file](/workers/wrangler/configuration/): @@ -170,7 +170,7 @@ Create a new D1 database using `wrangler`: npx wrangler d1 create database ``` -Then, paste the configuration details output from the previous command into the `wrangler.toml / wrangler.json` file: +Then, paste the configuration details output from the previous command into the [Wrangler configuration file](/workers/wrangler/configuration/): @@ -201,7 +201,9 @@ npx wrangler d1 execute database --remote --command "INSERT INTO notes (text) VA Before we begin creating notes, we will introduce a [Cloudflare Workflow](/workflows). This will allow us to define a durable workflow that can safely and robustly execute all the steps of the RAG process. -To begin, add a new `[[workflows]]` block to `wrangler.toml`: +To begin, add a new `[[workflows]]` block to your [Wrangler configuration file](/workers/wrangler/configuration/): + + ```toml # ... existing wrangler configuration @@ -212,6 +214,8 @@ binding = "RAG_WORKFLOW" class_name = "RAGWorkflow" ``` + + In `src/index.js`, add a new class called `RAGWorkflow` that extends `Workflow`: ```js diff --git a/src/content/docs/workers-ai/tutorials/llama-vision-tutorial.mdx b/src/content/docs/workers-ai/tutorials/llama-vision-tutorial.mdx index 2bc98c537b15a71..ef8142068718b63 100644 --- a/src/content/docs/workers-ai/tutorials/llama-vision-tutorial.mdx +++ b/src/content/docs/workers-ai/tutorials/llama-vision-tutorial.mdx @@ -100,7 +100,7 @@ export default { ## 4. Bind Workers AI to your Worker -1. Open `wrangler.toml / wrangler.json` and add the following configuration: +1. Open the [Wrangler configuration file](/workers/wrangler/configuration/) and add the following configuration: ```toml diff --git a/src/content/docs/workers/configuration/compatibility-dates.mdx b/src/content/docs/workers/configuration/compatibility-dates.mdx index 7c2d819ff1fc667..c556313735ea868 100644 --- a/src/content/docs/workers/configuration/compatibility-dates.mdx +++ b/src/content/docs/workers/configuration/compatibility-dates.mdx @@ -25,7 +25,7 @@ However, even though you do not need to update the `compatibility_date` field, i #### Via Wrangler -The compatibility date can be set in a Worker's [`wrangler.toml / wrangler.json` file](/workers/wrangler/configuration/). +The compatibility date can be set in a Worker's [Wrangler configuration file](/workers/wrangler/configuration/). diff --git a/src/content/docs/workers/configuration/compatibility-flags.mdx b/src/content/docs/workers/configuration/compatibility-flags.mdx index a0d79290eaaaf59..92235e77cd294ea 100644 --- a/src/content/docs/workers/configuration/compatibility-flags.mdx +++ b/src/content/docs/workers/configuration/compatibility-flags.mdx @@ -18,7 +18,7 @@ You may provide a list of `compatibility_flags`, which enable or disable specifi #### Via Wrangler -Compatibility flags can be set in a Worker's [`wrangler.toml / wrangler.json` file](/workers/wrangler/configuration/). +Compatibility flags can be set in a Worker's [Wrangler configuration file](/workers/wrangler/configuration/). This example enables the specific flag `formdata_parser_supports_files`, which is described [below](/workers/configuration/compatibility-flags/#formdata-parsing-supports-file). As of the specified date, `2021-09-14`, this particular flag was not yet enabled by default, but, by specifying it in `compatibility_flags`, we can enable it anyway. `compatibility_flags` can also be used to disable changes that became the default in the past. @@ -50,7 +50,7 @@ If your compatibility date is 2024-09-22 or before and you want to enable v2, ad If your compatibility date is after 2024-09-23, but you want to disable v2 to avoid increasing your bundle size, add the `no_nodejs_compat_v2` in addition to the `nodejs_compat flag`. ::: -A [growing subset](/workers/runtime-apis/nodejs/) of Node.js APIs are available directly as [Runtime APIs](/workers/runtime-apis/nodejs), with no need to add polyfills to your own code. To enable these APIs in your Worker, add the `nodejs_compat` compatibility flag to your `wrangler.toml`: +A [growing subset](/workers/runtime-apis/nodejs/) of Node.js APIs are available directly as [Runtime APIs](/workers/runtime-apis/nodejs), with no need to add polyfills to your own code. To enable these APIs in your Worker, add the `nodejs_compat` compatibility flag to your [Wrangler configuration file](/workers/wrangler/configuration/): diff --git a/src/content/docs/workers/configuration/cron-triggers.mdx b/src/content/docs/workers/configuration/cron-triggers.mdx index d58257ace20de35..93f0ea15f2dbbb0 100644 --- a/src/content/docs/workers/configuration/cron-triggers.mdx +++ b/src/content/docs/workers/configuration/cron-triggers.mdx @@ -36,9 +36,9 @@ Refer to the following examples to write your code: After you have updated your Worker code to include a `"scheduled"` event, you must update your Worker project configuration. -#### Via the `wrangler.toml / wrangler.json` file +#### Via the [Wrangler configuration file](/workers/wrangler/configuration/) -If a Worker is managed with Wrangler, Cron Triggers should be exclusively managed through the [`wrangler.toml / wrangler.json` file](/workers/wrangler/configuration/). +If a Worker is managed with Wrangler, Cron Triggers should be exclusively managed through the [Wrangler configuration file](/workers/wrangler/configuration/). Refer to the example below for a Cron Triggers configuration: @@ -55,7 +55,7 @@ crons = [ "*/3 * * * *", "0 15 1 * *", "59 23 LW * *" ] -You also can set a different Cron Trigger for each [environment](/workers/wrangler/environments/) in your `wrangler.toml / wrangler.json` file. You need to put the `[triggers]` table under your chosen environment. For example: +You also can set a different Cron Trigger for each [environment](/workers/wrangler/environments/) in your [Wrangler configuration file](/workers/wrangler/configuration/). You need to put the `[triggers]` table under your chosen environment. For example: @@ -198,5 +198,5 @@ Green Compute can be configured at the account level: ## Related resources -- [Triggers](/workers/wrangler/configuration/#triggers) - Review `wrangler.toml / wrangler.json` file syntax for Cron Triggers. +- [Triggers](/workers/wrangler/configuration/#triggers) - Review Wrangler configuration file syntax for Cron Triggers. - Learn how to access Cron Triggers in [ES modules syntax](/workers/reference/migrate-to-module-workers/) for an optimized experience. diff --git a/src/content/docs/workers/configuration/environment-variables.mdx b/src/content/docs/workers/configuration/environment-variables.mdx index 92c7f177c056006..f51f2764caf5d1a 100644 --- a/src/content/docs/workers/configuration/environment-variables.mdx +++ b/src/content/docs/workers/configuration/environment-variables.mdx @@ -70,14 +70,14 @@ SERVICE_X_DATA = { URL = "service-x-api.prod.example", MY_ID = 456 } -For local development with `wrangler dev`, variables in the `wrangler.toml / wrangler.json` file are automatically overridden by any values defined in a `.dev.vars` file located in the root directory of your worker. This is useful for providing values you do not want to check in to source control. +For local development with `wrangler dev`, variables in the [Wrangler configuration file](/workers/wrangler/configuration/) are automatically overridden by any values defined in a `.dev.vars` file located in the root directory of your worker. This is useful for providing values you do not want to check in to source control. ```shell API_HOST = "localhost:4000" API_ACCOUNT_ID = "local_example_user" ``` -Alternatively, you can specify per-environment values in the `wrangler.toml / wrangler.json` file and provide an `environment` value via the `env` flag when developing locally like so `wrangler dev --env=local`. +Alternatively, you can specify per-environment values in the [Wrangler configuration file](/workers/wrangler/configuration/) and provide an `environment` value via the `env` flag when developing locally like so `wrangler dev --env=local`. ## Add environment variables via the dashboard diff --git a/src/content/docs/workers/configuration/previews.mdx b/src/content/docs/workers/configuration/previews.mdx index 810c62f82de90dc..29c4c0f2c7c73c9 100644 --- a/src/content/docs/workers/configuration/previews.mdx +++ b/src/content/docs/workers/configuration/previews.mdx @@ -77,7 +77,7 @@ To disable Preview URLs for a Worker: 4. On "Preview URLs" click "Disable". 5. Confirm you want to disable. -### Disabling Preview URLs in the `wrangler.toml / wrangler.json` file +### Disabling Preview URLs in the [Wrangler configuration file](/workers/wrangler/configuration/) :::note Wrangler 3.91.0 or higher is required to use this feature. diff --git a/src/content/docs/workers/configuration/routing/custom-domains.mdx b/src/content/docs/workers/configuration/routing/custom-domains.mdx index 7ef768c97f3cc2d..d64591aaf7c3e21 100644 --- a/src/content/docs/workers/configuration/routing/custom-domains.mdx +++ b/src/content/docs/workers/configuration/routing/custom-domains.mdx @@ -49,9 +49,9 @@ To set up a Custom Domain in the dashboard: After you have added the domain or subdomain, Cloudflare will create a new DNS record for you. You can add multiple Custom Domains. -### Set up a Custom Domain in your `wrangler.toml / wrangler.json` file +### Set up a Custom Domain in your Wrangler configuration file -To configure a Custom Domain in your `wrangler.toml / wrangler.json` file, add the `custom_domain=true` option on each pattern under `routes`. For example, to configure a Custom Domain: +To configure a Custom Domain in your [Wrangler configuration file](/workers/wrangler/configuration/), add the `custom_domain=true` option on each pattern under `routes`. For example, to configure a Custom Domain: @@ -156,7 +156,7 @@ To migrate the route `example.com/*`: ### Migrate from Routes via Wrangler -To migrate the route `example.com/*` in your `wrangler.toml / wrangler.json` file: +To migrate the route `example.com/*` in your [Wrangler configuration file](/workers/wrangler/configuration/): 1. Log in to the [Cloudflare dashboard](https://dash.cloudflare.com) and select your account. 2. Go to **DNS** and delete the CNAME record for `example.com`. diff --git a/src/content/docs/workers/configuration/routing/routes.mdx b/src/content/docs/workers/configuration/routing/routes.mdx index 417be53e981bc70..5beac9f152873da 100644 --- a/src/content/docs/workers/configuration/routing/routes.mdx +++ b/src/content/docs/workers/configuration/routing/routes.mdx @@ -49,11 +49,11 @@ To set up a route in the dashboard: 4. Select the zone and enter the route pattern. 5. Select **Add route**. -### Set up a route in the `wrangler.toml / wrangler.json` file +### Set up a route in the Wrangler configuration file Before you set up a route, make sure you have a DNS record set up for the [domain](/dns/manage-dns-records/how-to/create-zone-apex/) or [subdomain](/dns/manage-dns-records/how-to/create-subdomain/) you would like to route to. -To configure a route using your Wrangler file, refer to the following example. +To configure a route using your [Wrangler configuration file](/workers/wrangler/configuration/), refer to the following example. diff --git a/src/content/docs/workers/configuration/routing/workers-dev.mdx b/src/content/docs/workers/configuration/routing/workers-dev.mdx index 546227fa80916ae..4052c61d5982579 100644 --- a/src/content/docs/workers/configuration/routing/workers-dev.mdx +++ b/src/content/docs/workers/configuration/routing/workers-dev.mdx @@ -31,9 +31,9 @@ To disable the `workers.dev` route for a Worker: 4. On `workers.dev` click "Disable". 5. Confirm you want to disable. -### Disabling `workers.dev` in the `wrangler.toml / wrangler.json` file +### Disabling `workers.dev` in the Wrangler configuration file -To disable the `workers.dev` route for a Worker, include the following in your Worker's Wrangler file: +To disable the `workers.dev` route for a Worker, include the following in your Worker's [Wrangler configuration file](/workers/wrangler/configuration/): @@ -45,7 +45,7 @@ workers_dev = false When you redeploy your Worker with this change, the `workers.dev` route will be disabled. Disabling your `workers.dev` route does not disable Preview URLs. Learn how to [disable Preview URLs](/workers/configuration/previews/#disabling-preview-urls). -If you do not specify `workers_dev = false` but add a [`routes` component](/workers/wrangler/configuration/#routes) to your `wrangler.toml / wrangler.json` file, the value of `workers_dev` will be inferred as `false` on the next deploy. +If you do not specify `workers_dev = false` but add a [`routes` component](/workers/wrangler/configuration/#routes) to your [Wrangler configuration file](/workers/wrangler/configuration/), the value of `workers_dev` will be inferred as `false` on the next deploy. :::caution diff --git a/src/content/docs/workers/configuration/sites/configuration.mdx b/src/content/docs/workers/configuration/sites/configuration.mdx index a6a79f1b235947b..a9b7cc029b48c90 100644 --- a/src/content/docs/workers/configuration/sites/configuration.mdx +++ b/src/content/docs/workers/configuration/sites/configuration.mdx @@ -18,7 +18,7 @@ There are a few specific configuration settings for Workers Sites in your Wrangl - `bucket` required - - The directory containing your static assets, path relative to your `wrangler.toml / wrangler.json` file. Example: `bucket = "./public"`. + - The directory containing your static assets, path relative to your [Wrangler configuration file](/workers/wrangler/configuration/). Example: `bucket = "./public"`. - `include` optional @@ -35,7 +35,7 @@ If your project uses [environments](/workers/wrangler/environments/), make sure ::: -Example of a `wrangler.toml / wrangler.json` file: +Example of a [Wrangler configuration file](/workers/wrangler/configuration/): diff --git a/src/content/docs/workers/configuration/sites/start-from-existing.mdx b/src/content/docs/workers/configuration/sites/start-from-existing.mdx index 99937e36aebad68..51f56c995d70597 100644 --- a/src/content/docs/workers/configuration/sites/start-from-existing.mdx +++ b/src/content/docs/workers/configuration/sites/start-from-existing.mdx @@ -30,7 +30,7 @@ To deploy a pre-existing static site project, start with a pre-generated site. W This command adds/update the following files: - - `wrangler.json`: The file containing project configuration. + - `wrangler.jsonc`: The file containing project configuration. - `package.json`: Wrangler `devDependencies` are added. - `tsconfig.json`: Added if not already there to support writing the Worker in TypeScript. - `src/index.ts`: A basic Cloudflare Worker, written in TypeScript. diff --git a/src/content/docs/workers/configuration/sites/start-from-scratch.mdx b/src/content/docs/workers/configuration/sites/start-from-scratch.mdx index fe71ca55a981e85..1223ec837a5190c 100644 --- a/src/content/docs/workers/configuration/sites/start-from-scratch.mdx +++ b/src/content/docs/workers/configuration/sites/start-from-scratch.mdx @@ -43,11 +43,11 @@ The template project contains the following files and directories: - `public`: The static assets for your project. By default it contains an `index.html` and a `favicon.ico`. - `src`: The Worker configured for serving your assets. You do not need to edit this but if you want to see how it works or add more functionality to your Worker, you can edit `src/index.ts`. -- `wrangler.json`: The file containing project configuration. +- `wrangler.jsonc`: The file containing project configuration. The `bucket` property tells Wrangler where to find the static assets (e.g. `site = { bucket = "./public" }`). - `package.json`/`package-lock.json`: define the required Node.js dependencies. -## Customize the `wrangler.toml / wrangler.json` file: +## Customize the `wrangler.jsonc` file: - Change the `name` property to the name of your project: diff --git a/src/content/docs/workers/configuration/versions-and-deployments/index.mdx b/src/content/docs/workers/configuration/versions-and-deployments/index.mdx index 86e982765b9f914..686d29ad56a3cf3 100644 --- a/src/content/docs/workers/configuration/versions-and-deployments/index.mdx +++ b/src/content/docs/workers/configuration/versions-and-deployments/index.mdx @@ -19,7 +19,7 @@ Using versions and deployments is useful if: ## Versions -A version is defined by the state of code as well as the state of configuration in a Worker's [Wrangler configuration](/workers/wrangler/configuration/) file. Versions track historical changes to [bundled code](/workers/wrangler/bundling/), [static assets](/workers/static-assets/) and changes to configuration like [bindings](/workers/runtime-apis/bindings/) and [compatibility date and compatibility flags](/workers/configuration/compatibility-dates/) over time. +A version is defined by the state of code as well as the state of configuration in a Worker's [Wrangler configuration file](/workers/wrangler/configuration/). Versions track historical changes to [bundled code](/workers/wrangler/bundling/), [static assets](/workers/static-assets/) and changes to configuration like [bindings](/workers/runtime-apis/bindings/) and [compatibility date and compatibility flags](/workers/configuration/compatibility-dates/) over time. Versions also track metadata associated with a version, including: the version ID, the user that created the version, deploy source, and timestamp. Optionally, a version message and version tag can be configured on version upload. diff --git a/src/content/docs/workers/examples/cron-trigger.mdx b/src/content/docs/workers/examples/cron-trigger.mdx index 5facd46b6575d0f..8bf9e34325dcadf 100644 --- a/src/content/docs/workers/examples/cron-trigger.mdx +++ b/src/content/docs/workers/examples/cron-trigger.mdx @@ -61,7 +61,7 @@ crons = ["0 * * * *"] -You also can set a different Cron Trigger for each [environment](/workers/wrangler/environments/) in your `wrangler.toml / wrangler.json` file. You need to put the `[triggers]` table under your chosen environment. For example: +You also can set a different Cron Trigger for each [environment](/workers/wrangler/environments/) in your [Wrangler configuration file](/workers/wrangler/configuration/). You need to put the `[triggers]` table under your chosen environment. For example: diff --git a/src/content/docs/workers/frameworks/framework-guides/nextjs.mdx b/src/content/docs/workers/frameworks/framework-guides/nextjs.mdx index 0f35165902cc91c..f1111e8b7b578b7 100644 --- a/src/content/docs/workers/frameworks/framework-guides/nextjs.mdx +++ b/src/content/docs/workers/frameworks/framework-guides/nextjs.mdx @@ -50,9 +50,9 @@ First, install [@opennextjs/cloudflare](https://www.npmjs.com/package/@opennextj npm install --save-dev @opennextjs/cloudflare ``` -### 2. Add a Wrangler file +### 2. Add a Wrangler configuration file -Then, add a [`wrangler.toml / wrangler.json` file](/workers/wrangler/configuration/) to the root directory of your Next.js app: +Then, add a [Wrangler configuration file](/workers/wrangler/configuration/) to the root directory of your Next.js app: @@ -70,7 +70,7 @@ assets = { directory = ".open-next/assets", binding = "ASSETS" } As shown above, you must enable the [`nodejs_compat` compatibility flag](/workers/runtime-apis/nodejs/) _and_ set your [compatibility date](/workers/configuration/compatibility-dates/) to `2024-09-23` or later for your Next.js app to work with @opennextjs/cloudflare. ::: -You configure your Worker and define what resources it can access via [bindings](/workers/runtime-apis/bindings/) in the `wrangler.toml / wrangler.json` file. +You configure your Worker and define what resources it can access via [bindings](/workers/runtime-apis/bindings/) in the [Wrangler configuration file](/workers/wrangler/configuration/). ### 3. Update `package.json` diff --git a/src/content/docs/workers/get-started/guide.mdx b/src/content/docs/workers/get-started/guide.mdx index 0f27ef2688fe997..fce8efe6d0daa7c 100644 --- a/src/content/docs/workers/get-started/guide.mdx +++ b/src/content/docs/workers/get-started/guide.mdx @@ -48,7 +48,7 @@ cd my-first-worker In your project directory, C3 will have generated the following: -* `wrangler.json`: Your [Wrangler](/workers/wrangler/configuration/#sample-wrangler-configuration) configuration file. +* `wrangler.jsonc`: Your [Wrangler](/workers/wrangler/configuration/#sample-wrangler-configuration) configuration file. * `index.js` (in `/src`): A minimal `'Hello World!'` Worker written in [ES module](/workers/reference/migrate-to-module-workers/) syntax. * `package.json`: A minimal Node dependencies configuration file. * `package-lock.json`: Refer to [`npm` documentation on `package-lock.json`](https://docs.npmjs.com/cli/v9/configuring-npm/package-lock-json). @@ -78,8 +78,8 @@ npm create cloudflare@latest -- --template Your existing template folder must contain the following files, at a minimum, to meet the requirements for Cloudflare Workers: - `package.json` -- `wrangler.json` [See sample Wrangler configuration](/workers/wrangler/configuration/#sample-wrangler-configuration) -- `src/` containing a worker script referenced from `wrangler.json` +- `wrangler.jsonc` [See sample Wrangler configuration](/workers/wrangler/configuration/#sample-wrangler-configuration) +- `src/` containing a worker script referenced from `wrangler.jsonc`
diff --git a/src/content/docs/workers/languages/python/ffi.mdx b/src/content/docs/workers/languages/python/ffi.mdx index cae76aaaded497f..5fd704b8d9a7f59 100644 --- a/src/content/docs/workers/languages/python/ffi.mdx +++ b/src/content/docs/workers/languages/python/ffi.mdx @@ -22,7 +22,7 @@ The details of Pyodide's Foreign Function Interface are documented [here](https: Bindings allow your Worker to interact with resources on the Cloudflare Developer Platform. When you declare a binding on your Worker, you grant it a specific capability, such as being able to read and write files to an [R2](/r2/) bucket. -For example, to access a [KV](/kv) namespace from a Python Worker, you would declare the following in your Worker's [`wrangler.toml / wrangler.json` file](/workers/wrangler/configuration/): +For example, to access a [KV](/kv) namespace from a Python Worker, you would declare the following in your Worker's [Wrangler configuration file](/workers/wrangler/configuration/): diff --git a/src/content/docs/workers/languages/python/how-python-workers-work.mdx b/src/content/docs/workers/languages/python/how-python-workers-work.mdx index 43b2a786fc6aec3..2c188943083b4e8 100644 --- a/src/content/docs/workers/languages/python/how-python-workers-work.mdx +++ b/src/content/docs/workers/languages/python/how-python-workers-work.mdx @@ -24,7 +24,7 @@ async def on_fetch(request, env): return Response.new("Hello world!") ``` -…with a `wrangler.toml / wrangler.json` file that points to a .py file: +…with a [Wrangler configuration file](/workers/wrangler/configuration/) that points to a .py file: diff --git a/src/content/docs/workers/languages/python/index.mdx b/src/content/docs/workers/languages/python/index.mdx index e16aa3a196f9d47..4646ec93654be4a 100644 --- a/src/content/docs/workers/languages/python/index.mdx +++ b/src/content/docs/workers/languages/python/index.mdx @@ -123,7 +123,7 @@ the Python `fetch` handler and can be used to access [secrets](/workers/configuration/secrets/),and [bindings](/workers/runtime-apis/bindings/). -For example, let us try setting and using an environment variable in a Python Worker. First, add the environment variable to your Worker's `wrangler.toml / wrangler.json` file: +For example, let us try setting and using an environment variable in a Python Worker. First, add the environment variable to your Worker's [Wrangler configuration file](/workers/wrangler/configuration/): diff --git a/src/content/docs/workers/languages/python/packages/index.mdx b/src/content/docs/workers/languages/python/packages/index.mdx index be355eb14c02b87..71722c1fb61a42b 100644 --- a/src/content/docs/workers/languages/python/packages/index.mdx +++ b/src/content/docs/workers/languages/python/packages/index.mdx @@ -10,7 +10,7 @@ import { Render } from "~/components"; -To import a Python package, add the package name to the `requirements.txt` file within the same directory as your `wrangler.toml / wrangler.json` file. +To import a Python package, add the package name to the `requirements.txt` file within the same directory as your [Wrangler configuration file](/workers/wrangler/configuration/). For example, if your Worker depends on [FastAPI](https://fastapi.tiangolo.com/), you would add the following: diff --git a/src/content/docs/workers/languages/rust/index.mdx b/src/content/docs/workers/languages/rust/index.mdx index 8ce5f9a98844d90..135bbb17ae46d54 100644 --- a/src/content/docs/workers/languages/rust/index.mdx +++ b/src/content/docs/workers/languages/rust/index.mdx @@ -46,7 +46,7 @@ cargo generate cloudflare/workers-rs Your project will be created in a new directory that you named, in which you will find the following files and folders: - `Cargo.toml` - The standard project configuration file for Rust's [`Cargo`](https://doc.rust-lang.org/cargo/) package manager. The template pre-populates some best-practice settings for building for Wasm on Workers. -- `wrangler.json` - Wrangler configuration, pre-populated with a custom build command to invoke `worker-build` (Refer to [Wrangler Bundling](/workers/languages/rust/#bundling-worker-build)). +- `wrangler.toml` - Wrangler configuration, pre-populated with a custom build command to invoke `worker-build` (Refer to [Wrangler Bundling](/workers/languages/rust/#bundling-worker-build)). - `src` - Rust source directory, pre-populated with Hello World Worker. ## 2. Develop locally @@ -112,7 +112,7 @@ An object representing the incoming request. This includes methods for accessing Provides access to Worker [bindings](/workers/runtime-apis/bindings/). - [`Secret`](https://github.com/cloudflare/workers-rs/blob/e15f88110d814c2d7759b2368df688433f807694/worker/src/env.rs#L92) - Secret value configured in Cloudflare dashboard or using `wrangler secret put`. -- [`Var`](https://github.com/cloudflare/workers-rs/blob/e15f88110d814c2d7759b2368df688433f807694/worker/src/env.rs#L92) - Environment variable defined in `wrangler.json`. +- [`Var`](https://github.com/cloudflare/workers-rs/blob/e15f88110d814c2d7759b2368df688433f807694/worker/src/env.rs#L92) - Environment variable defined in `wrangler.toml`. - [`KvStore`](https://docs.rs/worker-kv/latest/worker_kv/struct.KvStore.html) - Workers [KV](/kv/api/) namespace binding. - [`ObjectNamespace`](https://docs.rs/worker/latest/worker/durable/struct.ObjectNamespace.html) - [Durable Object](/durable-objects/) binding. - [`Fetcher`](https://docs.rs/worker/latest/worker/struct.Fetcher.html) - [Service binding](/workers/runtime-apis/bindings/service-bindings/) to another Worker. @@ -208,7 +208,7 @@ To run the resulting Wasm binary on Workers, `workers-rs` includes a build tool 2. Invokes `web-pack` to minify and bundle the JavaScript code. 3. Outputs a directory structure that Wrangler can use to bundle and deploy the final Worker. -`worker-build` is invoked by default in the template project using a custom build command specified in the `wrangler.toml / wrangler.json` file. +`worker-build` is invoked by default in the template project using a custom build command specified in the `wrangler.toml` file. ### Binary Size (`wasm-opt`) diff --git a/src/content/docs/workers/languages/typescript/index.mdx b/src/content/docs/workers/languages/typescript/index.mdx index 8122cf431f70e65..68e7a00f9f1cb92 100644 --- a/src/content/docs/workers/languages/typescript/index.mdx +++ b/src/content/docs/workers/languages/typescript/index.mdx @@ -24,7 +24,7 @@ This means the correct TypeScript types for your Worker depend on: 1. Your Worker's [Compatibility Date](/workers/configuration/compatibility-dates/). 2. Your Worker's [Compatibility Flags](/workers/configuration/compatibility-flags/). -For example, if you have `compatibility_flags = ["nodejs_als"]` in your `wrangler.toml / wrangler.json` file, then the runtime will allow you to use the [`AsyncLocalStorage`](https://nodejs.org/api/async_context.html#class-asynclocalstorage) class in your worker code, but you will not see this reflected in the type definitions in `@cloudflare/workers-types`. +For example, if you have `compatibility_flags = ["nodejs_als"]` in your [Wrangler configuration file](/workers/wrangler/configuration/), then the runtime will allow you to use the [`AsyncLocalStorage`](https://nodejs.org/api/async_context.html#class-asynclocalstorage) class in your worker code, but you will not see this reflected in the type definitions in `@cloudflare/workers-types`. In order to solve this issue, and to ensure that your type definitions are always up-to-date with your compatibility settings, you can dynamically generate the runtime types (as of `wrangler 3.66.0`): diff --git a/src/content/docs/workers/local-development.mdx b/src/content/docs/workers/local-development.mdx index 026b51bcee39497..09889a95999210d 100644 --- a/src/content/docs/workers/local-development.mdx +++ b/src/content/docs/workers/local-development.mdx @@ -62,7 +62,7 @@ When running `wrangler dev`, resources such as KV, Durable Objects, D1, and R2 w ### Use bindings in Wrangler configuration files -[Wrangler](/workers/wrangler/) will automatically create local versions of bindings found in the [`wrangler.toml / wrangler.json` file](/workers/wrangler/configuration/). These local resources will not have data in them initially, so you will need to add data manually via Wrangler commands and the [`--local` flag](#use---local-flag). +[Wrangler](/workers/wrangler/) will automatically create local versions of bindings found in the [Wrangler configuration file](/workers/wrangler/configuration/). These local resources will not have data in them initially, so you will need to add data manually via Wrangler commands and the [`--local` flag](#use---local-flag). When you run `wrangler dev` Wrangler stores local resources in a `.wrangler/state` folder, which is automatically created. @@ -97,7 +97,7 @@ If using `--persist-to` to specify a custom folder with `wrangler dev` you shoul npx wrangler kv:key put test 12345 --binding MY_KV_NAMESPACE --local --persist-to worker-local ``` -Running `wrangler kv:key put` will create a new key `test` with a value of `12345` on the local namespace specified via the binding `MY_KV_NAMESPACE` in the `wrangler.toml / wrangler.json` file. This example command sets the local persistence directory to `worker-local` using `--persist-to`, to ensure that the data is created in the correct location. If `--persist-to` was not set, it would create the data in the `.wrangler` folder. +Running `wrangler kv key put` will create a new key `test` with a value of `12345` on the local namespace specified via the binding `MY_KV_NAMESPACE` in the [Wrangler configuration file](/workers/wrangler/configuration/). This example command sets the local persistence directory to `worker-local` using `--persist-to`, to ensure that the data is created in the correct location. If `--persist-to` was not set, it would create the data in the `.wrangler` folder. ### Clear Wrangler's local storage @@ -107,7 +107,7 @@ Any deleted folders will be created automatically the next time you run `wrangle ## Local-only environment variables -When running `wrangler dev`, variables in the `wrangler.toml / wrangler.json` file are automatically overridden by values defined in a `.dev.vars` file located in the root directory of your worker. This is useful for providing values you do not want to check in to source control. +When running `wrangler dev`, variables in the [Wrangler configuration file](/workers/wrangler/configuration/) are automatically overridden by values defined in a `.dev.vars` file located in the root directory of your worker. This is useful for providing values you do not want to check in to source control. ```shell API_HOST = "localhost:4000" @@ -122,7 +122,7 @@ There may be times you want to develop against remote resources and bindings. To npx wrangler dev --remote ``` -For some products like KV and R2, remote resources used for `wrangler dev --remote` must be specified with preview ID/names in the `wrangler.toml / wrangler.json` file such as `preview_id` for KV or `preview_bucket name` for R2. Resources used for remote mode (preview) can be different from resources used for production to prevent changing production data during development. To use production data in `wrangler dev --remote`, set the preview ID/name of the resource to the ID/name of your production resource. +For some products like KV and R2, remote resources used for `wrangler dev --remote` must be specified with preview ID/names in the [Wrangler configuration file](/workers/wrangler/configuration/) such as `preview_id` for KV or `preview_bucket name` for R2. Resources used for remote mode (preview) can be different from resources used for production to prevent changing production data during development. To use production data in `wrangler dev --remote`, set the preview ID/name of the resource to the ID/name of your production resource. ## Customize `wrangler dev` diff --git a/src/content/docs/workers/observability/source-maps.mdx b/src/content/docs/workers/observability/source-maps.mdx index c710a010c48e1c6..60ed84a6c411495 100644 --- a/src/content/docs/workers/observability/source-maps.mdx +++ b/src/content/docs/workers/observability/source-maps.mdx @@ -23,7 +23,7 @@ Support for uploading source maps is available now in open beta. Minimum require ## Source Maps -To enable source maps, add the following to your Worker's [Wrangler configuration](/workers/wrangler/configuration/) file: +To enable source maps, add the following to your Worker's [Wrangler configuration](/workers/wrangler/configuration/): diff --git a/src/content/docs/workers/reference/migrate-to-module-workers.mdx b/src/content/docs/workers/reference/migrate-to-module-workers.mdx index 981542bcf8997e1..7239823dbb5c00b 100644 --- a/src/content/docs/workers/reference/migrate-to-module-workers.mdx +++ b/src/content/docs/workers/reference/migrate-to-module-workers.mdx @@ -65,7 +65,7 @@ To understand bindings, refer the following `TODO` KV namespace binding example. 1. Create a KV namespace named `My Tasks` and receive an ID that you will use in your binding. 2. Create a Worker. -3. Find your Worker's `wrangler.toml / wrangler.json` file and add a KV namespace binding: +3. Find your Worker's [Wrangler configuration file](/workers/wrangler/configuration/) and add a KV namespace binding: @@ -141,7 +141,7 @@ export { getTodos } [Environment variables](/workers/configuration/environment-variables/) are accessed differently in code written in ES modules format versus Service Worker format. -Review the following example environment variable configuration in the `wrangler.toml / wrangler.json` file: +Review the following example environment variable configuration in the [Wrangler configuration file](/workers/wrangler/configuration/): diff --git a/src/content/docs/workers/runtime-apis/bindings/service-bindings/index.mdx b/src/content/docs/workers/runtime-apis/bindings/service-bindings/index.mdx index 530a0b85e381a94..053abbc2b6382c9 100644 --- a/src/content/docs/workers/runtime-apis/bindings/service-bindings/index.mdx +++ b/src/content/docs/workers/runtime-apis/bindings/service-bindings/index.mdx @@ -30,9 +30,9 @@ Service bindings are commonly used to: ## Configuration -You add a Service binding by modifying the `wrangler.toml / wrangler.json` file of the caller — the Worker that you want to be able to initiate requests. +You add a Service binding by modifying the [Wrangler configuration file](/workers/wrangler/configuration/) of the caller — the Worker that you want to be able to initiate requests. -For example, if you want Worker A to be able to call Worker B — you'd add the following to the `wrangler.toml / wrangler.json` file for Worker A: +For example, if you want Worker A to be able to call Worker B — you'd add the following to the [Wrangler configuration file](/workers/wrangler/configuration/) for Worker A: diff --git a/src/content/docs/workers/runtime-apis/webassembly/javascript.mdx b/src/content/docs/workers/runtime-apis/webassembly/javascript.mdx index c91dc4f5728cdc6..ab9fb6a74020f06 100644 --- a/src/content/docs/workers/runtime-apis/webassembly/javascript.mdx +++ b/src/content/docs/workers/runtime-apis/webassembly/javascript.mdx @@ -47,7 +47,7 @@ wat2wasm src/simple.wat -o src/simple.wasm ## Bundling -Wrangler will bundle any Wasm module that ends in `.wasm` or `.wasm?module`, so that it is available at runtime within your Worker. This is done using a default bundling rule which can be customized in the `wrangler.toml / wrangler.json` file. Refer to [Wrangler Bundling](/workers/wrangler/bundling/) for more information. +Wrangler will bundle any Wasm module that ends in `.wasm` or `.wasm?module`, so that it is available at runtime within your Worker. This is done using a default bundling rule which can be customized in the [Wrangler configuration file](/workers/wrangler/configuration/). Refer to [Wrangler Bundling](/workers/wrangler/bundling/) for more information. ## Use from JavaScript diff --git a/src/content/docs/workers/static-assets/routing.mdx b/src/content/docs/workers/static-assets/routing.mdx index 40e199fab913a34..d59ee64a19584d1 100644 --- a/src/content/docs/workers/static-assets/routing.mdx +++ b/src/content/docs/workers/static-assets/routing.mdx @@ -38,9 +38,9 @@ In this example, a request to `example.com/api` doesn't match a static asset so ## Invoking Worker Script Ahead of Assets -You may wish to run code before assets are served. This is often the case when implementing authentication, logging, personalization, internationalization, or other similar functions. [`run_worker_first`](/workers/static-assets/binding/#run_worker_first) is a configuration option available in `wrangler.toml / wrangler.json` which controls this behavior. When enabled, `run_worker_first = true` will invoke your Worker's code, regardless of any assets that would have otherwise matched. +You may wish to run code before assets are served. This is often the case when implementing authentication, logging, personalization, internationalization, or other similar functions. [`run_worker_first`](/workers/static-assets/binding/#run_worker_first) is a configuration option available in [Wrangler configuration file](/workers/wrangler/configuration/) which controls this behavior. When enabled, `run_worker_first = true` will invoke your Worker's code, regardless of any assets that would have otherwise matched. -Take the following directory structure, `wrangler.toml / wrangler.json` file, and user Worker code: +Take the following directory structure, [Wrangler configuration file](/workers/wrangler/configuration/), and user Worker code: @@ -94,7 +94,7 @@ In this example, any request will be routed to our user Worker, due to `run_work ## Routing configuration -There are two options for asset serving that can be [configured in the `wrangler.toml / wrangler.json` file](/workers/wrangler/configuration/#assets): +There are two options for asset serving that can be configured in the [Wrangler configuration file](/workers/wrangler/configuration/#assets): #### 1. `html_handling` @@ -156,9 +156,9 @@ For all non-matching requests, Cloudflare will return a null-body 404-status res ### Alternate configuration options -Alternate configuration options are outlined on this page and can be specified in your project's [`wrangler.toml / wrangler.json` file](/workers/wrangler/configuration/#assets). If you're deploying using a [framework](/workers/frameworks/), these options will be defined by the framework provider. +Alternate configuration options are outlined on this page and can be specified in your project's [Wrangler configuration file](/workers/wrangler/configuration/#assets). If you're deploying using a [framework](/workers/frameworks/), these options will be defined by the framework provider. -Example `wrangler.toml / wrangler.json` file: +Example Wrangler configuration file: @@ -303,7 +303,7 @@ For example, to serve assets from `example.com/blog/*`, create a `blog` director - post2.html -With a `wrangler.toml / wrangler.json` file like so: +With a [Wrangler configuration file](/workers/wrangler/configuration/) like so: ```toml diff --git a/src/content/docs/workers/testing/index.mdx b/src/content/docs/workers/testing/index.mdx index af144d0de844c5a..7705fa2c1d2502c 100644 --- a/src/content/docs/workers/testing/index.mdx +++ b/src/content/docs/workers/testing/index.mdx @@ -17,7 +17,7 @@ Review the tools available for testing and debugging Workers. | ----------------------------------------------- | ----------- | ---------------- | --------------- | | Unit testing | ✅ | ❌ | ❌ | | Integration testing | ✅ | ✅ | ✅ | -| Loading `wrangler.toml / wrangler.json` files | ✅ | ✅ | ❌ | +| Loading [Wrangler configuration files](/workers/wrangler/configuration/) | ✅ | ✅ | ❌ | | Bindings directly in tests | ✅ | ❌ | ✅ | | Isolated per-test storage | ✅ | ❌ | ❌ | | Outbound request mocking | ✅ | ❌ | ✅ | diff --git a/src/content/docs/workers/testing/integration-testing.mdx b/src/content/docs/workers/testing/integration-testing.mdx index 4a7675c568df83a..06f098742bb426a 100644 --- a/src/content/docs/workers/testing/integration-testing.mdx +++ b/src/content/docs/workers/testing/integration-testing.mdx @@ -86,7 +86,7 @@ This method is less recommended than `SELF` for integration tests because of its ## Wrangler's `unstable_dev()` API -If you do not want to use Vitest and would like to write integration tests for a single Worker, consider using [Wrangler's `unstable_dev()` API](/workers/wrangler/api/#unstable_dev). `unstable_dev()` allows you to start an HTTP server similar to [`wrangler dev`](/workers/wrangler/commands/#dev) that you can send HTTP requests to. `unstable_dev()` will automatically load options from your `wrangler.toml / wrangler.json` file. Note that `unstable_dev()` is an experimental API subject to breaking changes. +If you do not want to use Vitest and would like to write integration tests for a single Worker, consider using [Wrangler's `unstable_dev()` API](/workers/wrangler/api/#unstable_dev). `unstable_dev()` allows you to start an HTTP server similar to [`wrangler dev`](/workers/wrangler/commands/#dev) that you can send HTTP requests to. `unstable_dev()` will automatically load options from your [Wrangler configuration file](/workers/wrangler/configuration/). Note that `unstable_dev()` is an experimental API subject to breaking changes. ```js import assert from "node:assert"; @@ -109,7 +109,7 @@ If you have been using `unstable_dev()` for integration testing and want to migr ## Miniflare's API -If you would like to write integration tests for multiple Workers, need direct access to [bindings](/workers/runtime-apis/bindings/) outside your Worker in tests, or have another advanced use case, consider using [Miniflare's API](/workers/testing/miniflare) directly. Miniflare is the foundation for the other testing tools on this page, exposing a JavaScript API for the [`workerd` runtime](https://github.com/cloudflare/workerd) and local simulators for the other Developer Platform products. Unlike `unstable_dev()`, Miniflare does not automatically load options from your `wrangler.toml / wrangler.json` file. +If you would like to write integration tests for multiple Workers, need direct access to [bindings](/workers/runtime-apis/bindings/) outside your Worker in tests, or have another advanced use case, consider using [Miniflare's API](/workers/testing/miniflare) directly. Miniflare is the foundation for the other testing tools on this page, exposing a JavaScript API for the [`workerd` runtime](https://github.com/cloudflare/workerd) and local simulators for the other Developer Platform products. Unlike `unstable_dev()`, Miniflare does not automatically load options from your [Wrangler configuration file](/workers/wrangler/configuration/). ```js import assert from "node:assert"; diff --git a/src/content/docs/workers/testing/vitest-integration/configuration.mdx b/src/content/docs/workers/testing/vitest-integration/configuration.mdx index 9ad1971fdc887e1..b9ef6632d0fd1f7 100644 --- a/src/content/docs/workers/testing/vitest-integration/configuration.mdx +++ b/src/content/docs/workers/testing/vitest-integration/configuration.mdx @@ -145,7 +145,7 @@ The following functions are exported from the `@cloudflare/vitest-pool-workers/c * `miniflare`: `SourcelessWorkerOptions & { workers?: WorkerOptions\[]; }` optional - * Use this to provide configuration information that is typically stored within the `wrangler.toml / wrangler.json` file, such as [bindings](/workers/runtime-apis/bindings/), [compatibility dates](/workers/configuration/compatibility-dates/), and [compatibility flags](/workers/configuration/compatibility-flags/). The `WorkerOptions` interface is defined [here](https://github.com/cloudflare/workers-sdk/tree/main/packages/miniflare#interface-workeroptions). Use the `main` option above to configure the entry point, instead of the Miniflare `script`, `scriptPath`, or `modules` options. + * Use this to provide configuration information that is typically stored within the [Wrangler configuration file](/workers/wrangler/configuration/), such as [bindings](/workers/runtime-apis/bindings/), [compatibility dates](/workers/configuration/compatibility-dates/), and [compatibility flags](/workers/configuration/compatibility-flags/). The `WorkerOptions` interface is defined [here](https://github.com/cloudflare/workers-sdk/tree/main/packages/miniflare#interface-workeroptions). Use the `main` option above to configure the entry point, instead of the Miniflare `script`, `scriptPath`, or `modules` options. * If your project makes use of multiple Workers, you can configure auxiliary Workers that run in the same `workerd` process as your tests and can be bound to. Auxiliary Workers are configured using the `workers` array, containing regular Miniflare [`WorkerOptions`](https://github.com/cloudflare/workers-sdk/tree/main/packages/miniflare#interface-workeroptions) objects. Note that unlike the `main` Worker, auxiliary Workers: * Cannot have TypeScript entrypoints. You must compile auxiliary Workers to JavaScript first. You can use the [`wrangler deploy --dry-run --outdir dist`](/workers/wrangler/commands/#deploy) command for this. @@ -157,7 +157,7 @@ The following functions are exported from the `@cloudflare/vitest-pool-workers/c * `wrangler`: `{ configPath?: string; environment?: string; }` optional - * Path to `wrangler.toml / wrangler.json` file to load `main`, [compatibility settings](/workers/configuration/compatibility-dates/) and [bindings](/workers/runtime-apis/bindings/) from. These options will be merged with the `miniflare` option above, with `miniflare` values taking precedence. For example, if your Wrangler configuration defined a [service binding](/workers/runtime-apis/bindings/service-bindings/) named `SERVICE` to a Worker named `service`, but you included `serviceBindings: { SERVICE(request) { return new Response("body"); } }` in the `miniflare` option, all requests to `SERVICE` in tests would return `body`. Note `configPath` accepts both `.toml` and `.json` files. + * Path to [Wrangler configuration file](/workers/wrangler/configuration/) to load `main`, [compatibility settings](/workers/configuration/compatibility-dates/) and [bindings](/workers/runtime-apis/bindings/) from. These options will be merged with the `miniflare` option above, with `miniflare` values taking precedence. For example, if your Wrangler configuration defined a [service binding](/workers/runtime-apis/bindings/service-bindings/) named `SERVICE` to a Worker named `service`, but you included `serviceBindings: { SERVICE(request) { return new Response("body"); } }` in the `miniflare` option, all requests to `SERVICE` in tests would return `body`. Note `configPath` accepts both `.toml` and `.json` files. * The environment option can be used to specify the [Wrangler environment](/workers/wrangler/environments/) to pick up bindings and variables from. diff --git a/src/content/docs/workers/testing/vitest-integration/get-started/migrate-from-unstable-dev.mdx b/src/content/docs/workers/testing/vitest-integration/get-started/migrate-from-unstable-dev.mdx index 48932cd85249c9e..38a1ff2dbd59d95 100644 --- a/src/content/docs/workers/testing/vitest-integration/get-started/migrate-from-unstable-dev.mdx +++ b/src/content/docs/workers/testing/vitest-integration/get-started/migrate-from-unstable-dev.mdx @@ -28,7 +28,7 @@ it("dispatches fetch event", () => { }) ``` -With the Workers Vitest integration, you can accomplish the same goal using `SELF` from `cloudflare:test`. `SELF` is a [service binding](/workers/runtime-apis/bindings/service-bindings/) to the default export defined by the `main` option in your `wrangler.toml / wrangler.json` file. This `main` Worker runs in the same isolate as tests so any global mocks will apply to it too. +With the Workers Vitest integration, you can accomplish the same goal using `SELF` from `cloudflare:test`. `SELF` is a [service binding](/workers/runtime-apis/bindings/service-bindings/) to the default export defined by the `main` option in your [Wrangler configuration file](/workers/wrangler/configuration/). This `main` Worker runs in the same isolate as tests so any global mocks will apply to it too. ```js import { SELF } from "cloudflare:test"; @@ -46,7 +46,7 @@ With the Workers Vitest integration, there is no need to stop a Worker via `work ## Import Wrangler configuration -Via the `unstable_dev` API, you can reference a `wrangler.toml / wrangler.json` file by adding it as an option: +Via the `unstable_dev` API, you can reference a [Wrangler configuration file](/workers/wrangler/configuration/) by adding it as an option: ```js await unstable_dev("src/index.ts", { @@ -54,7 +54,7 @@ await unstable_dev("src/index.ts", { }); ``` -With the Workers Vitest integration, you can now set this reference to `wrangler.toml` in `vitest.config.js` for all of your tests: +With the Workers Vitest integration, you can now set this reference to a [Wrangler configuration file](/workers/wrangler/configuration/) in `vitest.config.js` for all of your tests: ```js null {5-7} export default defineWorkersConfig({ diff --git a/src/content/docs/workers/testing/vitest-integration/get-started/write-your-first-test.mdx b/src/content/docs/workers/testing/vitest-integration/get-started/write-your-first-test.mdx index 57a3ae23cd00d12..b0cc8f99bc912eb 100644 --- a/src/content/docs/workers/testing/vitest-integration/get-started/write-your-first-test.mdx +++ b/src/content/docs/workers/testing/vitest-integration/get-started/write-your-first-test.mdx @@ -17,7 +17,7 @@ This guide will instruct you through installing and setting up the `@cloudflare/ - Make sure that your Worker is developed using the ES modules format. To migrate from the service worker format to the ES modules format, refer to the [Migrate to the ES modules format](/workers/reference/migrate-to-module-workers/) guide. -- In your project's `wrangler.toml / wrangler.json` file, define a [compatibility date](/workers/configuration/compatibility-dates/) of `2022-10-31` or higher, and include `nodejs_compat` in your [compatibility flags](/workers/configuration/compatibility-flags). +- In your project's [Wrangler configuration file](/workers/wrangler/configuration/), define a [compatibility date](/workers/configuration/compatibility-dates/) of `2022-10-31` or higher, and include `nodejs_compat` in your [compatibility flags](/workers/configuration/compatibility-flags). ## Install Vitest and `@cloudflare/vitest-pool-workers` diff --git a/src/content/docs/workers/tutorials/automated-analytics-reporting/index.mdx b/src/content/docs/workers/tutorials/automated-analytics-reporting/index.mdx index d749c538b2e914c..d7c74c69a3e463a 100644 --- a/src/content/docs/workers/tutorials/automated-analytics-reporting/index.mdx +++ b/src/content/docs/workers/tutorials/automated-analytics-reporting/index.mdx @@ -94,7 +94,7 @@ yarn add mimetext ## 2. Update Wrangler configuration file -[`wrangler.json`](/workers/wrangler/configuration/) contains the configuration for your Worker. It was created when you ran `c3` CLI. Open `wrangler.json` in your code editor and update it with the following configuration: +[`wrangler.jsonc`](/workers/wrangler/configuration/) contains the configuration for your Worker. It was created when you ran `c3` CLI. Open `wrangler.jsonc` in your code editor and update it with the following configuration: ```toml diff --git a/src/content/docs/workers/tutorials/build-a-jamstack-app/index.mdx b/src/content/docs/workers/tutorials/build-a-jamstack-app/index.mdx index 6a26c677f32cf11..90185cfa47af771 100644 --- a/src/content/docs/workers/tutorials/build-a-jamstack-app/index.mdx +++ b/src/content/docs/workers/tutorials/build-a-jamstack-app/index.mdx @@ -87,7 +87,7 @@ To get started with KV, set up a namespace. All of your cached data will be stor npx wrangler kv:namespace create "TODOS" --preview ``` -The associated namespace can be combined with a `--preview` flag to interact with a preview namespace instead of a production namespace. Namespaces can be added to your application by defining them inside your Wrangler configuration. Copy your newly created namespace ID, and in your `wrangler.toml / wrangler.json` file, define a `kv_namespaces` key to set up your namespace: +The associated namespace can be combined with a `--preview` flag to interact with a preview namespace instead of a production namespace. Namespaces can be added to your application by defining them inside your Wrangler configuration. Copy your newly created namespace ID, and in your [Wrangler configuration file](/workers/wrangler/configuration/), define a `kv_namespaces` key to set up your namespace: diff --git a/src/content/docs/workers/tutorials/connect-to-turso-using-workers/index.mdx b/src/content/docs/workers/tutorials/connect-to-turso-using-workers/index.mdx index 66d9d917fa0c022..af48ce3deadf4b2 100644 --- a/src/content/docs/workers/tutorials/connect-to-turso-using-workers/index.mdx +++ b/src/content/docs/workers/tutorials/connect-to-turso-using-workers/index.mdx @@ -130,12 +130,12 @@ cd worker-turso-ts In your project directory, you now have the following files: -- `wrangler.json`: your `wrangler.toml / wrangler.json` file. +- `wrangler.json` / `wrangler.toml`: [Wrangler configuration file](/workers/wrangler/configuration/) - `src/index.ts`: A minimal Hello World Worker written in TypeScript - `package.json`: A minimal Node dependencies configuration file. - `tsconfig.json`: TypeScript configuration that includes Workers types. Only generated if indicated. -For this tutorial, only the `wrangler.toml / wrangler.json` file and `src/index.ts` file are relevant. You will not need to edit the other files, and they should be left as is. +For this tutorial, only the [Wrangler configuration file](/workers/wrangler/configuration/) and `src/index.ts` file are relevant. You will not need to edit the other files, and they should be left as is. ## Configure your Worker for your Turso database @@ -154,7 +154,7 @@ turso db show my-db --url libsql://my-db-.turso.io ``` -Open the `wrangler.toml / wrangler.json` file in your editor and at the bottom of the file, create a new `[vars]` section representing the [environment variables](/workers/configuration/environment-variables/) for your project: +Open the [Wrangler configuration file](/workers/wrangler/configuration/) in your editor and at the bottom of the file, create a new `[vars]` section representing the [environment variables](/workers/configuration/environment-variables/) for your project: @@ -165,7 +165,7 @@ LIBSQL_DB_URL = "paste-your-url-here" -Save the changes to the `wrangler.toml / wrangler.json` file. +Save the changes to the [Wrangler configuration file](/workers/wrangler/configuration/). Next, create a long-lived authentication token for your Worker to use when connecting to your database. Run the following Turso CLI command, and copy the output to your clipboard: @@ -357,7 +357,7 @@ You should see JSON similar to the following containing the data from the `examp If you see an error instead of a list of users, double check that: -- You have entered the correct value for your `LIBSQL_DB_URL` in the `wrangler.toml / wrangler.json` file. +- You have entered the correct value for your `LIBSQL_DB_URL` in the [Wrangler configuration file](/workers/wrangler/configuration/). - You have set a secret called `LIBSQL_DB_AUTH_TOKEN` with your database authentication token. Both of these need to be present and match the variable names in your Worker's code. diff --git a/src/content/docs/workers/tutorials/deploy-a-realtime-chat-app/index.mdx b/src/content/docs/workers/tutorials/deploy-a-realtime-chat-app/index.mdx index e6654391c484e99..82e67cd2003d95b 100644 --- a/src/content/docs/workers/tutorials/deploy-a-realtime-chat-app/index.mdx +++ b/src/content/docs/workers/tutorials/deploy-a-realtime-chat-app/index.mdx @@ -48,9 +48,9 @@ Your application will be deployed to your `*.workers.dev` subdomain. To deploy your application to a custom domain within the Cloudflare dashboard, go to your Worker > **Triggers** > **Add Custom Domain**. -To deploy your application to a custom domain using Wrangler, open your project's `wrangler.toml / wrangler.json` file. +To deploy your application to a custom domain using Wrangler, open your project's [Wrangler configuration file](/workers/wrangler/configuration/). -To configure a route in your `wrangler.toml / wrangler.json` file, add the following to your environment: +To configure a route in your Wrangler configuration file, add the following to your environment: @@ -62,9 +62,9 @@ routes = [ -If you have specified your zone ID in the environment of your `wrangler.toml / wrangler.json` file, you will not need to write it again in object form. +If you have specified your zone ID in the environment of your Wrangler configuration file, you will not need to write it again in object form. -To configure a subdomain in your `wrangler.toml / wrangler.json` file, add the following to your environment: +To configure a subdomain in your Wrangler configuration file, add the following to your environment: diff --git a/src/content/docs/workers/tutorials/upload-assets-with-r2/index.mdx b/src/content/docs/workers/tutorials/upload-assets-with-r2/index.mdx index cb153e4436a25b6..53028e72cfa123f 100644 --- a/src/content/docs/workers/tutorials/upload-assets-with-r2/index.mdx +++ b/src/content/docs/workers/tutorials/upload-assets-with-r2/index.mdx @@ -66,7 +66,7 @@ npx wrangler r2 bucket list After your new R2 bucket is ready, use it inside your Worker application. -Use your R2 bucket inside your Worker project by modifying the `wrangler.toml / wrangler.json` file to include an R2 bucket [binding](/workers/runtime-apis/bindings/). Add the following R2 bucket binding to your Wrangler file: +Use your R2 bucket inside your Worker project by modifying the [Wrangler configuration file](/workers/wrangler/configuration/) to include an R2 bucket [binding](/workers/runtime-apis/bindings/). Add the following R2 bucket binding to your Wrangler file: diff --git a/src/content/docs/workers/wrangler/api.mdx b/src/content/docs/workers/wrangler/api.mdx index 0c9e62edc35bc91..511810c448fe9da 100644 --- a/src/content/docs/workers/wrangler/api.mdx +++ b/src/content/docs/workers/wrangler/api.mdx @@ -252,14 +252,10 @@ const platform = await getPlatformProxy(options); The path to the config file to use. - If no path is specified, the default behavior is to search from the current directory up the filesystem for a `wrangler.toml / wrangler.json` file to use. + If no path is specified, the default behavior is to search from the current directory up the filesystem for a [Wrangler configuration file](/workers/wrangler/configuration/) to use. **Note:** this field is optional but if a path is specified it must point to a valid file on the filesystem. - - `experimentalJsonConfig` boolean - - If `true`, allows the utility to read a JSON config file (for example, `wrangler.json` or `wrangler.jsonc`). - - `persist` boolean | `{ path: string }` Indicates if and where to persist the bindings data. If `true` or `undefined`, defaults to the same location used by Wrangler, so data can be shared between it and the caller. If `false`, no data is persisted to or read from the filesystem. @@ -295,7 +291,7 @@ const platform = await getPlatformProxy(options); ### Usage -The `getPlatformProxy` function uses bindings found in the `wrangler.toml / wrangler.json` file. For example, if you have an [environment variable](/workers/configuration/environment-variables/#add-environment-variables-via-wrangler) configuration set up in the `wrangler.toml / wrangler.json` file: +The `getPlatformProxy` function uses bindings found in the [Wrangler configuration file](/workers/wrangler/configuration/). For example, if you have an [environment variable](/workers/configuration/environment-variables/#add-environment-variables-via-wrangler) configuration set up in the Wrangler configuration file: @@ -324,7 +320,7 @@ This will print the following output: `MY_VARIABLE = test`. ### Supported bindings -All supported bindings found in your `wrangler.toml / wrangler.json` file are available to you via `env`. +All supported bindings found in your [Wrangler configuration file](/workers/wrangler/configuration/) are available to you via `env`. The bindings supported by `getPlatformProxy` are: diff --git a/src/content/docs/workers/wrangler/commands.mdx b/src/content/docs/workers/wrangler/commands.mdx index 7e3b062cfda0ff7..9eb040eee4568e6 100644 --- a/src/content/docs/workers/wrangler/commands.mdx +++ b/src/content/docs/workers/wrangler/commands.mdx @@ -147,7 +147,7 @@ wrangler init [] [OPTIONS] ``` - `NAME` - - The name of the Workers project. This is both the directory name and `name` property in the generated [Wrangler configuration](/workers/wrangler/configuration/) file. + - The name of the Workers project. This is both the directory name and `name` property in the generated [Wrangler configuration](/workers/wrangler/configuration/). - `--yes` - Answer yes to any prompts for new projects. - `--from-dash` @@ -173,7 +173,7 @@ wrangler generate [] [TEMPLATE] ``` - `NAME` - - The name of the Workers project. This is both the directory name and `name` property in the generated [Wrangler configuration](/workers/wrangler/configuration/) file. + - The name of the Workers project. This is both the directory name and `name` property in the generated [Wrangler configuration](/workers/wrangler/configuration/). - `TEMPLATE` - The URL of a GitHub template, with a default [worker-template](https://github.com/cloudflare/worker-template). Browse a list of available templates on the [cloudflare/workers-sdk](https://github.com/cloudflare/workers-sdk/tree/main/templates#usage) repository. @@ -441,7 +441,7 @@ As of Wrangler v3.2.0, `wrangler dev` is supported by any Linux distributions pr ::: - `SCRIPT` - - The path to an entry point for your Worker. Only required if your `wrangler.toml / wrangler.json` file does not include a `main` key (for example, `main = "index.js"`). + - The path to an entry point for your Worker. Only required if your [Wrangler configuration file](/workers/wrangler/configuration/) does not include a `main` key (for example, `main = "index.js"`). - `--name` - Name of the Worker. - `--no-bundle` @@ -491,11 +491,11 @@ As of Wrangler v3.2.0, `wrangler dev` is supported by any Linux distributions pr - `--var` - Array of `key:value` pairs to inject as variables into your code. The value will always be passed as a string to your Worker. - For example, `--var git_hash:$(git rev-parse HEAD) test:123` makes the `git_hash` and `test` variables available in your Worker's `env`. - - This flag is an alternative to defining [`vars`](/workers/wrangler/configuration/#non-inheritable-keys) in your `wrangler.toml / wrangler.json` file. If defined in both places, this flag's values will be used. + - This flag is an alternative to defining [`vars`](/workers/wrangler/configuration/#non-inheritable-keys) in your [Wrangler configuration file](/workers/wrangler/configuration/). If defined in both places, this flag's values will be used. - `--define` - Array of `key:value` pairs to replace global identifiers in your code. - For example, `--define GIT_HASH:$(git rev-parse HEAD)` will replace all uses of `GIT_HASH` with the actual value at build time. - - This flag is an alternative to defining [`define`](/workers/wrangler/configuration/#non-inheritable-keys) in your `wrangler.toml / wrangler.json` file. If defined in both places, this flag's values will be used. + - This flag is an alternative to defining [`define`](/workers/wrangler/configuration/#non-inheritable-keys) in your [Wrangler configuration file](/workers/wrangler/configuration/). If defined in both places, this flag's values will be used. - `--tsconfig` - Path to a custom `tsconfig.json` file. - `--minify` @@ -536,7 +536,7 @@ None of the options for this command are required. Also, many can be set in your ::: - `SCRIPT` - - The path to an entry point for your Worker. Only required if your `wrangler.toml / wrangler.json` file does not include a `main` key (for example, `main = "index.js"`). + - The path to an entry point for your Worker. Only required if your [Wrangler configuration file](/workers/wrangler/configuration/) does not include a `main` key (for example, `main = "index.js"`). - `--name` - Name of the Worker. - `--no-bundle` @@ -567,11 +567,11 @@ None of the options for this command are required. Also, many can be set in your - `--var` - Array of `key:value` pairs to inject as variables into your code. The value will always be passed as a string to your Worker. - For example, `--var git_hash:$(git rev-parse HEAD) test:123` makes the `git_hash` and `test` variables available in your Worker's `env`. - - This flag is an alternative to defining [`vars`](/workers/wrangler/configuration/#non-inheritable-keys) in your `wrangler.toml / wrangler.json` file. If defined in both places, this flag's values will be used. + - This flag is an alternative to defining [`vars`](/workers/wrangler/configuration/#non-inheritable-keys) in your [Wrangler configuration file](/workers/wrangler/configuration/). If defined in both places, this flag's values will be used. - `--define` - Array of `key:value` pairs to replace global identifiers in your code. - For example, `--define GIT_HASH:$(git rev-parse HEAD)` will replace all uses of `GIT_HASH` with the actual value at build time. - - This flag is an alternative to defining [`define`](/workers/wrangler/configuration/#non-inheritable-keys) in your `wrangler.toml / wrangler.json` file. If defined in both places, this flag's values will be used. + - This flag is an alternative to defining [`define`](/workers/wrangler/configuration/#non-inheritable-keys) in your [Wrangler configuration file](/workers/wrangler/configuration/). If defined in both places, this flag's values will be used. - `--triggers`, `--schedule`, `--schedules` - Cron schedules to attach to the deployed Worker. Refer to [Cron Trigger Examples](/workers/configuration/cron-triggers/#examples). - `--routes`, `--route` string\[] optional @@ -620,7 +620,7 @@ wrangler delete [