Document several missing compat flags (#19129)

Co-authored-by: ToriLindsay <[email protected]>

Author: jasnell

src/content/compatibility-flags/disable-top-level-await-in-require.md

@@ -0,0 +1,24 @@
+---
+_build:
+publishResources: false
+render: never
+list: never
+
+name: "Disable top-level await in require(...)"
+sort_date: "2024-12-02"
+enable_date: "2024-12-02"
+enable_flag: "disable_top_level_await_in_require"
+disable_flag: "enable_top_level_await_in_require"
+---
+
+Workers implements the ability to use the Node.js style `require(...)` method
+to import modules in the Worker bundle. Historically, this mechanism allowed
+required modules to use top-level await. This, however, is not Node.js
+compatible.
+
+The `disable_top_level_await_in_require` compat flag will cause `require()`
+to fail if the module uses a top-level await. This flag is default enabled
+with a compatibility date of 2024-12-02 or later.
+
+To restore the original behavior allowing top-level await, use the
+`enable_top_level_await_in_require` compatibility flag.

src/content/compatibility-flags/streams-transform-backpressure.md

@@ -0,0 +1,23 @@
+---
+_build:
+publishResources: false
+render: never
+list: never
+
+name: "Apply TransformStream backpressure fix"
+sort_date: "2024-12-16"
+enable_date: "2024-12-16"
+enable_flag: "fixup-transform-stream-backpressure"
+disable_flag: "original-transform-stream-backpressure"
+---
+
+The original implementation of `TransformStream` included a bug that would
+cause backpressure signaling to fail after the first write to the transform.
+Unfortunately, the fix can cause existing code written to address the bug to
+fail. Therefore, the `fixup-transform-stream-backpressure` compat flag is
+provided to enable the fix.
+
+The fix is enabled by default with compatibility dates of 2024-12-16 or later.
+
+To restore the original backpressure logic, disable the fix using the
+`original-transform-stream-backpressure` flag.

src/content/compatibility-flags/to-string-tag.md

@@ -0,0 +1,17 @@
+---
+_build:
+publishResources: false
+render: never
+list: never
+
+name: "Automatically set the Symbol.toStringTag for Workers API objects"
+sort_date: "2024-09-26"
+enable_date: "2024-09-26"
+enable_flag: "set_tostring_tag"
+disable_flag: "do_not_set_tostring_tag"
+---
+
+A change was made to set the Symbol.toStringTag on all Workers API objects
+in order to fix several spec compliance bugs. Unfortunately,
+this change was more breaking than anticipated. The `do_not_set_tostring_tag`  compat
+flag restores the original behavior with compatibility dates of 2024-09-26 or earlier.

src/content/compatibility-flags/upper-case-http-methods.md

@@ -0,0 +1,24 @@
+---
+_build:
+publishResources: false
+render: never
+list: never
+
+name: "Upper-case HTTP methods"
+sort_date: "2024-10-14"
+enable_date: "2024-10-14"
+enable_flag: "upper_case_all_http_methods"
+disable_flag: "no_upper_case_all_http_methods"
+---
+
+HTTP methods are expected to be upper-cased. Per the fetch spec, if the
+method is specified as `get`, `post`, `put`, `delete`, `head`, or `options`,
+implementations are expected to uppercase the method. All other method names
+would generally be expected to throw as unrecognized (e.g. `patch` would be
+an error while `PATCH` is accepted). This is a bit restrictive, even if it
+is in the spec. This flag modifies the behavior to uppercase all methods
+prior to parsing so that the method is always recognized if it is a known
+method.
+
+To restore the standard behavior, use the `no_upper_case_all_http_methods`
+compatibility flag.