Update recently added compatibility flags

src/content/compatibility-flags/allow-eval-during-startup.md

@@ -0,0 +1,19 @@
+---
+_build:
+  publishResources: false
+  render: never
+  list: never
+
+name: "Enable eval during startup"
+sort_date: "2025-06-01"
+enable_date: "2025-06-01"
+enable_flag: "allow_eval_during_startup"
+disable_flag: "disallow_eval_during_startup"
+---
+
+When the `allow_eval_during_startup` flag is set, Workers can use `eval()`
+and `new Function(text)` during the startup phase of a Worker script. This
+allows for dynamic code execution at the beginning of a Worker lifecycle.
+
+When the `disallow_eval_during_startup` flag is set, using `eval()` or
+`new Function(text)` during the startup phase will throw an error.

src/content/compatibility-flags/bind-asynclocalstorage-snapshot-to-request.md

@@ -0,0 +1,22 @@
+---
+_build:
+  publishResources: false
+  render: never
+  list: never
+
+name: "Bind AsyncLocalStorage snapshots to the request"
+sort_date: "2025-06-16"
+enable_date: "2025-06-16"
+enable_flag: "bind_asynclocalstorage_snapshot_to_request"
+disable_flag: "do_not_bind_asynclocalstorage_snapshot_to"
+---
+
+The AsyncLocalStorage frame can capture values that are bound to the
+current request context. This is not always in the users control since we use
+the ALS storage frame to propagate internal trace spans as well as
+user-provided values. When the `bind_asynclocalstorage_snapshot_to_request`
+flag is set, the runtime binds the snapshot / bound functions to the current
+request context and will throw an error if the bound functions are called
+outside of the request in which they were created.
+
+The `do_not_bind_asynclocalstorage_snapshot_to` flag disables this behavior.

src/content/compatibility-flags/disallow_importable_env.md

@@ -0,0 +1,18 @@
+---
+_build:
+  publishResources: false
+  render: never
+  list: never
+
+name: "Disallowing importable environment"
+sort_date: "2025-05-05"
+enable_flag: "disallow_importable_env"
+disable_flag: "allow_importable_env"
+---
+
+When the `disallow_importable_env` flag is enabled, Workers will not allow importing the
+environment variables via the `cloudflare:workers` module and will not populate the
+environment variables in the global `process.env` object when Node.js compatibility is
+enabled.
+
+There is no default enabled date for this flag.

src/content/compatibility-flags/enable-navigator-language.md

@@ -0,0 +1,19 @@
+---
+_build:
+  publishResources: false
+  render: never
+  list: never
+
+name: "Enable `navigator.language`"
+sort_date: "2025-05-19"
+enable_date: "2025-05-19"
+enable_flag: "enable_navigator_language"
+disable_flag: "disable_navigator_language"
+---
+
+When the `enable_navigator_language` flag is set, the `navigator.language` property
+will be available in Workers. For now, the value of `navigator.language` will
+always be `en`.
+
+When the `disable_navigator_language` flag is set, the `navigator.language` property
+will not be available.

src/content/compatibility-flags/enable-nodejs-http-modules.md

@@ -0,0 +1,18 @@
+---
+_build:
+  publishResources: false
+  render: never
+  list: never
+
+name: "Enable availability of `node:http` and `node:https` modules"
+sort_date: "2025-08-15"
+enable_date: "2025-08-15"
+enable_flag: "enable_nodejs_http_modules"
+disable_flag: "disable_nodejs_http_modules"
+---
+
+The `enable_nodejs_http_modules` flag enables the availability of Node.js
+`node:http` and `node:https` modules in Workers.
+
+The `disable_nodejs_http_modules` flag disables the availability of these
+modules.

src/content/compatibility-flags/expose-global-message-channel.md

@@ -0,0 +1,18 @@
+---
+_build:
+  publishResources: false
+  render: never
+  list: never
+
+name: "Expose global MessageChannel and MessagePort"
+sort_date: "2025-08-15"
+enable_date: "2025-08-15"
+enable_flag: "expose_global_message_channel"
+disable_flag: "no_expose_global_message_channel"
+---
+
+When the `expose_global_message_channel` flag is set, Workers will expose
+the `MessageChannel` and `MessagePort` constructors globally.
+
+When the `no_expose_global_message_channel` flag is set, Workers will not
+expose these.

