Extracts compatibility-flags out of compatibility-dates (#17900)

* Extracts compatibility-flags out of compatibility-dates

While the concepts are related they are not the same.

compatibility-flags will grow as we had more flags and deserves a separate page. This also has the benefit to have add an entry in the side bar. Having to click on "Configuration > Compatibility dates" to get info on the Compatibility flags is counter-intuitive.

I have updated internal links to point to the newly added flag page. Unfortunately external links to a given flag (i.e. "workers/configuration/compatibility-dates/#nodejs-compatibility-flag") will not point to that flag but to the top of the "Compatibility date". This is a limitation of the redirect mechanism on the site which can not redirect a fragment.

There are only a few changes in the content for the new flag page. I extracted a sentence from the first section into as the subtitle and I fixed a typo. The only other change is updating the CODEOWNERS of the new page to the same as the page is was extracted from.

* fixup! Extracts compatibility-flags out of compatibility-dates

Author: vicb

.github/CODEOWNERS

@@ -123,6 +123,8 @@
 /src/content/docs/workers/runtime-apis/bindings/ @irvinebroque @mikenomitch @GregBrimble @cloudflare/pcx-technical-writing
 /src/content/docs/workers/platform/ @irvinebroque @tanushree-sharma @GregBrimble @cloudflare/deploy-config @cloudflare/pcx-technical-writing
 /src/content/docs/workers/configuration/compatibility-dates/ @irvinebroque @mikenomitch @GregBrimble @cloudflare/deploy-config @cloudflare/pcx-technical-writing
+/src/content/docs/workers/configuration/compatibility-flags/ @irvinebroque @mikenomitch @GregBrimble @cloudflare/deploy-config @cloudflare/pcx-technical-writing
+
 /src/content/docs/workers/reference/migrate-to-module-workers/ @irvinebroque @GregBrimble @cloudflare/deploy-config @cloudflare/pcx-technical-writing
 /src/content/docs/workers/reference/security-model/ @irvinebroque @GregBrimble @cloudflare/pcx-technical-writing
 /src/content/compatibility-dates/ @irvinebroque @kflansburg @mikenomitch @GregBrimble @cloudflare/pcx-technical-writing

src/content/changelogs/queues.yaml

@@ -31,7 +31,7 @@ entries:
     description: |-
       The default [content type](/queues/configuration/javascript-apis/#queuescontenttype) for messages published to a queue is now `json`, which improves compatibility with the upcoming pull-based queues.
 
-      Any Workers created on or after the [compatibility date](/workers/configuration/compatibility-dates/#queues-send-messages-in-json-format) of `2024-03-18`, or that explicitly set the `queues_json_messages` compatibility flag, will use the new default behaviour. Existing Workers with a compatibility date prior will continue to use `v8` as the default content type for published messages.
+      Any Workers created on or after the [compatibility date](/workers/configuration/compatibility-flags/#queues-send-messages-in-json-format) of `2024-03-18`, or that explicitly set the `queues_json_messages` compatibility flag, will use the new default behaviour. Existing Workers with a compatibility date prior will continue to use `v8` as the default content type for published messages.
   - publish_date: "2024-02-24"
     title: Explicit retries no longer impact consumer concurrency/scaling.
     description: |-

src/content/changelogs/vectorize.yaml

@@ -56,7 +56,7 @@ entries:
     description: |-
       Vectorize `/query` HTTP endpoint has the following changes:
       - `returnVectors` request body property is deprecated in favor of `returnValues` and `returnMetadata` properties.
-      - Response format has changed to the below format to match [Workers API change]:(/workers/configuration/compatibility-dates/#vectorize-query-with-metadata-optionally-returned)
+      - Response format has changed to the below format to match [Workers API change]:(/workers/configuration/compatibility-flags/#vectorize-query-with-metadata-optionally-returned)
 
       ```json
       {

src/content/changelogs/workers.yaml

@@ -25,7 +25,7 @@ entries:
       - Updated v8 to version 12.9.
   - publish_date: "2024-08-19"
     description: |-
-      -  Workers now support the [`allow_custom_ports` compatibility flag](/workers/configuration/compatibility-dates/#allow-specifying-a-custom-port-when-making-a-subrequest-with-the-fetch-api) which enables using the `fetch()` calls to custom ports.
+      -  Workers now support the [`allow_custom_ports` compatibility flag](/workers/configuration/compatibility-flags/#allow-specifying-a-custom-port-when-making-a-subrequest-with-the-fetch-api) which enables using the `fetch()` calls to custom ports.
   - publish_date: "2024-08-15"
     description: |-
       - Updated v8 to version 12.8.
@@ -80,12 +80,12 @@ entries:
       - Updated v8 to version 12.6.
   - publish_date: "2024-05-15"
     description: |-
-      - The new [`fetch_standard_url` compatibility flag](/workers/configuration/compatibility-dates/#use-standard-url-parsing-in-fetch) will become active by default on June 3rd, 2024 and ensures that URLs passed into the `fetch(...)` API, the `new Request(...)` constructor, and redirected requests will be parsed using the standard WHATWG URL parser.
+      - The new [`fetch_standard_url` compatibility flag](/workers/configuration/compatibility-flags/#use-standard-url-parsing-in-fetch) will become active by default on June 3rd, 2024 and ensures that URLs passed into the `fetch(...)` API, the `new Request(...)` constructor, and redirected requests will be parsed using the standard WHATWG URL parser.
       - DigestStream is now more efficient and exposes a new `bytesWritten` property that indicates that number of bytes written to the digest.
   - publish_date: "2024-05-13"
     description: |-
       - Updated v8 to version 12.5.
-      - A bug in the fetch API implementation would cause the content type of a Blob to be incorrectly set. The fix is being released behind a new [`blob_standard_mime_type` compatibility flag](/workers/configuration/compatibility-dates/#properly-extract-blob-mime-type-from-content-type-headers).
+      - A bug in the fetch API implementation would cause the content type of a Blob to be incorrectly set. The fix is being released behind a new [`blob_standard_mime_type` compatibility flag](/workers/configuration/compatibility-flags/#properly-extract-blob-mime-type-from-content-type-headers).
   - publish_date: "2024-05-03"
     description: |-
       - Fixed RPC to/from Durable Objects not honoring the output gate.
@@ -108,13 +108,13 @@ entries:
       - The Web standard `ReadableStream.from()` API is now implemented. The API enables creating a `ReadableStream` from a either a sync or async iterable.
   - publish_date: "2024-04-03"
     description: |-
-      - When the [`brotli_content_encoding`](/workers/configuration/compatibility-dates/#brotli-content-encoding-support) compatibility flag is enabled, the Workers runtime now supports compressing and decompressing request bodies encoded using the [Brotli](https://developer.mozilla.org/en-US/docs/Glossary/Brotli_compression) compression algorithm. Refer to [this docs section](/workers/runtime-apis/fetch/#how-the-accept-encoding-header-is-handled) for more detail.
+      - When the [`brotli_content_encoding`](/workers/configuration/compatibility-flags/#brotli-content-encoding-support) compatibility flag is enabled, the Workers runtime now supports compressing and decompressing request bodies encoded using the [Brotli](https://developer.mozilla.org/en-US/docs/Glossary/Brotli_compression) compression algorithm. Refer to [this docs section](/workers/runtime-apis/fetch/#how-the-accept-encoding-header-is-handled) for more detail.
   - publish_date: "2024-04-02"
     description: |-
       - You can now [write Workers in Python](/workers/languages/python)
   - publish_date: "2024-04-01"
     description: |-
-      - The new [`unwrap_custom_thenables` compatibility flag](/workers/configuration/compatibility-dates/#handling-custom-thenables) enables workers to accept custom thenables in internal APIs that expect a promise (for instance, the `ctx.waitUntil(...)` method).
+      - The new [`unwrap_custom_thenables` compatibility flag](/workers/configuration/compatibility-flags/#handling-custom-thenables) enables workers to accept custom thenables in internal APIs that expect a promise (for instance, the `ctx.waitUntil(...)` method).
       - TransformStreams created with the TransformStream constructor now have a cancel algorithm that is called when the stream is canceled or aborted. This change is part of the implementation of the WHATWG Streams standard.
       - The [`nodejs_compat` compatibility flag](/workers/runtime-apis/nodejs/) now includes an implementation of the [`MockTracker` API from `node:test`](https://nodejs.org/api/test.html#class-mocktracker). This is not an implementation of the full `node:test` module, and mock timers are currently not included.
       - Exceptions reported to [Tail Workers](/workers/observability/logs/tail-workers/) now include a "stack" property containing the exception's stack trace, if available.
@@ -143,7 +143,7 @@ entries:
       - Workers and Pages Functions on the Standard usage model can set custom [CPU limits](/workers/wrangler/configuration/#limits) for their Workers
   - publish_date: "2023-10-20"
     description: |-
-      - Added the [`crypto_preserve_public_exponent`](/workers/configuration/compatibility-dates/#webcrypto-preserve-publicexponent-field)
+      - Added the [`crypto_preserve_public_exponent`](/workers/configuration/compatibility-flags/#webcrypto-preserve-publicexponent-field)
         compatibility flag to correct a wrong type being used in the algorithm field of RSA keys in
         the WebCrypto API.
   - publish_date: "2023-10-18"
@@ -156,7 +156,7 @@ entries:
   - publish_date: "2023-10-09"
     description: |-
       - The Web Platform standard [`CustomEvent` class](https://dom.spec.whatwg.org/#interface-customevent) is now available in Workers.
-      - Fixed a bug in the WebCrypto API where the `publicExponent` field of the algorithm of RSA keys would have the wrong type. Use the [`crypto_preserve_public_exponent` compatibility flag](/workers/configuration/compatibility-dates/#webcrypto-preserve-publicexponent-field) to enable the new behavior.
+      - Fixed a bug in the WebCrypto API where the `publicExponent` field of the algorithm of RSA keys would have the wrong type. Use the [`crypto_preserve_public_exponent` compatibility flag](/workers/configuration/compatibility-flags/#webcrypto-preserve-publicexponent-field) to enable the new behavior.
   - publish_date: "2023-09-14"
     description: |-
       - An implementation of the [`node:crypto`](/workers/runtime-apis/nodejs/crypto/)
@@ -173,7 +173,7 @@ entries:
       - An implementation of the [`diagnostics_channel`](/workers/runtime-apis/nodejs/diagnostics-channel) API from Node.js is now available when using the `nodejs_compat` compatibility flag.
   - publish_date: "2023-06-22"
     description: |-
-      - Added the [`strict_crypto_checks`](/workers/configuration/compatibility-dates/#strict-crypto-error-checking) compatibility flag to enable additional [Web Crypto API](/workers/runtime-apis/web-crypto/) error and security checking.
+      - Added the [`strict_crypto_checks`](/workers/configuration/compatibility-flags/#strict-crypto-error-checking) compatibility flag to enable additional [Web Crypto API](/workers/runtime-apis/web-crypto/) error and security checking.
       - Fixes regression in the [TCP Sockets API](/workers/runtime-apis/tcp-sockets/) where `connect("google.com:443")` would fail with a `TypeError`.
   - publish_date: "2023-06-19"
     description: |-
@@ -183,8 +183,8 @@ entries:
     description: |-
       - `AbortSignal.any()` is now available.
       - Updated V8 to 11.4.
-      - Following an update to the [WHATWG URL spec](https://url.spec.whatwg.org/#interface-urlsearchparams), the `delete()` and `has()` methods of the `URLSearchParams` class now accept an optional second argument to specify the search parameter’s value. This is potentially a breaking change, so it is gated behind the new `urlsearchparams_delete_has_value_arg` and [`url_standard`](/workers/configuration/compatibility-dates/#new-url-parser-implementation) compatibility flags.
-      - Added the [`strict_compression_checks`](/workers/configuration/compatibility-dates/#strict-compression-error-checking) compatibility flag for additional [`DecompressionStream`](/workers/runtime-apis/web-standards/#compression-streams) error checking.
+      - Following an update to the [WHATWG URL spec](https://url.spec.whatwg.org/#interface-urlsearchparams), the `delete()` and `has()` methods of the `URLSearchParams` class now accept an optional second argument to specify the search parameter’s value. This is potentially a breaking change, so it is gated behind the new `urlsearchparams_delete_has_value_arg` and [`url_standard`](/workers/configuration/compatibility-flags/#new-url-parser-implementation) compatibility flags.
+      - Added the [`strict_compression_checks`](/workers/configuration/compatibility-flags/#strict-compression-error-checking) compatibility flag for additional [`DecompressionStream`](/workers/runtime-apis/web-standards/#compression-streams) error checking.
   - publish_date: "2023-05-26"
     description: |-
       - A new [Hibernatable WebSockets API](/durable-objects/api/websockets/)

src/content/compatibility-dates/new-url-parser-implementation.md

@@ -27,4 +27,4 @@ The original implementation of the [`URL`](https://developer.mozilla.org/en-US/d
 
 Set the compatibility date of your Worker to a date after `2022-10-31` or enable the `url_standard` compatibility flag to opt-in the fully spec compliant `URL` API implementation.
 
-Refer to the [`response_redirect_url_standard` compatibility flag](/workers/configuration/compatibility-dates/#use-a-spec-compliant-url-implementation-in-redirects) , which affects the URL implementation used in `Response.redirect()`.
+Refer to the [`response_redirect_url_standard` compatibility flag](/workers/configuration/compatibility-flags/#use-a-spec-compliant-url-implementation-in-redirects) , which affects the URL implementation used in `Response.redirect()`.

src/content/docs/browser-rendering/get-started/browser-rendering-with-DO.mdx

@@ -71,7 +71,7 @@ After running the `list` command, you will see all bucket names, including the o
 
 ## 5. Configure `wrangler.toml`
 
-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-dates/#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`](/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.
 
 Update your `wrangler.toml` configuration file with the Browser Rendering API binding, the R2 bucket you created and a Durable Object:
 

src/content/docs/browser-rendering/get-started/screenshots.mdx

@@ -58,7 +58,7 @@ Take note of the IDs for the next step.
 
 ## 4. Configure `wrangler.toml`
 
-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-dates/#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`](/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.
 
 Update your `wrangler.toml` configuration file with the Browser Rendering API binding and the KV namespaces you created:
 

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-dates/#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` configuration file](/workers/wrangler/configuration/) of your Durable Object.
 
 ```
 compatibility_flags = ["experimental", "webgpu"]

src/content/docs/durable-objects/best-practices/create-durable-object-stubs-and-send-requests.mdx

@@ -9,7 +9,7 @@ import { Render, Tabs, TabItem, GlossaryTooltip } from "~/components";
 
 ## Invoking methods on a Durable Object
 
-All new projects and existing projects with a compatibility date greater than or equal to [`2024-04-03`](/workers/configuration/compatibility-dates/#durable-object-stubs-and-service-bindings-support-rpc) should prefer to invoke [Remote Procedure Call (RPC)](/workers/runtime-apis/rpc/) methods defined on a <GlossaryTooltip term="Durable Object class">Durable Object class</GlossaryTooltip>. Legacy projects can continue to invoke the `fetch` handler on the Durable Object class indefinitely.
+All new projects and existing projects with a compatibility date greater than or equal to [`2024-04-03`](/workers/configuration/compatibility-flags/#durable-object-stubs-and-service-bindings-support-rpc) should prefer to invoke [Remote Procedure Call (RPC)](/workers/runtime-apis/rpc/) methods defined on a <GlossaryTooltip term="Durable Object class">Durable Object class</GlossaryTooltip>. Legacy projects can continue to invoke the `fetch` handler on the Durable Object class indefinitely.
 
 ### Invoke RPC methods
 
@@ -29,7 +29,7 @@ Refer to [Build a Counter](/durable-objects/examples/build-a-counter/) for a com
 
 ### Invoking the `fetch` handler
 
-If your project is stuck on a compatibility date before [`2024-04-03`](/workers/configuration/compatibility-dates/#durable-object-stubs-and-service-bindings-support-rpc), or has the need to send a [`Request`](/workers/runtime-apis/request/) object and return a `Response` object, then you should send requests to a Durable Object via the fetch handler.
+If your project is stuck on a compatibility date before [`2024-04-03`](/workers/configuration/compatibility-flags/#durable-object-stubs-and-service-bindings-support-rpc), or has the need to send a [`Request`](/workers/runtime-apis/request/) object and return a `Response` object, then you should send requests to a Durable Object via the fetch handler.
 
 <Tabs> <TabItem label="JavaScript" icon="seti:javascript">
 

src/content/docs/queues/configuration/javascript-apis.mdx

@@ -139,7 +139,7 @@ type QueuesContentType = "text" | "bytes" | "json" | "v8";
 :::note
 
 
-The default content type for Queues changed to `json` (from `v8`) to improve compatibility with pull-based consumers for any Workers with a [compatibility date](/workers/configuration/compatibility-dates/#queues-send-messages-in-json-format) after `2024-03-18`.
+The default content type for Queues changed to `json` (from `v8`) to improve compatibility with pull-based consumers for any Workers with a [compatibility date](/workers/configuration/compatibility-flags/#queues-send-messages-in-json-format) after `2024-03-18`.
 
 
 :::