diff --git a/src/content/changelogs/queues.yaml b/src/content/changelogs/queues.yaml index 4af0d1031004bbf..825169372613d86 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` 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.toml / wrangler.json` file 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/ai-gateway/integrations/aig-workers-ai-binding.mdx b/src/content/docs/ai-gateway/integrations/aig-workers-ai-binding.mdx index 056c35ebc79dc9d..787608b9a2603a9 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 @@ -4,7 +4,7 @@ pcx_content_type: tutorial updated: 2024-10-17 --- -import { Render, PackageManagers } from "~/components"; +import { Render, PackageManagers, WranglerConfig } from "~/components"; This guide will walk you through setting up and deploying a Workers AI project. You will use [Workers](/workers/), an AI Gateway binding, and a large language model (LLM), to deploy your first AI-powered application on the Cloudflare global network. @@ -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.toml` configuration file. +- A `wrangler.json` configuration file. Go to your application directory: @@ -47,9 +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.toml` file: - -import { WranglerConfig } from "~/components"; +To bind Workers AI to your Worker, add the following to the end of your `wrangler.json` file: @@ -72,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 wrangler.toml as the value for 'binding', + // If you set another name in the `wrangler.toml / wrangler.json` file as the value for 'binding', // replace "AI" with the variable name you defined. AI: Ai; } diff --git a/src/content/docs/analytics/analytics-engine/get-started.mdx b/src/content/docs/analytics/analytics-engine/get-started.mdx index 10e30f6c323c90f..a37dd476312dce9 100644 --- a/src/content/docs/analytics/analytics-engine/get-started.mdx +++ b/src/content/docs/analytics/analytics-engine/get-started.mdx @@ -9,13 +9,11 @@ head: --- -import { DirectoryListing } from "~/components" +import { DirectoryListing, WranglerConfig } from "~/components" ## 1. Name your dataset and add it to your Worker -Add the following to your `wrangler.toml` 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. - -import { WranglerConfig } from "~/components"; +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. diff --git a/src/content/docs/analytics/analytics-engine/worker-querying.mdx b/src/content/docs/analytics/analytics-engine/worker-querying.mdx index e6e37857cb23557..b45aaeaade67382 100644 --- a/src/content/docs/analytics/analytics-engine/worker-querying.mdx +++ b/src/content/docs/analytics/analytics-engine/worker-querying.mdx @@ -8,6 +8,9 @@ head: content: Querying Workers Analytics Engine from a Worker --- + +import { WranglerConfig } from "~/components"; + If you want to access Analytics Engine data from within a Worker you can use `fetch` to access the SQL API. The API can return JSON data that is easy to interact with in JavaScript. ## Authentication @@ -46,9 +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 `wrangler.toml`: - -import { WranglerConfig } from "~/components"; +The account ID is set in the `wrangler.toml / wrangler.json` file: 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 299e8aff7227fed..6a40018be18649d 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 @@ -14,7 +14,7 @@ sidebar: order: 2 --- -import { Render, PackageManagers } from "~/components"; +import { Render, PackageManagers, WranglerConfig } from "~/components"; By following this guide, you will create a Worker that uses the Browser Rendering API along with [Durable Objects](/durable-objects/) to take screenshots from web pages and store them in [R2](/r2/). @@ -69,13 +69,11 @@ wrangler r2 bucket list After running the `list` command, you will see all bucket names, including the ones you have just created. -## 5. Configure `wrangler.toml` +## 5. Configure your Wrangler configuration file -Configure your `browser-worker` project's [`wrangler.toml`](/workers/wrangler/configuration/) file 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.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. -Update your `wrangler.toml` configuration file with the Browser Rendering API binding, the R2 bucket you created and a Durable Object: - -import { WranglerConfig } from "~/components"; +Update your `wrangler.toml / wrangler.json` 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 68fc77f791b7037..f6637b5678fb5f4 100644 --- a/src/content/docs/browser-rendering/get-started/reuse-sessions.mdx +++ b/src/content/docs/browser-rendering/get-started/reuse-sessions.mdx @@ -5,7 +5,7 @@ sidebar: order: 3 --- -import { Render, PackageManagers } from "~/components"; +import { Render, PackageManagers, WranglerConfig } from "~/components"; The best way to improve the performance of your browser rendering worker is to reuse sessions. One way to do that is via [Durable Objects](/browser-rendering/get-started/browser-rendering-with-do/), which allows you to keep a long running connection from a worker to a browser. Another way is to keep the browser open after you've finished with it, and connect to that session each time you have a new request. @@ -35,15 +35,16 @@ Create a new Worker project named `browser-worker` by running: ## 2. Install Puppeteer -In your `browser-worker` directory, install Cloudflare’s [fork of Puppeteer](/browser-rendering/platform/puppeteer/): +In your `browser-worker` directory, install Cloudflare's [fork of Puppeteer](/browser-rendering/platform/puppeteer/): ```sh npm install @cloudflare/puppeteer --save-dev ``` -## 3. Configure `wrangler.toml` +## 3. Configure the `wrangler.toml / wrangler.json` file -``` + +```toml name = "browser-worker" main = "src/index.ts" compatibility_date = "2023-03-14" @@ -51,6 +52,7 @@ compatibility_flags = [ "nodejs_compat" ] browser = { binding = "MYBROWSER" } ``` + ## 4. Code diff --git a/src/content/docs/browser-rendering/get-started/screenshots.mdx b/src/content/docs/browser-rendering/get-started/screenshots.mdx index e9e6f30a3b4dcb5..4f565bd92a68228 100644 --- a/src/content/docs/browser-rendering/get-started/screenshots.mdx +++ b/src/content/docs/browser-rendering/get-started/screenshots.mdx @@ -5,7 +5,7 @@ sidebar: order: 1 --- -import { Render, TabItem, Tabs, PackageManagers } from "~/components"; +import { Render, TabItem, Tabs, PackageManagers, WranglerConfig } from "~/components"; By following this guide, you will create a Worker that uses the Browser Rendering API to take screenshots from web pages. This is a common use case for browser automation. @@ -56,17 +56,15 @@ npx wrangler kv:namespace create BROWSER_KV_DEMO --preview Take note of the IDs for the next step. -## 4. Configure `wrangler.toml` +## 4. Configure the `wrangler.toml / wrangler.json` file -Configure your `browser-worker` project's [`wrangler.toml`](/workers/wrangler/configuration/) file 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.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. -Update your `wrangler.toml` configuration file with the Browser Rendering API binding and the KV namespaces you created: - -import { WranglerConfig } from "~/components"; +Update your `wrangler.toml / wrangler.json` file with the Browser Rendering API binding and the KV namespaces you created: -```toml +```toml title="wrangler.toml" name = "browser-worker" main = "src/index.js" compatibility_date = "2023-03-14" diff --git a/src/content/docs/browser-rendering/how-to/ai.mdx b/src/content/docs/browser-rendering/how-to/ai.mdx index d95ab64425c9dfd..7bf88493d1a0cdd 100644 --- a/src/content/docs/browser-rendering/how-to/ai.mdx +++ b/src/content/docs/browser-rendering/how-to/ai.mdx @@ -4,9 +4,9 @@ sidebar: order: 2 --- -import { Aside } from "~/components"; +import { Aside, WranglerConfig } from "~/components"; -The ability to browse websites can be crucial when building workflows with AI. Here, we provide an example where we use Browser Rendering to visit +The ability to browse websites can be crucial when building workflows with AI. Here, we provide an example where we use Browser Rendering to visit `https://news.ycombinator.com/` and then, using a machine learning model available in [Workers AI](/workers-ai/), extract the first post as JSON with a specified schema. ## Prerequisites @@ -30,16 +30,20 @@ npm i zod npm i zod-to-json-schema ``` -3. Activate the nodejs compatibility flag and add your Browser Rendering binding to your new `wrangler.toml` configuration: +3. Activate the nodejs compatibility flag and add your Browser Rendering binding to your new Wrangler configuration: + ```toml compatibility_flags = [ "nodejs_compat" ] ``` + + ```toml [browser] binding = "MY_BROWSER" ``` + 4. In order to use [Workers AI](/workers-ai/), you need to get your [Account ID and API token](/workers-ai/get-started/rest-api/#1-get-api-token-and-account-id). Once you have those, create a [`.dev.vars`](/workers/configuration/environment-variables/#add-environment-variables-via-wrangler) file and set them there: diff --git a/src/content/docs/browser-rendering/how-to/pdf-generation.mdx b/src/content/docs/browser-rendering/how-to/pdf-generation.mdx index c5ea765a3556dc3..22a40c370f71631 100644 --- a/src/content/docs/browser-rendering/how-to/pdf-generation.mdx +++ b/src/content/docs/browser-rendering/how-to/pdf-generation.mdx @@ -5,7 +5,7 @@ sidebar: order: 1 --- -import { Aside } from "~/components"; +import { Aside, WranglerConfig } from "~/components"; As seen in the [Getting Started guide](/browser-rendering/get-started/screenshots/), Browser Rendering can be used to generate screenshots for any given URL. Alongside screenshots, you can also generate full PDF documents for a given webpage, and can also provide the webpage markup and style ourselves. @@ -23,11 +23,13 @@ npm create cloudflare@latest -- browser-worker npm install @cloudflare/puppeteer --save-dev ``` -3. Add your Browser Rendering binding to your new `wrangler.toml` configuration: +3. Add your Browser Rendering binding to your new Wrangler configuration: + ```toml browser = { binding = "BROWSER" } ``` + 4. Replace the contents of `src/index.ts` (or `src/index.js` for JavaScript projects) with the following skeleton script: diff --git a/src/content/docs/browser-rendering/platform/wrangler.mdx b/src/content/docs/browser-rendering/platform/wrangler.mdx index f94f7bad96e7f6b..91cd57c36cdca89 100644 --- a/src/content/docs/browser-rendering/platform/wrangler.mdx +++ b/src/content/docs/browser-rendering/platform/wrangler.mdx @@ -19,7 +19,7 @@ To install Wrangler, refer to [Install and Update Wrangler](/workers/wrangler/in [Bindings](/workers/runtime-apis/bindings/) allow your Workers to interact with resources on the Cloudflare developer platform. A browser binding will provide your Worker with an authenticated endpoint to interact with a dedicated Chromium browser instance. -To deploy a Browser Rendering Worker, you must declare a [browser binding](/workers/runtime-apis/bindings/) in your Worker's `wrangler.toml` configuration file. +To deploy a Browser Rendering Worker, you must declare a [browser binding](/workers/runtime-apis/bindings/) in your Worker's Wrangler configuration file. 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 7eec498aa71076d..d3d86e065bef2bd 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 @@ -4,7 +4,9 @@ title: Outbound Workers --- -Outbound Workers sit between your customer’s Workers and the public Internet. They give you visibility into all outgoing `fetch()` requests from user Workers. +import { WranglerConfig } from "~/components"; + +Outbound Workers sit between your customer's Workers and the public Internet. They give you visibility into all outgoing `fetch()` requests from user Workers. ![Outbound Workers diagram information](~/assets/images/cloudflare-for-platforms/outbound-worker-diagram.png) @@ -25,8 +27,6 @@ To use Outbound Workers: Make sure that you have `wrangler@3.3.0` or later [installed](/workers/wrangler/install-and-update/). -import { WranglerConfig } from "~/components"; - ```toml diff --git a/src/content/docs/cloudflare-for-platforms/workers-for-platforms/get-started/configuration.mdx b/src/content/docs/cloudflare-for-platforms/workers-for-platforms/get-started/configuration.mdx index cfd397c1a1ccbc3..7750a40cacd968f 100644 --- a/src/content/docs/cloudflare-for-platforms/workers-for-platforms/get-started/configuration.mdx +++ b/src/content/docs/cloudflare-for-platforms/workers-for-platforms/get-started/configuration.mdx @@ -5,7 +5,7 @@ sidebar: order: 1 --- -import { Render, PackageManagers } from "~/components"; +import { Render, PackageManagers, WranglerConfig } from "~/components"; ## Prerequisites: @@ -113,9 +113,7 @@ Change to your project's directory: cd my-dispatcher ``` -Open the `wrangler.toml` file in your project directory, and add the dispatch namespace binding: - -import { WranglerConfig } from "~/components"; +Open the Wrangler file in your project directory, and add the dispatch namespace binding: diff --git a/src/content/docs/cloudflare-for-platforms/workers-for-platforms/get-started/developing-with-wrangler.mdx b/src/content/docs/cloudflare-for-platforms/workers-for-platforms/get-started/developing-with-wrangler.mdx index 76665dbd288b852..5b886dfa8728cc3 100644 --- a/src/content/docs/cloudflare-for-platforms/workers-for-platforms/get-started/developing-with-wrangler.mdx +++ b/src/content/docs/cloudflare-for-platforms/workers-for-platforms/get-started/developing-with-wrangler.mdx @@ -5,7 +5,7 @@ sidebar: order: 3 --- -import { Render, PackageManagers } from "~/components"; +import { Render, PackageManagers, WranglerConfig } from "~/components"; To test your [Dispatch Worker](/cloudflare-for-platforms/workers-for-platforms/reference/how-workers-for-platforms-works/#dynamic-dispatch-worker), [user Worker](/cloudflare-for-platforms/workers-for-platforms/reference/how-workers-for-platforms-works/#user-workers) and [Outbound Worker](/cloudflare-for-platforms/workers-for-platforms/configuration/outbound-workers/) before deploying to production, you can use [Wrangler](/workers/wrangler) for development and testing. @@ -52,9 +52,7 @@ export default { }; ``` -Update the `wrangler.toml` file for customer-worker-1 and add the dispatch namespace: - -import { WranglerConfig } from "~/components"; +Update the Wrangler file for customer-worker-1 and add the dispatch namespace: @@ -111,7 +109,7 @@ export default { }; ``` -Update the `wrangler.toml` file for dispatch-worker and add the dispatch namespace binding: +Update the Wrangler file for dispatch-worker and add the dispatch namespace binding: 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 b5ed268f0a3221c..b5e3e1b6a0637e7 100644 --- a/src/content/docs/cloudflare-one/policies/access/external-evaluation.mdx +++ b/src/content/docs/cloudflare-one/policies/access/external-evaluation.mdx @@ -5,7 +5,7 @@ sidebar: order: 4 --- -import { GlossaryTooltip, Example } from "~/components"; +import { GlossaryTooltip, Example, WranglerConfig } from "~/components"; With Cloudflare Access, you can create Allow or Block policies which evaluate the user based on custom criteria. This is done by adding an **External Evaluation** rule to your policy. The **External Evaluation** selector requires two values: @@ -53,12 +53,14 @@ You can set up External Evaluation rules using any API service, but to get start id = "YOUR_KV_NAMESPACE_ID" ``` -4. Open `wrangler.toml` in a text editor and insert the following: +4. Open the `wrangler.toml / wrangler.json` file in an editor and insert the following: - `[[kv_namespaces]]`: Add the output generated in the previous step. - ``: your Cloudflare Zero Trust team name. - ```txt + + + ```toml name = "my-worker" workers_dev = true compatibility_date = "2024-08-06" @@ -73,6 +75,7 @@ You can set up External Evaluation rules using any API service, but to get start TEAM_DOMAIN=".cloudflareaccess.com" DEBUG=false ``` + ### 2. Program your business logic @@ -136,7 +139,7 @@ To debug your External Evaluation rule: cd my-worker ``` -2. Open `wrangler.toml` in a text editor and set the `debug` variable to `TRUE`. +2. Open the `wrangler.toml / wrangler.json` file 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 6e7590add20715a..515c05a805c65de 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 `wrangler.toml` to include the following values: +3. Modify the `wrangler.toml / wrangler.json` file 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 0e9e33d380cc271..d917b8aa44e9af0 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 @@ -6,7 +6,7 @@ pcx_content_type: tutorial title: Send SSO attributes to Access-protected origins with Workers --- -import { Render, GlossaryTooltip, PackageManagers } from "~/components" +import { Render, GlossaryTooltip, PackageManagers, WranglerConfig } from "~/components" This tutorial will walk you through extending the single-sign-on (SSO) capabilities of [Cloudflare Access](/cloudflare-one/policies/access/) with our serverless computing platform, [Cloudflare Workers](/workers/). Specifically, this guide will demonstrate how to modify requests sent to your secured origin to include additional information from the Cloudflare Access authentication event. @@ -185,9 +185,7 @@ Below is an example of a user identity that includes the `disk_encryption` and ` ## 3. Route the Worker to your application -In `wrangler.toml`, [set up a route](/workers/configuration/routing/routes/) that maps the Worker to your Access application domain: - -import { WranglerConfig } from "~/components"; +In the `wrangler.toml / wrangler.json` file, [set up a route](/workers/configuration/routing/routes/) that maps the Worker to your Access application domain: diff --git a/src/content/docs/constellation/platform/client-api.mdx b/src/content/docs/constellation/platform/client-api.mdx index 329dc99b6442070..550376d7dccaa87 100644 --- a/src/content/docs/constellation/platform/client-api.mdx +++ b/src/content/docs/constellation/platform/client-api.mdx @@ -213,7 +213,7 @@ const session = new InferenceSession( ); ``` -* **env.PROJECT** is the project binding defined in your `wrangler.toml` configuration. +* **env.PROJECT** is the project binding defined in your Wrangler configuration. * **0ae7bd14...** is the model ID inside the project. Use Wrangler to list the models and their IDs in a project. #### async session.run() diff --git a/src/content/docs/d1/best-practices/local-development.mdx b/src/content/docs/d1/best-practices/local-development.mdx index 5d3d38b1c159864..98e2ed772a364cb 100644 --- a/src/content/docs/d1/best-practices/local-development.mdx +++ b/src/content/docs/d1/best-practices/local-development.mdx @@ -5,6 +5,8 @@ sidebar: order: 8 --- +import { WranglerConfig } from "~/components"; + D1 has fully-featured support for local development, running the same version of D1 as Cloudflare runs globally. Local development uses [Wrangler](/workers/wrangler/install-and-update/), the command-line interface for Workers, to manage local development sessions and state. ## Start a local development session @@ -52,13 +54,11 @@ 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` configuration file would resemble the following: - -import { WranglerConfig } from "~/components"; +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: -```toml title="wrangler.toml" +```toml [[d1_databases]] binding = "DB" database_name = "test-db" @@ -73,21 +73,19 @@ 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` 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.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. :::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` should resemble the following: - - +your `wrangler.toml / wrangler.json` file should resemble the following: ```toml -# If you are only using Pages + D1, you only need the below in your wrangler.toml to interact with D1 locally. +# If you are only using Pages + D1, you only need the below in your Wrangler config file to interact with D1 locally. [[d1_databases]] binding = "DB" # Should match preview_database_id database_name = "YOUR_DATABASE_NAME" @@ -160,11 +158,9 @@ console.log(results); ### `unstable_dev` -Wrangler exposes an [`unstable_dev()`](/workers/wrangler/api/) that allows you to run a local HTTP server for testing Workers and D1. Run [migrations](/d1/reference/migrations/) against a local database by setting a `preview_database_id` in your `wrangler.toml` configuration. - -Given the below `wrangler.toml` configuration: - +Wrangler exposes an [`unstable_dev()`](/workers/wrangler/api/) that allows you to run a local HTTP server for testing Workers and D1. Run [migrations](/d1/reference/migrations/) against a local database by setting a `preview_database_id` in your Wrangler configuration. +Given the below Wrangler configuration: diff --git a/src/content/docs/d1/configuration/environments.mdx b/src/content/docs/d1/configuration/environments.mdx index 2f4a62c1e3e49a9..18d9d451d4943d8 100644 --- a/src/content/docs/d1/configuration/environments.mdx +++ b/src/content/docs/d1/configuration/environments.mdx @@ -6,11 +6,11 @@ sidebar: --- -[Environments](/workers/wrangler/environments/) are different contexts that your code runs in. Cloudflare Developer Platform allows you to create and manage different environments. Through environments, you can deploy the same project to multiple places under multiple names. +import { WranglerConfig } from "~/components"; -To specify different D1 databases for different environments, use the following syntax in your `wrangler.toml` file: +[Environments](/workers/wrangler/environments/) are different contexts that your code runs in. Cloudflare Developer Platform allows you to create and manage different environments. Through environments, you can deploy the same project to multiple places under multiple names. -import { WranglerConfig } from "~/components"; +To specify different D1 databases for different environments, use the following syntax in your Wrangler file: @@ -32,11 +32,9 @@ d1_databases = [ In the code above, the `staging` environment is using a different database (`DATABASE_NAME_1`) than the `production` environment (`DATABASE_NAME_2`). -## Anatomy of `wrangler.toml` file - -If you need to specify different D1 databases for different environments, your `wrangler.toml` may contain bindings that resemble the following: - +## 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: diff --git a/src/content/docs/d1/examples/d1-and-hono.mdx b/src/content/docs/d1/examples/d1-and-hono.mdx index 9a2784c5f6e4059..a77e6abc9dfed85 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 [`wrangler.toml`](/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.toml / wrangler.json` 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: 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.toml / wrangler.json` 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 3cf86ffd579eef4..bd706040910ea87 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: 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.toml / wrangler.json` file: 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 12b48a3785dba5c..e2b9885736907b4 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: 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.toml / wrangler.json` file: 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 e5a2f198f6358d4..a135c34270a1dd4 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 @@ -11,6 +11,8 @@ sidebar: description: Learn how to query D1 from a Python Worker --- +import { WranglerConfig } from "~/components"; + The Cloudflare Workers platform supports [multiple languages](/workers/languages/), including TypeScript, JavaScript, Rust and Python. This guide shows you how to query a D1 database from [Python](/workers/languages/python/) and deploy your application globally. :::note @@ -31,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` configuration 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.toml / wrangler.json` file. 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: @@ -55,9 +57,7 @@ npx wrangler d1 info some-existing-db ### 1. Configure bindings -In your `wrangler.toml` file, create a new `[[d1_databases]]` configuration block and set `database_name` and `database_id` to the name and id (respectively) of the D1 database you want to query: - -import { WranglerConfig } from "~/components"; +In your Wrangler file, create a new `[[d1_databases]]` configuration block and set `database_name` and `database_id` to the name and id (respectively) of the D1 database you want to query: @@ -79,7 +79,7 @@ The value of `binding` is how you will refer to your database from within your W ### 2. Create your Python Worker -To create a Python Worker, create an empty file at `src/entry.py`, matching the value of `main` in your `wrangler.toml` file with the contents below: +To create a Python Worker, create an empty file at `src/entry.py`, matching the value of `main` in your Wrangler file with the contents below: ```python from js import Response @@ -94,7 +94,7 @@ async def on_fetch(request, env): ``` -The value of `binding` in your `wrangler.toml` file exactly must match the name of the variable in your Python code. This example refers to the database via a `DB` binding, and query this binding via `await env.DB.prepare(...)`. +The value of `binding` in your Wrangler file exactly must match the name of the variable in your Python code. This example refers to the database via a `DB` binding, and query this binding via `await env.DB.prepare(...)`. You can then deploy your Python Worker directly: @@ -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` with the `database_id` and `database_name` of a valid D1 database. -- Ensure `compatibility_flags = ["python_workers"]` is set in your `wrangler.toml`, which is required for Python. +- 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. - 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 a2477f988e65753..db4a97528d73e45 100644 --- a/src/content/docs/d1/get-started.mdx +++ b/src/content/docs/d1/get-started.mdx @@ -19,7 +19,7 @@ import { This guide instructs you through: -- Creating your first database using D1, Cloudflare’s native serverless SQL database. +- Creating your first database using D1, Cloudflare's native serverless SQL database. - Creating a schema and querying your database via the command-line. - Connecting a [Cloudflare Worker](/workers/) to your D1 database to query your D1 database programmatically. @@ -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.toml** + - **wrangler.json** Your new `d1-tutorial` directory includes: - A `"Hello World"` [Worker](/workers/get-started/guide/#3-write-code) in `index.ts`. - - A [`wrangler.toml`](/workers/wrangler/configuration/) configuration file. `wrangler.toml` is how your `d1-tutorial` Worker accesses your D1 database. + - A [`wrangler.toml / wrangler.json` file](/workers/wrangler/configuration/). This file is how your `d1-tutorial` Worker accesses your D1 database. @@ -170,12 +170,12 @@ To bind your D1 database to your Worker: -You create bindings by updating your `wrangler.toml` file. +You create bindings by updating your Wrangler file. 1. Copy the lines obtained from [step 2](/d1/get-started/#2-create-a-database) from your terminal. -2. Add them to the end of your `wrangler.toml` file. +2. Add them to the end of your Wrangler file. @@ -230,7 +230,7 @@ You create bindings by adding them to the Worker you have created. -With `wrangler.toml` configured properly, set up your database. Use the example `schema.sql` file below to initialize your database. +After correctly preparing your `wrangler.toml / wrangler.json` file, 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: @@ -309,7 +309,7 @@ After you have set up your database, run an SQL query from within your Worker. ```typescript export interface Env { - // If you set another name in wrangler.toml as the value for 'binding', + // If you set another name in the Wrangler config file for the value for 'binding', // replace "DB" with the variable name you defined. DB: D1Database; } @@ -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 `wrangler.toml` 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.toml / wrangler.json` file 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/reference/migrations.mdx b/src/content/docs/d1/reference/migrations.mdx index ca152a6bc53a5d1..363b0df10c0e316 100644 --- a/src/content/docs/d1/reference/migrations.mdx +++ b/src/content/docs/d1/reference/migrations.mdx @@ -6,6 +6,8 @@ sidebar: --- +import { WranglerConfig } from "~/components"; + Database migrations are a way of versioning your database. Each migration is stored as an `.sql` file in your `migrations` folder. The `migrations` folder is created in your project directory when you create your first migration. This enables you to store and track changes throughout database development. ## Features @@ -22,9 +24,7 @@ Every migration file in the `migrations` folder has a specified version number i By default, migrations are created in the `migrations/` folder in your Worker project directory. Creating migrations will keep a record of applied migrations in the `d1_migrations` table found in your database. -This location and table name can be customized in your `wrangler.toml` file, inside the D1 binding. - -import { WranglerConfig } from "~/components"; +This location and table name can be customized in your Wrangler file, inside the D1 binding. 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 012173de452f1a1..aa97a6c69c271ab 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 @@ -13,7 +13,7 @@ languages: - SQL --- -import { Render, PackageManagers, Stream } from "~/components"; +import { Render, PackageManagers, Stream, WranglerConfig } from "~/components"; In this tutorial, you will learn how to use D1 to add comments to a static blog site. To do this, you will construct a new D1 database, and build a JSON API that allows the creation and retrieval of comments. @@ -88,9 +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.toml` 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 `wrangler.toml`, set up the binding `DB` and connect it to the `database_name` and `database_id`: - -import { WranglerConfig } from "~/components"; +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`: @@ -103,7 +101,7 @@ database_id = "4e1c28a9-90e4-41da-8b4b-6cf36e5abb29" -With your binding configured in your `wrangler.toml` file, you can interact with your database from the command line, and inside your Workers function. +With your binding configured in your Wrangler file, you can interact with your database from the command line, and inside your Workers function. ## 4. Interact with D1 @@ -149,7 +147,7 @@ npx wrangler d1 execute d1-example --remote --file schemas/schema.sql ## 5. Execute SQL -In earlier steps, you created a SQL database and populated it with initial data. Now, you will add a route to your Workers function to retrieve data from that database. Based on your `wrangler.toml` configuration in previous steps, your D1 database is now accessible via the `DB` binding. In your code, use the binding to prepare SQL statements and execute them, for example, to retrieve comments: +In earlier steps, you created a SQL database and populated it with initial data. Now, you will add a route to your Workers function to retrieve data from that database. Based on your Wrangler configuration in previous steps, your D1 database is now accessible via the `DB` binding. In your code, use the binding to prepare SQL statements and execute them, for example, to retrieve comments: ```js app.get("/api/posts/:slug/comments", async (c) => { @@ -205,7 +203,7 @@ With your application ready for deployment, use Wrangler to build and deploy you Begin by running `wrangler whoami` to confirm that you are logged in to your Cloudflare account. If you are not logged in, Wrangler will prompt you to login, creating an API key that you can use to make authenticated requests automatically from your local machine. -After you have logged in, confirm that your `wrangler.toml` file is configured similarly to what is seen below. You can change the `name` field to a project name of your choice: +After you have logged in, confirm that your Wrangler file is configured similarly to what is seen below. You can change the `name` field to a project name of your choice: 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 486bc38f373ea14..ae25e1d87afd4a4 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 @@ -13,6 +13,8 @@ languages: - SQL --- +import { WranglerConfig } from "~/components"; + In this tutorial, you will learn how to use D1 to build a staff directory. This application will allow users to access information about an organization's employees and give admins the ability to add new employees directly within the app. To do this, you will first need to set up a [D1 database](/d1/get-started/) to manage data seamlessly, then you will develop and deploy your application using the [HonoX Framework](https://github.com/honojs/honox) and [Cloudflare Pages](/pages). @@ -68,11 +70,9 @@ 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 configuration 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.toml / wrangler.json` file 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.toml` file in your project's root directory and input the basic setup information: - -import { WranglerConfig } from "~/components"; +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: @@ -83,7 +83,7 @@ compatibility_date = "2023-12-01" -Next, add the database binding details to your `wrangler.toml` file. This involves specifying a binding name (in this case, `DB`), which will be used to reference the database within your application, along with the `database_name` and `database_id` provided when you created the database: +Next, add the database binding details to your Wrangler file. This involves specifying a binding name (in this case, `DB`), which will be used to reference the database within your application, along with the `database_name` and `database_id` provided when you created the database: @@ -173,7 +173,7 @@ To execute the schema locally and seed data into your local directory, pass the ## 5. Create SQL statements -After setting up your D1 database and configuring the `wrangler.toml` file as outlined in previous steps, your database is accessible in your code through the `DB` binding. This allows you to directly interact with the database by preparing and executing SQL statements. In the following step, you will learn how to use this binding to perform common database operations such as retrieving data and inserting new records. +After setting up your D1 database and configuring the Wrangler file as outlined in previous steps, your database is accessible in your code through the `DB` binding. This allows you to directly interact with the database by preparing and executing SQL statements. In the following step, you will learn how to use this binding to perform common database operations such as retrieving data and inserting new records. ### Retrieve data from database @@ -377,7 +377,7 @@ Use the `wrangler r2 bucket create` command to create a bucket: wrangler r2 bucket create employee-avatars ``` -Once the bucket is created, add the R2 bucket binding to your `wrangler.toml` file: +Once the bucket is created, add the R2 bucket binding to your Wrangler file: @@ -428,7 +428,7 @@ if (imageFile instanceof File) { With your application ready for deployment, you can use Wrangler to build and deploy your project to the Cloudflare Network. Ensure you are logged in to your Cloudflare account by running the `wrangler whoami` command. If you are not logged in, Wrangler will prompt you to login by creating an API key that you can use to make authenticated requests automatically from your computer. -After successful login, confirm that your `wrangler.toml` file is configured similarly to the code block below: +After successful login, confirm that your Wrangler file is configured similarly to the code block below: diff --git a/src/content/docs/d1/tutorials/build-an-api-to-access-d1/index.mdx b/src/content/docs/d1/tutorials/build-an-api-to-access-d1/index.mdx index bb92a93b867cced..d69f1becdea36b3 100644 --- a/src/content/docs/d1/tutorials/build-an-api-to-access-d1/index.mdx +++ b/src/content/docs/d1/tutorials/build-an-api-to-access-d1/index.mdx @@ -220,7 +220,7 @@ Make a note of the displayed `database_name` and `database_id`. You will use thi ## 7. Add a binding -1. From your `d1-http` folder, open the `wrangler.toml` file, Wrangler's configuration file. +1. From your `d1-http` folder, open the Wrangler file, Wrangler's configuration file. 2. Add the following binding in the file. Make sure that the `database_name` and the `database_id` are correct. diff --git a/src/content/docs/d1/tutorials/d1-and-prisma-orm/index.mdx b/src/content/docs/d1/tutorials/d1-and-prisma-orm/index.mdx index 7542b338e88da60..19c11b7aca284bd 100644 --- a/src/content/docs/d1/tutorials/d1-and-prisma-orm/index.mdx +++ b/src/content/docs/d1/tutorials/d1-and-prisma-orm/index.mdx @@ -11,6 +11,8 @@ languages: - SQL --- +import { WranglerConfig } from "~/components"; + ## What is Prisma ORM? [Prisma ORM](https://www.prisma.io/orm) is a next-generation JavaScript and TypeScript ORM that unlocks a new level of developer experience when working with databases thanks to its intuitive data model, automated migrations, type-safety and auto-completion. @@ -112,9 +114,7 @@ database_id = "__YOUR_D1_DATABASE_ID__" You now have a D1 database in your Cloudflare account with a binding to your Cloudflare Worker. -Copy the last part of the command output and paste it into your `wrangler.toml` file. It should look similar to this: - -import { WranglerConfig } from "~/components"; +Copy the last part of the command output and paste it into your Wrangler file. It should look similar to this: diff --git a/src/content/docs/d1/worker-api/d1-database.mdx b/src/content/docs/d1/worker-api/d1-database.mdx index 4054166f9375dab..993939f1f33ce14 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 file. + // D1 database is 'env.DB', where "DB" is the binding name from the `wrangler.toml / wrangler.json` 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 8a3d916bdae203d..7207cd6c7090c10 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 @@ -17,7 +17,7 @@ spotlight: author_bio_source: LinkedIn --- -import { TabItem, Tabs } from "~/components"; +import { TabItem, Tabs, WranglerConfig } from "~/components"; In this tutorial, you will put together a Cloudflare Worker that creates and serves a sitemap using data from [Sanity.io](https://www.sanity.io), a headless CMS. @@ -90,15 +90,13 @@ yarn add @sanity/client -## Configure wrangler.toml +## Configure Wrangler -A default `wrangler.toml` was generated in the previous step. +A default `wrangler.json` was generated in the previous step. -The `wrangler.toml` file is a configuration file used to specify project settings and deployment configurations in a structured format. +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` should be similar to the following: - -import { WranglerConfig } from "~/components"; +For this tutorial your `wrangler.toml / wrangler.json` file should be similar to the following: @@ -122,7 +120,7 @@ You must update the `[vars]` section to match your needs. See the inline comment :::caution -Secrets do not belong in `wrangler.toml`. 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.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/). ::: @@ -145,7 +143,7 @@ Paste the following code into the existing `index.ts|js` file: * - Open a browser tab at http://localhost:8787/ to see your worker in action * - Run `npm run deploy` to publish your worker * - * Bind resources to your worker in `wrangler.toml`. After adding bindings, a type definition for the + * Bind resources to your worker in Wrangler config file. After adding bindings, a type definition for the * `Env` object can be regenerated with `npm run cf-typegen`. * * Learn more at https://developers.cloudflare.com/workers/ 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 43287c5a2e1ddb5..e939c1dc9ee4d1e 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 @@ -22,7 +22,7 @@ sidebar: order: 2 --- -import { Render, TabItem, Tabs } from "~/components"; +import { Render, TabItem, Tabs, WranglerConfig } from "~/components"; E-commerce and media sites often work on increasing the average transaction value to boost profitability. One of the strategies to increase the average transaction value is "cross-selling," which involves recommending related products. Cloudflare offers a range of products designed to build mechanisms for retrieving data related to the products users are viewing or requesting. In this tutorial, you will experience developing functionalities necessary for cross-selling by creating APIs for related product searches and product recommendations. @@ -179,7 +179,7 @@ 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 `wrangler.toml` 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.toml / wrangler.json` file to bind the Vectorize index with your Worker application. Copy the three lines starting with `[[vectorize]]`. ```sh ✅ Successfully created a new Vectorize index: 'stripe-products' @@ -190,9 +190,7 @@ binding = "VECTORIZE_INDEX" index_name = "stripe-products" ``` -To use the created Vectorize index from your Worker, let's add the binding. Open `wrangler.toml` and add the copied lines. - -import { WranglerConfig } from "~/components"; +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. @@ -208,9 +206,7 @@ index_name = "stripe-products" -Additionally, let's add the configuration to use Workers AI in `wrangler.toml`. - - +Additionally, let's add the configuration to use Workers AI in the `wrangler.toml / wrangler.json` file. 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 1edce6b17cd6dc6..040332d4b8b92ee 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 @@ -17,7 +17,7 @@ spotlight: author_bio_source: GitHub --- -import { Render, PackageManagers } from "~/components"; +import { Render, PackageManagers, WranglerConfig } from "~/components"; This tutorial gives you an overview on how to create a TypeScript-based Cloudflare Worker which allows you to control file access based on a simple username and password authentication. To achieve this, we will use a [D1 database](/d1/) for user management and an [R2 bucket](/r2/) for file storage. @@ -70,9 +70,7 @@ Replace `` with the name you want to use for your database. After the database is successfully created, you will see the data for the binding displayed as an output. The binding declaration will start with `[[d1_databases]]` and contain the binding name, database name and ID. -To use the database in your worker, you will need to add the binding to your `wrangler.toml` file, by copying the declaration and pasting it into the wrangler file, as shown in the example below. - -import { WranglerConfig } from "~/components"; +To use the database in your worker, you will need to add the binding to your Wrangler file, by copying the declaration and pasting it into the wrangler file, as shown in the example below. @@ -96,7 +94,7 @@ npx wrangler r2 bucket create ``` This works similar to the D1 database creation, where you will need to replace `` with the name you want to use for your bucket. -To do this, go to the `wrangler.toml` file again and then add the following lines: +To do this, go to the Wrangler file again and then add the following lines: @@ -112,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 configuration 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.toml / wrangler.json` file (recommended). ```sh npm run cf-typegen diff --git a/src/content/docs/durable-objects/api/namespace.mdx b/src/content/docs/durable-objects/api/namespace.mdx index 624629688822528..bafef513d287c3d 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 `wrangler.toml`. +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. 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 eea471fb178acba..505513cddb5d397 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` configuration 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.toml / wrangler.json` file](/workers/wrangler/configuration/) of your Durable Object. ``` compatibility_flags = ["experimental", "webgpu"] diff --git a/src/content/docs/durable-objects/best-practices/access-durable-objects-storage.mdx b/src/content/docs/durable-objects/best-practices/access-durable-objects-storage.mdx index b93175cbb23eff1..e291ac0d8e2dda0 100644 --- a/src/content/docs/durable-objects/best-practices/access-durable-objects-storage.mdx +++ b/src/content/docs/durable-objects/best-practices/access-durable-objects-storage.mdx @@ -6,7 +6,7 @@ sidebar: --- -import { Render, GlossaryTooltip } from "~/components"; +import { Render, GlossaryTooltip, WranglerConfig } from "~/components"; Durable Objects are a powerful compute API that provides a compute with storage building block. Each Durable Object has its own private, transactional and strongly consistent storage. Durable Objects Storage API provides access to a Durable Object's attached storage. @@ -56,9 +56,7 @@ The new beta version of Durable Objects is available where each Durable Object h ::: -To allow a new Durable Object class to use SQLite storage backend, use `new_sqlite_classes` on the migration in your Worker's `wrangler.toml` file: - -import { WranglerConfig } from "~/components"; +To allow a new Durable Object class to use SQLite storage backend, use `new_sqlite_classes` on the migration in your Worker's Wrangler file: diff --git a/src/content/docs/durable-objects/best-practices/websockets.mdx b/src/content/docs/durable-objects/best-practices/websockets.mdx index 23c4f900bd6b009..2766f0185ab123f 100644 --- a/src/content/docs/durable-objects/best-practices/websockets.mdx +++ b/src/content/docs/durable-objects/best-practices/websockets.mdx @@ -217,7 +217,7 @@ export class WebSocketServer extends DurableObject { -To execute this code, configure your `wrangler.toml` file to include a Durable Object [binding](/durable-objects/get-started/walkthrough/#5-configure-durable-object-bindings) and [migration](/durable-objects/reference/durable-objects-migrations/) based on the namespace and class name chosen previously. +To execute this code, configure your Wrangler file to include a Durable Object [binding](/durable-objects/get-started/walkthrough/#5-configure-durable-object-bindings) and [migration](/durable-objects/reference/durable-objects-migrations/) based on the namespace and class name chosen previously. ```toml title="wrangler.toml" name = "websocket-server" @@ -355,7 +355,7 @@ export class WebSocketHibernationServer extends DurableObject { -Similar to the WebSocket Standard API example, to execute this code, configure your `wrangler.toml` file to include a Durable Object [binding](/durable-objects/get-started/walkthrough/#5-configure-durable-object-bindings) and [migration](/durable-objects/reference/durable-objects-migrations/) based on the namespace and class name chosen previously. +Similar to the WebSocket Standard API example, to execute this code, configure your Wrangler file to include a Durable Object [binding](/durable-objects/get-started/walkthrough/#5-configure-durable-object-bindings) and [migration](/durable-objects/reference/durable-objects-migrations/) based on the namespace and class name chosen previously. ```toml title="wrangler.toml" name = "websocket-hibernation-server" diff --git a/src/content/docs/durable-objects/examples/alarms-api.mdx b/src/content/docs/durable-objects/examples/alarms-api.mdx index 55d86de038fa929..62aebe812e46a45 100644 --- a/src/content/docs/durable-objects/examples/alarms-api.mdx +++ b/src/content/docs/durable-objects/examples/alarms-api.mdx @@ -13,7 +13,7 @@ description: Use the Durable Objects Alarms API to batch requests to a Durable O --- -import { GlossaryTooltip } from "~/components"; +import { GlossaryTooltip, WranglerConfig } from "~/components"; This example implements an `alarm()` handler that wakes the Durable Object once every 10 seconds to batch requests to a single Durable Object. The `alarm()` handler will delay processing until there is enough work in the queue. @@ -74,9 +74,7 @@ export class Batcher extends DurableObject { The `alarm()` handler will be called once every 10 seconds. If an unexpected error terminates the Durable Object, the `alarm()` handler will be re-instantiated on another machine. Following a short delay, the `alarm()` handler will run from the beginning on the other machine. -Finally, configure your `wrangler.toml` file to include a Durable Object [binding](/durable-objects/get-started/walkthrough/#5-configure-durable-object-bindings) and [migration](/durable-objects/reference/durable-objects-migrations/) based on the namespace and class name chosen previously. - -import { WranglerConfig } from "~/components"; +Finally, configure your Wrangler file to include a Durable Object [binding](/durable-objects/get-started/walkthrough/#5-configure-durable-object-bindings) and [migration](/durable-objects/reference/durable-objects-migrations/) based on the namespace and class name chosen previously. diff --git a/src/content/docs/durable-objects/examples/build-a-counter.mdx b/src/content/docs/durable-objects/examples/build-a-counter.mdx index 220c43fd73e082d..0b6946196e6af16 100644 --- a/src/content/docs/durable-objects/examples/build-a-counter.mdx +++ b/src/content/docs/durable-objects/examples/build-a-counter.mdx @@ -11,7 +11,7 @@ description: Build a counter using Durable Objects and Workers with RPC methods. --- -import { TabItem, Tabs } from "~/components" +import { TabItem, Tabs, WranglerConfig } from "~/components" This example shows how to build a counter using Durable Objects and Workers with [RPC methods](/workers/runtime-apis/rpc) that can print, increment, and decrement a `name` provided by the URL query string parameter, for example, `?name=A`. @@ -170,9 +170,7 @@ export class Counter extends DurableObject { -Finally, configure your `wrangler.toml` file to include a Durable Object [binding](/durable-objects/get-started/walkthrough/#5-configure-durable-object-bindings) and [migration](/durable-objects/reference/durable-objects-migrations/) based on the namespace and class name chosen previously. - -import { WranglerConfig } from "~/components"; +Finally, configure your Wrangler file to include a Durable Object [binding](/durable-objects/get-started/walkthrough/#5-configure-durable-object-bindings) and [migration](/durable-objects/reference/durable-objects-migrations/) based on the namespace and class name chosen previously. diff --git a/src/content/docs/durable-objects/examples/build-a-rate-limiter.mdx b/src/content/docs/durable-objects/examples/build-a-rate-limiter.mdx index c18155010e889ca..68ae928fa754a4e 100644 --- a/src/content/docs/durable-objects/examples/build-a-rate-limiter.mdx +++ b/src/content/docs/durable-objects/examples/build-a-rate-limiter.mdx @@ -11,7 +11,7 @@ description: Build a rate limiter using Durable Objects and Workers. --- -import { TabItem, Tabs, GlossaryTooltip } from "~/components" +import { TabItem, Tabs, GlossaryTooltip, WranglerConfig } from "~/components" This example shows how to build a rate limiter using Durable Objects and Workers that can be used to protect upstream resources, including third-party APIs that your application relies on and/or services that may be costly for you to invoke. @@ -264,9 +264,7 @@ export class RateLimiter extends DurableObject { -Finally, configure your `wrangler.toml` file to include a Durable Object [binding](/durable-objects/get-started/walkthrough/#5-configure-durable-object-bindings) and [migration](/durable-objects/reference/durable-objects-migrations/) based on the namespace and class name chosen previously. - -import { WranglerConfig } from "~/components"; +Finally, configure your Wrangler file to include a Durable Object [binding](/durable-objects/get-started/walkthrough/#5-configure-durable-object-bindings) and [migration](/durable-objects/reference/durable-objects-migrations/) based on the namespace and class name chosen previously. diff --git a/src/content/docs/durable-objects/examples/durable-object-in-memory-state.mdx b/src/content/docs/durable-objects/examples/durable-object-in-memory-state.mdx index ec4c4f0e202cb10..d7f25d57cc7f1dd 100644 --- a/src/content/docs/durable-objects/examples/durable-object-in-memory-state.mdx +++ b/src/content/docs/durable-objects/examples/durable-object-in-memory-state.mdx @@ -13,6 +13,8 @@ description: Create a Durable Object that stores the last location it was --- +import { WranglerConfig } from "~/components"; + This example shows you how Durable Objects are stateful, meaning in-memory state can be retained between requests. After a brief period of inactivity, the Durable Object will be evicted, and all in-memory state will be lost. The next request will reconstruct the object, but instead of showing the city of the previous request, it will display a message indicating that the object has been reinitialized. If you need your applications state to survive eviction, write the state to storage by using the [Storage API](/durable-objects/api/storage-api/), or by storing your data elsewhere. ```js @@ -68,9 +70,7 @@ New Location: ${request.cf.city}`); } ``` -Finally, configure your `wrangler.toml` file to include a Durable Object [binding](/durable-objects/get-started/walkthrough/#5-configure-durable-object-bindings) and [migration](/durable-objects/reference/durable-objects-migrations/) based on the namespace and class name chosen previously. - -import { WranglerConfig } from "~/components"; +Finally, configure your Wrangler file to include a Durable Object [binding](/durable-objects/get-started/walkthrough/#5-configure-durable-object-bindings) and [migration](/durable-objects/reference/durable-objects-migrations/) based on the namespace and class name chosen previously. diff --git a/src/content/docs/durable-objects/examples/durable-object-ttl.mdx b/src/content/docs/durable-objects/examples/durable-object-ttl.mdx index e01f04819fc8859..c02ab6883fcd59c 100644 --- a/src/content/docs/durable-objects/examples/durable-object-ttl.mdx +++ b/src/content/docs/durable-objects/examples/durable-object-ttl.mdx @@ -12,7 +12,7 @@ sidebar: description: Use the Durable Objects Alarms API to implement a Time To Live (TTL) for Durable Object instances. --- -import { TabItem, Tabs, GlossaryTooltip } from "~/components"; +import { TabItem, Tabs, GlossaryTooltip, WranglerConfig } from "~/components"; A common feature request for Durable Objects is a Time To Live (TTL) for Durable Object instances. Durable Objects give developers the tools to implement a custom TTL in only a few lines of code. This example demonstrates how to implement a TTL making use of `alarms`. While this TTL will be extended upon every new request to the Durable Object, this can be customized based on a particular use case. @@ -100,9 +100,7 @@ export default { -To test and deploy this example, configure your `wrangler.toml` file to include a Durable Object [binding](/durable-objects/get-started/walkthrough/#5-configure-durable-object-bindings) and [migration](/durable-objects/reference/durable-objects-migrations/) based on the namespace and class name chosen previously. - -import { WranglerConfig } from "~/components"; +To test and deploy this example, configure your Wrangler file to include a Durable Object [binding](/durable-objects/get-started/walkthrough/#5-configure-durable-object-bindings) and [migration](/durable-objects/reference/durable-objects-migrations/) based on the namespace and class name chosen previously. diff --git a/src/content/docs/durable-objects/examples/use-kv-from-durable-objects.mdx b/src/content/docs/durable-objects/examples/use-kv-from-durable-objects.mdx index 742b8e024122f8d..4ed2f79340b3ead 100644 --- a/src/content/docs/durable-objects/examples/use-kv-from-durable-objects.mdx +++ b/src/content/docs/durable-objects/examples/use-kv-from-durable-objects.mdx @@ -11,19 +11,17 @@ description: Read and write to/from KV within a Durable Object --- -import { GlossaryTooltip } from "~/components"; +import { GlossaryTooltip, WranglerConfig } from "~/components"; The following Worker script shows you how to configure a Durable Object to read from and/or write to a [Workers KV namespace](/kv/concepts/how-kv-works/). This is useful when using a Durable Object to coordinate between multiple clients, and allows you to serialize writes to KV and/or broadcast a single read from KV to hundreds or thousands of clients connected to a single Durable Object [using WebSockets](/durable-objects/best-practices/websockets/). Prerequisites: * A [KV namespace](/kv/api/) created via the Cloudflare dashboard or the [wrangler CLI](/workers/wrangler/install-and-update/). -* A [configured binding](/kv/concepts/kv-bindings/) for the `kv_namespace` in the Cloudflare dashboard or `wrangler.toml` file. +* A [configured binding](/kv/concepts/kv-bindings/) for the `kv_namespace` in the Cloudflare dashboard or Wrangler file. * A [Durable Object namespace binding](/workers/wrangler/configuration/#durable-objects). -Configure your `wrangler.toml` file as follows: - -import { WranglerConfig } from "~/components"; +Configure your Wrangler file as follows: diff --git a/src/content/docs/durable-objects/examples/websocket-hibernation-server.mdx b/src/content/docs/durable-objects/examples/websocket-hibernation-server.mdx index 40699a52402af0f..f8076683d1048dc 100644 --- a/src/content/docs/durable-objects/examples/websocket-hibernation-server.mdx +++ b/src/content/docs/durable-objects/examples/websocket-hibernation-server.mdx @@ -13,7 +13,7 @@ description: Build a WebSocket server using WebSocket Hibernation on Durable --- -import { TabItem, Tabs } from "~/components" +import { TabItem, Tabs, WranglerConfig } from "~/components" This example is similar to the [Build a WebSocket server](/durable-objects/examples/websocket-server/) example, but uses the WebSocket Hibernation API. The WebSocket Hibernation API should be preferred for WebSocket server applications built on Durable Objects, since it significantly decreases duration charge, and provides additional features that pair well with WebSocket applications. For more information, refer to [Use Durable Objects with WebSockets](/durable-objects/best-practices/websockets/). @@ -177,9 +177,7 @@ export class WebSocketHibernationServer extends DurableObject { -Finally, configure your `wrangler.toml` file to include a Durable Object [binding](/durable-objects/get-started/walkthrough/#5-configure-durable-object-bindings) and [migration](/durable-objects/reference/durable-objects-migrations/) based on the namespace and class name chosen previously. - -import { WranglerConfig } from "~/components"; +Finally, configure your Wrangler file to include a Durable Object [binding](/durable-objects/get-started/walkthrough/#5-configure-durable-object-bindings) and [migration](/durable-objects/reference/durable-objects-migrations/) based on the namespace and class name chosen previously. diff --git a/src/content/docs/durable-objects/examples/websocket-server.mdx b/src/content/docs/durable-objects/examples/websocket-server.mdx index ded0ede2bdb8652..916dc1a77b090b7 100644 --- a/src/content/docs/durable-objects/examples/websocket-server.mdx +++ b/src/content/docs/durable-objects/examples/websocket-server.mdx @@ -11,7 +11,7 @@ description: Build a WebSocket server using Durable Objects and Workers. --- -import { TabItem, Tabs, GlossaryTooltip } from "~/components" +import { TabItem, Tabs, GlossaryTooltip, WranglerConfig } from "~/components" This example shows how to build a WebSocket server using Durable Objects and Workers. The example exposes an endpoint to create a new WebSocket connection. This WebSocket connection echos any message while including the total number of WebSocket connections currently established. For more information, refer to [Use Durable Objects with WebSockets](/durable-objects/best-practices/websockets/). @@ -187,9 +187,7 @@ export class WebSocketServer extends DurableObject { -Finally, configure your `wrangler.toml` file to include a Durable Object [binding](/durable-objects/get-started/walkthrough/#5-configure-durable-object-bindings) and [migration](/durable-objects/reference/durable-objects-migrations/) based on the namespace and class name chosen previously. - -import { WranglerConfig } from "~/components"; +Finally, configure your Wrangler file to include a Durable Object [binding](/durable-objects/get-started/walkthrough/#5-configure-durable-object-bindings) and [migration](/durable-objects/reference/durable-objects-migrations/) based on the namespace and class name chosen previously. 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 03c2985921c92c5..1527e77108a4ee9 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 @@ -5,7 +5,7 @@ sidebar: order: 2 --- -import { Render, TabItem, Tabs, PackageManagers } from "~/components"; +import { Render, TabItem, Tabs, PackageManagers, WranglerConfig } from "~/components"; This guide will instruct you through: @@ -56,7 +56,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.toml`](/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.json`](/workers/wrangler/configuration/) configuration file. Move into your new directory: @@ -201,9 +201,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` will include a binding name (for this guide, use `MY_DURABLE_OBJECT`) and the class name (`MyDurableObject`). - -import { WranglerConfig } from "~/components"; +[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`). @@ -225,9 +223,9 @@ The `[[durable_objects.bindings]]` section contains the following fields: A migration is a mapping process from a class name to a runtime state. You perform a migration when creating a new Durable Object class, or when renaming, deleting or transferring an existing Durable Object class. -Migrations are performed through the `[[migrations]]` configurations key in your `wrangler.toml` file. +Migrations are performed through the `[[migrations]]` configurations key in your Wrangler file. -The Durable Object migration to create a new Durable Object class with SQLite storage backend will look like the following in your Worker's `wrangler.toml` file: +The Durable Object migration to create a new Durable Object class with SQLite storage backend will look like the following in your Worker's Wrangler file: diff --git a/src/content/docs/durable-objects/get-started/walkthrough.mdx b/src/content/docs/durable-objects/get-started/walkthrough.mdx index 25eb0723df1ac20..13c663579f5e56c 100644 --- a/src/content/docs/durable-objects/get-started/walkthrough.mdx +++ b/src/content/docs/durable-objects/get-started/walkthrough.mdx @@ -5,7 +5,7 @@ sidebar: order: 1 --- -import { Render, TabItem, Tabs, PackageManagers } from "~/components"; +import { Render, TabItem, Tabs, PackageManagers, WranglerConfig } from "~/components"; This guide will instruct you through: @@ -49,7 +49,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.toml`](/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.json`](/workers/wrangler/configuration/) configuration file. Move into your new directory: @@ -174,9 +174,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`](/workers/wrangler/configuration/#durable-objects) file. The binding is configured to use a particular Durable Object class. - -import { WranglerConfig } from "~/components"; +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. @@ -201,9 +199,9 @@ Refer to [Wrangler Configuration](/workers/wrangler/configuration/#durable-objec A migration is a mapping process from a class name to a runtime state. You perform a migration when creating a new Durable Object class, or when renaming, deleting or transferring an existing Durable Object class. -Migrations are performed through the `[[migrations]]` configurations key in your `wrangler.toml` file. +Migrations are performed through the `[[migrations]]` configurations key in your Wrangler file. -The Durable Object migration to create a new Durable Object class will look like the following in your Worker's `wrangler.toml` file: +The Durable Object migration to create a new Durable Object class will look like the following in your Worker's Wrangler file: @@ -227,7 +225,7 @@ New beta version of Durable Objects is available where each Durable Object has a A Durable Object class can only have a single storage type, which cannot be changed after the Durable Object class is created. -To configure SQL storage and API, replace `new_classes` with `new_sqlite_classes` in your Worker's `wrangler.toml` file: +To configure SQL storage and API, replace `new_classes` with `new_sqlite_classes` in your Worker's Wrangler file: diff --git a/src/content/docs/durable-objects/observability/troubleshooting.mdx b/src/content/docs/durable-objects/observability/troubleshooting.mdx index 78a126ce25b8d73..d10e6f180dd7d5f 100644 --- a/src/content/docs/durable-objects/observability/troubleshooting.mdx +++ b/src/content/docs/durable-objects/observability/troubleshooting.mdx @@ -17,11 +17,11 @@ The `wrangler dev` command opens a tunnel from your local development environmen ### No event handlers were registered. This script does nothing. -In your `wrangler.toml` file, make sure the `dir` and `main` entries point to the correct file containing your Worker code, and that the file extension is `.mjs` instead of `.js` if using ES modules syntax. +In your Wrangler file, make sure the `dir` and `main` entries point to the correct file containing your Worker code, and that the file extension is `.mjs` instead of `.js` if using ES modules syntax. ### 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 `wrangler.toml` 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.toml / wrangler.json` file before attempting to apply `--delete-class` again. ### Durable Object is overloaded. diff --git a/src/content/docs/durable-objects/reference/durable-objects-migrations.mdx b/src/content/docs/durable-objects/reference/durable-objects-migrations.mdx index 50909cb778c961e..e11c4e28abb2697 100644 --- a/src/content/docs/durable-objects/reference/durable-objects-migrations.mdx +++ b/src/content/docs/durable-objects/reference/durable-objects-migrations.mdx @@ -6,7 +6,7 @@ sidebar: --- -import { GlossaryTooltip } from "~/components"; +import { GlossaryTooltip, WranglerConfig } from "~/components"; A migration is a mapping process from a class name to a runtime state. @@ -41,7 +41,7 @@ The destination class (the class that stored Durable Objects are being transferr After a rename or transfer migration, requests to the destination Durable Object class will have access to the source Durable Object's stored data. -After a migration, any existing bindings to the original Durable Object class (for example, from other Workers) will automatically forward to the updated destination class. However, any Workers bound to the updated Durable Object class must update their Durable Object binding configuration in the `wrangler.toml` file for their next deployment. +After a migration, any existing bindings to the original Durable Object class (for example, from other Workers) will automatically forward to the updated destination class. However, any Workers bound to the updated Durable Object class must update their Durable Object binding configuration in the Wrangler file for their next deployment. ::: @@ -56,22 +56,20 @@ Running a delete migration will delete all Durable Objects associated with the d ::: -### Durable Object migrations in `wrangler.toml` +### Durable Object migrations in the Wrangler configuration file -Migrations are performed through the `[[migrations]]` configurations key in your `wrangler.toml` file. +Migrations are performed through the `[[migrations]]` configurations key in your Wrangler file. Migrations require a migration tag, which is defined by the `tag` property in each migration entry. Migration tags are treated like unique names and are used to determine which migrations have already been applied. Once a given Worker code has a migration tag set on it, all future Worker code deployments must include a migration tag. -The migration list is an ordered array of tables, specified as a top-level key in your `wrangler.toml` file. The migration list is inherited by all environments and cannot be overridden by a specific environment. +The migration list is an ordered array of tables, specified as a top-level key in your Wrangler file. The migration list is inherited by all environments and cannot be overridden by a specific environment. All migrations are applied at deployment. Each migration can only be applied once per [environment](/durable-objects/reference/environments/). To illustrate an example migrations workflow, the `DurableObjectExample` class can be initially defined with: -import { WranglerConfig } from "~/components"; - ```toml @@ -117,7 +115,7 @@ The new beta version of Durable Objects is available where each Durable Object h ::: -To allow a new Durable Object class to use a SQLite storage backend, use `new_sqlite_classes` on the migration in your Worker's `wrangler.toml` file: +To allow a new Durable Object class to use a SQLite storage backend, use `new_sqlite_classes` on the migration in your Worker's Wrangler file: diff --git a/src/content/docs/durable-objects/reference/environments.mdx b/src/content/docs/durable-objects/reference/environments.mdx index efbbefee13f4b64..95e05c25c346a37 100644 --- a/src/content/docs/durable-objects/reference/environments.mdx +++ b/src/content/docs/durable-objects/reference/environments.mdx @@ -6,14 +6,14 @@ sidebar: --- +import { WranglerConfig } from "~/components"; + [Wrangler](/workers/wrangler/install-and-update/) allows you to deploy the same Worker application with different configuration for each [environment](/workers/wrangler/environments/). If you are using Wrangler environments, you must specify any [Durable Object bindings](/workers/runtime-apis/bindings/) you wish to use on a per-environment basis. Durable Object bindings are not inherited. For example, you can define an environment named `staging` as below: -import { WranglerConfig } from "~/components"; - ```toml 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 6e8cccb0c72d8ca..bded7ea0797ab05 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 @@ -11,7 +11,7 @@ languages: - SQL --- -import { Render, PackageManagers, Details } from "~/components"; +import { Render, PackageManagers, Details, WranglerConfig } from "~/components"; In this tutorial, you will learn how to build a seat reservation app using Durable Objects. This app will allow users to book a seat for a flight. The app will be written in TypeScript and will use the new [SQLite storage backend in Durable Object](/durable-objects/best-practices/access-durable-objects-storage/#sqlite-storage-backend) to store the data. @@ -256,13 +256,11 @@ 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 `wrangler.toml` to configure `assets` to serve the `public` directory. - -import { WranglerConfig } from "~/components"; +4. Update the bindings in the `wrangler.toml / wrangler.json` file to configure `assets` to serve the `public` directory. -```toml title="wrangler.toml" +```toml [assets] directory = "public" ``` @@ -283,15 +281,13 @@ npm run dev ## 3. Create table for each flight -The application already has the binding for the Durable Objects class configured in `wrangler.toml`. If you update the name of the Durable Objects class in `src/index.ts`, make sure to also update the binding in `wrangler.toml`. - -1. Update the binding to use the SQLite storage in Durable Objects. In `wrangler.toml`, 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` should look like this: - +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. +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: -```toml {9} title="wrangler.toml" +```toml {9} [[durable_objects.bindings]] name = "FLIGHT" class_name = "Flight" 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 df307bbf3ae8480..76791896858b53d 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 @@ -6,12 +6,10 @@ sidebar: --- -import { Render } from "~/components" +import { Render, WranglerConfig } from "~/components" -import { WranglerConfig } from "~/components"; - ```toml diff --git a/src/content/docs/hyperdrive/configuration/connect-to-postgres.mdx b/src/content/docs/hyperdrive/configuration/connect-to-postgres.mdx index 24baf469101b757..33d68e9adee0dce 100644 --- a/src/content/docs/hyperdrive/configuration/connect-to-postgres.mdx +++ b/src/content/docs/hyperdrive/configuration/connect-to-postgres.mdx @@ -5,7 +5,7 @@ sidebar: order: 3 --- -import { TabItem, Tabs, Render } from "~/components"; +import { TabItem, Tabs, Render, WranglerConfig } from "~/components"; Hyperdrive supports PostgreSQL and PostgreSQL-compatible databases, [popular drivers](#supported-drivers) and Object Relational Mapper (ORM) libraries that use those drivers. @@ -26,9 +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` configuration file for your Workers project: - -import { WranglerConfig } from "~/components"; +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: @@ -110,7 +108,7 @@ Install the `node-postgres` driver: npm install pg ``` -**Ensure you have `compatibility_flags` and `compatibility_date` set in your `wrangler.toml` configuration file** as shown below: +**Ensure you have `compatibility_flags` and `compatibility_date` set in your `wrangler.toml / wrangler.json` file** as shown below: @@ -120,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 wrangler.toml as the value for 'binding', + // If you set another name in the `wrangler.toml / wrangler.json` 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 ad50bd38e7e49b5..7f566e156f8bcc5 100644 --- a/src/content/docs/hyperdrive/configuration/local-development.mdx +++ b/src/content/docs/hyperdrive/configuration/local-development.mdx @@ -5,6 +5,8 @@ sidebar: order: 6 --- +import { WranglerConfig } from "~/components"; + Hyperdrive can be used when developing and testing your Workers locally by connecting to any local database instance running on your machine directly. Local development uses [Wrangler](/workers/wrangler/install-and-update/), the command-line interface for Workers, to manage local development sessions and state. ## Configure local development @@ -19,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` or Pages configuration. This allows you to avoid committing potentially sensitive credentials to source control in your `wrangler.toml`, 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 `wrangler.toml`. +- **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. -If both the `WRANGLER_HYPERDRIVE_LOCAL_CONNECTION_STRING_` environmental variable and `localConnectionString` in `wrangler.toml` 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.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. For example, to use the environmental variable, export the environmental variable before running `wrangler dev`: @@ -33,9 +35,7 @@ export WRANGLER_HYPERDRIVE_LOCAL_CONNECTION_STRING_TEST_DB="postgres://user:pass npx wrangler dev ``` -To configure a `localConnectionString` in `wrangler.toml`, ensure your Hyperdrive bindings have a `localConnectionString` property set: - -import { WranglerConfig } from "~/components"; +To configure a `localConnectionString` in the `wrangler.toml / wrangler.json` file, 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 971ff24d1b5d522..0975fa258d06b5e 100644 --- a/src/content/docs/hyperdrive/configuration/rotate-credentials.mdx +++ b/src/content/docs/hyperdrive/configuration/rotate-credentials.mdx @@ -5,7 +5,7 @@ sidebar: order: 8 --- -import { TabItem, Tabs, Render } from "~/components"; +import { TabItem, Tabs, Render, WranglerConfig } from "~/components"; You can change the connection information and credentials of your Hyperdrive configuration in one of two ways: @@ -23,9 +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` configuration file for your Workers project: - -import { WranglerConfig } from "~/components"; +The command above will output the ID of your Hyperdrive. Set this ID in the `wrangler.toml / wrangler.json` file for your Workers project: diff --git a/src/content/docs/hyperdrive/get-started.mdx b/src/content/docs/hyperdrive/get-started.mdx index 720ab34eac42a0f..1a2287e1e9ee728 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.toml`](/workers/wrangler/configuration/) configuration file. `wrangler.toml` is how your `hyperdrive-tutorial` Worker will connect to Hyperdrive. +- A [`wrangler.json`](/workers/wrangler/configuration/) configuration file. `wrangler.json` is how your `hyperdrive-tutorial` Worker will connect to Hyperdrive. ### Enable Node.js compatibility @@ -100,7 +100,7 @@ cd hyperdrive-tutorial :::note -Support for the new `hyperdrive` commands in the wrangler CLI requires a wrangler version of `3.10.0` or later. You can use `npx wrangler@latest` to always ensure you are using the latest version of wrangler. +Support for the new `hyperdrive` commands in the wrangler CLI requires a wrangler version of `3.10.0` or later. You can use `npx wrangler@latest` to always ensure you are using the latest version of Wrangler. ::: @@ -182,7 +182,7 @@ Populate your `index.ts` file with the following code: import postgres from "postgres"; export interface Env { - // If you set another name in wrangler.toml as the value for 'binding', + // If you set another name in the Wrangler config file as the value for 'binding', // replace "HYPERDRIVE" with the variable name you defined. HYPERDRIVE: Hyperdrive; } diff --git a/src/content/docs/hyperdrive/tutorials/serverless-timeseries-api-with-timescale/index.mdx b/src/content/docs/hyperdrive/tutorials/serverless-timeseries-api-with-timescale/index.mdx index 523cb957f4a3acb..bd3d0c12ffc8eed 100644 --- a/src/content/docs/hyperdrive/tutorials/serverless-timeseries-api-with-timescale/index.mdx +++ b/src/content/docs/hyperdrive/tutorials/serverless-timeseries-api-with-timescale/index.mdx @@ -13,7 +13,7 @@ languages: - SQL --- -import { Render, PackageManagers } from "~/components"; +import { Render, PackageManagers, WranglerConfig } from "~/components"; In this tutorial, you will learn to build an API on Workers which will ingest and query time-series data stored in [Timescale](https://www.timescale.com/) (they make PostgreSQL faster in the cloud). @@ -140,9 +140,7 @@ Hyperdrive will attempt to connect to your database with the provided credential ::: -This command outputs your Hyperdrive ID. You can now bind your Hyperdrive configuration to your Worker in your `wrangler.toml` configuration by replacing the content with the following: - -import { WranglerConfig } from "~/components"; +This command outputs your Hyperdrive ID. You can now bind your Hyperdrive configuration to your Worker in your Wrangler configuration by replacing the content with the following: diff --git a/src/content/docs/kv/concepts/kv-bindings.mdx b/src/content/docs/kv/concepts/kv-bindings.mdx index 8ef9fac5ee09493..eb546834577699e 100644 --- a/src/content/docs/kv/concepts/kv-bindings.mdx +++ b/src/content/docs/kv/concepts/kv-bindings.mdx @@ -5,6 +5,8 @@ sidebar: order: 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/). @@ -21,9 +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.toml` file, add: - -import { WranglerConfig } from "~/components"; +In the following example, the binding is called `TODO`. In the `kv_namespaces` portion of your Wrangler file, add: @@ -58,7 +58,7 @@ export default { When you use Wrangler to develop locally with the `wrangler dev` command, Wrangler will default to using a local version of KV to avoid interfering with any of your live production data in KV. This means that reading keys that you have not written locally will return `null`. -To have `wrangler dev` connect to your Workers KV namespace running on Cloudflare's global network, call `wrangler dev --remote` instead. This will use the `preview_id` of the KV binding configuration in the `wrangler.toml` file. This is how a `wrangler.toml` file looks with the `preview_id` specified. +To have `wrangler dev` connect to your Workers KV namespace running on Cloudflare's global network, call `wrangler dev --remote` instead. This will use the `preview_id` of the KV binding configuration in the Wrangler file. This is how a Wrangler file looks with the `preview_id` specified. diff --git a/src/content/docs/kv/concepts/kv-namespaces.mdx b/src/content/docs/kv/concepts/kv-namespaces.mdx index 57d4a6c4fea6ba1..42939b6ba116e4d 100644 --- a/src/content/docs/kv/concepts/kv-namespaces.mdx +++ b/src/content/docs/kv/concepts/kv-namespaces.mdx @@ -5,7 +5,7 @@ sidebar: order: 7 --- -import { Type, MetaInfo } from "~/components"; +import { Type, MetaInfo, WranglerConfig } from "~/components"; A KV namespace is a key-value database replicated to Cloudflare’s global network. @@ -35,8 +35,6 @@ To bind KV namespaces to your Worker, assign an array of the below object to the Example: -import { WranglerConfig } from "~/components"; - ```toml title="wrangler.toml" diff --git a/src/content/docs/kv/examples/workers-kv-to-serve-assets.mdx b/src/content/docs/kv/examples/workers-kv-to-serve-assets.mdx index 7fa1702a33f3626..ba78758a47484f6 100644 --- a/src/content/docs/kv/examples/workers-kv-to-serve-assets.mdx +++ b/src/content/docs/kv/examples/workers-kv-to-serve-assets.mdx @@ -80,7 +80,7 @@ To create a KV store via Wrangler: id = "" ``` -2. In your `wrangler.toml` file, add the following with the values generated in the terminal: +2. In your Wrangler file, add the following with the values generated in the terminal: ```bash {3} title="wrangler.toml" [[kv_namespaces]] @@ -90,7 +90,7 @@ To create a KV store via Wrangler: The [KV binding](/kv/concepts/kv-bindings/) `assets` is how your Worker will interact with the [KV namespace](/kv/concepts/kv-namespaces/). This binding will be provided as a runtime variable within your Workers code by the Workers runtime. - We'll also create a preview KV namespace. It is recommended to create a separate KV namespace when developing locally to avoid making changes to the production namespace. When developing locally against remote resources, the Wrangler CLI will only use the namespace specified by `preview_id` in the KV namespace configuration of the `wrangler.toml` file. + We'll also create a preview KV namespace. It is recommended to create a separate KV namespace when developing locally to avoid making changes to the production namespace. When developing locally against remote resources, the Wrangler CLI will only use the namespace specified by `preview_id` in the KV namespace configuration of the Wrangler file. 3. In your terminal, run the following command: @@ -113,7 +113,7 @@ To create a KV store via Wrangler: preview_id = "" ``` -4. In your `wrangler.toml` file, add the additional preview_id below kv_namespaces with the values generated in the terminal: +4. In your Wrangler file, add the additional preview_id below kv_namespaces with the values generated in the terminal: ```bash {4} title="wrangler.toml" [[kv_namespaces]] @@ -141,7 +141,7 @@ npx wrangler kv key put index.html --path index.html --binding assets --preview npx wrangler kv key put index.html --path index.html --binding assets --preview ``` -This will create a KV pair with the filename as key and the file content as value, within the our production and preview namespaces specified by your binding in your `wrangler.toml` file. +This will create a KV pair with the filename as key and the file content as value, within the our production and preview namespaces specified by your binding in your Wrangler file. ## 4. Serve static assets from KV from your Worker application @@ -377,7 +377,7 @@ Run `wrangler deploy` to deploy your Workers project to Cloudflare with the bind npx wrangler deploy ``` -Wrangler will automatically set your KV binding to use the production KV namespace set in our `wrangler.toml` file with the KV namespace id. Throughout this example, we uploaded our assets to both the preview and the production KV namespaces. +Wrangler will automatically set your KV binding to use the production KV namespace set in our Wrangler file with the KV namespace id. Throughout this example, we uploaded our assets to both the preview and the production KV namespaces. We can now verify that our project is properly working by accessing our Workers default hostname and accessing `..dev/index.html` or `..dev/hello-world` to see our deployed Worker in action, generating responses from the values in our KV store. diff --git a/src/content/docs/kv/get-started.mdx b/src/content/docs/kv/get-started.mdx index 07864f5ec22060f..e3e22e1a1852fd4 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.toml** + - **wrangler.json** Your new `kv-tutorial` directory includes: - A `"Hello World"` [Worker](/workers/get-started/guide/#3-write-code) in `index.ts`. - - A [`wrangler.toml`](/workers/wrangler/configuration/) configuration file. `wrangler.toml` is how your `kv-tutorial` Worker accesses your kv database. + - A [`wrangler.json`](/workers/wrangler/configuration/) configuration file. `wrangler.json` is how your `kv-tutorial` Worker accesses your kv database. 2. Change into the directory you just created for your Worker project: @@ -119,7 +119,7 @@ To create a KV namespace via Wrangler: npx wrangler kv namespace create ``` - The `npx wrangler kv namespace create ` subcommand takes a new binding name as its argument. A KV namespace is created using a concatenation of your Worker’s name (from your `wrangler.toml` file) and the binding name you provide. A `BINDING_ID` is randomly generated for you. + The `npx wrangler kv namespace create ` subcommand takes a new binding name as its argument. A KV namespace is created using a concatenation of your Worker’s name (from your Wrangler file) and the binding name you provide. A `BINDING_ID` is randomly generated for you. For this tutorial, use the binding name `BINDING_NAME`. @@ -161,7 +161,7 @@ To bind your KV namespace to your Worker: -1. In your `wrangler.toml` file, add the following with the values generated in your terminal from [step 2](/kv/get-started/#2-create-a-kv-namespace): +1. In your Wrangler file, add the following with the values generated in your terminal from [step 2](/kv/get-started/#2-create-a-kv-namespace): @@ -182,7 +182,7 @@ To bind your KV namespace to your Worker: :::note[Bindings] -A binding is how your Worker interacts with external resources such as [KV namespaces](/kv/concepts/kv-namespaces/). A binding is a runtime variable that the Workers runtime provides to your code. You can declare a variable name in your `wrangler.toml` file that binds to these resources at runtime, and interact with them through this variable. Every binding's variable name and behavior is determined by you when deploying the Worker. +A binding is how your Worker interacts with external resources such as [KV namespaces](/kv/concepts/kv-namespaces/). A binding is a runtime variable that the Workers runtime provides to your code. You can declare a variable name in your Wrangler file that binds to these resources at runtime, and interact with them through this variable. Every binding's variable name and behavior is determined by you when deploying the Worker. Refer to [Environment](/kv/reference/environments/) for more information. @@ -315,7 +315,7 @@ You can view key-value pairs directly from the dashboard. When using [`wrangler dev`](/workers/wrangler/commands/#dev) to develop locally, Wrangler defaults to using a local version of KV to avoid interfering with any of your live production data in KV. This means that reading keys that you have not written locally returns null. -To have `wrangler dev` connect to your Workers KV namespace running on Cloudflare's global network, call `wrangler dev --remote` instead. This uses the `preview_id` of the KV binding configuration in the `wrangler.toml` file. Refer to the [KV binding docs](/kv/concepts/kv-bindings/#use-kv-bindings-when-developing-locally) for more information. +To have `wrangler dev` connect to your Workers KV namespace running on Cloudflare's global network, call `wrangler dev --remote` instead. This uses the `preview_id` of the KV binding configuration in the Wrangler file. Refer to the [KV binding docs](/kv/concepts/kv-bindings/#use-kv-bindings-when-developing-locally) for more information. ::: diff --git a/src/content/docs/kv/reference/environments.mdx b/src/content/docs/kv/reference/environments.mdx index 4b4f6d58e9e6264..8eef01fdb0e69ce 100644 --- a/src/content/docs/kv/reference/environments.mdx +++ b/src/content/docs/kv/reference/environments.mdx @@ -5,11 +5,11 @@ sidebar: order: 3 --- -KV namespaces can be used with [environments](/workers/wrangler/environments/). This is useful when you have code in your Worker that refers to a KV binding like `MY_KV`, and you want to have these bindings point to different KV namespaces (for example, one for staging and one for production). +import { WranglerConfig } from "~/components"; -The following code in the `wrangler.toml` file shows you how to have two environments that have two different KV namespaces but the same binding name: +KV namespaces can be used with [environments](/workers/wrangler/environments/). This is useful when you have code in your Worker that refers to a KV binding like `MY_KV`, and you want to have these bindings point to different KV namespaces (for example, one for staging and one for production). -import { WranglerConfig } from "~/components"; +The following code in the Wrangler file shows you how to have two environments that have two different KV namespaces but the same binding name: @@ -52,7 +52,7 @@ Most `kv` subcommands also allow you to specify an environment with the optional Specifying an environment with the optional `--env` flag allows you to publish Workers running the same code but with different KV namespaces. -For example, you could use separate staging and production KV namespaces for KV data in your `wrangler.toml` file: +For example, you could use separate staging and production KV namespaces for KV data in your Wrangler file: @@ -78,9 +78,9 @@ kv_namespaces = [ -With the `wrangler.toml` file above, you can specify `--env production` when you want to perform a KV action on the KV namespace `MY_KV` under `env.production`. +With the Wrangler file above, you can specify `--env production` when you want to perform a KV action on the KV namespace `MY_KV` under `env.production`. -For example, with the `wrangler.toml` file above, you can get a value out of a production KV instance with: +For example, with the Wrangler file above, you can get a value out of a production KV instance with: ```sh wrangler kv key get --binding "MY_KV" --env=production "" 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 64125e6c313051e..49ab962c55310ae 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`](/workers/wrangler/configuration/) file 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.toml / wrangler.json` 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 `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.toml / wrangler.json` file (for example, `wrangler.json` or `wrangler.toml`), 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 b179eb3177fcbce..f43daf62364bfe3 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.toml`: Your [Wrangler](/workers/wrangler/configuration/#sample-wrangler-configuration) configuration file. +1. `wrangler.json`: 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 f26026ac689fef0..49d97532ca141ab 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.toml` 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 `wrangler.toml`. +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. :::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 c140334ae10cd23..0cdf9866f6a49c3 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 @@ -3,7 +3,7 @@ pcx_content_type: how-to title: Remix --- -import { PagesBuildPreset, Render, PackageManagers } from "~/components"; +import { PagesBuildPreset, Render, PackageManagers, WranglerConfig } from "~/components"; [Remix](https://remix.run/) is a framework that is focused on fully utilizing the power of the web. Like Cloudflare Workers, it uses modern JavaScript APIs, and it places emphasis on web fundamentals such as meaningful HTTP status codes, caching and optimizing for both usability and performance. @@ -82,9 +82,9 @@ A [binding](/pages/functions/bindings/) allows your application to interact with Remix uses Wrangler's [`getPlatformProxy`](/workers/wrangler/api/#getplatformproxy) to simulate the Cloudflare environment locally. You configure `getPlatformProxy` in your project's `vite.config.ts` file via [`cloudflareDevProxyVitePlugin`](https://remix.run/docs/en/main/future/vite#cloudflare-proxy). -To bind resources in local development, you need to configure the bindings in the `wrangler.toml` file. Refer to [Bindings](/workers/wrangler/configuration/#bindings) to learn more. +To bind resources in local development, you need to configure the bindings in the Wrangler file. Refer to [Bindings](/workers/wrangler/configuration/#bindings) to learn more. -Once you have configured the bindings in the `wrangler.toml` file, the proxies are then available within `context.cloudflare` in your `loader` or `action` functions: +Once you have configured the bindings in the Wrangler file, the proxies are then available within `context.cloudflare` in your `loader` or `action` functions: ```typescript export const loader = ({ context }: LoaderFunctionArgs) => { @@ -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 `wrangler.toml`. +You may have noticed that `context.cloudflare.env` is not typed correctly when you add additional bindings in the `wrangler.toml / wrangler.json` file. 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. @@ -113,9 +113,7 @@ Once you have configured the bindings in the Cloudflare dashboard, the proxies a As an example, you will bind and query a D1 database in a Remix application. 1. Create a D1 database. Refer to the [D1 documentation](/d1/) to learn more. -2. Configure bindings for your D1 database in the `wrangler.toml` file: - -import { WranglerConfig } from "~/components"; +2. Configure bindings for your D1 database in the Wrangler file: 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 bf19694e41f4275..a87a9547ba4373c 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 @@ -102,15 +102,15 @@ export default defineNitroPlugin((nitroApp: NitroApp) => { }); ``` -In the code above, the `getPlatformProxy` helper function will automatically detect any bindings defined in your project's `wrangler.toml` 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 `wrangler.toml`. +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 `wrangler.toml` with the following command: +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: ```sh npm run cf-typegen ``` -This should be done any time you add new bindings to `wrangler.toml`. +This should be done any time you add new bindings to your Wrangler configuration. ### Setup bindings in deployed applications diff --git a/src/content/docs/pages/framework-guides/nextjs/ssr/advanced.mdx b/src/content/docs/pages/framework-guides/nextjs/ssr/advanced.mdx index 7de369abf105bc5..c43dced68f8795e 100644 --- a/src/content/docs/pages/framework-guides/nextjs/ssr/advanced.mdx +++ b/src/content/docs/pages/framework-guides/nextjs/ssr/advanced.mdx @@ -32,7 +32,7 @@ export default { } as ExportedHandler<{ ASSETS: Fetcher }>; ``` -This looks like a Worker — but it does not need its own `wrangler.toml` file. You can think of it purely as code that `@cloudflare/next-on-pages` will then use to wrap the output of the build that is deployed to your Cloudflare Pages project. +This looks like a Worker — but it does not need its own Wrangler file. You can think of it purely as code that `@cloudflare/next-on-pages` will then use to wrap the output of the build that is deployed to your Cloudflare Pages project. 2. Pass the entrypoint argument to the next-on-pages CLI with the path to your handler. 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 3d5e9372f782a5d..79ecc4ac1f77c7c 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` configuration file](/pages/functions/wrangler-configuration/). +Add bindings to your Pages project by [adding them to your `wrangler.toml / wrangler.json` 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 f1c76217a886f43..87d20e861dce355 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 @@ -9,7 +9,7 @@ head: description: Deploy a full-stack Next.js app to Cloudflare Pages --- -import { PackageManagers } from "~/components"; +import { PackageManagers, WranglerConfig } from "~/components"; Learn how to deploy full-stack (SSR) Next.js apps to Cloudflare Pages. @@ -43,11 +43,9 @@ First, install [@cloudflare/next-on-pages](https://github.com/cloudflare/next-on npm install --save-dev @cloudflare/next-on-pages ``` -### 2. Add `wrangler.toml` file +### 2. Add Wrangler file -Then, add a [`wrangler.toml`](/pages/functions/wrangler-configuration/) file to the root directory of your Next.js app: - -import { WranglerConfig } from "~/components"; +Then, add a [`wrangler.toml / wrangler.json` 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 df5f95d32f74206..976cc4dcc29fe51 100644 --- a/src/content/docs/pages/functions/bindings.mdx +++ b/src/content/docs/pages/functions/bindings.mdx @@ -5,7 +5,7 @@ sidebar: order: 7 --- -import { Render, TabItem, Tabs } from "~/components"; +import { Render, TabItem, Tabs, WranglerConfig } from "~/components"; A [binding](/workers/runtime-apis/bindings/) enables your Pages Functions to interact with resources on the Cloudflare developer platform. Use bindings to integrate your Pages Functions with Cloudflare resources like [KV](/kv/concepts/how-kv-works/), [Durable Objects](/durable-objects/), [R2](/r2/), and [D1](/d1/). You can set bindings for both production and preview environments. @@ -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 [`wrangler.toml`](/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.toml / wrangler.json` file](/pages/functions/wrangler-configuration/#kv-namespaces) or the Cloudflare dashboard. To configure a KV namespace binding via the Cloudflare dashboard: @@ -63,7 +63,7 @@ export const onRequest: PagesFunction = async (context) => { You can interact with your KV namespace bindings locally in one of two ways: -- Configure your Pages project's `wrangler.toml` file and run [`npx wrangler pages dev`](/workers/wrangler/commands/#dev-1). +- Configure your Pages project's Wrangler file and run [`npx wrangler pages dev`](/workers/wrangler/commands/#dev-1). - Pass arguments to `wrangler pages dev` directly. To interact with your KV namespace binding locally by passing arguments to the Wrangler CLI, add `-k ` or `--kv=` to the `wrangler pages dev` command. For example, if your KV namespace is bound your Function via the `TODO_LIST` binding, access the KV namespace in local development by running: @@ -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 [`wrangler.toml`](/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.toml / wrangler.json` file](/pages/functions/wrangler-configuration/#kv-namespaces) or the Cloudflare dashboard. To configure a Durable Object binding via the Cloudflare dashboard: @@ -128,7 +128,7 @@ export const onRequestGet: PagesFunction = async (context) => { You can interact with your Durable Object bindings locally in one of two ways: -- Configure your Pages project's `wrangler.toml` file and run [`npx wrangler pages dev`](/workers/wrangler/commands/#dev-1). +- Configure your Pages project's Wrangler file and run [`npx wrangler pages dev`](/workers/wrangler/commands/#dev-1). - Pass arguments to `wrangler pages dev` directly. While developing locally, to interact with a Durable Object namespace, run `wrangler dev` in the directory of the Worker exporting the Durable Object. In another terminal, run `wrangler pages dev` in the directory of your Pages project. @@ -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 [`wrangler.toml`](/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.toml / wrangler.json` file](/pages/functions/wrangler-configuration/#r2-buckets) or the Cloudflare dashboard. To configure a R2 bucket binding via the Cloudflare dashboard: @@ -191,7 +191,7 @@ export const onRequest: PagesFunction = async (context) => { You can interact with your R2 bucket bindings locally in one of two ways: -- Configure your Pages project's `wrangler.toml` file and run [`npx wrangler pages dev`](/workers/wrangler/commands/#dev-1). +- Configure your Pages project's Wrangler file and run [`npx wrangler pages dev`](/workers/wrangler/commands/#dev-1). - Pass arguments to `wrangler pages dev` directly. :::note @@ -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 [`wrangler.toml`](/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.toml / wrangler.json` file](/pages/functions/wrangler-configuration/#d1-databases) or the Cloudflare dashboard. To configure a D1 database binding via the Cloudflare dashboard: @@ -262,12 +262,12 @@ export const onRequest: PagesFunction = async (context) => { You can interact with your D1 database bindings locally in one of two ways: -- Configure your Pages project's `wrangler.toml` file and run [`npx wrangler pages dev`](/workers/wrangler/commands/#dev-1). +- Configure your Pages project's Wrangler file and run [`npx wrangler pages dev`](/workers/wrangler/commands/#dev-1). - Pass arguments to `wrangler pages dev` directly. To interact with a D1 database via the Wrangler CLI while [developing locally](/d1/best-practices/local-development/#develop-locally-with-pages), add `--d1 =` to the `wrangler pages dev` command. -If your D1 database is bound to your Pages Function via the `NORTHWIND_DB` binding and the `database_id` in your `wrangler.toml` file is `xxxx-xxxx-xxxx-xxxx-xxxx`, access this database in local development by running: +If your D1 database is bound to your Pages Function via the `NORTHWIND_DB` binding and the `database_id` in your Wrangler file is `xxxx-xxxx-xxxx-xxxx-xxxx`, access this database in local development by running: ```sh npx wrangler pages dev --d1 NORTHWIND_DB=xxxx-xxxx-xxxx-xxxx-xxxx @@ -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 [`wrangler.toml`](/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.toml / wrangler.json` 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 [`wrangler.toml`](/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.toml / wrangler.json` 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. @@ -485,7 +485,7 @@ export const onRequest: PagesFunction = async (context) => { You can interact with your Workers AI bindings locally in one of two ways: -- Configure your Pages project's `wrangler.toml` file and run [`npx wrangler pages dev`](/workers/wrangler/commands/#dev-1). +- Configure your Pages project's Wrangler file and run [`npx wrangler pages dev`](/workers/wrangler/commands/#dev-1). - Pass arguments to `wrangler pages dev` directly. To interact with a Workers AI binding via the Wrangler CLI while developing locally, run: @@ -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 [`wrangler.toml`](/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.toml / wrangler.json` file](/pages/functions/wrangler-configuration/#service-bindings) or the Cloudflare dashboard. To configure a Service binding via the Cloudflare dashboard: @@ -540,7 +540,7 @@ export const onRequest: PagesFunction = async (context) => { You can interact with your Service bindings locally in one of two ways: -- Configure your Pages project's `wrangler.toml` file and run [`npx wrangler pages dev`](/workers/wrangler/commands/#dev-1). +- Configure your Pages project's Wrangler file and run [`npx wrangler pages dev`](/workers/wrangler/commands/#dev-1). - Pass arguments to `wrangler pages dev` directly. To interact with a [Service binding](/workers/runtime-apis/bindings/service-bindings/) while developing locally, run the Worker you want to bind to via `wrangler dev` and in parallel, run `wrangler pages dev` with `--service =` where `SCRIPT_NAME` indicates the name of the Worker. For example, if your Worker is called `my-worker`, connect with this Worker by running it via `npx wrangler dev` (in the Worker's directory) alongside `npx wrangler pages dev --service MY_SERVICE=my-worker` (in the Pages' directory). Interact with this binding by using `context.env` (for example, `context.env.MY_SERVICE`). @@ -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 [`wrangler.toml`](/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.toml / wrangler.json` file](/pages/functions/wrangler-configuration/#queues-producers) or the Cloudflare dashboard: To configure a queue producer binding via the Cloudflare dashboard: @@ -613,8 +613,6 @@ If using a queue producer binding with a Pages Function, you will be able to sen PostgreSQL drivers like [`Postgres.js`](https://github.com/porsager/postgres) depend on Node.js APIs. Pages Functions with Hyperdrive bindings must be [deployed with Node.js compatibility](/workers/runtime-apis/nodejs). -import { WranglerConfig } from "~/components"; - ```toml title="wrangler.toml" @@ -628,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 [`wrangler.toml`](/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.toml / wrangler.json` 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. @@ -693,13 +691,13 @@ export const onRequest: PagesFunction = async (context) => { ### Interact with your Hyperdrive binding locally -To interact with your Hyperdrive binding locally, you must provide a local connection string to your database that your Pages project will connect to directly. You can set an environment variable `WRANGLER_HYPERDRIVE_LOCAL_CONNECTION_STRING_` with the connection string of the database, or use the `wrangler.toml` file to configure your Hyperdrive binding with a `localConnectionString` as specified in [Hyperdrive documentation for local development](/hyperdrive/configuration/local-development/). Then, run [`npx wrangler pages dev `](/workers/wrangler/commands/#dev-1). +To interact with your Hyperdrive binding locally, you must provide a local connection string to your database that your Pages project will connect to directly. You can set an environment variable `WRANGLER_HYPERDRIVE_LOCAL_CONNECTION_STRING_` with the connection string of the database, or use the Wrangler file to configure your Hyperdrive binding with a `localConnectionString` as specified in [Hyperdrive documentation for local development](/hyperdrive/configuration/local-development/). Then, run [`npx wrangler pages dev `](/workers/wrangler/commands/#dev-1). ## Analytics Engine 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 [`wrangler.toml`](/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.toml / wrangler.json` file](/pages/functions/wrangler-configuration/#analytics-engine-datasets) or the Cloudflare dashboard: To configure an Analytics Engine binding via the Cloudflare dashboard: @@ -759,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 [`wrangler.toml`](/pages/functions/wrangler-configuration/#environment-variables) or the Cloudflare dashboard. +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 configure an environment variable via the Cloudflare dashboard: @@ -805,7 +803,7 @@ export const onRequest: PagesFunction = async (context) => { You can interact with your environment variables locally in one of two ways: -- Configure your Pages project's `wrangler.toml` file and running `npx wrangler pages dev`. +- Configure your Pages project's Wrangler file and running `npx wrangler pages dev`. - Pass arguments to [`wrangler pages dev`](/workers/wrangler/commands/#dev-1) directly. To interact with your environment variables locally via the Wrangler CLI, add `--binding==` to the `wrangler pages dev` command: diff --git a/src/content/docs/pages/functions/local-development.mdx b/src/content/docs/pages/functions/local-development.mdx index 87b149c7a25aafd..8c430386201310c 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`](/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.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. ::: ### HTTPS support -To serve your local development server over HTTPS with a self-signed certificate, you can [set `local_protocol` via `wrangler.toml`](/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.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): ```sh npx wrangler pages dev --local-protocol=https @@ -41,6 +41,6 @@ npx wrangler pages dev --local-protocol=https To attach a binding to local development, refer to [Bindings](/pages/functions/bindings/) and find the Cloudflare Developer Platform resource you would like to work with. -## Additional configuration via `wrangler.toml` +## Additional Wrangler configuration -If you are using a `wrangler.toml` configuration file in your project, you can set up dev server values like: `port`, `local protocol`, `ip`, and `port`. For more information, read about [configuring local development settings](/pages/functions/wrangler-configuration/#local-development-settings). +If you are using a Wrangler configuration file in your project, you can set up dev server values like: `port`, `local protocol`, `ip`, and `port`. For more information, read about [configuring local development settings](/pages/functions/wrangler-configuration/#local-development-settings). diff --git a/src/content/docs/pages/functions/source-maps.mdx b/src/content/docs/pages/functions/source-maps.mdx index e88463b8466777f..1878e223f979ab9 100644 --- a/src/content/docs/pages/functions/source-maps.mdx +++ b/src/content/docs/pages/functions/source-maps.mdx @@ -9,7 +9,7 @@ sidebar: --- -import { Render } from "~/components" +import { Render, WranglerConfig } from "~/components" @@ -23,9 +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`](/pages/functions/wrangler-configuration/) file if you are using the Pages build environment: - -import { WranglerConfig } from "~/components"; +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: diff --git a/src/content/docs/pages/functions/wrangler-configuration.mdx b/src/content/docs/pages/functions/wrangler-configuration.mdx index ed66149b387e69e..460b0cd99dcc033 100644 --- a/src/content/docs/pages/functions/wrangler-configuration.mdx +++ b/src/content/docs/pages/functions/wrangler-configuration.mdx @@ -5,36 +5,34 @@ sidebar: order: 6 --- -import { Render, TabItem, Tabs, Type, MetaInfo } from "~/components"; +import { Render, TabItem, Tabs, Type, MetaInfo, WranglerConfig } from "~/components"; :::caution -If your project contains an existing `wrangler.toml` 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 `wrangler.toml`. Instead of writing your `wrangler.toml` file by hand, Cloudflare recommends using `npx wrangler pages download config` to download your current project settings into a `wrangler.toml` 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.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. ::: -Pages Functions can be configured two ways, either via the [Cloudflare dashboard](https://dash.cloudflare.com) or `wrangler.toml`, a configuration file used to customize the development and deployment setup for [Workers](/workers/) and Pages Functions. +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. -This page serves as a reference on how to configure your Pages project via `wrangler.toml`. +This page serves as a reference on how to configure your Pages project via the `wrangler.toml / wrangler.json` file. -If using `wrangler.toml`, you must treat your `wrangler.toml` as the [source of truth](/pages/functions/wrangler-configuration/#source-of-truth) for your Pages project configuration. +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 `wrangler.toml` is in open beta.] +:::note[Configuration via the `wrangler.toml / wrangler.json` file is in open beta.] Cloudflare welcomes your feedback. Join the #functions channel in the [Cloudflare Developers Discord](https://discord.com/invite/cloudflaredev) to report bugs and request features. ::: -Using `wrangler.toml` to configure your Pages project allows you to: +Using the `wrangler.toml / wrangler.json` 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. - **Write configuration that is shared across environments:** Define configuration like [bindings](/pages/functions/bindings/) for local development, preview and production in one file. - **Ensure better access control:** By using a configuration file in your project repository, you can control who has access to make changes without giving access to your Cloudflare dashboard. -## Example `wrangler.toml` file - -import { WranglerConfig } from "~/components"; +## Example Wrangler file @@ -61,23 +59,21 @@ API_KEY = "1234567asdf" ### V2 build system -Pages Functions configuration via `wrangler.toml` 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.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). ### Wrangler -You must have Wrangler version 3.45.0 or higher to use `wrangler.toml` 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.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/). ## Migrate from dashboard configuration -The migration instructions for Pages projects that do not have a `wrangler.toml` file currently are different than those for Pages projects with an existing `wrangler.toml` file. Read the instructions based on your situation carefully to avoid errors in production. - -### Projects with existing `wrangler.toml` file - -Before you could use `wrangler.toml` to define your preview and production configuration, it was possible to use `wrangler.toml` to define which [bindings](/pages/functions/bindings/) should be available to your Pages project in local development. +The migration instructions for Pages projects that do not have a Wrangler file currently are different than those for Pages projects with an existing Wrangler file. Read the instructions based on your situation carefully to avoid errors in production. -If you have been using `wrangler.toml` for local development, you may already have a file in your Pages project that looks like this: +### 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. +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: @@ -89,24 +85,24 @@ id = "" -If you would like to use your existing `wrangler.toml` file for your Pages project configuration, you must: +If you would like to use your existing Wrangler file for your Pages project configuration, you must: 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.toml` configuration carefully to make sure it aligns with your desired project configuration before deploying. +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 `wrangler.toml` 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` is ready for production use. +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. :::caution[Overwriting configuration] -Running [`wrangler pages download config`](/pages/functions/wrangler-configuration/#projects-without-existing-wranglertoml-file) will overwrite your existing `wrangler.toml` file with a generated `wrangler.toml` file based on your Cloudflare dashboard configuration. Run this command only if you want to discard your previous `wrangler.toml` file that you used for local development and start over with configuration pulled from the Cloudflare dashboard. +Running [`wrangler pages download config`](/pages/functions/wrangler-configuration/#projects-without-existing-wranglertoml-file) will overwrite your existing Wrangler file with a generated Wrangler file based on your Cloudflare dashboard configuration. Run this command only if you want to discard your previous Wrangler file that you used for local development and start over with configuration pulled from the Cloudflare dashboard. ::: -You can continue to use your `wrangler.toml` file for local development without migrating it for production use by not adding a `pages_build_output_dir` key. If you do not add a `pages_build_output_dir` key and run `wrangler pages deploy`, you will see a warning message telling you that fields are missing and that the file will continue to be used for local development only. +You can continue to use your Wrangler file for local development without migrating it for production use by not adding a `pages_build_output_dir` key. If you do not add a `pages_build_output_dir` key and run `wrangler pages deploy`, you will see a warning message telling you that fields are missing and that the file will continue to be used for local development only. -### Projects without existing `wrangler.toml` file +### Projects without existing Wrangler file -If you have an existing Pages project with configuration set up via the Cloudflare dashboard and do not have an existing `wrangler.toml` file in your Project, run the `wrangler pages download config` command in your Pages project directory. The `wrangler pages download config` command will download your existing Cloudflare dashboard configuration and generate a valid `wrangler.toml` file in your Pages project directory. +If you have an existing Pages project with configuration set up via the Cloudflare dashboard and do not have an existing Wrangler file in your Project, run the `wrangler pages download config` command in your Pages project directory. The `wrangler pages download config` command will download your existing Cloudflare dashboard configuration and generate a valid Wrangler file in your Pages project directory. @@ -128,32 +124,32 @@ pnpm wrangler pages download config -Review your generated `wrangler.toml` file. To start using `wrangler.toml` 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.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/). ### 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` from a project configured with "Latest" using the `wrangler pages download` command, your `wrangler.toml` 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 `wrangler.toml`. +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. Refer to [this guide](/workers/configuration/compatibility-dates/) for more information on what compatibility dates are and how they work. -## Differences using `wrangler.toml` for Pages Functions and Workers +## Differences using a Wrangler configuration file for Pages Functions and Workers -If you have used [Workers](/workers), you may already be familiar with [`wrangler.toml`](/workers/wrangler/configuration/). There are a few key differences to be aware of when using `wrangler.toml` with your Pages Functions project: +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: -- The configuration fields **do not match exactly** between Pages Functions `wrangler.toml` 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`. 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` 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.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 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 `wrangler.toml` you can quickly set configuration across your local environment, preview deployments, and production. +With a `wrangler.toml / wrangler.json` file, you can quickly set configuration across your local environment, preview deployments, and production. ### Local development -`wrangler.toml` 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: +`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: @@ -172,7 +168,7 @@ id = "" -This `wrangler.toml` 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.toml` configuration 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.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`. :::note @@ -182,7 +178,7 @@ For a full list of configuration keys, refer to [inheritable keys](#inheritable- ### Production and preview deployments -Once you are ready to deploy your project, you can set the configuration for production and preview deployments by creating a new deployment containing a `wrangler.toml` file. +Once you are ready to deploy your project, you can set the configuration for production and preview deployments by creating a new deployment containing a Wrangler file. :::note @@ -220,7 +216,7 @@ Unlike [Workers Environments](/workers/wrangler/configuration/#environments), `p ::: -Refer to the following `wrangler.toml` configuration file for an example of how to override preview deployment configuration: +Refer to the following `wrangler.toml / wrangler.json` file for an example of how to override preview deployment configuration: @@ -439,20 +435,18 @@ When using Wrangler in the default local development mode, files will be written ::: -- Configure D1 database bindings via your [`wrangler.toml` file](/workers/wrangler/configuration/#d1-databases) the same way they are configured with Cloudflare Workers. +- Configure D1 database bindings via your [Wrangler file](/workers/wrangler/configuration/#d1-databases) the same way they are configured with Cloudflare Workers. - Interact with your [D1 Database binding](/pages/functions/bindings/#d1-databases). ### Durable Objects [Durable Objects](/durable-objects/) provide low-latency coordination and consistent storage for the Workers platform. -- Configure Durable Object namespace bindings via your [`wrangler.toml` file](/workers/wrangler/configuration/#durable-objects) the same way they are configured with Cloudflare Workers. +- Configure Durable Object namespace bindings via your [Wrangler file](/workers/wrangler/configuration/#durable-objects) the same way they are configured with Cloudflare Workers. :::caution - Durable Object bindings configured in -a Pages project's `wrangler.toml` require the `script_name` key. For Workers, -the `script_name` key is optional. + 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. ::: @@ -462,14 +456,14 @@ the `script_name` key is optional. [Environment variables](/workers/configuration/environment-variables/) are a type of binding that allow you to attach text strings or JSON values to your Pages Function. -- Configure environment variables via your [`wrangler.toml` file](/workers/wrangler/configuration/#environment-variables) the same way they are configured with Cloudflare Workers. +- Configure environment variables via your [Wrangler file](/workers/wrangler/configuration/#environment-variables) the same way they are configured with Cloudflare Workers. - Interact with your [environment variables](/pages/functions/bindings/#environment-variables). ### Hyperdrive [Hyperdrive](/hyperdrive/) bindings allow you to interact with and query any Postgres database from within a Pages Function. -- Configure Hyperdrive bindings via your [`wrangler.toml` file](/workers/wrangler/configuration/#hyperdrive) the same way they are configured with Cloudflare Workers. +- Configure Hyperdrive bindings via your [Wrangler file](/workers/wrangler/configuration/#hyperdrive) the same way they are configured with Cloudflare Workers. ### KV namespaces @@ -481,7 +475,7 @@ When using Wrangler in the default local development mode, files will be written ::: -- Configure KV namespace bindings via your [`wrangler.toml` file](/workers/wrangler/configuration/#kv-namespaces) the same way they are configured with Cloudflare Workers. +- Configure KV namespace bindings via your [Wrangler file](/workers/wrangler/configuration/#kv-namespaces) the same way they are configured with Cloudflare Workers. - Interact with your [KV namespace binding](/pages/functions/bindings/#kv-namespaces). ### Queues Producers @@ -494,7 +488,7 @@ You cannot currently configure a [queues consumer](/queues/reference/how-queues- ::: -- Configure Queues Producer bindings via your [`wrangler.toml` file](/workers/wrangler/configuration/#queues) the same way they are configured with Cloudflare Workers. +- Configure Queues Producer bindings via your [Wrangler file](/workers/wrangler/configuration/#queues) the same way they are configured with Cloudflare Workers. - Interact with your [Queues Producer binding](/pages/functions/bindings/#queue-producers). ### R2 buckets @@ -507,27 +501,27 @@ When using Wrangler in the default local development mode, files will be written ::: -- Configure R2 bucket bindings via your [`wrangler.toml` file](/workers/wrangler/configuration/#r2-buckets) the same way they are configured with Cloudflare Workers. +- Configure R2 bucket bindings via your [Wrangler file](/workers/wrangler/configuration/#r2-buckets) the same way they are configured with Cloudflare Workers. - Interact with your [R2 bucket bindings](/pages/functions/bindings/#r2-buckets). ### Vectorize indexes A [Vectorize index](/vectorize/) allows you to insert and query vector embeddings for semantic search, classification and other vector search use-cases. -- Configure Vectorize bindings via your [`wrangler.toml` file](/workers/wrangler/configuration/#vectorize-indexes) the same way they are configured with Cloudflare Workers. +- Configure Vectorize bindings via your [Wrangler file](/workers/wrangler/configuration/#vectorize-indexes) the same way they are configured with Cloudflare Workers. ### Service bindings A service binding allows you to call a Worker from within your Pages Function. Binding a Pages Function to a Worker allows you to send HTTP requests to the Worker without those requests going over the Internet. The request immediately invokes the downstream Worker, reducing latency as compared to a request to a third-party service. Refer to [About Service bindings](/workers/runtime-apis/bindings/service-bindings/). -- Configure service bindings via your [`wrangler.toml` file](/workers/wrangler/configuration/#service-bindings) the same way they are configured with Cloudflare Workers. +- Configure service bindings via your [Wrangler file](/workers/wrangler/configuration/#service-bindings) the same way they are configured with Cloudflare Workers. - Interact with your [service bindings](/pages/functions/bindings/#service-bindings). ### Analytics Engine Datasets [Workers Analytics Engine](/analytics/analytics-engine/) provides analytics, observability and data logging from Pages Functions. Write data points within your Pages Function binding then query the data using the [SQL API](/analytics/analytics-engine/sql-api/). -- Configure Analytics Engine Dataset bindings via your [`wrangler.toml` file](/workers/wrangler/configuration/#analytics-engine-datasets) the same way they are configured with Cloudflare Workers. +- Configure Analytics Engine Dataset bindings via your [Wrangler file](/workers/wrangler/configuration/#analytics-engine-datasets) the same way they are configured with Cloudflare Workers. - Interact with your [Analytics Engine Dataset](/pages/functions/bindings/#analytics-engine). ### Workers AI @@ -538,7 +532,7 @@ A service binding allows you to call a Worker from within your Pages Function. B Unlike other bindings, this binding is limited to one AI binding per Pages Function project. -- Configure Workers AI bindings via your [`wrangler.toml` file](/workers/wrangler/configuration/#workers-ai) the same way they are configured with Cloudflare Workers. +- Configure Workers AI bindings via your [Wrangler file](/workers/wrangler/configuration/#workers-ai) the same way they are configured with Cloudflare Workers. - Interact with your [Workers AI binding](/pages/functions/bindings/#workers-ai). ## Local development settings @@ -547,6 +541,6 @@ The local development settings that you can configure are the same for Pages Fun ## Source of truth -When used in your Pages Functions projects, your `wrangler.toml` 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. +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 don't want to use `wrangler.toml` 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.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. diff --git a/src/content/docs/pages/get-started/c3.mdx b/src/content/docs/pages/get-started/c3.mdx index 6246b1b2c48e8d8..af13984fcbe37cc 100644 --- a/src/content/docs/pages/get-started/c3.mdx +++ b/src/content/docs/pages/get-started/c3.mdx @@ -170,8 +170,8 @@ bun create cloudflare@latest [--] [] [OPTIONS] [-- ] At a minimum, templates must contain the following: - `package.json` - - `wrangler.toml` - - `src/` containing a worker script referenced from `wrangler.toml` + - `wrangler.json` + - `src/` containing a worker script referenced from `wrangler.json` 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 d696423ccb2f048..a5e50cfe196fce4 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 @@ -3,6 +3,8 @@ pcx_content_type: how-to title: Add custom HTTP headers --- +import { WranglerConfig } from "~/components"; + :::note Cloudflare provides HTTP header customization for Pages projects by adding a `_headers` file to your project. Refer to the [documentation](/pages/configuration/headers/) for more information. @@ -64,9 +66,7 @@ cd custom-headers-example npm install ``` -To operate your Workers function alongside your Pages application, deploy it to the same custom domain as your Pages application. To do this, update the `wrangler.toml` file in your project with your account and zone details: - -import { WranglerConfig } from "~/components"; +To operate your Workers function alongside your Pages application, deploy it to the same custom domain as your Pages application. To do this, update the Wrangler file in your project with your account and zone details: @@ -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`, run `npx wrangler deploy` in your terminal to deploy your Worker: +Once you have configured your `wrangler.toml / wrangler.json` file, 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 64cded1f056b5a0..ef891f3d21e1fcb 100644 --- a/src/content/docs/pages/migrations/migrating-from-workers/index.mdx +++ b/src/content/docs/pages/migrations/migrating-from-workers/index.mdx @@ -17,7 +17,7 @@ You may already have a reasonably complex Worker and/or it would be tedious to s :::note -When using a `_worker.js` file, the entire `/functions` directory is ignored – this includes its routing and middleware characteristics. Instead, the `_worker.js` file is deployed as is and must be written using the [Module Worker syntax](/workers/reference/migrate-to-module-workers/). +When using a `_worker.js` file, the entire `/functions` directory is ignored - this includes its routing and middleware characteristics. Instead, the `_worker.js` file is deployed as is and must be written using the [Module Worker syntax](/workers/reference/migrate-to-module-workers/). ::: @@ -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 `wrangler.toml`) 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.toml / wrangler.json` file) 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` 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.toml` file in your project's 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. ## Migrate headers and redirects diff --git a/src/content/docs/pages/tutorials/localize-a-website/index.mdx b/src/content/docs/pages/tutorials/localize-a-website/index.mdx index 2a7aad8fffcf359..ea94ce012754cf1 100644 --- a/src/content/docs/pages/tutorials/localize-a-website/index.mdx +++ b/src/content/docs/pages/tutorials/localize-a-website/index.mdx @@ -10,7 +10,7 @@ tags: - HTMLRewriter --- -import { Render, PackageManagers } from "~/components"; +import { Render, PackageManagers, WranglerConfig } from "~/components"; In this tutorial, you will build an example internationalization and localization engine (commonly referred to as **i18n** and **l10n**) for your application, serve the content of your site, and automatically translate the content based on your visitors’ location in the world. @@ -258,9 +258,7 @@ export async function onRequest(context) { Your i18n tool built on Cloudflare Pages is complete and it is time to deploy it to your domain. -To deploy your application to a `*.pages.dev` subdomain, you need to specify a directory of static assets to serve, configure the `pages_build_output_dir` in your project’s `wrangler.toml` file and set the value to `./public`: - -import { WranglerConfig } from "~/components"; +To deploy your application to a `*.pages.dev` subdomain, you need to specify a directory of static assets to serve, configure the `pages_build_output_dir` in your project’s Wrangler file and set the value to `./public`: 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 83353424c94221a..f016a6357a08c0b 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 @@ -12,6 +12,8 @@ languages: - JavaScript --- +import { WranglerConfig } from "~/components"; + This tutorial will teach you how to use [R2](/r2/) as a static asset storage bucket for your [Pages](/pages/) app. This is especially helpful if you're hitting the [file limit](/pages/platform/limits/#files) or the [max file size limit](/pages/platform/limits/#file-size) on Pages. To illustrate how this is done, we will use R2 as a static asset storage for a fictional cat blog. @@ -65,11 +67,9 @@ npx wrangler r2 object put / -f ## Bind R2 to Pages -To bind the R2 bucket we have created to the cat blog, we need to update `wrangler.toml`. +To bind the R2 bucket we have created to the cat blog, we need to update the Wrangler configuration. -Open `wrangler.toml`, 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: - -import { WranglerConfig } from "~/components"; +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: @@ -86,7 +86,7 @@ bucket_name = "cat-media" Note: The keyword `ASSETS` is reserved and cannot be used as a resource binding. ::: -Save `wrangler.toml` and we are ready to move on to the last step. +Save the `wrangler.toml / wrangler.json` file, 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 bd2399073fcc58c..3ba068f47cbcb01 100644 --- a/src/content/docs/pub-sub/learning/integrate-workers.mdx +++ b/src/content/docs/pub-sub/learning/integrate-workers.mdx @@ -5,6 +5,8 @@ sidebar: order: 2 --- +import { WranglerConfig } from "~/components"; + Once of the most powerful features of Pub/Sub is the ability to connect [Cloudflare Workers](/workers/) — powerful serverless functions that run on the edge — and filter, aggregate and mutate every message published to that broker. Workers can also mirror those messages to other sources, including writing to [Cloudflare R2 storage](/r2/), external databases, or other cloud services beyond Cloudflare, making it easy to persist or analyze incoming message payloads and data at scale. There are three ways to integrate a Worker with Pub/Sub: @@ -80,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` as an environmental variable: +Copy the array of public keys into your `wrangler.toml / wrangler.json` file as an environmental variable: :::note @@ -88,8 +90,6 @@ Your public keys will be unique to your own Pub/Sub Broker: you should ensure yo ::: -import { WranglerConfig } from "~/components"; - ```toml diff --git a/src/content/docs/queues/configuration/batching-retries.mdx b/src/content/docs/queues/configuration/batching-retries.mdx index 361cd9afcdce534..b09220c49f53009 100644 --- a/src/content/docs/queues/configuration/batching-retries.mdx +++ b/src/content/docs/queues/configuration/batching-retries.mdx @@ -5,6 +5,8 @@ sidebar: order: 2 --- +import { WranglerConfig } from "~/components"; + ## Batching When configuring a [consumer Worker](/queues/reference/how-queues-works#consumers) for a queue, you can also define how messages are batched as they are delivered. @@ -194,9 +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 [`wrangler.toml`](/workers/wrangler/configuration/#queues) with the `delivery_delay` setting for producers (when sending) and/or the `retry_delay` (when retrying) per-consumer: - -import { WranglerConfig } from "~/components"; +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: @@ -213,7 +213,7 @@ import { WranglerConfig } from "~/components"; -If you use both the `wrangler` CLI and `wrangler.toml` 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.toml / wrangler.json` file 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 6030d3d0654cfab..d34bc6c12272539 100644 --- a/src/content/docs/queues/configuration/configure-queues.mdx +++ b/src/content/docs/queues/configuration/configure-queues.mdx @@ -9,16 +9,18 @@ head: --- +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` configuration 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.toml` file. +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. Use the options below to configure your queue. :::note -Below are options for Queues, refer to the Wrangler documentation for a full reference of [`wrangler.toml`](/workers/wrangler/configuration/). +Below are options for Queues, refer to the Wrangler documentation for a full reference of the [`wrangler.toml / wrangler.json` file](/workers/wrangler/configuration/). ::: @@ -27,9 +29,7 @@ Below are options for Queues, refer to the Wrangler documentation for a full ref A producer is a [Cloudflare Worker](/workers/) that writes to one or more queues. A producer can accept messages over HTTP, asynchronously write messages when handling requests, and/or write to a queue from within a [Durable Object](/durable-objects/). Any Worker can write to a queue. -To produce to a queue, set up a binding in your `wrangler.toml` file. These options should be used when a Worker wants to send messages to a queue. - -import { WranglerConfig } from "~/components"; +To produce to a queue, set up a binding in your Wrangler file. These options should be used when a Worker wants to send messages to a queue. @@ -57,7 +57,7 @@ import { WranglerConfig } from "~/components"; ## Workers -To consume messages from one or more queues, set up a binding in your `wrangler.toml` file. These options should be used when a Worker wants to receive messages from a queue. +To consume messages from one or more queues, set up a binding in your Wrangler file. These options should be used when a Worker wants to receive messages from a queue. diff --git a/src/content/docs/queues/configuration/consumer-concurrency.mdx b/src/content/docs/queues/configuration/consumer-concurrency.mdx index e23d881d8ddfce1..add633b7286c562 100644 --- a/src/content/docs/queues/configuration/consumer-concurrency.mdx +++ b/src/content/docs/queues/configuration/consumer-concurrency.mdx @@ -5,6 +5,8 @@ sidebar: order: 5 --- +import { WranglerConfig } from "~/components"; + Consumer concurrency allows a [consumer Worker](/queues/reference/how-queues-works/#consumers) processing messages from a queue to automatically scale out horizontally to keep up with the rate that messages are being written to a queue. In many systems, the rate at which you write messages to a queue can easily exceed the rate at which a single consumer can read and process those same messages. This is often because your consumer might be parsing message contents, writing to storage or a database, or making third-party (upstream) API calls. @@ -58,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 `wrangler.toml` +2. Set concurrency settings via the `wrangler.toml / wrangler.json` file ### Set concurrency settings in the Cloudflare dashboard @@ -74,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 via `wrangler.toml` +### Set concurrency settings in the `wrangler.toml / wrangler.json` file :::note @@ -82,9 +84,7 @@ Ensure you are using the latest version of [wrangler](/workers/wrangler/install- ::: -To set a fixed maximum number of concurrent consumer invocations for a given queue, configure a `max_concurrency` in your `wrangler.toml` file: - -import { WranglerConfig } from "~/components"; +To set a fixed maximum number of concurrent consumer invocations for a given queue, configure a `max_concurrency` in your Wrangler file: diff --git a/src/content/docs/queues/configuration/dead-letter-queues.mdx b/src/content/docs/queues/configuration/dead-letter-queues.mdx index cdfe6d16253c847..847a079ed92c4f8 100644 --- a/src/content/docs/queues/configuration/dead-letter-queues.mdx +++ b/src/content/docs/queues/configuration/dead-letter-queues.mdx @@ -5,14 +5,14 @@ sidebar: order: 3 --- +import { WranglerConfig } from "~/components"; + A Dead Letter Queue (DLQ) is a common concept in a messaging system, and represents where messages are sent when a delivery failure occurs with a consumer after `max_retries` is reached. A Dead Letter Queue is like any other queue, and can be produced to and consumed from independently. With Cloudflare Queues, a Dead Letter Queue is defined within your [consumer configuration](/queues/configuration/configure-queues/). Messages are delivered to the DLQ when they reach the configured retry limit for the consumer. Without a DLQ configured, messages that reach the retry limit are deleted permanently. For example, the following consumer configuration would send messages to our DLQ named `"my-other-queue"` after retrying delivery (by default, 3 times): -import { WranglerConfig } from "~/components"; - ```toml diff --git a/src/content/docs/queues/configuration/pull-consumers.mdx b/src/content/docs/queues/configuration/pull-consumers.mdx index 6fce655387eed77..ca58cd2572b3e16 100644 --- a/src/content/docs/queues/configuration/pull-consumers.mdx +++ b/src/content/docs/queues/configuration/pull-consumers.mdx @@ -8,6 +8,8 @@ head: content: Cloudflare Queues - Pull consumers --- +import { WranglerConfig } from "~/components"; + A pull-based consumer allows you to pull from a queue over HTTP from any environment and/or programming language outside of Cloudflare Workers. A pull-based consumer can be useful when your message consumption rate is limited by upstream infrastructure or long-running tasks. ## How to choose between push or pull consumer @@ -34,13 +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 `wrangler.toml`, 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.toml / wrangler.json` file, the `wrangler` CLI, or via the [Cloudflare dashboard](https://dash.cloudflare.com/). -### wrangler.toml +### Wrangler configuration file -A HTTP consumer can be configured in `wrangler.toml` by setting `type = "http_pull"` in the consumer configuration: - -import { WranglerConfig } from "~/components"; +A HTTP consumer can be configured in the `wrangler.toml / wrangler.json` file 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`, 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 `wrangler.toml / wrangler.json` file, 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/examples/publish-to-a-queue-over-http.mdx b/src/content/docs/queues/examples/publish-to-a-queue-over-http.mdx index 7753c6f9c7225ce..e56b154f54ee1c7 100644 --- a/src/content/docs/queues/examples/publish-to-a-queue-over-http.mdx +++ b/src/content/docs/queues/examples/publish-to-a-queue-over-http.mdx @@ -10,6 +10,8 @@ head: description: Publish to a Queue directly via HTTP and Workers. --- +import { WranglerConfig } from "~/components"; + The following example shows you how to publish messages to a queue from any HTTP client, using a shared secret to securely authenticate the client. This allows you to write to a Queue from any service or programming language that support HTTP, including Go, Rust, Python or even a Bash script. @@ -17,11 +19,9 @@ This allows you to write to a Queue from any service or programming language tha ### Prerequisites - A [queue created](/queues/get-started/#3-create-a-queue) via the [Cloudflare dashboard](https://dash.cloudflare.com) or the [wrangler CLI](/workers/wrangler/install-and-update/). -- A [configured **producer** binding](/queues/configuration/configure-queues/#producer) in the Cloudflare dashboard or `wrangler.toml` file. +- A [configured **producer** binding](/queues/configuration/configure-queues/#producer) in the Cloudflare dashboard or Wrangler file. -Configure your `wrangler.toml` file as follows: - -import { WranglerConfig } from "~/components"; +Configure your Wrangler file as follows: diff --git a/src/content/docs/queues/examples/send-errors-to-r2.mdx b/src/content/docs/queues/examples/send-errors-to-r2.mdx index c8f3aa93d71cab8..c74a0f060358b79 100644 --- a/src/content/docs/queues/examples/send-errors-to-r2.mdx +++ b/src/content/docs/queues/examples/send-errors-to-r2.mdx @@ -11,10 +11,10 @@ description: Example of how to use Queues to batch data and store it in an R2 bu --- -The following Worker will catch JavaScript errors and send them to a queue. The same Worker will receive those errors in batches and store them to a log file in an R2 bucket. - import { WranglerConfig } from "~/components"; +The following Worker will catch JavaScript errors and send them to a queue. The same Worker will receive those errors in batches and store them to a log file in an R2 bucket. + ```toml diff --git a/src/content/docs/queues/examples/use-queues-with-durable-objects.mdx b/src/content/docs/queues/examples/use-queues-with-durable-objects.mdx index 79ccb57415ebfc4..b40279302a55b74 100644 --- a/src/content/docs/queues/examples/use-queues-with-durable-objects.mdx +++ b/src/content/docs/queues/examples/use-queues-with-durable-objects.mdx @@ -10,17 +10,17 @@ head: description: Publish to a queue from within a Durable Object. --- +import { WranglerConfig } from "~/components"; + The following example shows you how to write a Worker script to publish to [Cloudflare Queues](/queues/) from within a [Durable Object](/durable-objects/). Prerequisites: - A [queue created](/queues/get-started/#3-create-a-queue) via the Cloudflare dashboard or the [wrangler CLI](/workers/wrangler/install-and-update/). -- A [configured **producer** binding](/queues/configuration/configure-queues/#producer) in the Cloudflare dashboard or `wrangler.toml` file. +- A [configured **producer** binding](/queues/configuration/configure-queues/#producer) in the Cloudflare dashboard or Wrangler file. - A [Durable Object namespace binding](/workers/wrangler/configuration/#durable-objects). -Configure your `wrangler.toml` file as follows: - -import { WranglerConfig } from "~/components"; +Configure your Wrangler file as follows: diff --git a/src/content/docs/queues/get-started.mdx b/src/content/docs/queues/get-started.mdx index d04392af57517c9..f1bd0fd93e310e0 100644 --- a/src/content/docs/queues/get-started.mdx +++ b/src/content/docs/queues/get-started.mdx @@ -8,7 +8,7 @@ head: content: Get started --- -import { Render, PackageManagers } from "~/components"; +import { Render, PackageManagers, WranglerConfig } from "~/components"; Cloudflare Queues is a flexible messaging queue that allows you to queue messages for asynchronous processing. By following this guide, you will create your first queue, a Worker to publish messages to that queue, and a consumer Worker to consume messages from that queue. @@ -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.toml`](/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.json`](/workers/wrangler/configuration/) configuration file. After you create your Worker, you will create a Queue to access. Move into the newly created directory: @@ -68,9 +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` configuration file and add the following: - -import { WranglerConfig } from "~/components"; +To create a binding, open your newly generated `wrangler.toml / wrangler.json` file and add the following: @@ -108,7 +106,7 @@ export default { } satisfies ExportedHandler; ``` -Replace `MY_QUEUE` with the name you have set for your binding from your `wrangler.toml`. +Replace `MY_QUEUE` with the name you have set for your binding from your `wrangler.toml / wrangler.json` file. Also add the queue to `Env` interface in `index.ts`. @@ -124,7 +122,7 @@ In a production application, you would likely use a [`try...catch`](https://deve ### Publish your producer Worker -With your `wrangler.toml` file and `index.ts` file configured, you are ready to publish your producer Worker. To publish your producer Worker, run: +With your Wrangler file and `index.ts` file configured, you are ready to publish your producer Worker. To publish your producer Worker, run: ```sh npx wrangler deploy @@ -174,7 +172,7 @@ export default { } satisfies ExportedHandler; ``` -Replace `MY_QUEUE` with the name you have set for your binding from your `wrangler.toml`. +Replace `MY_QUEUE` with the name you have set for your binding from your `wrangler.toml / wrangler.json` 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. @@ -188,7 +186,7 @@ After you have configured your consumer Worker, you are ready to connect it to y Each queue can only have one consumer Worker connected to it. If you try to connect multiple consumers to the same queue, you will encounter an error when attempting to publish that Worker. -To connect your queue to your consumer Worker, open your `wrangler.toml` file and add this to the bottom: +To connect your queue to your consumer Worker, open your Wrangler file and add this to the bottom: @@ -215,7 +213,7 @@ In your consumer Worker, you are using queues to auto batch messages using the ` ### Publish your consumer Worker -With your `wrangler.toml` file and `index.ts` file configured, publish your consumer Worker by running: +With your Wrangler file and `index.ts` file configured, publish your consumer Worker by running: ```sh npx wrangler deploy @@ -241,7 +239,7 @@ With `wrangler tail` running, your consumer Worker will start logging the reques If you refresh less than 10 times, it may take a few seconds for the messages to appear because batch timeout is configured for 10 seconds. After 10 seconds, messages should arrive in your terminal. -If you get errors when you refresh, check that the queue name you created in [step 2](/queues/get-started/#2-create-a-queue) and the queue you referenced in your `wrangler.toml` file is the same. You should ensure that your producer Worker is returning `Success` and is not returning an error. +If you get errors when you refresh, check that the queue name you created in [step 2](/queues/get-started/#2-create-a-queue) and the queue you referenced in your Wrangler file is the same. You should ensure that your producer Worker is returning `Success` and is not returning an error. By completing this guide, you have now created a queue, a producer Worker that publishes messages to that queue, and a consumer Worker that consumes those messages from it. diff --git a/src/content/docs/queues/reference/how-queues-works.mdx b/src/content/docs/queues/reference/how-queues-works.mdx index e2b01267e6ee4f2..f9ffc0101018144 100644 --- a/src/content/docs/queues/reference/how-queues-works.mdx +++ b/src/content/docs/queues/reference/how-queues-works.mdx @@ -6,6 +6,8 @@ sidebar: --- +import { WranglerConfig } from "~/components"; + Cloudflare Queues is a flexible messaging queue that allows you to queue messages for asynchronous processing. Message queues are great at decoupling components of applications, like the checkout and order fulfillment services for an e-commerce site. Decoupled services are easier to reason about, deploy, and implement, allowing you to ship features that delight your customers without worrying about synchronizing complex deployments. Queues also allow you to batch and buffer calls to downstream services and APIs. There are four major concepts to understand with Queues: @@ -135,9 +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` manually: - -import { WranglerConfig } from "~/components"; +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: @@ -190,7 +190,7 @@ export default { ### Remove a consumer -To remove a queue from your project, run `wrangler queues consumer remove ` and then remove the desired queue below the `[[queues.consumers]]` in `wrangler.toml` file. +To remove a queue from your project, run `wrangler queues consumer remove ` and then remove the desired queue below the `[[queues.consumers]]` in Wrangler file. ### Pull consumers 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 ab05871bfbe181f..897469ac2462f2e 100644 --- a/src/content/docs/queues/tutorials/handle-rate-limits/index.mdx +++ b/src/content/docs/queues/tutorials/handle-rate-limits/index.mdx @@ -18,7 +18,7 @@ head: description: Example of how to use Queues to handle rate limits of external APIs. --- -import { Render, PackageManagers } from "~/components"; +import { Render, PackageManagers, WranglerConfig } from "~/components"; This tutorial explains how to use Queues to handle rate limits of external APIs by building an application that sends email notifications using [Resend](https://www.resend.com/). However, you can use this pattern to handle rate limits of any external API. @@ -73,11 +73,9 @@ Creating queue rate-limit-queue. Created queue rate-limit-queue. ``` -### Add Queue bindings to `wrangler.toml` +### Add Queue bindings to your `wrangler.toml / wrangler.json` file -In your `wrangler.toml` file, add the following: - -import { WranglerConfig } from "~/components"; +In your Wrangler file, add the following: @@ -97,7 +95,7 @@ max_retries = 3 It is important to include the `max_batch_size` of two to the consumer queue is important because the Resend API has a default rate limit of two requests per second. This batch size allows the queue to process the message in the batch size of two. If the batch size is less than two, the queue will wait for 10 seconds to collect the next message. If no more messages are available, the queue will process the message in the batch. For more information, refer to the [Batching, Retries and Delays documentation](/queues/configuration/batching-retries) -Your final `wrangler.toml` file should look similar to the example below. +Your final Wrangler file should look similar to the example below. 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 e364e5a2bbaaee9..ba1ba58ec583324 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 @@ -19,7 +19,7 @@ head: description: Example of how to use Queues and Browser Rendering to power a web crawler. --- -import { Render, PackageManagers } from "~/components"; +import { Render, PackageManagers, WranglerConfig } from "~/components"; This tutorial explains how to build and deploy a web crawler with Queues, [Browser Rendering](/browser-rendering/), and [Puppeteer](/browser-rendering/platform/puppeteer/). @@ -82,11 +82,9 @@ binding = "crawler_screenshots" id = "" ``` -### Add KV bindings to wrangler.toml +### Add KV bindings to the `wrangler.toml / wrangler.json` file -Then, in your `wrangler.toml` file, add the following with the values generated in the terminal: - -import { WranglerConfig } from "~/components"; +Then, in your Wrangler file, add the following with the values generated in the terminal: @@ -137,7 +135,7 @@ Created queue queues-web-crawler. ### Add Queue bindings to wrangler.toml -Then, in your `wrangler.toml` file, add the following: +Then, in your Wrangler file, add the following: @@ -157,7 +155,7 @@ binding = "CRAWLER_QUEUE" Adding the `max_batch_timeout` of 60 seconds to the consumer queue is important because Browser Rendering has a limit of two new browsers per minute per account. This timeout waits up to a minute before collecting queue messages into a batch. The Worker will then remain under this browser invocation limit. -Your final `wrangler.toml` file should look similar to the one below. +Your final Wrangler file should look similar to the one below. diff --git a/src/content/docs/r2/api/s3/presigned-urls.mdx b/src/content/docs/r2/api/s3/presigned-urls.mdx index 99fd02874e46a28..d089be4156fa9bf 100644 --- a/src/content/docs/r2/api/s3/presigned-urls.mdx +++ b/src/content/docs/r2/api/s3/presigned-urls.mdx @@ -68,9 +68,9 @@ A valid alternative design to presigned URLs is to use a Worker with a [binding] :::note[Bindings] -A binding is how your Worker interacts with external resources such as [KV Namespaces](/kv/concepts/kv-namespaces/), [Durable Objects](/durable-objects/), or [R2 Buckets](/r2/buckets/). A binding is a runtime variable that the Workers runtime provides to your code. You can declare a variable name in your `wrangler.toml` file that will be bound to these resources at runtime, and interact with them through this variable. Every binding's variable name and behavior is determined by you when deploying the Worker. Refer to [Environment Variables](/workers/configuration/environment-variables/) for more information. +A binding is how your Worker interacts with external resources such as [KV Namespaces](/kv/concepts/kv-namespaces/), [Durable Objects](/durable-objects/), or [R2 Buckets](/r2/buckets/). A binding is a runtime variable that the Workers runtime provides to your code. You can declare a variable name in your Wrangler file that will be bound to these resources at runtime, and interact with them through this variable. Every binding's variable name and behavior is determined by you when deploying the Worker. Refer to [Environment Variables](/workers/configuration/environment-variables/) for more information. -A binding is defined in the `wrangler.toml` file of your Worker project's directory. +A binding is defined in the Wrangler file of your Worker project's directory. ::: @@ -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` [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, 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. 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/api/workers/workers-api-reference.mdx b/src/content/docs/r2/api/workers/workers-api-reference.mdx index ce0539010e6bd57..ac28aeb841de536 100644 --- a/src/content/docs/r2/api/workers/workers-api-reference.mdx +++ b/src/content/docs/r2/api/workers/workers-api-reference.mdx @@ -3,7 +3,7 @@ pcx_content_type: reference title: Workers API reference --- -import { Type, MetaInfo } from "~/components"; +import { Type, MetaInfo, WranglerConfig } from "~/components"; The in-Worker R2 API is accessed by binding an R2 bucket to a [Worker](/workers). The Worker you write can expose external access to buckets via a route or manipulate R2 objects internally. @@ -17,15 +17,13 @@ R2 organizes the data you store, called objects, into containers, called buckets :::note[Bindings] -A binding is how your Worker interacts with external resources such as [KV Namespaces](/kv/concepts/kv-namespaces/), [Durable Objects](/durable-objects/), or [R2 Buckets](/r2/buckets/). A binding is a runtime variable that the Workers runtime provides to your code. You can declare a variable name in your `wrangler.toml` file that will be bound to these resources at runtime, and interact with them through this variable. Every binding's variable name and behavior is determined by you when deploying the Worker. Refer to [Environment Variables](/workers/configuration/environment-variables/) for more information. +A binding is how your Worker interacts with external resources such as [KV Namespaces](/kv/concepts/kv-namespaces/), [Durable Objects](/durable-objects/), or [R2 Buckets](/r2/buckets/). A binding is a runtime variable that the Workers runtime provides to your code. You can declare a variable name in your Wrangler file that will be bound to these resources at runtime, and interact with them through this variable. Every binding's variable name and behavior is determined by you when deploying the Worker. Refer to [Environment Variables](/workers/configuration/environment-variables/) for more information. -A binding is defined in the `wrangler.toml` file of your Worker project's directory. +A binding is defined in the Wrangler file of your Worker project's directory. ::: -To bind your R2 bucket to your Worker, add the following to your `wrangler.toml` file. Update the `binding` property to a valid JavaScript variable identifier and `bucket_name` to the name of your R2 bucket: - -import { WranglerConfig } from "~/components"; +To bind your R2 bucket to your Worker, add the following to your Wrangler file. Update the `binding` property to a valid JavaScript variable identifier and `bucket_name` to the name of your R2 bucket: @@ -361,7 +359,7 @@ Only a single hashing algorithm can be specified at once. - Note that there is a limit on the total amount of data that a single `list` operation can return. If you request data, you may receive fewer than `limit` results in your response to accommodate metadata. - - The [compatibility date](/workers/configuration/compatibility-dates/) must be set to `2022-08-04` or later in your `wrangler.toml` file. If not, then the `r2_list_honor_include` compatibility flag must be set. Otherwise it is treated as `include: ['httpMetadata', 'customMetadata']` regardless of what the `include` option provided actually is. + - The [compatibility date](/workers/configuration/compatibility-dates/) must be set to `2022-08-04` or later in your Wrangler file. If not, then the `r2_list_honor_include` compatibility flag must be set. Otherwise it is treated as `include: ['httpMetadata', 'customMetadata']` regardless of what the `include` option provided actually is. This means applications must be careful to avoid comparing the amount of returned objects against your `limit`. Instead, use the `truncated` property to determine if the `list` request has more data to be returned. diff --git a/src/content/docs/r2/api/workers/workers-api-usage.mdx b/src/content/docs/r2/api/workers/workers-api-usage.mdx index 7ca5d9c8d1102c2..2c40d0b32a88f7c 100644 --- a/src/content/docs/r2/api/workers/workers-api-usage.mdx +++ b/src/content/docs/r2/api/workers/workers-api-usage.mdx @@ -8,7 +8,7 @@ head: content: Use R2 from Workers --- -import { Render, PackageManagers } from "~/components"; +import { Render, PackageManagers, WranglerConfig } from "~/components"; ## 1. Create a new application with C3 @@ -56,15 +56,13 @@ You will need to bind your bucket to a Worker. :::note[Bindings] -A binding is how your Worker interacts with external resources such as [KV Namespaces](/kv/concepts/kv-namespaces/), [Durable Objects](/durable-objects/), or [R2 Buckets](/r2/buckets/). A binding is a runtime variable that the Workers runtime provides to your code. You can declare a variable name in your `wrangler.toml` file that will be bound to these resources at runtime, and interact with them through this variable. Every binding's variable name and behavior is determined by you when deploying the Worker. Refer to the [Environment Variables](/workers/configuration/environment-variables/) documentation for more information. +A binding is how your Worker interacts with external resources such as [KV Namespaces](/kv/concepts/kv-namespaces/), [Durable Objects](/durable-objects/), or [R2 Buckets](/r2/buckets/). A binding is a runtime variable that the Workers runtime provides to your code. You can declare a variable name in your Wrangler file that will be bound to these resources at runtime, and interact with them through this variable. Every binding's variable name and behavior is determined by you when deploying the Worker. Refer to the [Environment Variables](/workers/configuration/environment-variables/) documentation for more information. -A binding is defined in the `wrangler.toml` file of your Worker project's directory. +A binding is defined in the Wrangler file of your Worker project's directory. ::: -To bind your R2 bucket to your Worker, add the following to your `wrangler.toml` file. Update the `binding` property to a valid JavaScript variable identifier and `bucket_name` to the `` you used to create your bucket in [step 2](#2-create-your-bucket): - -import { WranglerConfig } from "~/components"; +To bind your R2 bucket to your Worker, add the following to your Wrangler file. Update the `binding` property to a valid JavaScript variable identifier and `bucket_name` to the `` you used to create your bucket in [step 2](#2-create-your-bucket): diff --git a/src/content/docs/r2/reference/data-location.mdx b/src/content/docs/r2/reference/data-location.mdx index 950f7a9fc4c9a5d..4342a004ad4a1fc 100644 --- a/src/content/docs/r2/reference/data-location.mdx +++ b/src/content/docs/r2/reference/data-location.mdx @@ -5,6 +5,8 @@ sidebar: order: 7 --- +import { WranglerConfig } from "~/components"; + Learn how the location of data stored in R2 is determined and about the different available inputs that control the physical location where objects in your buckets are stored. ## Automatic (recommended) @@ -77,9 +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`: - -import { WranglerConfig } from "~/components"; +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: diff --git a/src/content/docs/r2/tutorials/summarize-pdf.mdx b/src/content/docs/r2/tutorials/summarize-pdf.mdx index 61dfdd9edc7be7b..79aed17692a5619 100644 --- a/src/content/docs/r2/tutorials/summarize-pdf.mdx +++ b/src/content/docs/r2/tutorials/summarize-pdf.mdx @@ -12,7 +12,7 @@ languages: - TypeScript --- -import { Render, PackageManagers, Details } from "~/components"; +import { Render, PackageManagers, Details, WranglerConfig } from "~/components"; In this tutorial, you will learn how to use [event notifications](/r2/buckets/event-notifications/) to process a PDF file when it is uploaded to an R2 bucket. You will use [Workers AI](/workers-ai/) to summarize the PDF and store the summary as a text file in the same bucket. @@ -61,9 +61,7 @@ cd pdf-summarizer ## 2. Create the front-end -Using Static Assets, you can serve the front-end of your application from your Worker. To use Static Assets, you need to add the required bindings to your `wrangler.toml` file. - -import { WranglerConfig } from "~/components"; +Using Static Assets, you can serve the front-end of your application from your Worker. To use Static Assets, you need to add the required bindings to your Wrangler file. @@ -237,7 +235,7 @@ When you open the URL in your browser, you will see that there is a file upload ## 3. Handle file upload -To handle the file upload, you will first need to add the R2 binding. In the `wrangler.toml` file, add the following code: +To handle the file upload, you will first need to add the R2 binding. In the Wrangler file, add the following code: @@ -305,7 +303,7 @@ Event notifications capture changes to data in your R2 bucket. You will need to npx wrangler queues create pdf-summarizer ``` -Add the binding to the `wrangler.toml` file: +Add the binding to the Wrangler file: @@ -387,7 +385,7 @@ The above code does the following: ## 7. Use Workers AI to summarize the content -To use Workers AI, you will need to add the Workers AI binding to the `wrangler.toml` file. The `wrangler.toml` file should contain the following code: +To use Workers AI, you will need to add the Workers AI binding to the Wrangler file. The Wrangler file should contain the following code: 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 b537755019a9c08..85d6763ecd902af 100644 --- a/src/content/docs/r2/tutorials/upload-logs-event-notifications.mdx +++ b/src/content/docs/r2/tutorials/upload-logs-event-notifications.mdx @@ -11,7 +11,7 @@ languages: - TypeScript --- -import { Render, PackageManagers } from "~/components"; +import { Render, PackageManagers, WranglerConfig } from "~/components"; This example provides a step-by-step guide on using [event notifications](/r2/buckets/event-notifications/) to capture and store R2 upload logs in a separate bucket. @@ -85,9 +85,7 @@ cd consumer-worker ## 5. Configure your Worker -In your Worker project's [`wrangler.toml`](/workers/wrangler/configuration/) file, 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. - -import { WranglerConfig } from "~/components"; +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. diff --git a/src/content/docs/radar/investigate/bgp-anomalies.mdx b/src/content/docs/radar/investigate/bgp-anomalies.mdx index c5d1f629fbd6418..3f537a2ab7eb950 100644 --- a/src/content/docs/radar/investigate/bgp-anomalies.mdx +++ b/src/content/docs/radar/investigate/bgp-anomalies.mdx @@ -7,7 +7,7 @@ sidebar: text: Beta --- -import { Render, PackageManagers } from "~/components"; +import { Render, PackageManagers, WranglerConfig } from "~/components"; To access Cloudflare Radar BGP Anomaly Detection results, you will first need to create an API token that includes a `Account:Radar` permission. All the following examples should work with a free-tier Cloudflare account. @@ -198,11 +198,9 @@ To start developing your Worker, `cd` into your new project directory: cd hijack-alerts ``` -In your `wrangler.toml` file, change the default checking frequency (once per hour) to what you like. Here is an example +In your Wrangler file, change the default checking frequency (once per hour) to what you like. Here is an example of configuring the workers to run the script five minutes. -import { WranglerConfig } from "~/components"; - ```toml @@ -372,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-send-email] file. +For this alert to work, you will need to configure the proper email bindings in the [`wrangler.toml / wrangler.json` file][wrangler-send-email]. diff --git a/src/content/docs/style-guide/documentation-content-strategy/content-types/changelog.mdx b/src/content/docs/style-guide/documentation-content-strategy/content-types/changelog.mdx index 3ec3c91722d5649..b57eb9d457f4a79 100644 --- a/src/content/docs/style-guide/documentation-content-strategy/content-types/changelog.mdx +++ b/src/content/docs/style-guide/documentation-content-strategy/content-types/changelog.mdx @@ -117,7 +117,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` 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 file 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/learning/consumer-concurrency/) documentation. - publish_date: "2023-03-02" 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 5450485a3fd28c8..4a6065f78b675b7 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` | +| Filenames, filename extensions (if used), and paths | `wrangler.toml`, `wrangler.json` | | 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 369559c59c722e4..00d0137be825152 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 @@ -164,7 +164,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`. +At the same time, change the filename specified in the `wrangler.toml / wrangler.json` file. ```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 97206d509642403..9a74850a867fde4 100644 --- a/src/content/docs/vectorize/get-started/embeddings.mdx +++ b/src/content/docs/vectorize/get-started/embeddings.mdx @@ -5,7 +5,7 @@ sidebar: order: 3 --- -import { Render, PackageManagers } from "~/components"; +import { Render, PackageManagers, WranglerConfig } from "~/components"; @@ -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.toml`](/workers/wrangler/configuration/) configuration file. `wrangler.toml` is how your `embeddings-tutorial` Worker will access your index. +- A [`wrangler.json`](/workers/wrangler/configuration/) configuration file. `wrangler.json` is how your `embeddings-tutorial` Worker will access your index. :::note @@ -107,11 +107,9 @@ This will create a new vector database, and output the [binding](/workers/runtim ## 3. Bind your Worker to your index -You must create a binding for your Worker to connect to your Vectorize index. [Bindings](/workers/runtime-apis/bindings/) allow your Workers to access resources, like Vectorize or R2, from Cloudflare Workers. You create bindings by updating your `wrangler.toml` file. +You must create a binding for your Worker to connect to your Vectorize index. [Bindings](/workers/runtime-apis/bindings/) allow your Workers to access resources, like Vectorize or R2, from Cloudflare Workers. You create bindings by updating your Wrangler file. -To bind your index to your Worker, add the following to the end of your `wrangler.toml` file: - -import { WranglerConfig } from "~/components"; +To bind your index to your Worker, add the following to the end of your Wrangler file: @@ -133,7 +131,7 @@ Specifically: Before you deploy your embedding example, ensure your Worker uses your model catalog, including the [text embedding model](/workers-ai/models/#text-embeddings) built-in. -From within the `embeddings-tutorial` directory, open your `wrangler.toml` file in your editor and add the new `[[ai]]` binding to make Workers AI's models available in your Worker: +From within the `embeddings-tutorial` directory, open your Wrangler file in your editor and add the new `[[ai]]` binding to make Workers AI's models available in your Worker: diff --git a/src/content/docs/vectorize/get-started/intro.mdx b/src/content/docs/vectorize/get-started/intro.mdx index 9bd0c1402a096e1..882753ab081b4a1 100644 --- a/src/content/docs/vectorize/get-started/intro.mdx +++ b/src/content/docs/vectorize/get-started/intro.mdx @@ -5,7 +5,7 @@ sidebar: order: 2 --- -import { Render, PackageManagers } from "~/components"; +import { Render, PackageManagers, WranglerConfig } from "~/components"; @@ -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.toml`](/workers/wrangler/configuration/) configuration file. `wrangler.toml` is how your `vectorize-tutorial` Worker will access your index. +- A [`wrangler.json`](/workers/wrangler/configuration/) configuration file. `wrangler.json` is how your `vectorize-tutorial` Worker will access your index. :::note @@ -114,11 +114,9 @@ The command above will create a new vector database, and output the [binding](/w ## 3. Bind your Worker to your index -You must create a binding for your Worker to connect to your Vectorize index. [Bindings](/workers/runtime-apis/bindings/) allow your Workers to access resources, like Vectorize or R2, from Cloudflare Workers. You create bindings by updating the worker's `wrangler.toml` file. +You must create a binding for your Worker to connect to your Vectorize index. [Bindings](/workers/runtime-apis/bindings/) allow your Workers to access resources, like Vectorize or R2, from Cloudflare Workers. You create bindings by updating the worker's Wrangler file. -To bind your index to your Worker, add the following to the end of your `wrangler.toml` file: - -import { WranglerConfig } from "~/components"; +To bind your index to your Worker, add the following to the end of your Wrangler file: @@ -274,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 `wrangler.toml` 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.toml / wrangler.json` file under `[[vectorize]]`. 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 81a8e8916fdde86..c0b20e5b4eba2cc 100644 --- a/src/content/docs/vectorize/reference/client-api.mdx +++ b/src/content/docs/vectorize/reference/client-api.mdx @@ -5,7 +5,7 @@ sidebar: order: 2 --- -import { Render } from "~/components"; +import { Render, WranglerConfig } from "~/components"; This page covers the Vectorize API available within [Cloudflare Workers](/workers/), including usage examples. @@ -200,12 +200,10 @@ 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`](/workers/wrangler/configuration/) configuration associated with your Workers project, or via the Cloudflare dashboard for your project. +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. Vectorize indexes are bound by name. A binding for an index named `production-doc-search` would resemble the below: -import { WranglerConfig } from "~/components"; - ```toml diff --git a/src/content/docs/workers-ai/configuration/ai-sdk.mdx b/src/content/docs/workers-ai/configuration/ai-sdk.mdx index 2eff0c111f514b4..2c0fbe6e1cbbd8a 100644 --- a/src/content/docs/workers-ai/configuration/ai-sdk.mdx +++ b/src/content/docs/workers-ai/configuration/ai-sdk.mdx @@ -16,7 +16,7 @@ Install the [`workers-ai-provider` provider](https://sdk.vercel.ai/providers/com npm install workers-ai-provider ``` -Then, add an AI binding in your Workers project `wrangler.toml` file: +Then, add an AI binding in your Workers project Wrangler file: ```toml [ai] diff --git a/src/content/docs/workers-ai/configuration/bindings.mdx b/src/content/docs/workers-ai/configuration/bindings.mdx index bcc052d223d4655..c5992550a082fad 100644 --- a/src/content/docs/workers-ai/configuration/bindings.mdx +++ b/src/content/docs/workers-ai/configuration/bindings.mdx @@ -6,17 +6,15 @@ sidebar: --- -import { Type, MetaInfo } from "~/components"; +import { Type, MetaInfo, WranglerConfig } from "~/components"; ## Workers [Workers](/workers/) provides a serverless execution environment that allows you to create new applications or augment existing ones. -To use Workers AI with Workers, you must create a Workers AI [binding](/workers/runtime-apis/bindings/). Bindings allow your Workers to interact with resources, like Workers AI, on the Cloudflare Developer Platform. You create bindings on the Cloudflare dashboard or by updating your [`wrangler.toml` file](/workers/wrangler/configuration/). +To use Workers AI with Workers, you must create a Workers AI [binding](/workers/runtime-apis/bindings/). Bindings allow your Workers to interact with resources, like Workers AI, on the Cloudflare Developer Platform. You create bindings on the Cloudflare dashboard or by updating your [Wrangler file](/workers/wrangler/configuration/). -To bind Workers AI to your Worker, add the following to the end of your `wrangler.toml` file: - -import { WranglerConfig } from "~/components"; +To bind Workers AI to your Worker, add the following to the end of your Wrangler file: diff --git a/src/content/docs/workers-ai/function-calling/embedded/examples/kv.mdx b/src/content/docs/workers-ai/function-calling/embedded/examples/kv.mdx index 894102287d8fbeb..a14b0f0475122f5 100644 --- a/src/content/docs/workers-ai/function-calling/embedded/examples/kv.mdx +++ b/src/content/docs/workers-ai/function-calling/embedded/examples/kv.mdx @@ -17,7 +17,7 @@ In this example we show how embedded function calling can interact with other re For this example to work, you need to provision a [KV](/kv/) namespace first. To do so, follow the [KV - Get started ](/kv/get-started/) guide. -Importantly, your `wrangler.toml` file must be updated to include the `KV` binding definition to your respective namespace. +Importantly, your Wrangler file must be updated to include the `KV` binding definition to your respective namespace. ## Worker code 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 75f84d268f2e1d9..f39f353d294ccd1 100644 --- a/src/content/docs/workers-ai/get-started/workers-wrangler.mdx +++ b/src/content/docs/workers-ai/get-started/workers-wrangler.mdx @@ -9,7 +9,7 @@ head: description: Deploy your first Cloudflare Workers AI project using the CLI. --- -import { Render, PackageManagers } from "~/components"; +import { Render, PackageManagers, WranglerConfig } from "~/components"; This guide will instruct you through setting up and deploying your first Workers AI project. You will use [Workers](/workers/), a Workers AI binding, and a large language model (LLM) to deploy your first AI-powered application on the Cloudflare global network. @@ -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.toml`](/workers/wrangler/configuration/) configuration file. +- A [`wrangler.json`](/workers/wrangler/configuration/) configuration file. Go to your application directory: @@ -50,13 +50,11 @@ cd hello-ai You must create an AI binding for your Worker to connect to Workers AI. [Bindings](/workers/runtime-apis/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.toml` file: - -import { WranglerConfig } from "~/components"; +To bind Workers AI to your Worker, add the following to the end of your Wrangler file: -```toml title="wrangler.toml" +```toml [ai] binding = "AI" ``` @@ -77,7 +75,7 @@ Update the `index.ts` file in your `hello-ai` application directory with the fol ```typescript title="src/index.ts" export interface Env { - // If you set another name in wrangler.toml as the value for 'binding', + // If you set another name in the Wrangler config file as the value for 'binding', // replace "AI" with the variable name you defined. AI: Ai; } 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 ed689e6a15fc19e..3c93d60b82f0c4d 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 @@ -16,7 +16,7 @@ sidebar: order: 2 --- -import { Details, Render, PackageManagers } from "~/components"; +import { Details, Render, PackageManagers, WranglerConfig } from "~/components"; This guide will instruct you through setting up and deploying your first application with Cloudflare AI. You will build a fully-featured AI-powered application, using tools like Workers AI, Vectorize, D1, and Cloudflare Workers. @@ -52,7 +52,7 @@ In your project directory, C3 has generated several files.
-1. `wrangler.toml`: Your [Wrangler](/workers/wrangler/configuration/#sample-wrangler-configuration) configuration file. +1. `wrangler.json`: 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). @@ -88,12 +88,10 @@ 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 `wrangler.toml`. 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.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. This example features the [`@cf/meta/llama-3-8b-instruct` model](/workers-ai/models/llama-3-8b-instruct/), which generates text. -import { WranglerConfig } from "~/components"; - ```toml @@ -145,7 +143,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 `wrangler.toml`: +Then, add the configuration details for your new Vectorize index to the `wrangler.toml / wrangler.json` file: @@ -171,9 +169,7 @@ Create a new D1 database using `wrangler`: npx wrangler d1 create database ``` -Then, paste the configuration details output from the previous command into `wrangler.toml`: - - +Then, paste the configuration details output from the previous command into the `wrangler.toml / wrangler.json` file: diff --git a/src/content/docs/workers-ai/tutorials/build-a-voice-notes-app-with-auto-transcription.mdx b/src/content/docs/workers-ai/tutorials/build-a-voice-notes-app-with-auto-transcription.mdx index 03f77c7e9b69b22..3b028a57979d240 100644 --- a/src/content/docs/workers-ai/tutorials/build-a-voice-notes-app-with-auto-transcription.mdx +++ b/src/content/docs/workers-ai/tutorials/build-a-voice-notes-app-with-auto-transcription.mdx @@ -104,7 +104,7 @@ This API makes use of Workers AI to transcribe the voice recordings. To use Work -Add the `AI` binding to the `wrangler.toml` file. +Add the `AI` binding to the Wrangler file. ```toml title="wrangler.toml" [ai] @@ -153,7 +153,7 @@ The above code does the following: ## 3. Create an API endpoint for uploading audio recordings to R2 -Before uploading the audio recordings to `R2`, you need to create a bucket first. You will also need to add the R2 binding to your `wrangler.toml` file and regenerate the Cloudflare type definitions. +Before uploading the audio recordings to `R2`, you need to create a bucket first. You will also need to add the R2 binding to your Wrangler file and regenerate the Cloudflare type definitions. Create an `R2` bucket. @@ -181,7 +181,7 @@ pnpm dlx wrangler r2 bucket create -Add the storage binding to your `wrangler.toml` file. +Add the storage binding to your Wrangler file. ```toml title="wrangler.toml" [[r2_buckets]] @@ -254,7 +254,7 @@ pnpm dlx wrangler d1 create -Add the D1 bindings to the `wrangler.toml` file. You can get the `DB_ID` from the output of the `d1 create` command. +Add the D1 bindings to the Wrangler file. You can get the `DB_ID` from the output of the `d1 create` command. ```toml title="wrangler.toml" [[d1_databases]] diff --git a/src/content/docs/workers-ai/tutorials/build-ai-interview-practice-tool.mdx b/src/content/docs/workers-ai/tutorials/build-ai-interview-practice-tool.mdx index 8ab69b2460d4a32..9c9cfdef7aece17 100644 --- a/src/content/docs/workers-ai/tutorials/build-ai-interview-practice-tool.mdx +++ b/src/content/docs/workers-ai/tutorials/build-ai-interview-practice-tool.mdx @@ -363,7 +363,7 @@ Now that you have your authentication system in place, create a Durable Object t - Handles multiple interview sessions efficiently without performance issues. - Creates a dedicated instance for each user, giving them their own isolated environment. -First, you will need to configure the Durable Object in `wrangler.toml` file. Add the following configuration: +First, you will need to configure the Durable Object in Wrangler file. Add the following configuration: ```toml title="wrangler.toml" [[durable_objects.bindings]] @@ -735,36 +735,36 @@ export class InterviewDatabaseService { // ... previous queries ... INSERT_INTERVIEW: ` - INSERT INTO ${CONFIG.database.tables.interviews} + INSERT INTO ${CONFIG.database.tables.interviews} (interviewId, title, skills, status, createdAt, updatedAt) VALUES (?, ?, ?, ?, ?, ?) `, GET_ALL_INTERVIEWS: ` - SELECT - interviewId, - title, - skills, - createdAt, - updatedAt, - status - FROM ${CONFIG.database.tables.interviews} + SELECT + interviewId, + title, + skills, + createdAt, + updatedAt, + status + FROM ${CONFIG.database.tables.interviews} ORDER BY createdAt DESC `, INSERT_MESSAGE: ` - INSERT INTO ${CONFIG.database.tables.messages} + INSERT INTO ${CONFIG.database.tables.messages} (messageId, interviewId, role, content, timestamp) VALUES (?, ?, ?, ?, ?) `, GET_INTERVIEW: ` - SELECT - i.interviewId, - i.title, - i.skills, - i.status, - i.createdAt, + SELECT + i.interviewId, + i.title, + i.skills, + i.status, + i.createdAt, i.updatedAt, COALESCE( json_group_array( @@ -1197,7 +1197,7 @@ Your `handleBinaryAudio` method currently logs when it receives audio data. Next Now that audio processing pipeline is set up, you will now integrate Workers AI's Whisper model for speech-to-text transcription. -Configure the Worker AI binding in your `wrangler.toml` file by adding: +Configure the Worker AI binding in your Wrangler file by adding: ```toml # ... previous configuration ... diff --git a/src/content/docs/workers-ai/tutorials/using-bigquery-with-workers-ai.mdx b/src/content/docs/workers-ai/tutorials/using-bigquery-with-workers-ai.mdx index 82e0158215487a2..8b3b32ba0b25634 100644 --- a/src/content/docs/workers-ai/tutorials/using-bigquery-with-workers-ai.mdx +++ b/src/content/docs/workers-ai/tutorials/using-bigquery-with-workers-ai.mdx @@ -15,6 +15,7 @@ sidebar: order: 2 --- +import { WranglerConfig } from "~/components"; The easiest way to get started with [Workers AI](/workers-ai/) is to try it out in the [Multi-modal Playground](https://multi-modal.ai.cloudflare.com/) and the [LLM playground](https://playground.ai.cloudflare.com/). If you decide that you want to integrate your code with Workers AI, you may then decide to then use its [REST API endpoints](/workers-ai/get-started/rest-api/) or via a [Worker binding](/workers-ai/configuration/bindings/). @@ -445,9 +446,7 @@ formattedResults = formattedResults?.map((formattedResult, i) => { ``` -Uncomment the following lines from the `wrangler.toml` file in your project: - -import { WranglerConfig } from "~/components"; +Uncomment the following lines from the Wrangler file in your project: diff --git a/src/content/docs/workers/configuration/compatibility-dates.mdx b/src/content/docs/workers/configuration/compatibility-dates.mdx index efc2f169a5a7db4..7c2d819ff1fc667 100644 --- a/src/content/docs/workers/configuration/compatibility-dates.mdx +++ b/src/content/docs/workers/configuration/compatibility-dates.mdx @@ -6,6 +6,8 @@ head: [] description: Opt into a specific version of the Workers runtime for your Workers project. --- +import { WranglerConfig } from "~/components"; + Cloudflare regularly updates the Workers runtime. These updates apply to all Workers globally and should never cause a Worker that is already deployed to stop functioning. Sometimes, though, some changes may be backwards-incompatible. In particular, there might be bugs in the runtime API that existing Workers may inadvertently depend upon. Cloudflare implements bug fixes that new Workers can opt into while existing Workers will continue to see the buggy behavior to prevent breaking deployed Workers. The compatibility date and flags are how you, as a developer, opt into these runtime changes. [Compatibility flags](/workers/configuration/compatibility-flags) will often have a date in which they are enabled by default, and so, by specifying a `compatibility_date` for your Worker, you can quickly enable all of these various compatibility flags up to, and including, that date. @@ -23,9 +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`](/workers/wrangler/configuration/) file. - -import { WranglerConfig } from "~/components"; +The compatibility date can be set in a Worker's [`wrangler.toml / wrangler.json` 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 10a4bb927fc8277..7ffa42342644dda 100644 --- a/src/content/docs/workers/configuration/compatibility-flags.mdx +++ b/src/content/docs/workers/configuration/compatibility-flags.mdx @@ -6,7 +6,7 @@ head: [] description: Opt into a specific features of the Workers runtime for your Workers project. --- -import { CompatibilityFlags } from "~/components"; +import { CompatibilityFlags, WranglerConfig } from "~/components"; Compatibility flags enable specific features. They can be useful if you want to help the Workers team test upcoming changes that are not yet enabled by default, or if you need to hold back a change that your code depends on but still want to apply other compatibility changes. @@ -18,12 +18,10 @@ 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`](/workers/wrangler/configuration/) file. +Compatibility flags can be set in a Worker's [`wrangler.toml / wrangler.json` 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. -import { WranglerConfig } from "~/components"; - ```toml diff --git a/src/content/docs/workers/configuration/cron-triggers.mdx b/src/content/docs/workers/configuration/cron-triggers.mdx index 76d2c88f8e95270..d58257ace20de35 100644 --- a/src/content/docs/workers/configuration/cron-triggers.mdx +++ b/src/content/docs/workers/configuration/cron-triggers.mdx @@ -5,6 +5,8 @@ head: [] description: Enable your Worker to be executed on a schedule. --- +import { WranglerConfig } from "~/components"; + ## Background Cron Triggers allow users to map a cron expression to a Worker using a [`scheduled()` handler](/workers/runtime-apis/handlers/scheduled/) that enables Workers to be executed on a schedule. @@ -34,13 +36,11 @@ 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 `wrangler.toml` +#### Via the `wrangler.toml / wrangler.json` file -If a Worker is managed with Wrangler, Cron Triggers should be exclusively managed through the [`wrangler.toml`](/workers/wrangler/configuration/) file. +If a Worker is managed with Wrangler, Cron Triggers should be exclusively managed through the [`wrangler.toml / wrangler.json` file](/workers/wrangler/configuration/). -Refer to the example below for a sample `wrangler.toml` Cron Triggers configuration: - -import { WranglerConfig } from "~/components"; +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`. 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.toml / wrangler.json` file. You need to put the `[triggers]` table under your chosen environment. For example: @@ -173,7 +173,7 @@ To delete a Cron Trigger on a deployed Worker via the dashboard: :::note -You can only delete Cron Triggers using the Cloudflare dashboard (and not through your `wrangler.toml` file). +You can only delete Cron Triggers using the Cloudflare dashboard (and not through your Wrangler file). ::: @@ -198,5 +198,5 @@ Green Compute can be configured at the account level: ## Related resources -- [Triggers](/workers/wrangler/configuration/#triggers) - Review `wrangler.toml` syntax for Cron Triggers. +- [Triggers](/workers/wrangler/configuration/#triggers) - Review `wrangler.toml / wrangler.json` 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 d64e189fd25748f..92c7f177c056006 100644 --- a/src/content/docs/workers/configuration/environment-variables.mdx +++ b/src/content/docs/workers/configuration/environment-variables.mdx @@ -6,7 +6,7 @@ description: Environment variables are a type of binding that allow you to attac --- -import { Render, TabItem, Tabs } from "~/components" +import { Render, TabItem, Tabs, WranglerConfig } from "~/components" ## Background @@ -16,7 +16,7 @@ Text strings and JSON values are not encrypted and are useful for storing applic ## Add environment variables via Wrangler -Text and JSON values are defined via the `[vars]` configuration in your `wrangler.toml` file. In the following example, `API_HOST` and `API_ACCOUNT_ID` are text values and `SERVICE_X_DATA` is a JSON value. +Text and JSON values are defined via the `[vars]` configuration in your Wrangler file. In the following example, `API_HOST` and `API_ACCOUNT_ID` are text values and `SERVICE_X_DATA` is a JSON value. @@ -52,8 +52,6 @@ export default { To define environment variables for different environments, refer to the example below: -import { WranglerConfig } from "~/components"; - ```toml @@ -72,14 +70,14 @@ SERVICE_X_DATA = { URL = "service-x-api.prod.example", MY_ID = 456 } -For local development with `wrangler dev`, variables in `wrangler.toml` 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.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. ```shell API_HOST = "localhost:4000" API_ACCOUNT_ID = "local_example_user" ``` -Alternatively, you can specify per-environment values in `wrangler.toml` 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.toml / wrangler.json` file 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 3ba95c1e0652b20..70e9bc1cfd2cf8b 100644 --- a/src/content/docs/workers/configuration/previews.mdx +++ b/src/content/docs/workers/configuration/previews.mdx @@ -8,7 +8,7 @@ sidebar: description: Preview URLs allow you to preview new versions of your project without deploying it to production. --- -import { Render } from "~/components"; +import { Render, WranglerConfig } from "~/components"; Preview URLs allow you to preview new versions of your Worker without deploying it to production. @@ -60,7 +60,7 @@ You must press enter after you input your Application domain for it to save. You 6. Go to the next page. 7. Add a name for your access policy (for example, "Allow employees access to preview URLs for my-worker"). -8. In the **Configure rules** section create a new rule with the **Emails** selector, or any other attributes which you wish to gate access to previews with. +8. In the **Configure rules** section create a new rule with the **Emails** selector, or any other attributes which you wish to gate access to previews with. 9. Enter the emails you want to authorize. View [access policies](/cloudflare-one/policies/access/#selectors) to learn about configuring alternate rules. 10. Go to the next page. 11. Add application. @@ -77,15 +77,13 @@ To disable Preview URLs for a Worker: 4. On "Preview URLs" click "Disable". 5. Confirm you want to disable. -### Disabling Preview URLs in `wrangler.toml` +### Disabling Preview URLs in the `wrangler.toml / wrangler.json` file :::note Wrangler 3.91.0 or higher is required to use this feature. ::: -To disable Preview URLs for a Worker, include the following in your Worker's `wrangler.toml` file: - -import { WranglerConfig } from "~/components"; +To disable Preview URLs for a Worker, include the following in your Worker's Wrangler file: @@ -99,7 +97,7 @@ When you redeploy your Worker with this change, Preview URLs will be disabled. :::caution -If you disable Preview URLs in the Cloudflare dashboard but do not update your Worker's `wrangler.toml` file with `preview_urls = false`, then Preview URLs will be re-enabled the next time you deploy your Worker with Wrangler. +If you disable Preview URLs in the Cloudflare dashboard but do not update your Worker's Wrangler file with `preview_urls = false`, then Preview URLs will be re-enabled the next time you deploy your Worker with Wrangler. ::: ## Limitations diff --git a/src/content/docs/workers/configuration/routing/custom-domains.mdx b/src/content/docs/workers/configuration/routing/custom-domains.mdx index b84a05ded426afb..8cf7e10d0838be7 100644 --- a/src/content/docs/workers/configuration/routing/custom-domains.mdx +++ b/src/content/docs/workers/configuration/routing/custom-domains.mdx @@ -4,6 +4,8 @@ title: Custom Domains --- +import { WranglerConfig } from "~/components"; + ## Background Custom Domains allow you to connect your Worker to a domain or subdomain, without having to make changes to your DNS settings or perform any certificate management. After you set up a Custom Domain for your Worker, Cloudflare will create DNS records and issue necessary certificates on your behalf. The created DNS records will point directly to your Worker. Unlike [Routes](/workers/configuration/routing/routes/#set-up-a-route), Custom Domains point all paths of a domain or subdomain to your Worker. @@ -47,11 +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` +### Set up a Custom Domain in your `wrangler.toml / wrangler.json` file -To configure a Custom Domain in your `wrangler.toml`, add the `custom_domain=true` option on each pattern under `routes`. For example, to configure a Custom Domain: - -import { WranglerConfig } from "~/components"; +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: @@ -156,11 +156,11 @@ To migrate the route `example.com/*`: ### Migrate from Routes via Wrangler -To migrate the route `example.com/*` in your `wrangler.toml`: +To migrate the route `example.com/*` in your `wrangler.toml / wrangler.json` file: 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`. -3. Add the following to your `wrangler.toml` file: +3. Add the following to your Wrangler file: diff --git a/src/content/docs/workers/configuration/routing/routes.mdx b/src/content/docs/workers/configuration/routing/routes.mdx index 38a3c8892f5fdd0..417be53e981bc70 100644 --- a/src/content/docs/workers/configuration/routing/routes.mdx +++ b/src/content/docs/workers/configuration/routing/routes.mdx @@ -3,6 +3,8 @@ pcx_content_type: concept title: Routes --- +import { WranglerConfig } from "~/components"; + ## Background Routes allow users to map a URL pattern to a Worker. When a request comes in to the Cloudflare network that matches the specified URL pattern, your Worker will execute on that route. @@ -47,13 +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 `wrangler.toml` +### Set up a route in the `wrangler.toml / wrangler.json` 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.toml` file, refer to the following example. - -import { WranglerConfig } from "~/components"; +To configure a route using your Wrangler file, 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 25c7c26915dfaab..546227fa80916ae 100644 --- a/src/content/docs/workers/configuration/routing/workers-dev.mdx +++ b/src/content/docs/workers/configuration/routing/workers-dev.mdx @@ -3,6 +3,8 @@ pcx_content_type: concept title: workers.dev --- +import { WranglerConfig } from "~/components"; + Cloudflare Workers accounts come with a `workers.dev` subdomain that is configurable in the Cloudflare dashboard. Your `workers.dev` subdomain allows you getting started quickly by deploying Workers without first onboarding your custom domain to Cloudflare. It's recommended to run production Workers on a [Workers route or custom domain](/workers/configuration/routing/), rather than on your `workers.dev` subdomain. Your `workers.dev` subdomain is treated as a [Free website](https://www.cloudflare.com/plans/) and is intended for personal or hobby projects that aren't business-critical. @@ -29,11 +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 `wrangler.toml` +### Disabling `workers.dev` in the `wrangler.toml / wrangler.json` file -To disable the `workers.dev` route for a Worker, include the following in your Worker's `wrangler.toml` file: - -import { WranglerConfig } from "~/components"; +To disable the `workers.dev` route for a Worker, include the following in your Worker's Wrangler file: @@ -45,11 +45,11 @@ 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`, 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.toml / wrangler.json` file, the value of `workers_dev` will be inferred as `false` on the next deploy. :::caution -If you disable your `workers.dev` route in the Cloudflare dashboard but do not update your Worker's `wrangler.toml` file with `workers_dev = false`, the `workers.dev` route will be re-enabled the next time you deploy your Worker with Wrangler. +If you disable your `workers.dev` route in the Cloudflare dashboard but do not update your Worker's Wrangler file with `workers_dev = false`, the `workers.dev` route will be re-enabled the next time you deploy your Worker with Wrangler. ::: ## Limitations @@ -59,4 +59,4 @@ If you disable your `workers.dev` route in the Cloudflare dashboard but do not u ## Related resources - [Announcing `workers.dev`](https://blog.cloudflare.com/announcing-workers-dev) -- [`wrangler.toml` routes configuration](/workers/wrangler/configuration/#types-of-routes) +- [Wrangler routes configuration](/workers/wrangler/configuration/#types-of-routes) diff --git a/src/content/docs/workers/configuration/sites/configuration.mdx b/src/content/docs/workers/configuration/sites/configuration.mdx index a0e70ed61fd4cd4..26203d3d2b6f3d4 100644 --- a/src/content/docs/workers/configuration/sites/configuration.mdx +++ b/src/content/docs/workers/configuration/sites/configuration.mdx @@ -6,21 +6,21 @@ sidebar: --- -import { Render } from "~/components" +import { Render, WranglerConfig } from "~/components" Workers Sites require the latest version of [Wrangler](https://github.com/cloudflare/workers-sdk/tree/main/packages/wrangler). -## wrangler.toml +## Wrangler configuration file -There are a few specific configuration settings for Workers Sites in your `wrangler.toml` file: +There are a few specific configuration settings for Workers Sites in your Wrangler file: * `bucket` required - * The directory containing your static assets, path relative to your `wrangler.toml`. Example: `bucket = "./public"`. + * The directory containing your static assets, path relative to your `wrangler.toml / wrangler.json` file. Example: `bucket = "./public"`. * `include` optional @@ -41,9 +41,7 @@ If your project uses [environments](/workers/wrangler/environments/), make sure ::: -Example of a `wrangler.toml`: - -import { WranglerConfig } from "~/components"; +Example of a `wrangler.toml / wrangler.json` file: @@ -80,7 +78,7 @@ This means that you should use gitignore semantics when declaring which director ### Exclusively including files/directories -If you want to include only a certain set of files or directories in your `bucket`, you can add an `include` field to your `[site]` section of your `wrangler.toml` file: +If you want to include only a certain set of files or directories in your `bucket`, you can add an `include` field to your `[site]` section of your Wrangler file: @@ -98,7 +96,7 @@ Wrangler will only upload files or directories matching the patterns in the `inc ### Excluding files/directories -If you want to exclude files or directories in your `bucket`, you can add an `exclude` field to your `[site]` section of your `wrangler.toml` file: +If you want to exclude files or directories in your `bucket`, you can add an `exclude` field to your `[site]` section of your Wrangler file: 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 6c00ad676f8aa8a..efcbaacb27c500b 100644 --- a/src/content/docs/workers/configuration/sites/start-from-existing.mdx +++ b/src/content/docs/workers/configuration/sites/start-from-existing.mdx @@ -21,7 +21,7 @@ To deploy a pre-existing static site project, start with a pre-generated site. W ## Getting started -1. Run the `wrangler init` command in the root of your project’s directory to generate a basic Worker: +1. Run the `wrangler init` command in the root of your project's directory to generate a basic Worker: ```sh wrangler init -y @@ -29,12 +29,12 @@ To deploy a pre-existing static site project, start with a pre-generated site. W This command adds/update the following files: - - `wrangler.toml`: The file containing project configuration. + - `wrangler.json`: 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. -2. Add your site’s build/output directory to the `wrangler.toml` file: +2. Add your site's build/output directory to the Wrangler file: @@ -124,7 +124,7 @@ async function handleEvent(event) { npx wrangler deploy ``` -6. Deploy your site to a [custom domain](/workers/configuration/routing/custom-domains/) that you own and have already attached as a Cloudflare zone. Add a `route` property to the `wrangler.toml` file. +6. Deploy your site to a [custom domain](/workers/configuration/routing/custom-domains/) that you own and have already attached as a Cloudflare zone. Add a `route` property to the Wrangler file. 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 f7312ead5b407df..c5198648b52b172 100644 --- a/src/content/docs/workers/configuration/sites/start-from-scratch.mdx +++ b/src/content/docs/workers/configuration/sites/start-from-scratch.mdx @@ -42,11 +42,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.toml`: The file containing project configuration. +- `wrangler.json`: 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 `wrangler.toml`: +## Customize the `wrangler.toml / wrangler.json` file: - Change the `name` property to the name of your project: diff --git a/src/content/docs/workers/configuration/sites/start-from-worker.mdx b/src/content/docs/workers/configuration/sites/start-from-worker.mdx index 403b6dddbb553a3..46d789a4db225de 100644 --- a/src/content/docs/workers/configuration/sites/start-from-worker.mdx +++ b/src/content/docs/workers/configuration/sites/start-from-worker.mdx @@ -17,7 +17,7 @@ If you have a pre-existing Worker project, you can use Workers Sites to serve st 1. Create a directory that will contain the assets in the root of your project (for example, `./public`) -2. Add configuration to your `wrangler.toml` file to point to it. +2. Add configuration to your Wrangler file to point to it. diff --git a/src/content/docs/workers/configuration/smart-placement.mdx b/src/content/docs/workers/configuration/smart-placement.mdx index 5db5172f9093f25..13f448cd4862ace 100644 --- a/src/content/docs/workers/configuration/smart-placement.mdx +++ b/src/content/docs/workers/configuration/smart-placement.mdx @@ -45,7 +45,7 @@ To enable Smart Placement via Wrangler: 1. Make sure that you have `wrangler@2.20.0` or later [installed](/workers/wrangler/install-and-update/). -2. Add the following to your Worker project's `wrangler.toml` file: +2. Add the following to your Worker project's Wrangler file: 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 43bc2ede38fa515..86e982765b9f914 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.toml`](/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](/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. 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 1260b238dd734b7..5facd46b6575d0f 100644 --- a/src/content/docs/workers/examples/cron-trigger.mdx +++ b/src/content/docs/workers/examples/cron-trigger.mdx @@ -13,7 +13,7 @@ sidebar: description: Set a Cron Trigger for your Worker. --- -import { TabItem, Tabs } from "~/components"; +import { TabItem, Tabs, WranglerConfig } from "~/components"; @@ -46,9 +46,7 @@ export default { Refer to [Cron Triggers](/workers/configuration/cron-triggers/) for more information on how to add a Cron Trigger. -If you are deploying with Wrangler, set the cron syntax (once per hour as shown below) by adding this to your `wrangler.toml` file: - -import { WranglerConfig } from "~/components"; +If you are deploying with Wrangler, set the cron syntax (once per hour as shown below) by adding this to your Wrangler file: @@ -63,7 +61,7 @@ crons = ["0 * * * *"] -You also can set a different Cron Trigger for each [environment](/workers/wrangler/environments/) in your `wrangler.toml`. 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.toml / wrangler.json` file. 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 f01e1b0a5051b7a..0f35165902cc91c 100644 --- a/src/content/docs/workers/frameworks/framework-guides/nextjs.mdx +++ b/src/content/docs/workers/frameworks/framework-guides/nextjs.mdx @@ -12,6 +12,7 @@ import { Render, PackageManagers, Stream, + WranglerConfig } from "~/components"; ## New apps @@ -49,11 +50,9 @@ First, install [@opennextjs/cloudflare](https://www.npmjs.com/package/@opennextj npm install --save-dev @opennextjs/cloudflare ``` -### 2. Add a `wrangler.toml` file +### 2. Add a Wrangler file -Then, add a [`wrangler.toml`](/workers/wrangler/configuration/) file to the root directory of your Next.js app: - -import { WranglerConfig } from "~/components"; +Then, add a [`wrangler.toml / wrangler.json` file](/workers/wrangler/configuration/) to the root directory of your Next.js app: @@ -71,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. ::: -`wrangler.toml` is where you configure your Worker and define what resources it can access via [bindings](/workers/runtime-apis/bindings/). +You configure your Worker and define what resources it can access via [bindings](/workers/runtime-apis/bindings/) in the `wrangler.toml / wrangler.json` file. ### 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 0356e21b0ef5efd..0f27ef2688fe997 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.toml`: Your [Wrangler](/workers/wrangler/configuration/#sample-wrangler-configuration) configuration file. +* `wrangler.json`: 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.toml` [See sample Wrangler configuration](/workers/wrangler/configuration/#sample-wrangler-configuration) -- `src/` containing a worker script referenced from `wrangler.toml` +- `wrangler.json` [See sample Wrangler configuration](/workers/wrangler/configuration/#sample-wrangler-configuration) +- `src/` containing a worker script referenced from `wrangler.json`
diff --git a/src/content/docs/workers/languages/python/ffi.mdx b/src/content/docs/workers/languages/python/ffi.mdx index fc0683958a47a12..cae76aaaded497f 100644 --- a/src/content/docs/workers/languages/python/ffi.mdx +++ b/src/content/docs/workers/languages/python/ffi.mdx @@ -8,6 +8,8 @@ head: --- +import { WranglerConfig } from "~/components"; + Via [Pyodide](https://pyodide.org/en/stable/), Python Workers provide a [Foreign Function Interface (FFI)](https://en.wikipedia.org/wiki/Foreign_function_interface) to JavaScript. This allows you to: * Use [bindings](/workers/runtime-apis/bindings/) to resources on Cloudflare, including [Workers AI](/workers-ai/), [Vectorize](/vectorize/), [R2](/r2/), [KV](/kv/), [D1](/d1/), [Queues](/queues/), [Durable Objects](/durable-objects/), [Service Bindings](/workers/runtime-apis/bindings/service-bindings/) and more. @@ -20,9 +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`](/workers/wrangler/configuration/): - -import { WranglerConfig } from "~/components"; +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/): 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 0a895058ab5c34c..43b2a786fc6aec3 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 @@ -9,7 +9,7 @@ head: --- -import { Render } from "~/components" +import { Render, WranglerConfig } from "~/components" Workers written in Python are executed by [Pyodide](https://pyodide.org/en/stable/index.html). Pyodide is a port of [CPython](https://github.com/python) (the reference implementation of Python — commonly referred to as just "Python") to WebAssembly. @@ -24,9 +24,7 @@ async def on_fetch(request, env): return Response.new("Hello world!") ``` -…with a wrangler.toml file that points to a .py file: - -import { WranglerConfig } from "~/components"; +…with a `wrangler.toml / wrangler.json` file 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 8f062f87a4f7b3f..e16aa3a196f9d47 100644 --- a/src/content/docs/workers/languages/python/index.mdx +++ b/src/content/docs/workers/languages/python/index.mdx @@ -11,6 +11,8 @@ head: description: Write Workers in 100% Python --- +import { WranglerConfig } from "~/components"; + Cloudflare Workers provides first-class support for Python, including support for: - The majority of Python's [Standard library](/workers/languages/python/stdlib/) @@ -121,10 +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's try setting and using an environment variable in a Python -Worker. First, add the environment variable to your Worker's `wrangler.toml`: - -import { WranglerConfig } from "~/components"; +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: diff --git a/src/content/docs/workers/languages/python/packages/index.mdx b/src/content/docs/workers/languages/python/packages/index.mdx index cc2200c9a3c6923..be355eb14c02b87 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` configuration file. +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. 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 5cfe41cd9aa704b..8ce5f9a98844d90 100644 --- a/src/content/docs/workers/languages/rust/index.mdx +++ b/src/content/docs/workers/languages/rust/index.mdx @@ -11,6 +11,8 @@ head: description: Write Workers in 100% Rust using the [`workers-rs` crate](https://github.com/cloudflare/workers-rs) --- +import { WranglerConfig } from "~/components"; + Cloudflare Workers provides support for Rust via the [`workers-rs` crate](https://github.com/cloudflare/workers-rs), which makes [Runtime APIs](/workers/runtime-apis) and [bindings](/workers/runtime-apis/bindings/) to developer platform products, such as [Workers KV](/kv/concepts/how-kv-works/), [R2](/r2/), and [Queues](/queues/), available directly from your Rust code. By following this guide, you will learn how to build a Worker entirely in the Rust programming language. @@ -44,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.toml` - Wrangler configuration, pre-populated with a custom build command to invoke `worker-build` (Refer to [Wrangler Bundling](/workers/languages/rust/#bundling-worker-build)). +- `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)). - `src` - Rust source directory, pre-populated with Hello World Worker. ## 2. Develop locally @@ -110,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.toml`. +- [`Var`](https://github.com/cloudflare/workers-rs/blob/e15f88110d814c2d7759b2368df688433f807694/worker/src/env.rs#L92) - Environment variable defined in `wrangler.json`. - [`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. @@ -206,14 +208,12 @@ 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 `wrangler.toml`. +`worker-build` is invoked by default in the template project using a custom build command specified in the `wrangler.toml / wrangler.json` file. ### Binary Size (`wasm-opt`) Unoptimized Rust Wasm binaries can be large and may exceed Worker bundle size limits or experience long startup times. The template project pre-configures several useful size optimizations in your `Cargo.toml` file: -import { WranglerConfig } from "~/components"; - ```toml diff --git a/src/content/docs/workers/languages/typescript/index.mdx b/src/content/docs/workers/languages/typescript/index.mdx index db05d1c0e236a5b..3e061693ea04fcd 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`, 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.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`. 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/observability/logs/logpush.mdx b/src/content/docs/workers/observability/logs/logpush.mdx index 1472b5baa1f50c9..0ab799f17042993 100644 --- a/src/content/docs/workers/observability/logs/logpush.mdx +++ b/src/content/docs/workers/observability/logs/logpush.mdx @@ -9,6 +9,8 @@ sidebar: --- +import { WranglerConfig } from "~/components"; + [Cloudflare Logpush](/logs/about/) supports the ability to send [Workers Trace Event Logs](/logs/reference/log-fields/account/workers_trace_events/) to a [supported destination](/logs/get-started/enable-destinations/). Worker’s Trace Events Logpush includes metadata about requests and responses, unstructured `console.log()` messages and any uncaught exceptions. This product is available on the Workers Paid plan. For pricing information, refer to [Pricing](/workers/platform/pricing/#workers-trace-events-logpush). :::caution @@ -73,9 +75,7 @@ In Logpush, you can configure [filters](/logs/reference/filters/) and a [samplin ## Enable logging on your Worker -Enable logging on your Worker by adding a new property, `logpush = true`, to your `wrangler.toml` file. This can be added either in the top-level configuration or under an [environment](/workers/wrangler/environments/). Any new Workers with this property will automatically get picked up by the Logpush job. - -import { WranglerConfig } from "~/components"; +Enable logging on your Worker by adding a new property, `logpush = true`, to your Wrangler file. This can be added either in the top-level configuration or under an [environment](/workers/wrangler/environments/). Any new Workers with this property will automatically get picked up by the Logpush job. diff --git a/src/content/docs/workers/observability/logs/tail-workers.mdx b/src/content/docs/workers/observability/logs/tail-workers.mdx index 4bc84300502b70e..fceb06aad8c0460 100644 --- a/src/content/docs/workers/observability/logs/tail-workers.mdx +++ b/src/content/docs/workers/observability/logs/tail-workers.mdx @@ -11,6 +11,8 @@ sidebar: --- +import { WranglerConfig } from "~/components"; + A Tail Worker receives information about the execution of other Workers (known as producer Workers), such as HTTP statuses, data passed to `console.log()` or uncaught exceptions. Tail Workers can process logs for alerts, debugging, or analytics. Tail Workers are available to all customers on the Workers Paid and Enterprise tiers. Tail Workers are billed by [CPU time](/workers/platform/pricing/#workers), not by the number of requests. @@ -83,9 +85,7 @@ The following Worker code is an example of what the `events` object may look lik ] ``` -3. Add the following to the `wrangler.toml` file of the producer Worker: - -import { WranglerConfig } from "~/components"; +3. Add the following to the Wrangler file of the producer Worker: diff --git a/src/content/docs/workers/observability/logs/workers-logs.mdx b/src/content/docs/workers/observability/logs/workers-logs.mdx index 80c5558f5961b6a..a8f6fb07c48aeba 100644 --- a/src/content/docs/workers/observability/logs/workers-logs.mdx +++ b/src/content/docs/workers/observability/logs/workers-logs.mdx @@ -27,7 +27,7 @@ To send logs to a third party, use [Workers Logpush](/workers/observability/logs Minimum required Wrangler version: 3.78.6. Check your version by running `wrangler version`. To update Wrangler, refer to [Install/Update Wrangler](/workers/wrangler/install-and-update/). ::: -You must add the observability setting for your Worker to write logs to Workers Logs. Add the following setting to your Worker's `wrangler.toml` file and redeploy your Worker. +You must add the observability setting for your Worker to write logs to Workers Logs. Add the following setting to your Worker's Wrangler file and redeploy your Worker. diff --git a/src/content/docs/workers/observability/source-maps.mdx b/src/content/docs/workers/observability/source-maps.mdx index 28f4c96d86da2b2..c710a010c48e1c6 100644 --- a/src/content/docs/workers/observability/source-maps.mdx +++ b/src/content/docs/workers/observability/source-maps.mdx @@ -9,7 +9,7 @@ sidebar: --- -import { Render } from "~/components" +import { Render, WranglerConfig } from "~/components" @@ -23,9 +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.toml`](/workers/wrangler/configuration/) file: - -import { WranglerConfig } from "~/components"; +To enable source maps, add the following to your Worker's [Wrangler configuration](/workers/wrangler/configuration/) file: diff --git a/src/content/docs/workers/platform/pricing.mdx b/src/content/docs/workers/platform/pricing.mdx index b264a22bd1d60f9..728c3bb1c245d55 100644 --- a/src/content/docs/workers/platform/pricing.mdx +++ b/src/content/docs/workers/platform/pricing.mdx @@ -93,7 +93,7 @@ A high traffic Worker that serves 100 million requests per month, and uses an av :::note[Custom limits] -To prevent accidental runaway bills or denial-of-wallet attacks, configure the maximum amount of CPU time that can be used per invocation by [defining limits in your Worker's `wrangler.toml` file](/workers/wrangler/configuration/#limits), or via the Cloudflare dashboard (Workers & Pages > Select your Worker > Settings > CPU Limits). +To prevent accidental runaway bills or denial-of-wallet attacks, configure the maximum amount of CPU time that can be used per invocation by [defining limits in your Worker's Wrangler file](/workers/wrangler/configuration/#limits), or via the Cloudflare dashboard (**Workers & Pages** > Select your Worker > **Settings** > **CPU Limits**). If you had a Worker on the Bundled usage model prior to the migration to Standard pricing on March 1, 2024, Cloudflare has automatically added a 50 ms CPU limit on your Worker. 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 ab7f176c368c2e5..981542bcf8997e1 100644 --- a/src/content/docs/workers/reference/migrate-to-module-workers.mdx +++ b/src/content/docs/workers/reference/migrate-to-module-workers.mdx @@ -6,6 +6,8 @@ description: Write your Worker code in ES modules syntax for an optimized experi --- +import { WranglerConfig } from "~/components"; + This guide will show you how to migrate your Workers from the [Service Worker](https://developer.mozilla.org/en-US/docs/Web/API/Service_Worker_API) format to the [ES modules](https://blog.cloudflare.com/workers-javascript-modules/) format. ## Advantages of migrating @@ -63,9 +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` configuration file and add a KV namespace binding: - -import { WranglerConfig } from "~/components"; +3. Find your Worker's `wrangler.toml / wrangler.json` file and add a KV namespace binding: @@ -141,9 +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 `wrangler.toml`: - - +Review the following example environment variable configuration in the `wrangler.toml / wrangler.json` file: diff --git a/src/content/docs/workers/runtime-apis/bindings/index.mdx b/src/content/docs/workers/runtime-apis/bindings/index.mdx index 2dba2a391786a51..bea8670fd9eac77 100644 --- a/src/content/docs/workers/runtime-apis/bindings/index.mdx +++ b/src/content/docs/workers/runtime-apis/bindings/index.mdx @@ -6,7 +6,7 @@ description: Worker Bindings that allow for interaction with other Cloudflare Re --- -import { DirectoryListing } from "~/components" +import { DirectoryListing, WranglerConfig } from "~/components" Bindings allow your Worker to interact with resources on the Cloudflare Developer Platform. @@ -18,8 +18,6 @@ The following bindings available today: 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: -import { WranglerConfig } from "~/components"; - ```toml diff --git a/src/content/docs/workers/runtime-apis/bindings/mTLS.mdx b/src/content/docs/workers/runtime-apis/bindings/mTLS.mdx index 1677d1ce146bba5..57261b9f6c5454b 100644 --- a/src/content/docs/workers/runtime-apis/bindings/mTLS.mdx +++ b/src/content/docs/workers/runtime-apis/bindings/mTLS.mdx @@ -6,13 +6,13 @@ description: Configure your Worker to present a client certificate to services that enforce an mTLS connection. --- -import { TabItem, Tabs } from "~/components"; +import { TabItem, Tabs, WranglerConfig } from "~/components"; When using [HTTPS](https://www.cloudflare.com/learning/ssl/what-is-https/), a server presents a certificate for the client to authenticate in order to prove their identity. For even tighter security, some services require that the client also present a certificate. This process - known as [mTLS](https://www.cloudflare.com/learning/access-management/what-is-mutual-tls/) - moves authentication to the protocol of TLS, rather than managing it in application code. Connections from unauthorized clients are rejected during the TLS handshake instead. -To present a client certificate when communicating with a service, create a mTLS certificate [binding](/workers/runtime-apis/bindings/) in your Worker project's `wrangler.toml` file. This will allow your Worker to present a client certificate to a service on your behalf. +To present a client certificate when communicating with a service, create a mTLS certificate [binding](/workers/runtime-apis/bindings/) in your Worker project's Wrangler file. This will allow your Worker to present a client certificate to a service on your behalf. :::caution @@ -31,9 +31,7 @@ The `wrangler mtls-certificate upload` command requires the [SSL and Certificate npx wrangler mtls-certificate upload --cert cert.pem --key key.pem --name my-client-cert ``` -Then, update your Worker project's `wrangler.toml` file to create an mTLS certificate binding: - -import { WranglerConfig } from "~/components"; +Then, update your Worker project's Wrangler file to create an mTLS certificate binding: diff --git a/src/content/docs/workers/runtime-apis/bindings/rate-limit.mdx b/src/content/docs/workers/runtime-apis/bindings/rate-limit.mdx index 9e9cf821e4be462..17f854aa1192099 100644 --- a/src/content/docs/workers/runtime-apis/bindings/rate-limit.mdx +++ b/src/content/docs/workers/runtime-apis/bindings/rate-limit.mdx @@ -9,7 +9,7 @@ sidebar: --- -import { TabItem, Tabs } from "~/components" +import { TabItem, Tabs, WranglerConfig } from "~/components" The Rate Limiting API lets you define rate limits and write code around them in your Worker. @@ -36,8 +36,6 @@ We want your feedback. Tell us what you'd like to see in the [#workers-discussio First, add a [binding](/workers/runtime-apis/bindings) to your Worker that gives it access to the Rate Limiting API: -import { WranglerConfig } from "~/components"; - ```toml diff --git a/src/content/docs/workers/runtime-apis/bindings/service-bindings/http.mdx b/src/content/docs/workers/runtime-apis/bindings/service-bindings/http.mdx index 62cce30a3526fb0..407a241931f0ce7 100644 --- a/src/content/docs/workers/runtime-apis/bindings/service-bindings/http.mdx +++ b/src/content/docs/workers/runtime-apis/bindings/service-bindings/http.mdx @@ -8,12 +8,12 @@ description: Facilitate Worker-to-Worker communication by forwarding Request obj --- +import { WranglerConfig } from "~/components"; + Worker A that declares a Service binding to Worker B can forward a [`Request`](/workers/runtime-apis/request/) object to Worker B, by calling the `fetch()` method that is exposed on the binding object. For example, consider the following Worker that implements a [`fetch()` handler](/workers/runtime-apis/handlers/fetch/): -import { WranglerConfig } from "~/components"; - ```toml 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 34cb96e76f820ec..0adf12fae27e4fc 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 @@ -8,6 +8,8 @@ description: Facilitate Worker-to-Worker communication. --- +import { WranglerConfig } from "~/components"; + ## About Service bindings [Service bindings](/workers/runtime-apis/bindings/service-bindings/) allow one worker to call into another, without going through a publicly-accessible URL. A Service binding allows Worker A to call a method on Worker B, or to forward a request from Worker A to Worker B. @@ -28,11 +30,9 @@ Service bindings are commonly used to: ## Configuration -You add a Service binding by modifying the `wrangler.toml` of the caller — the Worker that you want to be able to initiate requests. +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. -For example, if you want Worker A to be able to call Worker B — you'd add the following to the `wrangler.toml` for Worker A: - -import { WranglerConfig } from "~/components"; +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: @@ -128,7 +128,7 @@ Your worker has access to the following bindings: - ANOTHER_WORKER: another-worker [not connected] ``` -Wrangler also supports running multiple Workers at once with one command. To try it out, pass multiple `-c` flags to Wrangler, like this: `wrangler dev -c wrangler.toml -c ../other-worker/wrangler.toml`. The first config will be treated as the _primary_ worker, which will be exposed over HTTP as usual at `http://localhost:8787`. The remaining config files will be treated as _secondary_ and will only be accessible via a service binding from the primary worker. +Wrangler also supports running multiple Workers at once with one command. To try it out, pass multiple `-c` flags to Wrangler, like this: `wrangler dev -c wrangler.json -c ../other-worker/wrangler.json`. The first config will be treated as the _primary_ worker, which will be exposed over HTTP as usual at `http://localhost:8787`. The remaining config files will be treated as _secondary_ and will only be accessible via a service binding from the primary worker. :::caution diff --git a/src/content/docs/workers/runtime-apis/bindings/service-bindings/rpc.mdx b/src/content/docs/workers/runtime-apis/bindings/service-bindings/rpc.mdx index ba34c3c6e086230..cb5e29f610183d1 100644 --- a/src/content/docs/workers/runtime-apis/bindings/service-bindings/rpc.mdx +++ b/src/content/docs/workers/runtime-apis/bindings/service-bindings/rpc.mdx @@ -8,7 +8,7 @@ description: Facilitate Worker-to-Worker communication via RPC. --- -import { DirectoryListing, Render } from "~/components" +import { DirectoryListing, Render, WranglerConfig } from "~/components" [Service bindings](/workers/runtime-apis/bindings/service-bindings) allow one Worker to call into another, without going through a publicly-accessible URL. @@ -49,8 +49,6 @@ The [`env`](/workers/runtime-apis/bindings) object is exposed as a class propert For example, a Worker that declares a binding to the [environment variable](/workers/configuration/environment-variables/) `GREETING`: -import { WranglerConfig } from "~/components"; - ```toml diff --git a/src/content/docs/workers/runtime-apis/bindings/version-metadata.mdx b/src/content/docs/workers/runtime-apis/bindings/version-metadata.mdx index a667aa7ef9fff84..1b0d8b4f6fdd6b6 100644 --- a/src/content/docs/workers/runtime-apis/bindings/version-metadata.mdx +++ b/src/content/docs/workers/runtime-apis/bindings/version-metadata.mdx @@ -13,15 +13,13 @@ sidebar: --- -import { TabItem, Tabs } from "~/components" +import { TabItem, Tabs, WranglerConfig } from "~/components" The version metadata binding can be used to access metadata associated with a [version](/workers/configuration/versions-and-deployments/#versions) from inside the Workers runtime. Worker version ID, version tag and timestamp of when the version was created are available through the version metadata binding. They can be used in events sent to [Workers Analytics Engine](/analytics/analytics-engine/) or to any third-party analytics/metrics service in order to aggregate by Worker version. -To use the version metadata binding, update your Worker's `wrangler.toml` file: - -import { WranglerConfig } from "~/components"; +To use the version metadata binding, update your Worker's Wrangler file: diff --git a/src/content/docs/workers/runtime-apis/nodejs/index.mdx b/src/content/docs/workers/runtime-apis/nodejs/index.mdx index 11ddfcf217e7bb1..c935e4eba65820c 100644 --- a/src/content/docs/workers/runtime-apis/nodejs/index.mdx +++ b/src/content/docs/workers/runtime-apis/nodejs/index.mdx @@ -5,7 +5,7 @@ head: [] description: Node.js APIs available in Cloudflare Workers --- -import { DirectoryListing } from "~/components"; +import { DirectoryListing, WranglerConfig } from "~/components"; When you write a Worker, you may need to import packages from [npm](https://www.npmjs.com/). Many npm packages rely on APIs from the [Node.js runtime](https://nodejs.org/en/about), and will not work unless these Node.js APIs are available. @@ -55,8 +55,6 @@ If an API you wish to use is missing and you want to suggest that Workers suppor To enable only the Node.js `AsyncLocalStorage` API, use the `nodejs_als` compatibility flag. -import { WranglerConfig } from "~/components"; - ```toml diff --git a/src/content/docs/workers/runtime-apis/rpc/index.mdx b/src/content/docs/workers/runtime-apis/rpc/index.mdx index 3d7f1a6be71f294..eb597955f835931 100644 --- a/src/content/docs/workers/runtime-apis/rpc/index.mdx +++ b/src/content/docs/workers/runtime-apis/rpc/index.mdx @@ -7,7 +7,7 @@ description: The built-in, JavaScript-native RPC system built into Workers and --- -import { DirectoryListing, Render, Stream } from "~/components" +import { DirectoryListing, Render, Stream, WranglerConfig } from "~/components" :::note To use RPC, [define a compatibility date](/workers/configuration/compatibility-dates) of `2024-04-03` or higher, or include `rpc` in your [compatibility flags](/workers/configuration/compatibility-flags/#nodejs-compatibility-flag). @@ -68,8 +68,6 @@ To use an instance of a class that you define as a parameter or return value of Consider the following example: -import { WranglerConfig } from "~/components"; - ```toml diff --git a/src/content/docs/workers/runtime-apis/webassembly/javascript.mdx b/src/content/docs/workers/runtime-apis/webassembly/javascript.mdx index d8ad8e0697cfd5d..c91dc4f5728cdc6 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 `wrangler.toml`. 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.toml / wrangler.json` file. Refer to [Wrangler Bundling](/workers/wrangler/bundling/) for more information. ## Use from JavaScript diff --git a/src/content/docs/workers/static-assets/binding.mdx b/src/content/docs/workers/static-assets/binding.mdx index 3c6855147c4c7c1..38c47b44b0f768a 100644 --- a/src/content/docs/workers/static-assets/binding.mdx +++ b/src/content/docs/workers/static-assets/binding.mdx @@ -15,11 +15,10 @@ import { Render, TabItem, Tabs, + WranglerConfig } from "~/components"; -import { WranglerConfig } from "~/components"; - -Configuring a Worker with assets requires specifying a [directory](/workers/static-assets/binding/#directory) and, optionally, an [assets binding](/workers/static-assets/binding/), in your Worker's `wrangler.toml` file. The [assets binding](/workers/static-assets/binding/) allows you to dynamically fetch assets from within your Worker script (e.g. `env.ASSETS.fetch()`), similarly to how you might with a make a `fetch()` call with a [Service binding](/workers/runtime-apis/bindings/service-bindings/http/). +Configuring a Worker with assets requires specifying a [directory](/workers/static-assets/binding/#directory) and, optionally, an [assets binding](/workers/static-assets/binding/), in your Worker's Wrangler file. The [assets binding](/workers/static-assets/binding/) allows you to dynamically fetch assets from within your Worker script (e.g. `env.ASSETS.fetch()`), similarly to how you might with a make a `fetch()` call with a [Service binding](/workers/runtime-apis/bindings/service-bindings/http/). Only one collection of static assets can be configured in each Worker. diff --git a/src/content/docs/workers/static-assets/routing.mdx b/src/content/docs/workers/static-assets/routing.mdx index 75944034736f8fe..37c2bdb2435c1e0 100644 --- a/src/content/docs/workers/static-assets/routing.mdx +++ b/src/content/docs/workers/static-assets/routing.mdx @@ -15,10 +15,9 @@ import { Render, TabItem, Tabs, + WranglerConfig } from "~/components"; -import { WranglerConfig } from "~/components"; - ## Default behavior By default, assets are served by attempting to match up the incoming request's pathname to a static asset. The structure and organization of files in your static asset directory, along with any routing configuration, determine the routing paths for your application. When a request invokes a Worker with assets: @@ -39,13 +38,13 @@ 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. [`experimental_serve_directly`](/workers/static-assets/binding/#experimental_serve_directly) is a configuration option available in `wrangler.toml` which controls this behavior. When disabled, `experimental_serve_directly = false` 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. [`experimental_serve_directly`](/workers/static-assets/binding/#experimental_serve_directly) is a configuration option available in the `wrangler.toml / wrangler.json` file which controls this behavior. When disabled, `experimental_serve_directly = false` will invoke your Worker's code, regardless of any assets that would have otherwise matched. -Take the following directory structure, wrangler.toml, and user Worker code: +Take the following directory structure, `wrangler.toml / wrangler.json` file, and user Worker code: -- wrangler.toml +- wrangler.json - package.json - public - supersecret.txt @@ -95,7 +94,7 @@ In this example, any request will be routed to our user Worker, due to `experime ## Routing configuration -There are two options for asset serving that can be [configured in `wrangler.toml`](/workers/wrangler/configuration/#assets): +There are two options for asset serving that can be [configured in the `wrangler.toml / wrangler.json` file](/workers/wrangler/configuration/#assets): #### 1. `html_handling` @@ -157,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`](/workers/wrangler/configuration/#assets) file. 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.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. -Example `wrangler.toml` configuration: +Example `wrangler.toml / wrangler.json` file: @@ -304,7 +303,7 @@ For example, to serve assets from `example.com/blog/*`, create a `blog` director - post2.html -With a Wrangler configuration file like so: +With a `wrangler.toml / wrangler.json` file like so: ```toml diff --git a/src/content/docs/workers/testing/index.mdx b/src/content/docs/workers/testing/index.mdx index 4ede7ed43eceb8f..559425debea07e7 100644 --- a/src/content/docs/workers/testing/index.mdx +++ b/src/content/docs/workers/testing/index.mdx @@ -13,19 +13,19 @@ Review the tools available for testing and debugging Workers. ## Testing comparison matrix -| Feature | Vitest Pool | `unstable_dev()` | Miniflare's API | -| ----------------------------------------- | ----------- | ---------------- | --------------- | -| Unit testing | ✅ | ❌ | ❌ | -| Integration testing | ✅ | ✅ | ✅ | -| Loading Wrangler configuration files | ✅ | ✅ | ❌ | -| Bindings directly in tests | ✅ | ❌ | ✅ | -| Isolated per-test storage | ✅ | ❌ | ❌ | -| Outbound request mocking | ✅ | ❌ | ✅ | -| Multiple Worker support | ✅ | 🚧[^1] | ✅ | -| Direct access to Durable Objects | ✅ | ❌ | ❌ | -| Run Durable Object alarms immediately | ✅ | ❌ | ❌ | -| List Durable Objects | ✅ | ❌ | ❌ | -| Testing service Workers | ❌ | ✅ | ✅ | +| Feature | Vitest Pool | `unstable_dev()` | Miniflare's API | +| ----------------------------------------------- | ----------- | ---------------- | --------------- | +| Unit testing | ✅ | ❌ | ❌ | +| Integration testing | ✅ | ✅ | ✅ | +| Loading `wrangler.toml / wrangler.json` files | ✅ | ✅ | ❌ | +| Bindings directly in tests | ✅ | ❌ | ✅ | +| Isolated per-test storage | ✅ | ❌ | ❌ | +| Outbound request mocking | ✅ | ❌ | ✅ | +| Multiple Worker support | ✅ | 🚧[^1] | ✅ | +| Direct access to Durable Objects | ✅ | ❌ | ❌ | +| Run Durable Object alarms immediately | ✅ | ❌ | ❌ | +| List Durable Objects | ✅ | ❌ | ❌ | +| Testing service Workers | ❌ | ✅ | ✅ | [^1]: Support for multiple Workers in [`unstable_dev()`](/workers/wrangler/api/#unstable_dev) relies on `wrangler dev`'s service registry which can be unreliable when running multiple tests in parallel. diff --git a/src/content/docs/workers/testing/integration-testing.mdx b/src/content/docs/workers/testing/integration-testing.mdx index a23e47eed47fa78..4a7675c568df83a 100644 --- a/src/content/docs/workers/testing/integration-testing.mdx +++ b/src/content/docs/workers/testing/integration-testing.mdx @@ -76,7 +76,7 @@ it("dispatches fetch event", async () => { Instead of running the Worker-under-test in the same Worker as the test runner like `SELF`, this example defines the Worker-under-test as an _auxiliary_ Worker. This means the Worker runs in a separate isolate to the test runner, with a different global scope. The Worker-under-test runs in an environment closer to production, but Vite transformations and hot-module-reloading aren't applied to the Worker—you must compile your TypeScript to JavaScript beforehand. -Auxiliary Workers cannot be configured from `wrangler.toml` files. You must use Miniflare [`WorkerOptions`](https://github.com/cloudflare/workers-sdk/tree/main/packages/miniflare#interface-workeroptions) in `vitest.config.ts`. +Auxiliary Workers cannot be configured from Wrangler files. You must use Miniflare [`WorkerOptions`](https://github.com/cloudflare/workers-sdk/tree/main/packages/miniflare#interface-workeroptions) in `vitest.config.ts`. :::note @@ -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 configuration 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.toml / wrangler.json` file. 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 configuration 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.toml / wrangler.json` file. ```js import assert from "node:assert"; diff --git a/src/content/docs/workers/testing/local-development.mdx b/src/content/docs/workers/testing/local-development.mdx index 0ad894cf04cab47..00e608b7c078201 100644 --- a/src/content/docs/workers/testing/local-development.mdx +++ b/src/content/docs/workers/testing/local-development.mdx @@ -60,9 +60,9 @@ With any bindings that are not supported locally, you will need to use the `--re When running `wrangler dev`, resources such as KV, Durable Objects, D1, and R2 will be stored and persisted locally and not affect the production resources. -### Use bindings in `wrangler.toml` +### Use bindings in Wrangler configuration files -[Wrangler](/workers/wrangler/) will automatically create local versions of bindings found in the `wrangler.toml` [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](/workers/testing/local-development/#use---local-flag). +[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](/workers/testing/local-development/#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 `wrangler.toml`. 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.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. ### 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 `wrangler.toml` 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.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. ```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 `wrangler.toml` 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.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. ## Customize `wrangler dev` diff --git a/src/content/docs/workers/testing/vitest-integration/configuration.mdx b/src/content/docs/workers/testing/vitest-integration/configuration.mdx index ad10d50a6e38bb9..9ad1971fdc887e1 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 configuration 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.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. * 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 configuration 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.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. * 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-miniflare-2.mdx b/src/content/docs/workers/testing/vitest-integration/get-started/migrate-from-miniflare-2.mdx index 3d1792271e0732f..875a0fcfc212b21 100644 --- a/src/content/docs/workers/testing/vitest-integration/get-started/migrate-from-miniflare-2.mdx +++ b/src/content/docs/workers/testing/vitest-integration/get-started/migrate-from-miniflare-2.mdx @@ -36,7 +36,7 @@ npm install --save-dev @cloudflare/vitest-pool-workers ## Update your Vitest configuration file -After installing the Workers Vitest configuration, update your Vitest configuration file to use the pool instead. Most Miniflare configuration previously specified `environmentOptions` can be moved to `poolOptions.workers.miniflare` instead. Refer to [Miniflare's `WorkerOptions` interface](https://github.com/cloudflare/workers-sdk/blob/main/packages/miniflare/README.md#interface-workeroptions) for supported options and the [Miniflare version 2 to 3 migration guide](https://miniflare.dev/get-started/migrating#api-changes) for more information. If you relied on configuration stored in a `wrangler.toml` file, set `wrangler.configPath` too. +After installing the Workers Vitest configuration, update your Vitest configuration file to use the pool instead. Most Miniflare configuration previously specified `environmentOptions` can be moved to `poolOptions.workers.miniflare` instead. Refer to [Miniflare's `WorkerOptions` interface](https://github.com/cloudflare/workers-sdk/blob/main/packages/miniflare/README.md#interface-workeroptions) for supported options and the [Miniflare version 2 to 3 migration guide](https://miniflare.dev/get-started/migrating#api-changes) for more information. If you relied on configuration stored in a Wrangler file, set `wrangler.configPath` too. ```diff + import { defineWorkersConfig } from "@cloudflare/vitest-pool-workers/config"; 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 9895f441c18d6ea..48932cd85249c9e 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`. 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.toml / wrangler.json` file. 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` configuration file by adding it as an option: +Via the `unstable_dev` API, you can reference a `wrangler.toml / wrangler.json` file by adding it as an option: ```js await unstable_dev("src/index.ts", { 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 4914465a5aa2ae9..3a14774726ad460 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` configuration file, define a [compatibility date](/workers/configuration/compatibility-dates/) of `2022-10-31` or higher, and include `nodejs_compat` in your [compatibility flags](/workers/wrangler/configuration/#use-runtime-apis-directly). +- 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/wrangler/configuration/#use-runtime-apis-directly). ## Install Vitest and `@cloudflare/vitest-pool-workers` @@ -39,7 +39,7 @@ Currently, the `@cloudflare/vitest-pool-workers` package _only_ works with Vites ## Define Vitest configuration If you do not already have a `vitest.config.js` or `vitest.config.ts` file, you will need to create one and define the following configuration. -You can reference a `wrangler.toml` file to leverage its `main` entry point, [compatibility settings](/workers/configuration/compatibility-dates/), and [bindings](/workers/runtime-apis/bindings/). +You can reference a Wrangler file to leverage its `main` entry point, [compatibility settings](/workers/configuration/compatibility-dates/), and [bindings](/workers/runtime-apis/bindings/). ```js import { defineWorkersConfig } from "@cloudflare/vitest-pool-workers/config"; 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 197869ca1b676e0..d749c538b2e914c 100644 --- a/src/content/docs/workers/tutorials/automated-analytics-reporting/index.mdx +++ b/src/content/docs/workers/tutorials/automated-analytics-reporting/index.mdx @@ -16,8 +16,7 @@ languages: - JavaScript --- -import { Render, PackageManagers } from "~/components"; -import { TabItem, Tabs } from "~/components"; +import { Render, PackageManagers, TabItem, Tabs, WranglerConfig } from "~/components"; In this tutorial, you will create a [Cloudflare Worker](https://workers.cloudflare.com/) that fetches analytics data about your account from Cloudflare's [GraphQL Analytics API](https://developers.cloudflare.com/analytics/graphql-api/). You will be able to view the account analytics data in your browser and receive a scheduled email report. @@ -93,10 +92,11 @@ yarn add mimetext -## 2. Update wrangler.toml file +## 2. Update Wrangler configuration file -[`wrangler.toml`](https://developers.cloudflare.com/workers/wrangler/configuration/) is the configuration file for your Worker. It was created when you ran `c3` CLI. Open `wrangler.toml` in your code editor and update it with the following configuration: +[`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: + ```toml name = "account-analytics" main = "src/index.js" @@ -130,6 +130,7 @@ RECIPIENT_EMAIL = "<>" # This value will be used as the subject of the email EMAIL_SUBJECT = "Cloudflare Analytics Report" ``` + Before you continue, update the following: @@ -408,7 +409,7 @@ async function sendEmail(env, content) { This function sends an email with the formatted analytics data to the specified recipient email address using Cloudflare's Email Routing service. :::note -`sendEmail` function uses multiple environment variables that are set in the `wrangler.toml` file. +`sendEmail` function uses multiple environment variables that are set in the Wrangler file. ::: ## 4. Test the Worker 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 fe7fa2b677b6b43..6a26c677f32cf11 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 @@ -10,7 +10,7 @@ languages: - JavaScript --- -import { Render, PackageManagers } from "~/components"; +import { Render, PackageManagers, WranglerConfig } from "~/components"; In this tutorial, you will build a todo list application using HTML, CSS, and JavaScript. The application data will be stored in [Workers KV](/kv/api/). @@ -87,9 +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`, define a `kv_namespaces` key to set up your namespace: - -import { WranglerConfig } from "~/components"; +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: 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 0a81709ac834bb5..66d9d917fa0c022 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 @@ -9,7 +9,7 @@ languages: - SQL --- -import { Render, PackageManagers } from "~/components"; +import { Render, PackageManagers, WranglerConfig } from "~/components"; This tutorial will guide you on how to build globally distributed applications with Cloudflare Workers, and [Turso](https://chiselstrike.com/), an edge-hosted distributed database based on libSQL. By using Workers and Turso, you can create applications that are close to your end users without having to maintain or operate infrastructure in tens or hundreds of regions. @@ -130,12 +130,12 @@ cd worker-turso-ts In your project directory, you now have the following files: -- `wrangler.toml`: Your Wrangler configuration file. +- `wrangler.json`: your `wrangler.toml / wrangler.json` file. - `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` and `src/index.ts` files are relevant. You will not need to edit the other files, and they should be left as is. +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. ## Configure your Worker for your Turso database @@ -154,9 +154,7 @@ turso db show my-db --url libsql://my-db-.turso.io ``` -Open `wrangler.toml` 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: - -import { WranglerConfig } from "~/components"; +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: @@ -167,7 +165,7 @@ LIBSQL_DB_URL = "paste-your-url-here" -Save the changes to `wrangler.toml`. +Save the changes to the `wrangler.toml / wrangler.json` file. 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: @@ -359,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 `wrangler.toml`. +- You have entered the correct value for your `LIBSQL_DB_URL` in the `wrangler.toml / wrangler.json` file. - 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/create-finetuned-chatgpt-ai-models-with-r2/index.mdx b/src/content/docs/workers/tutorials/create-finetuned-chatgpt-ai-models-with-r2/index.mdx index 7634b2188d9a3b8..0cbff4a9d1729ed 100644 --- a/src/content/docs/workers/tutorials/create-finetuned-chatgpt-ai-models-with-r2/index.mdx +++ b/src/content/docs/workers/tutorials/create-finetuned-chatgpt-ai-models-with-r2/index.mdx @@ -15,7 +15,7 @@ sidebar: order: 1 --- -import { Render, PackageManagers } from "~/components"; +import { Render, PackageManagers, WranglerConfig } from "~/components"; In this tutorial, you will use the [OpenAI](https://openai.com) API and [Cloudflare R2](/r2) to create a [fine-tuned model](https://platform.openai.com/docs/guides/fine-tuning). @@ -91,9 +91,7 @@ npx wrangler r2 object put -f A binding is how your Worker interacts with external resources such as the R2 bucket. -To bind the R2 bucket to your Worker, add the following to your `wrangler.toml` file. Update the binding property to a valid JavaScript variable identifier. Replace `` with the name of the bucket you created in [step 2](#2-upload-a-fine-tune-document-to-r2): - -import { WranglerConfig } from "~/components"; +To bind the R2 bucket to your Worker, add the following to your Wrangler file. Update the binding property to a valid JavaScript variable identifier. Replace `` with the name of the bucket you created in [step 2](#2-upload-a-fine-tune-document-to-r2): @@ -119,7 +117,7 @@ You also need to install the [OpenAI Node API library](https://www.npmjs.com/pac npm install openai ``` -Next, open the `src/index.ts` file and replace the default code with the below code. Replace `` with the binding name you set in `wrangler.toml` file. +Next, open the `src/index.ts` file and replace the default code with the below code. Replace `` with the binding name you set in Wrangler file. ```typescript import { Context, Hono } from "hono"; @@ -161,7 +159,7 @@ In `createFile`, your Worker reads the file from R2 and converts it to a `File` The `GET /files` route listens for `GET` requests with a query parameter `file`, representing a filename of an uploaded fine-tune document in R2. The function uses the `createFile` function to manage the file upload process. -Replace `` with the binding name you set in `wrangler.toml` file. +Replace `` with the binding name you set in Wrangler file. ```typescript // New import added at beginning of file 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 dc023bb0bf6ccf9..e6654391c484e99 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 @@ -10,7 +10,7 @@ languages: - JavaScript --- -import { Render } from "~/components"; +import { Render, WranglerConfig } from "~/components"; In this tutorial, you will deploy a serverless, real-time chat application that runs using [Durable Objects](/durable-objects/). @@ -48,11 +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`. +To deploy your application to a custom domain using Wrangler, open your project's `wrangler.toml / wrangler.json` file. -To configure a route in your `wrangler.toml`, add the following to your environment: - -import { WranglerConfig } from "~/components"; +To configure a route in your `wrangler.toml / wrangler.json` file, add the following to your environment: @@ -64,11 +62,9 @@ routes = [ -If you have specified your zone ID in the environment of your `wrangler.toml`, you will not need to write it again in object form. - -To configure a subdomain in your `wrangler.toml`, add the following to your environment: - +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. +To configure a subdomain in your `wrangler.toml / wrangler.json` file, add the following to your environment: @@ -89,7 +85,7 @@ To test your live application: ## Uninstall your application -To uninstall your chat application, modify your `wrangler.toml` file to remove the `durable_objects` bindings and add a `deleted_classes` migration: +To uninstall your chat application, modify your Wrangler file to remove the `durable_objects` bindings and add a `deleted_classes` migration: diff --git a/src/content/docs/workers/tutorials/generate-dynamic-og-images-using-workers/index.mdx b/src/content/docs/workers/tutorials/generate-dynamic-og-images-using-workers/index.mdx index b682418ded929ff..04295050121aa5a 100644 --- a/src/content/docs/workers/tutorials/generate-dynamic-og-images-using-workers/index.mdx +++ b/src/content/docs/workers/tutorials/generate-dynamic-og-images-using-workers/index.mdx @@ -18,7 +18,7 @@ spotlight: author_bio_source: GitHub --- -import { PackageManagers, Render, Tabs, TabItem } from "~/components"; +import { PackageManagers, Render, Tabs, TabItem, WranglerConfig } from "~/components"; Social media thrives on compelling visuals. With Cloudflare Workers, you can effortlessly generate dynamic Open Graph (OG) images that grab attention and boost platform performance. In this tutorial, you'll learn how to create a customizable OG image generator powered by serverless edge computing. Cloudflare Workers enable you to deliver blazing-fast visuals globally, ensuring a seamless experience for your users. Let's dive in to see how you can take your OG images to the next level with Cloudflare Workers. @@ -203,8 +203,9 @@ Key TypeScript configuration features: ### Configure Wrangler for runtime compatibility and static assets -Before starting, ensure your `wrangler.toml` includes these essential configurations: +Before starting, ensure your `wrangler.toml / wrangler.json` file includes these essential configurations: + ```toml title="wrangler.toml" compatibility_date = "2024-11-06" compatibility_flags = [ "nodejs_compat_v2" ] @@ -213,6 +214,7 @@ minify = true [build] watch_dir = "public" ``` + [The `nodejs_compat` flag](/workers/configuration/compatibility-flags/#nodejs-compatibility-flag) enables runtime compatibility features required by the OG image generation library, even when using Bun. While we're using Bun as our development runtime, this flag ensures all necessary APIs are available in the Workers environment. The `assets` configuration maps your Worker's public directory, allowing direct access to static files like fonts, images, and favicons through URL paths (for example, `/fonts/Inter.ttf`, `/images/logo.png`). diff --git a/src/content/docs/workers/tutorials/generate-youtube-thumbnails-with-workers-and-images/index.mdx b/src/content/docs/workers/tutorials/generate-youtube-thumbnails-with-workers-and-images/index.mdx index 48e62c09777b66c..d6a0bb12c47af6e 100644 --- a/src/content/docs/workers/tutorials/generate-youtube-thumbnails-with-workers-and-images/index.mdx +++ b/src/content/docs/workers/tutorials/generate-youtube-thumbnails-with-workers-and-images/index.mdx @@ -11,7 +11,7 @@ languages: - Rust --- -import { Render, PackageManagers } from "~/components"; +import { Render, PackageManagers, WranglerConfig } from "~/components"; In this tutorial, you will learn how to programmatically generate a custom YouTube thumbnail using Cloudflare Workers and Cloudflare Image Resizing. You may want to generate a custom YouTube thumbnail to customize the thumbnail's design, call-to-actions and images used to encourage more viewers to watch your video. @@ -335,9 +335,7 @@ Adding a query parameter with custom text, you should receive: ![Follow the instructions above to receive an output image](~/assets/images/workers/tutorials/youtube-thumbnails/build-serverles.png) -To deploy your Worker, open your `wrangler.toml` file and update the `name` key with your project's name. Below is an example with this tutorial's project name: - -import { WranglerConfig } from "~/components"; +To deploy your Worker, open your Wrangler file and update the `name` key with your project's name. Below is an example with this tutorial's project name: @@ -498,7 +496,7 @@ fetch(imageURL, { Image transformations can only be tested when you deploy your Worker. -To deploy your Worker, open your `wrangler.toml` file and update the `name` key with your project's name. Below is an example with this tutorial's project name: +To deploy your Worker, open your Wrangler file and update the `name` key with your project's name. Below is an example with this tutorial's project name: diff --git a/src/content/docs/workers/tutorials/github-sms-notifications-using-twilio/index.mdx b/src/content/docs/workers/tutorials/github-sms-notifications-using-twilio/index.mdx index cd617d5b4c086f0..afdd3b7af06c1b9 100644 --- a/src/content/docs/workers/tutorials/github-sms-notifications-using-twilio/index.mdx +++ b/src/content/docs/workers/tutorials/github-sms-notifications-using-twilio/index.mdx @@ -8,7 +8,7 @@ languages: - JavaScript --- -import { Render, PackageManagers } from "~/components"; +import { Render, PackageManagers, WranglerConfig } from "~/components"; In this tutorial, you will learn to build an SMS notification system on Workers to receive updates on a GitHub repository. Your Worker will send you a text update using Twilio when there is new activity on your repository. @@ -153,9 +153,7 @@ To make this work, you need to use [`wrangler secret put`](/workers/wrangler/com npx wrangler secret put GITHUB_SECRET_TOKEN ``` -Add the nodejs_compat flag to your `wrangler.toml` file: - -import { WranglerConfig } from "~/components"; +Add the nodejs_compat flag to your Wrangler file: diff --git a/src/content/docs/workers/tutorials/handle-form-submissions-with-airtable/index.mdx b/src/content/docs/workers/tutorials/handle-form-submissions-with-airtable/index.mdx index 8dfcb0a8a582f4f..af0239267989484 100644 --- a/src/content/docs/workers/tutorials/handle-form-submissions-with-airtable/index.mdx +++ b/src/content/docs/workers/tutorials/handle-form-submissions-with-airtable/index.mdx @@ -10,7 +10,7 @@ languages: - JavaScript --- -import { Render, PackageManagers } from "~/components"; +import { Render, PackageManagers, WranglerConfig } from "~/components"; In this tutorial, you will use [Cloudflare Workers](/workers/) and [Airtable](https://airtable.com) to persist form submissions from a front-end user interface. Airtable is a free-to-use spreadsheet solution that has an approachable API for developers. Workers will handle incoming form submissions and use Airtable's [REST API](https://airtable.com/api) to asynchronously persist the data in an Airtable base (Airtable's term for a spreadsheet) for later reference. @@ -234,11 +234,9 @@ async function createAirtableRecord(env, body) { // export default ... ``` -To make an authenticated request to Airtable, you need to provide four constants that represent data about your Airtable account, base, and table name. You have already set `AIRTABLE_ACCESS_TOKEN` using `wrangler secret`, since it is a value that should be encrypted. The **Airtable base ID** and **table name**, and `FORM_URL` are values that can be publicly shared in places like GitHub. Use Wrangler's [`vars`](/workers/wrangler/migration/v1-to-v2/wrangler-legacy/configuration/#vars) feature to pass public environment variables from your `wrangler.toml` file. +To make an authenticated request to Airtable, you need to provide four constants that represent data about your Airtable account, base, and table name. You have already set `AIRTABLE_ACCESS_TOKEN` using `wrangler secret`, since it is a value that should be encrypted. The **Airtable base ID** and **table name**, and `FORM_URL` are values that can be publicly shared in places like GitHub. Use Wrangler's [`vars`](/workers/wrangler/migration/v1-to-v2/wrangler-legacy/configuration/#vars) feature to pass public environment variables from your Wrangler file. -Add a `vars` table at the end of your `wrangler.toml` file: - -import { WranglerConfig } from "~/components"; +Add a `vars` table at the end of your Wrangler file: diff --git a/src/content/docs/workers/tutorials/live-cursors-with-nextjs-rpc-do/index.mdx b/src/content/docs/workers/tutorials/live-cursors-with-nextjs-rpc-do/index.mdx index 8342fd6e6ed99fd..d27595d4ba5969f 100644 --- a/src/content/docs/workers/tutorials/live-cursors-with-nextjs-rpc-do/index.mdx +++ b/src/content/docs/workers/tutorials/live-cursors-with-nextjs-rpc-do/index.mdx @@ -348,7 +348,7 @@ that will be made available to the Next.js Worker using a [`WorkerEntrypoint`](/ ## 4. Build Next.js Worker functionality -1. In your Next.js `wrangler.toml` file, declare the external Durable Object binding and the Service binding to `SessionsRPC`: +1. In your Next.js Wrangler file, declare the external Durable Object binding and the Service binding to `SessionsRPC`: ```toml title="next-rpc/wrangler.toml" ins={10-18} # ... rest of the configuration diff --git a/src/content/docs/workers/tutorials/postgres/index.mdx b/src/content/docs/workers/tutorials/postgres/index.mdx index 84053c1c725cfbf..e1ec2e65f713948 100644 --- a/src/content/docs/workers/tutorials/postgres/index.mdx +++ b/src/content/docs/workers/tutorials/postgres/index.mdx @@ -114,7 +114,7 @@ DB_URL="" ### Set explicit parameters -Configure each database parameter as an [environment variable](/workers/configuration/environment-variables/) via the [Cloudflare dashboard](/workers/configuration/environment-variables/#add-environment-variables-via-the-dashboard) or in your `wrangler.toml` file. Refer to an example of a`wrangler.toml` file configuration: +Configure each database parameter as an [environment variable](/workers/configuration/environment-variables/) via the [Cloudflare dashboard](/workers/configuration/environment-variables/#add-environment-variables-via-the-dashboard) or in your Wrangler file. Refer to an example of aWrangler file configuration: @@ -315,7 +315,7 @@ npx wrangler hyperdrive create --connection-string=" You can also use explicit parameters by following the [wrangler documentation for Hyperdrive](/workers/wrangler/commands/#r2-bucket-create). -This command outputs the Hyperdrive configuration `id` that will be used for your Hyperdrive [binding](/workers/runtime-apis/bindings/). Set up your binding by specifying the `id` in the `wrangler.toml` file. +This command outputs the Hyperdrive configuration `id` that will be used for your Hyperdrive [binding](/workers/runtime-apis/bindings/). Set up your binding by specifying the `id` in the Wrangler file. diff --git a/src/content/docs/workers/tutorials/store-data-with-fauna/index.mdx b/src/content/docs/workers/tutorials/store-data-with-fauna/index.mdx index fbbd5c8baf72547..1a66b1262383b94 100644 --- a/src/content/docs/workers/tutorials/store-data-with-fauna/index.mdx +++ b/src/content/docs/workers/tutorials/store-data-with-fauna/index.mdx @@ -10,7 +10,7 @@ languages: - TypeScript --- -import { Render, TabItem, Tabs, PackageManagers } from "~/components"; +import { Render, TabItem, Tabs, PackageManagers, WranglerConfig } from "~/components"; In this tutorial, you learn how to store and retrieve data in your Cloudflare Workers applications by building a REST API that manages an inventory catalog using [Fauna](https://fauna.com/) as its data layer. @@ -112,9 +112,7 @@ Then, move into your newly created directory: cd fauna-workers ``` -Update the `wrangler.toml` file to set the name for the Worker. - -import { WranglerConfig } from "~/components"; +Update the Wrangler file to set the name for the Worker. 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 443be11b1542779..cb153e4436a25b6 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 @@ -10,7 +10,7 @@ languages: - TypeScript --- -import { Render, PackageManagers } from "~/components"; +import { Render, PackageManagers, WranglerConfig } from "~/components"; This tutorial explains how to create a TypeScript-based Cloudflare Workers project that can securely access files from and upload files to a [Cloudflare R2](/r2/) bucket. Cloudflare R2 allows developers to store large amounts of unstructured data without the costly egress bandwidth fees associated with typical cloud storage services. @@ -66,9 +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` configuration file to include an R2 bucket [binding](/workers/runtime-apis/bindings/). Add the following R2 bucket binding to your `wrangler.toml` file: - -import { WranglerConfig } from "~/components"; +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: diff --git a/src/content/docs/workers/tutorials/workers-kv-from-rust/index.mdx b/src/content/docs/workers/tutorials/workers-kv-from-rust/index.mdx index 36e5136f475e0c1..1b5f73740885698 100644 --- a/src/content/docs/workers/tutorials/workers-kv-from-rust/index.mdx +++ b/src/content/docs/workers/tutorials/workers-kv-from-rust/index.mdx @@ -10,7 +10,7 @@ languages: - Rust --- -import { Render } from "~/components"; +import { Render, WranglerConfig } from "~/components"; This tutorial will teach you how to read and write to KV directly from Rust using [workers-rs](https://github.com/cloudflare/workers-rs). @@ -50,9 +50,7 @@ In the terminal, use Wrangler to create a KV namespace for `cities`. This genera npx wrangler kv:namespace create cities ``` -To add this configuration to your project, open the `wrangler.toml` file and create an entry for `kv_namespaces` above the build command: - -import { WranglerConfig } from "~/components"; +To add this configuration to your project, open the Wrangler file and create an entry for `kv_namespaces` above the build command: diff --git a/src/content/docs/workers/wrangler/api.mdx b/src/content/docs/workers/wrangler/api.mdx index d097174f06251f6..0c9e62edc35bc91 100644 --- a/src/content/docs/workers/wrangler/api.mdx +++ b/src/content/docs/workers/wrangler/api.mdx @@ -8,7 +8,7 @@ description: A set of programmatic APIs that can be integrated with local Cloudflare Workers-related workflows. --- -import { Render, TabItem, Tabs, Type, MetaInfo } from "~/components"; +import { Render, TabItem, Tabs, Type, MetaInfo, WranglerConfig } from "~/components"; Wrangler offers APIs to programmatically interact with your Cloudflare Workers. @@ -252,7 +252,7 @@ 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` 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. **Note:** this field is optional but if a path is specified it must point to a valid file on the filesystem. @@ -295,9 +295,7 @@ const platform = await getPlatformProxy(options); ### Usage -The `getPlatformProxy` function uses bindings found in `wrangler.toml`. For example, if you have an [environment variable](/workers/configuration/environment-variables/#add-environment-variables-via-wrangler) configuration set up in `wrangler.toml`: - -import { WranglerConfig } from "~/components"; +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: @@ -326,7 +324,7 @@ This will print the following output: `MY_VARIABLE = test`. ### Supported bindings -All supported bindings found in your `wrangler.toml` are available to you via `env`. +All supported bindings found in your `wrangler.toml / wrangler.json` file 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 75678eb37116619..7d997e50bb8b623 100644 --- a/src/content/docs/workers/wrangler/commands.mdx +++ b/src/content/docs/workers/wrangler/commands.mdx @@ -7,7 +7,7 @@ head: description: Create, develop, and deploy your Cloudflare Workers with Wrangler commands. --- -import { TabItem, Tabs, Render, Type, MetaInfo } from "~/components"; +import { TabItem, Tabs, Render, Type, MetaInfo, WranglerConfig } from "~/components"; Wrangler offers a number of commands to manage your Cloudflare Workers. @@ -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.toml` [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/) file. - `--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.toml` [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/) file. - `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. @@ -203,7 +203,7 @@ Interact with a [Vectorize](/vectorize/) vector database. ### `create` -Creates a new vector index, and provides the binding and name that you will put in your `wrangler.toml` file. +Creates a new vector index, and provides the binding and name that you will put in your Wrangler file. ```sh npx wrangler vectorize create [--dimensions=] [--metric=] [--description=] @@ -430,7 +430,7 @@ wrangler dev [