src/content/compatibility-flags/pedantic-wpt.md

@@ -0,0 +1,16 @@
+---
+_build:
+  publishResources: false
+  render: never
+  list: never
+
+name: "Pedantic Web Platform Tests (WPT) compliance"
+sort_date: "2025-07-15"
+enable_flag: "pedantic_wpt"
+disable_flag: "non_pedantic_wpt"
+---
+
+The `pedantic_wpt` flag enables strict compliance with Web Platform Tests (WPT)
+in Workers. Initially this only effects `Event` and `EventTarget` APIs but
+will be expanded to other APIs in the future. There is no default enable
+date for this flag.

src/content/compatibility-flags/python-no-global-handlers.md

@@ -0,0 +1,15 @@
+---
+_build:
+  publishResources: false
+  render: never
+  list: never
+
+name: "Disable global handlers for Python Workers"
+sort_date: "2025-08-14"
+enable_date: "2025-08-14"
+enable_flag: "python_no_global_handlers"
+disable_flag: "disable_python_no_global_handlers"
+---
+
+When the `python_no_global_handlers` flag is set, Python Workers will disable
+the global handlers and enforce their use via default entrypoint classes.

src/content/compatibility-flags/request-signal-passthrough.md

@@ -0,0 +1,18 @@
+---
+_build:
+  publishResources: false
+  render: never
+  list: never
+
+name: "Passthrough AbortSignal of incoming request to subrequests"
+sort_date: "2025-05-05"
+enable_flag: "request_signal_passthrough"
+disable_flag: "no_request_signal_passthrough"
+---
+
+When the `request_signal_passthrough` flag set, the `AbortSignal` of an incoming
+request will be passed through to subrequests when the request is forwarded to
+a subrequest using the `fetch()` API.
+
+The the `no_request_signal_passthrough` flag is set, the `AbortSignal` of the
+incoming request will not be passed through.

src/content/compatibility-flags/set-event-target-this.md

@@ -0,0 +1,19 @@
+---
+_build:
+  publishResources: false
+  render: never
+  list: never
+
+name: "Set the `this` value of EventTarget event handlers"
+sort_date: "2025-08-01"
+enable_date: "2025-08-01"
+enable_flag: "set_event_target_this"
+disable_flag: "no_set_event_target_this"
+---
+
+When the `set_event_target_this` flag is se, Workers will set the `this` value
+of event handlers to the `EventTarget` instance that the event is being
+dispatched on. This is compliant with the specification.
+
+When then `no_set_event_target_this` flag is set, Workers will not set the
+`this` value of event handlers, and it will be `undefined` instead.

src/content/compatibility-flags/set-forwardable-email-full-headers.md

@@ -0,0 +1,17 @@
+---
+_build:
+  publishResources: false
+  render: never
+  list: never
+
+name: "Set forwardable email full headers"
+sort_date: "2025-08-01"
+enable_date: "2025-08-01"
+enable_flag: "set_forwardable_email_full_headers"
+disable_flag: "set_forwardable_email_single_headers"
+---
+
+The original version of the headers sent to edgeworker were truncated to a
+single value for specific header names, such as To and Cc. With the
+`set_forwardable_email_full_headers` flag set, Workers will receive the full
+header values to the worker script.

src/content/compatibility-flags/throw-on-unrecognized-import-assertion.md

@@ -0,0 +1,22 @@
+---
+_build:
+  publishResources: false
+  render: never
+  list: never
+
+name: "Throw on unrecognized import assertions"
+sort_date: "2025-06-16"
+enable_date: "2025-06-16"
+enable_flag: "throw_on_unrecognized_import_assertion"
+disable_flag: "ignore_unrecognized_import_assertion"
+---
+
+The `throw_on_unrecognized_import_assertion` flag controls how Workers handle
+import attributes that are not recognized by the runtime. Previously, Workers
+would ignore all import attributes, which is not compliant with the
+specification. Runtimes are expected to throw an error when an import
+attribute is encountered that is not recognized.
+
+When the `ignore_unrecognized_import_assertion` flag is set, Workers will
+ignore unrecognized import attributes.
+