diff --git a/basics/dependencies.mdx b/basics/dependencies.mdx index 1d3bf8f1..79d73e45 100644 --- a/basics/dependencies.mdx +++ b/basics/dependencies.mdx @@ -67,8 +67,7 @@ targets, we’ve made some strides in mitigating the downside by investing in tooling to automatically manage `BUILD` files to avoid burdening developers. Some of these tools, such as `buildifier` and `buildozer`, are available with -Bazel in the [`buildtools` -directory](https://github.com/bazelbuild/buildtools). +Bazel in the [`buildtools` directory](https://github.com/bazelbuild/buildtools). ## Minimizing Module Visibility @@ -108,8 +107,7 @@ transitive dependencies (Figure 1). Suppose target A depends on target B, which depends on a common library target C. Should target A be able to use classes defined in target C? -[![Transitive -dependencies](/images/transitive-dependencies.png)](/images/transitive-dependencies.png) +[![Transitive dependencies](/images/transitive-dependencies.png)](/images/transitive-dependencies.png) **Figure 1**. Transitive dependencies @@ -143,9 +141,7 @@ dependencies and adding them to a `BUILD` files without any developer intervention. But even without such tools, we’ve found the trade-off to be well worth it as the codebase scales: explicitly adding a dependency to `BUILD` file is a one-time cost, but dealing with implicit transitive dependencies can cause -ongoing problems as long as the build target exists. Bazel [enforces strict -transitive -dependencies](https://blog.bazel.build/2017/06/28/sjd-unused_deps.html) +ongoing problems as long as the build target exists. Bazel [enforces strict transitive dependencies](https://blog.bazel.build/2017/06/28/sjd-unused_deps.html) on Java code by default. ### External dependencies @@ -194,8 +190,7 @@ so in theory there’s no reason that different versions of the same external dependency couldn’t both be declared in the build system under different names. That way, each target could choose which version of the dependency it wanted to use. This causes a lot of problems in practice, so Google enforces a strict -[One-Version -Rule](https://opensource.google/docs/thirdparty/oneversion/) for +[One-Version Rule](https://opensource.google/docs/thirdparty/oneversion/) for all third-party dependencies in our codebase. The biggest problem with allowing multiple versions is the diamond dependency @@ -234,8 +229,7 @@ Bazel did not use to automatically download transitive dependencies. It used to employ a `WORKSPACE` file that required all transitive dependencies to be listed, which led to a lot of pain when managing external dependencies. Bazel has since added support for automatic transitive external dependency management -in the form of the `MODULE.bazel` file. See [external dependency -overview](/external/overview) for more details. +in the form of the `MODULE.bazel` file. See [external dependency overview](/external/overview) for more details. Yet again, the choice here is one between convenience and scalability. Small projects might prefer not having to worry about managing transitive dependencies diff --git a/community/sig.mdx b/community/sig.mdx index ae5f9189..3b4d6635 100644 --- a/community/sig.mdx +++ b/community/sig.mdx @@ -5,8 +5,7 @@ title: 'Bazel Special Interest Groups' Bazel hosts Special Interest Groups (SIGs) to focus collaboration on particular -areas and to support communication and coordination between [Bazel owners, -maintainers, and contributors](/contribute/policy). This policy +areas and to support communication and coordination between [Bazel owners, maintainers, and contributors](/contribute/policy). This policy applies to [`bazelbuild`](http://github.com/bazelbuild). SIGs do their work in public. The ideal scope for a SIG covers a well-defined diff --git a/community/users.mdx b/community/users.mdx index 25835f3d..227ee4bb 100644 --- a/community/users.mdx +++ b/community/users.mdx @@ -320,11 +320,9 @@ safety systems_. Pigweed is an open-source solution for sustained, robust, and rapid embedded product development for large teams. Pigweed has shipped in millions of devices, including Google's suite of Pixel devices, Nest thermostats, -[satellites](https://www.spinlaunch.com/), and [autonomous aerial -drones](https://www.flyzipline.com/). +[satellites](https://www.spinlaunch.com/), and [autonomous aerial drones](https://www.flyzipline.com/). -Pigweed [uses Bazel as its primary build -system](https://pigweed.dev/seed/0111-build-systems.html). The [Bazel for +Pigweed [uses Bazel as its primary build system](https://pigweed.dev/seed/0111-build-systems.html). The [Bazel for Embedded][pw-bazel-great] blog post discusses why we think it's a great build system for embedded projects! diff --git a/concepts/build-files.mdx b/concepts/build-files.mdx index ec87f4db..b85f472c 100644 --- a/concepts/build-files.mdx +++ b/concepts/build-files.mdx @@ -132,23 +132,6 @@ for anyone to create new rules. and binaries and tests can depend on libraries, with the expected separate-compilation behavior. - - - - - -
- - Labels - - - - Dependencies - -
- ## File encoding `BUILD` and `.bzl` files should be encoded in UTF-8, of which ASCII is a valid diff --git a/concepts/build-ref.mdx b/concepts/build-ref.mdx index 0af78970..ee67bcc6 100644 --- a/concepts/build-ref.mdx +++ b/concepts/build-ref.mdx @@ -19,8 +19,7 @@ its root; such a boundary marker file could be `MODULE.bazel`, `REPO.bazel`, or in legacy contexts, `WORKSPACE` or `WORKSPACE.bazel`. The repo in which the current Bazel command is being run is called the _main -repo_. Other, (external) repos are defined by _repo rules_; see [external -dependencies overview](/external/overview) for more information. +repo_. Other, (external) repos are defined by _repo rules_; see [external dependencies overview](/external/overview) for more information. ## Workspace {#workspace} @@ -97,9 +96,4 @@ have three properties: the list of packages they contain, their name, and other package groups they include. The only allowed ways to refer to them are from the `visibility` attribute of rules or from the `default_visibility` attribute of the `package` function; they do not generate or consume files. For more -information, refer to the [`package_group` -documentation](/reference/be/functions#package_group). - - - Labels - +information, refer to the [`package_group` documentation](/reference/be/functions#package_group). diff --git a/concepts/dependencies.mdx b/concepts/dependencies.mdx index 39fef86e..e03c1af7 100644 --- a/concepts/dependencies.mdx +++ b/concepts/dependencies.mdx @@ -366,21 +366,3 @@ filegroup( ``` You can then reference the label `my_data` as the data dependency in your test. - - - - - - -
- - BUILD files - - - - Visibility - -
- diff --git a/concepts/labels.mdx b/concepts/labels.mdx index 5b0b1c6a..3f14e001 100644 --- a/concepts/labels.mdx +++ b/concepts/labels.mdx @@ -12,8 +12,7 @@ form looks like: ``` The first part of the label is the repository name, `@@myrepo`. The double-`@` -syntax signifies that this is a [*canonical* repo -name](/external/overview#canonical-repo-name), which is unique within +syntax signifies that this is a [*canonical* repo name](/external/overview#canonical-repo-name), which is unique within the workspace. Labels with canonical repo names unambiguously identify a target no matter which context they appear in. @@ -241,20 +240,3 @@ the build. This directed acyclic graph over targets is called the _target graph_ or _build dependency graph_, and is the domain over which the [Bazel Query tool](/query/guide) operates. - - - - - - -
- - Targets - - - - BUILD files - -
diff --git a/concepts/platforms.mdx b/concepts/platforms.mdx index 591ef313..09cede52 100644 --- a/concepts/platforms.mdx +++ b/concepts/platforms.mdx @@ -79,8 +79,7 @@ To test your Android project with platforms, see for support. You can still use platform APIs with Apple builds (for example, when building -with a mixture of Apple rules and pure C++) with [platform -mappings](#platform-mappings). +with a mixture of Apple rules and pure C++) with [platform mappings](#platform-mappings). ### Other languages {#other-languages} @@ -244,8 +243,7 @@ sets `--cpu`, `--crossstool_top`, or other legacy flags, rules that read When migrating your project to platforms, you must either convert changes like `return { "//command_line_option:cpu": "arm" }` to `return { -"//command_line_option:platforms": "//:my_arm_platform" }` or use [platform -mappings](#platform-mappings) to support both styles during migration. +"//command_line_option:platforms": "//:my_arm_platform" }` or use [platform mappings](#platform-mappings) to support both styles during migration. window. ## Migrating your rule set {#migrating-your-rule-set} @@ -364,10 +362,8 @@ attributes declare a language's tools (like `compiler = this information to rules that need to build with these tools. Toolchains declare the `constraint_value`s of machines they can -[target][target_compatible_with Attribute] -(`target_compatible_with = ["@platforms//os:linux"]`) and machines their tools can -[run on][exec_compatible_with Attribute] -(`exec_compatible_with = ["@platforms//os:mac"]`). +[target][target_compatible_with Attribute](`target_compatible_with = ["@platforms//os:linux"]`) and machines their tools can +[run on][exec_compatible_with Attribute](`exec_compatible_with = ["@platforms//os:mac"]`). When building `$ bazel build //:myproject --platforms=//:myplatform`, Bazel automatically selects a toolchain that can run on the build machine and diff --git a/configure/attributes.mdx b/configure/attributes.mdx index 7f4936bb..4f03c453 100644 --- a/configure/attributes.mdx +++ b/configure/attributes.mdx @@ -4,8 +4,7 @@ title: 'Configurable Build Attributes' -**_Configurable attributes_**, commonly known as [`select()`]( -/reference/be/functions#select), is a Bazel feature that lets users toggle the values +**_Configurable attributes_**, commonly known as [`select()`](/reference/be/functions#select), is a Bazel feature that lets users toggle the values of build rule attributes at the command line. This can be used, for example, for a multiplatform library that automatically @@ -409,8 +408,7 @@ sh_library( ) ``` -If you need a `select` to match when multiple conditions match, consider [AND -chaining](#and-chaining). +If you need a `select` to match when multiple conditions match, consider [AND chaining](#and-chaining). ## OR chaining {#or-chaining} diff --git a/configure/integrate-cpp.mdx b/configure/integrate-cpp.mdx index b9ba8840..599fbd8f 100644 --- a/configure/integrate-cpp.mdx +++ b/configure/integrate-cpp.mdx @@ -14,8 +14,7 @@ To depend on a C++ toolchain in your rule, set the `toolchains` parameter to `use_cc_toolchain()`. Then, in the rule implementation, use `find_cpp_toolchain(ctx)` to get the [`CcToolchainInfo`](/rules/lib/providers/CcToolchainInfo). A complete working -example can be found [in the rules_cc -examples](https://github.com/bazelbuild/rules_cc/blob/main/examples/write_cc_toolchain_cpu/write_cc_toolchain_cpu.bzl). +example can be found [in the rules_cc examples](https://github.com/bazelbuild/rules_cc/blob/main/examples/write_cc_toolchain_cpu/write_cc_toolchain_cpu.bzl). ## Generating command lines and environment variables using the C++ toolchain {#generate-command-lines-toolchain} @@ -25,8 +24,7 @@ This is because when writing our own actions, they must behave consistently with the C++ toolchain - for example, passing C++ command line flags to a tool that invokes the C++ compiler behind the scenes. -C++ rules use a special way of constructing command lines based on [feature -configuration](/docs/cc-toolchain-config-reference). To construct a command line, +C++ rules use a special way of constructing command lines based on [feature configuration](/docs/cc-toolchain-config-reference). To construct a command line, you need the following: * `features` and `action_configs` - these come from the `CcToolchainConfigInfo` diff --git a/configure/windows.mdx b/configure/windows.mdx index 46e6073b..573f660d 100644 --- a/configure/windows.mdx +++ b/configure/windows.mdx @@ -162,8 +162,7 @@ To build C++ targets with MSVC, you need: set BAZEL_VC=C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC ``` -* The [Windows - SDK](https://developer.microsoft.com/en-us/windows/downloads/windows-10-sdk). +* The [Windows SDK](https://developer.microsoft.com/en-us/windows/downloads/windows-10-sdk). The Windows SDK contains header files and libraries you need when building Windows applications, including Bazel itself. By default, the latest Windows SDK installed will @@ -182,8 +181,7 @@ To build C++ targets with MSVC, you need: If everything is set up, you can build a C++ target now! -Try building a target from one of our [sample -projects](https://github.com/bazelbuild/bazel/tree/master/examples): +Try building a target from one of our [sample projects](https://github.com/bazelbuild/bazel/tree/master/examples): ``` ` is a common overload of `void accept(Bar value)`, -so doing this often leads to violations of the [Overloads: never -split](https://google.github.io/styleguide/javaguide.html#s3.4.2-ordering-class-contents) +so doing this often leads to violations of the [Overloads: never split](https://google.github.io/styleguide/javaguide.html#s3.4.2-ordering-class-contents) style-guide rule. Tip: Using a custom `ResultSink` type instead of a generic one from @@ -776,14 +772,11 @@ pattern after accepting output from either a subtask or SkyValue lookup. Note that the implementation of `acceptBarError` eagerly forwards the result to the `Caller.ResultSink`, as required by [Error bubbling](#error-bubbling). -Alternatives for top-level `StateMachine`s are described in [`Driver`s and -bridging to SkyFunctions](#drivers-and-bridging). +Alternatives for top-level `StateMachine`s are described in [`Driver`s and bridging to SkyFunctions](#drivers-and-bridging). ### Error handling {#error-handling} -There's a couple of examples of error handling already in [`Tasks.lookUp` -callbacks](#tasks-lookup-callbacks) and [Propagating values between -`StateMachines`](#propagating-values). Exceptions, other than +There's a couple of examples of error handling already in [`Tasks.lookUp` callbacks](#tasks-lookup-callbacks) and [Propagating values between `StateMachines`](#propagating-values). Exceptions, other than `InterruptedException` are not thrown, but instead passed around through callbacks as values. Such callbacks often have exclusive-or semantics, with exactly one of a value or error being passed. @@ -1186,8 +1179,7 @@ states. Where it is possible, local stack `step` variables are young generation variables and efficiently GC'd. For `StateMachine` variables, breaking things down into subtasks and following -the recommended pattern for [Propagating values between -`StateMachine`s](#propagating-values) is also helpful. Observe that when +the recommended pattern for [Propagating values between `StateMachine`s](#propagating-values) is also helpful. Observe that when following the pattern, only child `StateMachine`s have references to parent `StateMachine`s and not vice versa. This means that as children complete and update the parents using result callbacks, the children naturally fall out of @@ -1209,8 +1201,7 @@ potentially reflecting local behavior. ### Concurrency tree diagram {#concurrency-tree-diagram} -The following is an alternative view of the diagram in [Structured -concurrency](#structured-concurrency) that better depicts the tree structure. +The following is an alternative view of the diagram in [Structured concurrency](#structured-concurrency) that better depicts the tree structure. The blocks form a small tree. ![Structured Concurrency 3D](/contribute/images/structured-concurrency-3d.svg) diff --git a/docs/android-instrumentation-test.mdx b/docs/android-instrumentation-test.mdx index 82fb7b1e..e7be4e54 100644 --- a/docs/android-instrumentation-test.mdx +++ b/docs/android-instrumentation-test.mdx @@ -4,8 +4,7 @@ title: 'Android Instrumentation Tests' -_If you're new to Bazel, start with the [Building Android with -Bazel](/start/android-app ) tutorial._ +_If you're new to Bazel, start with the [Building Android with Bazel](/start/android-app) tutorial._ ![Running Android instrumentation tests in parallel](/docs/images/android_test.gif "Android instrumentation test") @@ -20,9 +19,7 @@ emulators in a sandbox, ensuring that tests always run from a clean state. Each test gets an isolated emulator instance, allowing tests to run in parallel without passing states between them. -For more information on Android instrumentation tests, check out the [Android -developer -documentation](https://developer.android.com/training/testing/unit-testing/instrumented-unit-tests.html). +For more information on Android instrumentation tests, check out the [Android developer documentation](https://developer.android.com/training/testing/unit-testing/instrumented-unit-tests.html). Please file issues in the [GitHub issue tracker](https://github.com/bazelbuild/bazel/issues). @@ -60,8 +57,7 @@ This results in output similar to the following: release 4.1.0 ``` -- **KVM**. Bazel requires emulators to have [hardware - acceleration](https://developer.android.com/studio/run/emulator-acceleration.html#accel-check) +- **KVM**. Bazel requires emulators to have [hardware acceleration](https://developer.android.com/studio/run/emulator-acceleration.html#accel-check) with KVM on Linux. You can follow these [installation instructions](https://help.ubuntu.com/community/KVM/Installation) for Ubuntu. @@ -176,11 +172,9 @@ The main attributes of the rule `android_instrumentation_test` are: - `target_device`: An `android_device` target. This target describes the specifications of the Android emulator which Bazel uses to create, launch and - run the tests. See the [section on choosing an Android - device](#android-device-target) for more information. + run the tests. See the [section on choosing an Android device](#android-device-target) for more information. -The test app's `AndroidManifest.xml` must include [an `` -tag](https://developer.android.com/studio/test/#configure_instrumentation_manifest_settings). +The test app's `AndroidManifest.xml` must include [an `` tag](https://developer.android.com/studio/test/#configure_instrumentation_manifest_settings). This tag must specify the attributes for the **package of the target app** and the **fully qualified class name of the instrumentation test runner**, `androidx.test.runner.AndroidJUnitRunner`. @@ -217,8 +211,7 @@ repositories: - `@androidsdk`: The Android SDK. Download this through Android Studio. - `@android_test_support`: Hosts the test runner, emulator launcher, and - `android_device` targets. You can find the [latest release - here](https://github.com/android/android-test/releases). + `android_device` targets. You can find the [latest release here](https://github.com/android/android-test/releases). Enable these dependencies by adding the following lines to your `WORKSPACE` file: @@ -244,8 +237,7 @@ android_test_repositories() ## Maven dependencies {#maven-dependencies} -For managing dependencies on Maven artifacts from repositories, such as [Google -Maven](https://maven.google.com) or [Maven Central](https://central.maven.org), +For managing dependencies on Maven artifacts from repositories, such as [Google Maven](https://maven.google.com) or [Maven Central](https://central.maven.org), you should use a Maven resolver, such as [`rules_jvm_external`](https://github.com/bazelbuild/rules_jvm_external). @@ -374,8 +366,7 @@ the device/emulator listed in `adb devices`. ## Sample projects {#sample-projects} -If you are looking for canonical project samples, see the [Android testing -samples](https://github.com/googlesamples/android-testing#experimental-bazel-support) +If you are looking for canonical project samples, see the [Android testing samples](https://github.com/googlesamples/android-testing#experimental-bazel-support) for projects using Espresso and UIAutomator. ## Espresso setup {#espresso-setup} @@ -564,8 +555,7 @@ API_LEVELS = [ ## Known issues {#known-issues} -- [Forked adb server processes are not terminated after - tests](https://github.com/bazelbuild/bazel/issues/4853) +- [Forked adb server processes are not terminated after tests](https://github.com/bazelbuild/bazel/issues/4853) - While APK building works on all platforms (Linux, macOS, Windows), testing only works on Linux. - Even with `--config=local_adb`, users still need to specify diff --git a/docs/android-ndk.mdx b/docs/android-ndk.mdx index 363b3620..abd76409 100644 --- a/docs/android-ndk.mdx +++ b/docs/android-ndk.mdx @@ -4,8 +4,7 @@ title: 'Using the Android Native Development Kit with Bazel' -_If you're new to Bazel, please start with the [Building Android with -Bazel](/start/android-app ) tutorial._ +_If you're new to Bazel, please start with the [Building Android with Bazel](/start/android-app) tutorial._ ## Overview {#overview} @@ -157,8 +156,7 @@ more details. ## Example setup {#example-setup} -This example is available in the [Bazel examples -repository](https://github.com/bazelbuild/examples/tree/master/android/ndk). +This example is available in the [Bazel examples repository](https://github.com/bazelbuild/examples/tree/master/android/ndk). In the `BUILD.bazel` file, three targets are defined with the `android_binary`, `android_library`, and `cc_library` rules. diff --git a/docs/configurable-attributes.mdx b/docs/configurable-attributes.mdx index 075431b7..8048f3a6 100644 --- a/docs/configurable-attributes.mdx +++ b/docs/configurable-attributes.mdx @@ -4,8 +4,7 @@ title: 'Configurable Build Attributes' -**_Configurable attributes_**, commonly known as [`select()`]( -/reference/be/functions#select), is a Bazel feature that lets users toggle the values +**_Configurable attributes_**, commonly known as [`select()`](/reference/be/functions#select), is a Bazel feature that lets users toggle the values of build rule attributes at the command line. This can be used, for example, for a multiplatform library that automatically @@ -410,8 +409,7 @@ sh_library( ) ``` -If you need a `select` to match when multiple conditions match, consider [AND -chaining](#and-chaining). +If you need a `select` to match when multiple conditions match, consider [AND chaining](#and-chaining). ## OR chaining {#or-chaining} diff --git a/docs/user-manual.mdx b/docs/user-manual.mdx index 95e95954..66d8a7e2 100644 --- a/docs/user-manual.mdx +++ b/docs/user-manual.mdx @@ -1148,10 +1148,7 @@ This option causes Bazel's execution phase to print the full command line for each command prior to executing it. 
-  >>>>> # //examples/cpp:hello-world [action 'Linking examples/cpp/hello-world']
-  (cd /home/johndoe/.cache/bazel/_bazel_johndoe/4c084335afceb392cfbe7c31afee3a9f/bazel && \
-    exec env - \
-    /usr/bin/gcc -o bazel-out/local-fastbuild/bin/examples/cpp/hello-world -B/usr/bin/ -Wl,-z,relro,-z,now -no-canonical-prefixes -pass-exit-codes -Wl,-S -Wl,@bazel-out/local_linux-fastbuild/bin/examples/cpp/hello-world-2.params)
+  >>>>> # //examples/cpp:hello-world [action 'Linking examples/cpp/hello-world'](cd /home/johndoe/.cache/bazel/_bazel_johndoe/4c084335afceb392cfbe7c31afee3a9f/bazel && \ exec env - \ /usr/bin/gcc -o bazel-out/local-fastbuild/bin/examples/cpp/hello-world -B/usr/bin/ -Wl,-z,relro,-z,now -no-canonical-prefixes -pass-exit-codes -Wl,-S -Wl,@bazel-out/local_linux-fastbuild/bin/examples/cpp/hello-world-2.params)
Where possible, commands are printed in a Bourne shell compatible syntax, diff --git a/extending/auto-exec-groups.mdx b/extending/auto-exec-groups.mdx index 36bcab48..48100b71 100644 --- a/extending/auto-exec-groups.mdx +++ b/extending/auto-exec-groups.mdx @@ -29,9 +29,7 @@ doesn't detect that ([the error](#first-error-message) is raised), you can set If you need to use multiple toolchains on a single execution platform (an action uses executable or tools from two or more toolchains), you need to manually -define [exec_groups][exec_groups] (check -[When should I use a custom exec_group?][multiple_toolchains_exec_groups] -section). +define [exec_groups][exec_groups](check [When should I use a custom exec_group?][multiple_toolchains_exec_groups] section). ## History {#history} @@ -44,8 +42,7 @@ my_rule = rule( ) ``` -Rule `my_rule` registers two toolchain types. This means that the [Toolchain -Resolution](https://bazel.build/extending/toolchains#toolchain-resolution) used +Rule `my_rule` registers two toolchain types. This means that the [Toolchain Resolution](https://bazel.build/extending/toolchains#toolchain-resolution) used to find an execution platform which supports both toolchain types. The selected execution platform was used for each registered action inside the rule, unless specified differently with [exec_groups][exec_groups]. diff --git a/extending/concepts.mdx b/extending/concepts.mdx index 3864fc88..988538fa 100644 --- a/extending/concepts.mdx +++ b/extending/concepts.mdx @@ -22,16 +22,14 @@ Before learning the more advanced concepts, first: ## Macros and rules {#macros-and-rules} A macro is a function that instantiates rules. Macros come in two flavors: -[symbolic macros](/extending/macros) (new in Bazel 8) and [legacy -macros](/extending/legacy-macros). The two flavors of macros are defined +[symbolic macros](/extending/macros) (new in Bazel 8) and [legacy macros](/extending/legacy-macros). The two flavors of macros are defined differently, but behave almost the same from the point of view of a user. A macro is useful when a `BUILD` file is getting too repetitive or too complex, as it lets you reuse some code. The function is evaluated as soon as the `BUILD` file is read. After the evaluation of the `BUILD` file, Bazel has little information about macros. If your macro generates a `genrule`, Bazel will behave *almost* as if you declared that `genrule` in the `BUILD` file. (The one -exception is that targets declared in a symbolic macro have [special visibility -semantics](/extending/macros#visibility): a symbolic macro can hide its internal +exception is that targets declared in a symbolic macro have [special visibility semantics](/extending/macros#visibility): a symbolic macro can hide its internal targets from the rest of the package.) A [rule](/extending/rules) is more powerful than a macro. It can access Bazel @@ -78,8 +76,7 @@ they will not be executed. ## Creating extensions * [Create your first macro](/rules/macro-tutorial) in order to reuse some code. - Then [learn more about macros](/extending/macros) and [using them to create - "custom verbs"](/rules/verbs-tutorial). + Then [learn more about macros](/extending/macros) and [using them to create "custom verbs"](/rules/verbs-tutorial). * [Follow the rules tutorial](/rules/rules-tutorial) to get started with rules. Next, you can read more about the [rules concepts](/extending/rules). @@ -94,8 +91,7 @@ them within reach: ## Going further In addition to [macros](/extending/macros) and [rules](/extending/rules), you -may want to write [aspects](/extending/aspects) and [repository -rules](/external/repo). +may want to write [aspects](/extending/aspects) and [repository rules](/external/repo). * Use [Buildifier](https://github.com/bazelbuild/buildtools) consistently to format and lint your code. diff --git a/extending/depsets.mdx b/extending/depsets.mdx index 4e84d3f2..8f0f31b0 100644 --- a/extending/depsets.mdx +++ b/extending/depsets.mdx @@ -113,8 +113,7 @@ need to ensure that if `B` depends on `A`, then `A.o` comes before `B.o` on the linker’s command line. Other tools might have the opposite requirement. Three traversal orders are supported: `postorder`, `preorder`, and -`topological`. The first two work exactly like [tree -traversals](https://en.wikipedia.org/wiki/Tree_traversal#Depth-first_search) +`topological`. The first two work exactly like [tree traversals](https://en.wikipedia.org/wiki/Tree_traversal#Depth-first_search) except that they operate on DAGs and skip already visited nodes. The third order works as a topological sort from root to leaves, essentially the same as preorder except that shared children are listed only after all of their parents. diff --git a/extending/exec-groups.mdx b/extending/exec-groups.mdx index bd2e6db1..68003af0 100644 --- a/extending/exec-groups.mdx +++ b/extending/exec-groups.mdx @@ -72,8 +72,7 @@ test rules. In the rule implementation, you can declare that actions should be run on the execution platform of an execution group. You can do this by using the `exec_group` -param of action generating methods, specifically [`ctx.actions.run`] -(/rules/lib/builtins/actions#run) and +param of action generating methods, specifically [`ctx.actions.run`](/rules/lib/builtins/actions#run) and [`ctx.actions.run_shell`](/rules/lib/builtins/actions#run_shell). ```python diff --git a/extending/macros.mdx b/extending/macros.mdx index 7920d7c6..30b7d5fe 100644 --- a/extending/macros.mdx +++ b/extending/macros.mdx @@ -33,8 +33,7 @@ two required parameters: `attrs` and `implementation`. ### Attributes {#attributes} -`attrs` accepts a dictionary of attribute name to [attribute -types](https://bazel.build/rules/lib/toplevel/attr#members), which represents +`attrs` accepts a dictionary of attribute name to [attribute types](https://bazel.build/rules/lib/toplevel/attr#members), which represents the arguments to the macro. Two common attributes – `name` and `visibility` – are implicitly added to all macros and are not included in the dictionary passed to `attrs`. @@ -68,9 +67,7 @@ To support this pattern, a macro can *inherit attributes* from a rule or another macro by passing the [rule](https://bazel.build/rules/lib/builtins/rule) or [macro symbol](https://bazel.build/rules/lib/builtins/macro) to `macro()`'s `inherit_attrs` argument. (You can also use the special string `"common"` -instead of a rule or macro symbol to inherit the [common attributes defined for -all Starlark build -rules](https://bazel.build/reference/be/common-definitions#common-attributes).) +instead of a rule or macro symbol to inherit the [common attributes defined for all Starlark build rules](https://bazel.build/reference/be/common-definitions#common-attributes).) Only public attributes get inherited, and the attributes in the macro's own `attrs` dictionary override inherited attributes with the same name. You can also *remove* inherited attributes by using `None` as a value in the `attrs` diff --git a/extending/platforms.mdx b/extending/platforms.mdx index 7009de11..f95f5e6a 100644 --- a/extending/platforms.mdx +++ b/extending/platforms.mdx @@ -256,8 +256,7 @@ cc_library( You can use the [`IncompatiblePlatformProvider`](/rules/lib/providers/IncompatiblePlatformProvider) -in `bazel cquery`'s [Starlark output -format](/query/cquery#output-format-definition) to distinguish +in `bazel cquery`'s [Starlark output format](/query/cquery#output-format-definition) to distinguish incompatible targets from compatible ones. This can be used to filter out incompatible targets. The example below will @@ -278,5 +277,4 @@ $ bazel cquery //... --output=starlark --starlark:file=example.cquery ### Known Issues -Incompatible targets [ignore visibility -restrictions](https://github.com/bazelbuild/bazel/issues/16044). +Incompatible targets [ignore visibility restrictions](https://github.com/bazelbuild/bazel/issues/16044). diff --git a/extending/rules.mdx b/extending/rules.mdx index 07515c96..1078fd74 100644 --- a/extending/rules.mdx +++ b/extending/rules.mdx @@ -451,8 +451,7 @@ def _example_library_impl(ctx): If `DefaultInfo` is not returned by a rule implementation or the `files` parameter is not specified, `DefaultInfo.files` defaults to all -*predeclared outputs* (generally, those created by [output -attributes](#output_attributes)). +*predeclared outputs* (generally, those created by [output attributes](#output_attributes)). Rules that perform actions should provide default outputs, even if those outputs are not expected to be directly used. Actions that are not in the graph of the @@ -995,8 +994,7 @@ By using `configuration_field`, the dependency on the Java LCOV merger tool can be avoided as long as coverage is not requested. When the test is run, it should emit coverage information in the form of one or -more [LCOV files] -(https://manpages.debian.org/unstable/lcov/geninfo.1.en.html#TRACEFILE_FORMAT) +more [LCOV files](https://manpages.debian.org/unstable/lcov/geninfo.1.en.html#TRACEFILE_FORMAT) with unique names into the directory specified by the `COVERAGE_DIR` environment variable. Bazel will then merge these files into a single LCOV file using the `_lcov_merger` tool. If present, it will also collect C/C++ coverage using the diff --git a/extending/toolchains.mdx b/extending/toolchains.mdx index 9534774d..33f8bac9 100644 --- a/extending/toolchains.mdx +++ b/extending/toolchains.mdx @@ -583,8 +583,7 @@ The set of available toolchains, in priority order, is created from 4. Toolchains registered in the "WORKSPACE suffix"; this is only used by certain native rules bundled with the Bazel installation. -**NOTE:** [Pseudo-targets like `:all`, `:*`, and -`/...`](/run/build#specifying-build-targets) are ordered by Bazel's package +**NOTE:** [Pseudo-targets like `:all`, `:*`, and `/...`](/run/build#specifying-build-targets) are ordered by Bazel's package loading mechanism, which uses a lexicographic ordering. The resolution steps are as follows. diff --git a/external/extension.mdx b/external/extension.mdx index 15a1961d..9a8dae94 100644 --- a/external/extension.mdx +++ b/external/extension.mdx @@ -6,8 +6,7 @@ title: 'Module extensions' Module extensions allow users to extend the module system by reading input data from modules across the dependency graph, performing necessary logic to resolve -dependencies, and finally creating repos by calling [repo -rules](/external/repo). These extensions have capabilities similar to repo +dependencies, and finally creating repos by calling [repo rules](/external/repo). These extensions have capabilities similar to repo rules, which enables them to perform file I/O, send network requests, and so on. Among other things, they allow Bazel to interact with other package management systems while also respecting the dependency graph built out of Bazel modules. diff --git a/external/faq.mdx b/external/faq.mdx index 817040a4..6c233aa5 100644 --- a/external/faq.mdx +++ b/external/faq.mdx @@ -127,16 +127,14 @@ Bazel instead uses [Minimal Version Selection](module#version-selection) like Go, which in contrast makes the output easy to predict and guarantees reproducibility. This is a tradeoff that matches Bazel's design goals. -Furthermore, Bazel module versions are [a superset of -SemVer](module#version-format), so what makes sense in a strict SemVer +Furthermore, Bazel module versions are [a superset of SemVer](module#version-format), so what makes sense in a strict SemVer environment doesn't always carry over to Bazel module versions. ### Can I automatically get the latest version for a `bazel_dep`? {#can-i-automatically-get-the-latest-version-for-a-bazel-dep} Some users occasionally ask for the ability to specify `bazel_dep(name = "foo", version = "latest")` to automatically get the latest version of a dep. This is -similar to [the question about SemVer -ranges](#can-i-specify-a-semver-range-for-a-bazel-dep), and the answer is also +similar to [the question about SemVer ranges](#can-i-specify-a-semver-range-for-a-bazel-dep), and the answer is also no. The recommended solution here is to have automation take care of this. For @@ -194,8 +192,7 @@ wonder which system is consulted first. The short answer is that MODULE.bazel The long answer is that "which evaluates first" is not the right question to ask; rather, the right question to ask is: in the context of the repo with -[canonical name](overview#canonical-repo-name) `@@foo`, what does the [apparent -repo name](overview#apparent-repo-name) `@bar` resolve to? Alternatively, what +[canonical name](overview#canonical-repo-name) `@@foo`, what does the [apparent repo name](overview#apparent-repo-name) `@bar` resolve to? Alternatively, what is the repo mapping of `@@base`? Labels with apparent repo names (a single leading `@`) can refer to different @@ -204,8 +201,7 @@ things based on the context they're resolved from. When you see a label what the context repo is: for example, if the label is in a BUILD file located in the repo `@@foo`, then the context repo is `@@foo`. -Then, depending on what the context repo is, the ["repository -visibility" table](migration#repository-visibility) in the migration guide can +Then, depending on what the context repo is, the ["repository visibility" table](migration#repository-visibility) in the migration guide can be used to find out which repo an apparent name actually resolves to. * If the context repo is the main repo (`@@`): @@ -257,8 +253,7 @@ as the context repo. Use the `bazel fetch` command to prefetch repos. You can use the `--repo` flag (like `bazel fetch --repo @foo`) to fetch only the repo `@foo` (resolved in the -context of the main repo, see [question -above](#which-is-evaluated-first-module-bazel-or-workspace)), or use a target +context of the main repo, see [question above](#which-is-evaluated-first-module-bazel-or-workspace)), or use a target pattern (like `bazel fetch @foo//:bar`) to fetch all transitive dependencies of `@foo//:bar` (this is equivalent to `bazel build --nobuild @foo//:bar`). @@ -308,21 +303,17 @@ preferring IPv4 if enabled. In some situations, for example when the IPv4 network cannot resolve/reach external addresses, this can cause `Network unreachable` exceptions and build failures. In these cases, you can override Bazel's behavior to prefer IPv6 by using the -[`java.net.preferIPv6Addresses=true` system -property](https://docs.oracle.com/javase/8/docs/api/java/net/doc-files/net-properties.html). +[`java.net.preferIPv6Addresses=true` system property](https://docs.oracle.com/javase/8/docs/api/java/net/doc-files/net-properties.html). Specifically: -* Use `--host_jvm_args=-Djava.net.preferIPv6Addresses=true` [startup - option](/docs/user-manual#startup-options), for example by adding the +* Use `--host_jvm_args=-Djava.net.preferIPv6Addresses=true` [startup option](/docs/user-manual#startup-options), for example by adding the following line in your [`.bazelrc` file](/run/bazelrc): `startup --host_jvm_args=-Djava.net.preferIPv6Addresses=true` * When running Java build targets that need to connect to the internet (such as for integration tests), use the - `--jvmopt=-Djava.net.preferIPv6Addresses=true` [tool - flag](/docs/user-manual#jvmopt). For example, include in your [`.bazelrc` - file](/run/bazelrc): + `--jvmopt=-Djava.net.preferIPv6Addresses=true` [tool flag](/docs/user-manual#jvmopt). For example, include in your [`.bazelrc` file](/run/bazelrc): `build --jvmopt=-Djava.net.preferIPv6Addresses` @@ -330,8 +321,7 @@ Specifically: [`rules_jvm_external`](https://github.com/bazelbuild/rules_jvm_external) for dependency version resolution, also add `-Djava.net.preferIPv6Addresses=true` to the `COURSIER_OPTS` environment - variable to [provide JVM options for - Coursier](https://github.com/bazelbuild/rules_jvm_external#provide-jvm-options-for-coursier-with-coursier_opts). + variable to [provide JVM options for Coursier](https://github.com/bazelbuild/rules_jvm_external#provide-jvm-options-for-coursier-with-coursier_opts). ### Can repo rules be run remotely with remote execution? {#can-repo-rules-be-run-remotely-with-remote-execution} @@ -356,9 +346,7 @@ build rules, which would naturally allow them to be run remotely, but conversely raise new architectural concerns (for example, the `query` commands would potentially need to run actions, complicating their design). -For more previous discussion on this topic, see [A way to support repositories -that need Bazel for being -fetched](https://github.com/bazelbuild/bazel/discussions/20464). +For more previous discussion on this topic, see [A way to support repositories that need Bazel for being fetched](https://github.com/bazelbuild/bazel/discussions/20464). [npm-semver]: https://docs.npmjs.com/about-semantic-versioning [cargo-semver]: https://doc.rust-lang.org/cargo/reference/specifying-dependencies.html#version-requirement-syntax diff --git a/external/migration.mdx b/external/migration.mdx index 38e049fd..57e55285 100644 --- a/external/migration.mdx +++ b/external/migration.mdx @@ -4,8 +4,7 @@ title: 'Bzlmod Migration Guide' -Due to the [shortcomings of -WORKSPACE](/external/overview#workspace-shortcomings), Bzlmod is replacing the +Due to the [shortcomings of WORKSPACE](/external/overview#workspace-shortcomings), Bzlmod is replacing the legacy WORKSPACE system. The WORKSPACE file is already disabled in Bazel 8 (late 2024) and will be removed in Bazel 9 (late 2025). This guide helps you migrate your project to Bzlmod and drop WORKSPACE for managing external dependencies. @@ -31,8 +30,7 @@ Recommended migration process: streamline the migration process as much as possible. 2. If there are errors left after using the migration tool, resolve them manually. For understanding the main differences between concepts inside - `WORKSPACE` and `MODULE.bazel` files, check [WORKSPACE versus - Bzlmod](#workspace-vs-bzlmod) section. + `WORKSPACE` and `MODULE.bazel` files, check [WORKSPACE versus Bzlmod](#workspace-vs-bzlmod) section. ## WORKSPACE vs Bzlmod {#workspace-vs-bzlmod} @@ -142,9 +140,7 @@ Bazel module when it also adopts Bzlmod. * **Bzlmod** - With Bzlmod, as long as your dependency is available in [Bazel Central - Registry](https://registry.bazel.build) or your custom [Bazel - registry](/external/registry), you can simply depend on it with a + With Bzlmod, as long as your dependency is available in [Bazel Central Registry](https://registry.bazel.build) or your custom [Bazel registry](/external/registry), you can simply depend on it with a [`bazel_dep`](/rules/lib/globals/module#bazel_dep) directive. ```python @@ -175,8 +171,7 @@ repository. If your dependency is not a Bazel project or not yet available in any Bazel registry, you can introduce it using -[`use_repo_rule`](/external/module#use_repo_rule) or [module -extensions](/external/extension). +[`use_repo_rule`](/external/module#use_repo_rule) or [module extensions](/external/extension). * **WORKSPACE** @@ -617,8 +612,7 @@ flag after fetching all repos needed for a build. ## Manual migration {#manual-migration} This section provides useful information and guidance for your **manual** Bzlmod -migration process. For more automatized migration process, check [recommended -migration process](#how-migrate-to-bzlmod) section. +migration process. For more automatized migration process, check [recommended migration process](#how-migrate-to-bzlmod) section. ### Know your dependencies in WORKSPACE {#know-deps-in-workspace} @@ -632,8 +626,7 @@ macros. Fortunately, the flag [`--experimental_repository_resolved_file`][resolved_file_flag] can help. This flag essentially generates a "lock file" of all fetched external -dependencies in your last Bazel command. You can find more details in this [blog -post](https://blog.bazel.build/2018/07/09/bazel-sync-and-resolved-file.html). +dependencies in your last Bazel command. You can find more details in this [blog post](https://blog.bazel.build/2018/07/09/bazel-sync-and-resolved-file.html). [resolved_file_flag]: /reference/command-line-reference#flag--experimental_repository_resolved_file @@ -674,11 +667,9 @@ You may also know `bazel query` can be used for inspecting repository rules with bazel query --output=build //external: ``` -While it is more convenient and much faster, [bazel query can lie about -external dependency version](https://github.com/bazelbuild/bazel/issues/12947), +While it is more convenient and much faster, [bazel query can lie about external dependency version](https://github.com/bazelbuild/bazel/issues/12947), so be careful using it! Querying and inspecting external -dependencies with Bzlmod is going to achieved by a [new -subcommand](https://github.com/bazelbuild/bazel/issues/15365). +dependencies with Bzlmod is going to achieved by a [new subcommand](https://github.com/bazelbuild/bazel/issues/15365). #### Built-in default dependencies {#builtin-default-deps} @@ -725,8 +716,7 @@ Using the WORKSPACE.bzlmod file can make the migration easier because: #### Repository visibility {#repository-visibility} Bzlmod is able to control which other repositories are visible from a given -repository, check [repository names and strict -deps](/external/module#repository_names_and_strict_deps) for more details. +repository, check [repository names and strict deps](/external/module#repository_names_and_strict_deps) for more details. Here is a summary of repository visibilities from different types of repositories when also taking WORKSPACE into consideration. @@ -739,8 +729,7 @@ repositories when also taking WORKSPACE into consideration. | WORKSPACE Repos | All visible | Not visible | Not visible | All visible | Note: For the root module, if a repository `@foo` is defined in WORKSPACE and -`@foo` is also used as an [apparent repository -name](/external/overview#apparent-repo-name) in MODULE.bazel, then `@foo` +`@foo` is also used as an [apparent repository name](/external/overview#apparent-repo-name) in MODULE.bazel, then `@foo` refers to the one introduced in MODULE.bazel. Note: For a module extension generated repository `@bar`, if `@foo` is used as @@ -785,9 +774,7 @@ the project. Take note of a few things when creating the source archive: GitHub isn't going to guarantee the checksum of source archives generated on demand. In short, URLs in the form of `https://github.com///releases/download/...` is considered stable - while `https://github.com///archive/...` is not. Check [GitHub - Archive Checksum - Outage](https://blog.bazel.build/2023/02/15/github-archive-checksum.html) + while `https://github.com///archive/...` is not. Check [GitHub Archive Checksum Outage](https://blog.bazel.build/2023/02/15/github-archive-checksum.html) for more context. * **Make sure the source tree follows the layout of the original repository.** @@ -816,8 +803,7 @@ Pull Request. [bcr_contrib_guide]: https://github.com/bazelbuild/bazel-central-registry/tree/main/docs#contribute-a-bazel-module -It is **highly recommended** to set up the [Publish to -BCR](https://github.com/bazel-contrib/publish-to-bcr) GitHub App for your +It is **highly recommended** to set up the [Publish to BCR](https://github.com/bazel-contrib/publish-to-bcr) GitHub App for your repository to automate the process of submitting your module to the BCR. ## Best practices {#best-practices} diff --git a/external/migration_tool.mdx b/external/migration_tool.mdx index e9435ced..cf59c153 100644 --- a/external/migration_tool.mdx +++ b/external/migration_tool.mdx @@ -102,8 +102,7 @@ migrate2bzlmod -t <targets> script. * `extension_for_XXX` - A file containing a module extension definition. The migration tool generates these files for dependencies that - are not standard Bazel modules but can be managed using Bzlmod's [module - extensions](/external/extension). + are not standard Bazel modules but can be managed using Bzlmod's [module extensions](/external/extension). ### Flags {#migration-script-flags} @@ -300,8 +299,7 @@ def my_custom_macro(name): The end goal is to have `MODULE.bazel` file and delete the `WORKSPACE` file, without impacting the user experience. -The first step is to follow [How to Use the Migration -Tool](#migration-tool-how-to-use), which mostly is checking the bazel version +The first step is to follow [How to Use the Migration Tool](#migration-tool-how-to-use), which mostly is checking the bazel version (it must be Bazel 7) and adding an alias to the migration script. Then, running `migrate2bzlmod -t=//...` outputs: @@ -634,8 +632,7 @@ may arise during the Bzlmod migration. ### Migration Report Generation {#migration-tool-report-generation} This file is updated with each run of the migration script or it's generated -from scratch if it's the first run or if the [`--i` -flag](#migration-script-flags) is used. The report contains: +from scratch if it's the first run or if the [`--i` flag](#migration-script-flags) is used. The report contains: * Command for local testing. * List of direct dependencies (at least the ones which are directly used in diff --git a/external/mod-command.mdx b/external/mod-command.mdx index 69a3cd8c..725f5df1 100644 --- a/external/mod-command.mdx +++ b/external/mod-command.mdx @@ -64,11 +64,9 @@ The available subcommands and their respective required arguments are: * ``: All present versions of the module ``. -* `@`: The repo with the given [apparent - name](overview#apparent-repo-name) in the context of the `--base_module`. +* `@`: The repo with the given [apparent name](overview#apparent-repo-name) in the context of the `--base_module`. -* `@@`: The repo with the given [canonical - name](overview#canonical-repo-name). +* `@@`: The repo with the given [canonical name](overview#canonical-repo-name). In a context requiring specifying modules, ``s referring to repos that correspond to modules (as opposed to extension-generated repos) can also be @@ -92,8 +90,7 @@ The following options only affect the subcommands that print graphs (`graph`, information about the version resolution of each module. If the module version changed during resolution, show either which version replaced it or what was the original version, the reason it was replaced, and which modules - requested the new version if the reason was [Minimal Version - Selection](module#version-selection). + requested the new version if the reason was [Minimal Version Selection](module#version-selection). * `--include_unused` *default: "false"*: Include in the output graph the modules which were originally present in the dependency graph, but became diff --git a/external/module.mdx b/external/module.mdx index e3fe9137..498b9951 100644 --- a/external/module.mdx +++ b/external/module.mdx @@ -56,8 +56,7 @@ Any valid SemVer version is a valid Bazel module version. Additionally, two SemVer versions `a` and `b` compare `a < b` if and only if the same holds when they're compared as Bazel module versions. -Finally, to learn more about module versioning, [see the `MODULE.bazel` -FAQ](faq#module-versioning-best-practices). +Finally, to learn more about module versioning, [see the `MODULE.bazel` FAQ](faq#module-versioning-best-practices). ## Version selection {#version-selection} @@ -111,8 +110,7 @@ serves multiple purposes: version, regardless of which versions of the dependency are requested in the dependency graph. * With the `registry` attribute, you can force this dependency to come from a - specific registry, instead of following the normal [registry - selection](/external/registry#selecting_registries) process. + specific registry, instead of following the normal [registry selection](/external/registry#selecting_registries) process. * With the `patch*` attributes, you can specify a set of patches to apply to the downloaded module. @@ -153,8 +151,7 @@ Bazel supports the following non-registry overrides: Note that setting a version value in the source archive `MODULE.bazel` can have downsides when the module is being overridden with a non-registry override. To -learn more about this [see the `MODULE.bazel` -FAQ](faq#module-versioning-best-practices). +learn more about this [see the `MODULE.bazel` FAQ](faq#module-versioning-best-practices). ## Define repos that don't represent Bazel modules {#use_repo_rule} @@ -162,13 +159,11 @@ With `bazel_dep`, you can define repos that represent other Bazel modules. Sometimes there is a need to define a repo that does _not_ represent a Bazel module; for example, one that contains a plain JSON file to be read as data. -In this case, you could use the [`use_repo_rule` -directive](/rules/lib/globals/module#use_repo_rule) to directly define a repo +In this case, you could use the [`use_repo_rule` directive](/rules/lib/globals/module#use_repo_rule) to directly define a repo by invoking a repo rule. This repo will only be visible to the module it's defined in. -Under the hood, this is implemented using the same mechanism as [module -extensions](/external/extension), which lets you define repos with more +Under the hood, this is implemented using the same mechanism as [module extensions](/external/extension), which lets you define repos with more flexibility. ## Repository names and strict deps diff --git a/external/overview.mdx b/external/overview.mdx index c6a24ec4..409dcd46 100644 --- a/external/overview.mdx +++ b/external/overview.mdx @@ -15,8 +15,7 @@ concepts in more detail. ## Overview of the system {#overview} -Bazel's external dependency system works on the basis of [*Bazel -modules*](#module), each of which is a versioned Bazel project, and +Bazel's external dependency system works on the basis of [*Bazel modules*](#module), each of which is a versioned Bazel project, and [*repositories*](#repository) (or repos), which are directory trees containing source files. @@ -33,8 +32,7 @@ bazel_dep(name = "platforms", version = "0.0.11") ``` From there, Bazel looks up all transitive dependency modules in a -[*Bazel registry*](registry) — by default, the [Bazel Central -Registry](https://bcr.bazel.build/). The registry provides the +[*Bazel registry*](registry) — by default, the [Bazel Central Registry](https://bcr.bazel.build/). The registry provides the dependencies' `MODULE.bazel` files, which allows Bazel to discover the entire transitive dependency graph before performing version resolution. @@ -106,8 +104,7 @@ Bazel's external dependency system offers a wide range of benefits. need to facilitate offline builds. - **[Lockfile](lockfile)**: The lockfile improves build reproducibility and accelerates dependency resolution. -- **(Upcoming) [BCR Provenance - Attestations](https://github.com/bazelbuild/bazel-central-registry/discussions/2721)**: +- **(Upcoming) [BCR Provenance Attestations](https://github.com/bazelbuild/bazel-central-registry/discussions/2721)**: Strengthen supply chain security by ensuring verified provenance of dependencies. @@ -231,8 +228,7 @@ contain anything to serve as a repo boundary file; however, it can also be used to specify some common attributes for all build targets inside the repo. The syntax of a `REPO.bazel` file is similar to `BUILD` files, except that no -`load` statements are supported. The `repo()` function takes the same arguments as the [`package()` -function](/reference/be/functions#package) in `BUILD` files; whereas `package()` +`load` statements are supported. The `repo()` function takes the same arguments as the [`package()` function](/reference/be/functions#package) in `BUILD` files; whereas `package()` specifies common attributes for all build targets inside the package, `repo()` analogously does so for all build targets inside the repo. diff --git a/external/registry.mdx b/external/registry.mdx index 1d441581..d0095622 100644 --- a/external/registry.mdx +++ b/external/registry.mdx @@ -21,14 +21,12 @@ An index registry must have the following format: * `/modules`: A directory containing a subdirectory for each module in this registry * `/modules/$MODULE`: A directory containing a subdirectory for each version - of the module named `$MODULE`, as well as the [`metadata.json` - file](#metadata-json) containing metadata for this module. + of the module named `$MODULE`, as well as the [`metadata.json` file](#metadata-json) containing metadata for this module. * `/modules/$MODULE/$VERSION`: A directory containing the following files: * `MODULE.bazel`: The `MODULE.bazel` file of this module version. Note that this is the `MODULE.bazel` file read during Bazel's external dependency resolution, _not_ the one from the source archive (unless - there's a [non-registry - override](/external/module#non-registry_overrides)). Also note that it's + there's a [non-registry override](/external/module#non-registry_overrides)). Also note that it's best to use this file to set the version of a release and avoid doing so in the source archive `MODULE.bazel` file. To learn more about module versioning, [see the FAQ](faq.md#module-versioning-best-practices). @@ -65,8 +63,7 @@ module, with the following fields: * `versions`: An array of strings, each denoting a version of the module available in this registry. This array should match the children of the module directory. -* `yanked_versions`: A JSON object specifying the [*yanked* - versions](/external/module#yanked_versions) of this module. The keys +* `yanked_versions`: A JSON object specifying the [*yanked* versions](/external/module#yanked_versions) of this module. The keys should be versions to yank, and the values should be descriptions of why the version is yanked, ideally containing a link to more information. diff --git a/external/repo.mdx b/external/repo.mdx index b878f030..958d403e 100644 --- a/external/repo.mdx +++ b/external/repo.mdx @@ -76,8 +76,7 @@ specified. The input parameter `repository_ctx` can be used to access attribute values, and non-hermetic functions (finding a binary, executing a binary, creating a file in -the repository or downloading a file from the Internet). See [the API -docs](/rules/lib/builtins/repository_ctx) for more context. Example: +the repository or downloading a file from the Internet). See [the API docs](/rules/lib/builtins/repository_ctx) for more context. Example: ```python def _impl(repository_ctx): @@ -146,8 +145,7 @@ definition has the `configure` attribute set, use `bazel fetch --force ## Examples -- [C++ auto-configured - toolchain](https://cs.opensource.google/bazel/bazel/+/master:tools/cpp/cc_configure.bzl;drc=644b7d41748e09eff9e47cbab2be2263bb71f29a;l=176): +- [C++ auto-configured toolchain](https://cs.opensource.google/bazel/bazel/+/master:tools/cpp/cc_configure.bzl;drc=644b7d41748e09eff9e47cbab2be2263bb71f29a;l=176): it uses a repo rule to automatically create the C++ configuration files for Bazel by looking for the local C++ compiler, the environment and the flags the C++ compiler supports. diff --git a/external/vendor.mdx b/external/vendor.mdx index 2c850def..ab82c46c 100644 --- a/external/vendor.mdx +++ b/external/vendor.mdx @@ -25,9 +25,7 @@ absolute path. ## Vendor a specific external repository {#vendor-specific-repository} You can use the `vendor` command with the `--repo` flag to specify which repo -to vendor, it accepts both [canonical repo -name](/external/overview#canonical-repo-name) and [apparent repo -name](/external/overview#apparent-repo-name). +to vendor, it accepts both [canonical repo name](/external/overview#canonical-repo-name) and [apparent repo name](/external/overview#apparent-repo-name). For example, running: diff --git a/help.mdx b/help.mdx index 6226c6e5..e6a1d79e 100644 --- a/help.mdx +++ b/help.mdx @@ -51,5 +51,4 @@ what level of support Bazel provides. ## File a bug {#file-bug} -If you encounter a bug or want to request a feature, file a [GitHub -Issue](https://github.com/bazelbuild/bazel/issues). +If you encounter a bug or want to request a feature, file a [GitHub Issue](https://github.com/bazelbuild/bazel/issues). diff --git a/install/bazelisk.mdx b/install/bazelisk.mdx index 6c0d5cc1..3acb1147 100644 --- a/install/bazelisk.mdx +++ b/install/bazelisk.mdx @@ -18,8 +18,7 @@ For more details, see ## Updating Bazel Bazel has a [backward compatibility policy](/release/backward-compatibility) -(see [guidance for rolling out incompatible -changes](/contribute/breaking-changes) if you +(see [guidance for rolling out incompatible changes](/contribute/breaking-changes) if you are the author of one). That page summarizes best practices on how to test and migrate your project with upcoming incompatible changes and how to provide feedback to the incompatible change authors. diff --git a/install/compile-source.mdx b/install/compile-source.mdx index c2fb5afd..9479e0cb 100644 --- a/install/compile-source.mdx +++ b/install/compile-source.mdx @@ -55,8 +55,7 @@ it by typing `bazel` in a terminal. **Reason**: To build Bazel from a GitHub source tree, you need a pre-existing Bazel binary. You can install one from a package manager or download one from -GitHub. See [Installing Bazel](/install). (Or you can [build from -scratch (bootstrap)](#bootstrap-bazel).) +GitHub. See [Installing Bazel](/install). (Or you can [build from scratch (bootstrap)](#bootstrap-bazel).) **Troubleshooting**: @@ -248,8 +247,7 @@ For instructions for Unix-like systems, see ``` * **The Visual C++ compiler.** Install the Visual C++ compiler either as part - of Visual Studio 2015 or newer, or by installing the latest [Build Tools - for Visual Studio 2017](https://aka.ms/BuildTools). + of Visual Studio 2015 or newer, or by installing the latest [Build Tools for Visual Studio 2017](https://aka.ms/BuildTools). * **JDK.** Version 21 is required. diff --git a/install/ide.mdx b/install/ide.mdx index 22ee969f..d43d0696 100644 --- a/install/ide.mdx +++ b/install/ide.mdx @@ -23,10 +23,8 @@ a discussion on [GitHub](https://github.com/bazelbuild/bazel/discussions). Official Bazel plugins exist for many of the JetBrains-associated IDEs. Full documentation is linked from the listings on the JetBrains Marketplace: -* [IntelliJ - plugin](https://plugins.jetbrains.com/plugin/22977-bazel) -* [Android Studio - plugin](https://plugins.jetbrains.com/plugin/9185-android-studio-with-bazel) +* [IntelliJ plugin](https://plugins.jetbrains.com/plugin/22977-bazel) +* [Android Studio plugin](https://plugins.jetbrains.com/plugin/9185-android-studio-with-bazel) * [CLion plugin](https://plugins.jetbrains.com/plugin/9554-clion-with-bazel) Features: @@ -62,8 +60,7 @@ Features: * Starlark debugger for `.bzl` files during a build (set breakpoints, step through code, inspect variables, and so on) -Find [the plugin on the Visual Studio -marketplace](https://marketplace.visualstudio.com/items?itemName=BazelBuild.vscode-bazel) +Find [the plugin on the Visual Studio marketplace](https://marketplace.visualstudio.com/items?itemName=BazelBuild.vscode-bazel) or the [OpenVSX marketplace](https://open-vsx.org/extension/BazelBuild/vscode-bazel). The plugin is [open source](https://github.com/bazelbuild/vscode-bazel). @@ -84,8 +81,7 @@ See also: [Autocomplete for Source Code](#autocomplete-for-source-code) ### Emacs {#emacs} -See [`bazelbuild/bazel-emacs-mode` on -GitHub](https://github.com/bazelbuild/emacs-bazel-mode) +See [`bazelbuild/bazel-emacs-mode` on GitHub](https://github.com/bazelbuild/emacs-bazel-mode) See also: [Autocomplete for Source Code](#autocomplete-for-source-code) @@ -123,6 +119,5 @@ tool for building Bazel targets when source files change. ## Building your own IDE plugin {#build-own-plugin} -Read the [**IDE support** blog -post](https://blog.bazel.build/2016/06/10/ide-support.html) to learn more about +Read the [**IDE support** blog post](https://blog.bazel.build/2016/06/10/ide-support.html) to learn more about the Bazel APIs to use when building an IDE plugin. diff --git a/install/windows.mdx b/install/windows.mdx index 9b0b07de..dc2edb0a 100644 --- a/install/windows.mdx +++ b/install/windows.mdx @@ -34,8 +34,7 @@ To check your Windows version: Alternatively you can: -* [Download the Bazel binary (`bazel-version-windows-x86_64.exe`) from - GitHub](https://github.com/bazelbuild/bazel/releases). +* [Download the Bazel binary (`bazel-version-windows-x86_64.exe`) from GitHub](https://github.com/bazelbuild/bazel/releases). * [Install Bazel from Chocolatey](#chocolately) * [Install Bazel from Scoop](#scoop) * [Build Bazel from source](/install/compile-source) @@ -211,8 +210,7 @@ If that doesn't help: its dependencies, such as the MSYS2 shell. This will not install Visual C++ though. -See [Chocolatey installation and package maintenance -guide](/contribute/windows-chocolatey-maintenance) for more +See [Chocolatey installation and package maintenance guide](/contribute/windows-chocolatey-maintenance) for more information about the Chocolatey package. ### Using Scoop {#scoop} @@ -229,8 +227,7 @@ information about the Chocolatey package. scoop install bazel ``` -See [Scoop installation and package maintenance -guide](/contribute/windows-scoop-maintenance) for more +See [Scoop installation and package maintenance guide](/contribute/windows-scoop-maintenance) for more information about the Scoop package. ### Build from source {#build-from-source} diff --git a/migrate/maven.mdx b/migrate/maven.mdx index ac8a042f..3b564450 100644 --- a/migrate/maven.mdx +++ b/migrate/maven.mdx @@ -19,8 +19,7 @@ directly run by Bazel since there's no Maven compatibility layer. ## Before you begin {#before-you-begin} * [Install Bazel](/install) if it's not yet installed. -* If you're new to Bazel, go through the tutorial [Introduction to Bazel: - Build Java](/start/java) before you start migrating. The tutorial explains +* If you're new to Bazel, go through the tutorial [Introduction to Bazel: Build Java](/start/java) before you start migrating. The tutorial explains Bazel's concepts, structure, and label syntax. ## Differences between Maven and Bazel {#dif-maven-bazel} @@ -44,8 +43,7 @@ The steps below describe how to migrate your project to Bazel: 3. [Create more BUILD files](#3-build) 4. [Build using Bazel](#4-build) -Examples below come from a migration of the [Guava -project](https://github.com/google/guava) from Maven to Bazel. The +Examples below come from a migration of the [Guava project](https://github.com/google/guava) from Maven to Bazel. The Guava project used is release `v31.1`. The examples using Guava do not walk through each step in the migration, but they do show the files and contents that are generated or added manually for the migration. @@ -63,14 +61,12 @@ has no external dependencies, this file can be empty. If your project depends on files or packages that are not in one of the project's directories, specify these external dependencies in the MODULE.bazel file. You can use `rules_jvm_external` to manage dependencies from Maven. For -instructions about using this ruleset, see [the -README](https://github.com/bazelbuild/rules_jvm_external/#rules_jvm_external) +instructions about using this ruleset, see [the README](https://github.com/bazelbuild/rules_jvm_external/#rules_jvm_external) . #### Guava project example: external dependencies {#guava-1} -You can list the external dependencies of the [Guava -project](https://github.com/google/guava) with the +You can list the external dependencies of the [Guava project](https://github.com/google/guava) with the [`rules_jvm_external`](https://github.com/bazelbuild/rules_jvm_external) ruleset. @@ -164,8 +160,7 @@ your build by adding more `BUILD` files with more granular targets. * `resources`: Use globbing to list all resources in your project. * `deps`: You need to determine which external dependencies your project needs. - * Take a look at the [example below of this top-level BUILD - file](#guava-2) from the migration of the Guava project. + * Take a look at the [example below of this top-level BUILD file](#guava-2) from the migration of the Guava project. 3. Now that you have a `BUILD` file at the root of your project, build your project to ensure that it works. On the command line, from your workspace diff --git a/migrate/xcode.mdx b/migrate/xcode.mdx index 84e52f86..5f6a05a2 100644 --- a/migrate/xcode.mdx +++ b/migrate/xcode.mdx @@ -32,8 +32,7 @@ Before you begin, do the following: 1. [Install Bazel](/install) if you have not already done so. -2. If you're not familiar with Bazel and its concepts, complete the [iOS app - tutorial](/start/ios-app)). You should understand the Bazel workspace, +2. If you're not familiar with Bazel and its concepts, complete the [iOS app tutorial](/start/ios-app)). You should understand the Bazel workspace, including the `MODULE.bazel` and `BUILD` files, as well as the concepts of targets, build rules, and Bazel packages. @@ -44,8 +43,7 @@ Before you begin, do the following: Unlike Xcode, Bazel requires you to explicitly declare all dependencies for every target in the `BUILD` file. -For more information on external dependencies, see [Working with external -dependencies](/docs/external). +For more information on external dependencies, see [Working with external dependencies](/docs/external). ## Build or test an Xcode project with Bazel {#build-xcode-project} @@ -84,8 +82,7 @@ Note: Place the project source code within the directory tree containing the To integrate SwiftPM dependencies into the Bazel workspace with [swift_bazel](https://github.com/cgrindel/swift_bazel), you must -convert them into Bazel packages as described in the [following -tutorial](https://chuckgrindel.com/swift-packages-in-bazel-using-swift_bazel/) +convert them into Bazel packages as described in the [following tutorial](https://chuckgrindel.com/swift-packages-in-bazel-using-swift_bazel/) . Note: SwiftPM support is a manual process with many variables. SwiftPM @@ -103,8 +100,7 @@ initial build of the project as follows: * [Step 3b: (Optional) Add the test target(s)](#step-3b-optional-add-the-test-target-s) * [Step 3c: Add the library target(s)](#step-3c-add-the-library-target-s) -**Tip:** To learn more about packages and other Bazel concepts, see [Workspaces, -packages, and targets](/concepts/build-ref). +**Tip:** To learn more about packages and other Bazel concepts, see [Workspaces, packages, and targets](/concepts/build-ref). #### Step 3a: Add the application target {#add-app-target} @@ -132,8 +128,7 @@ In the target, specify the following at the minimum: #### Step 3b: (Optional) Add the test target(s) {#add-test-target} -Bazel's [Apple build -rules](https://github.com/bazelbuild/rules_apple) support running +Bazel's [Apple build rules](https://github.com/bazelbuild/rules_apple) support running unit and UI tests on all Apple platforms. Add test targets as follows: * [`macos_unit_test`](https://github.com/bazelbuild/rules_apple/blob/master/doc/rules-macos.md#macos_unit_test) @@ -181,8 +176,7 @@ all sources and/or headers of a certain type. Use it carefully as it might include files you do not want Bazel to build. You can browse existing examples for various types of applications directly in -the [rules_apple examples -directory](https://github.com/bazelbuild/rules_apple/tree/master/examples/). For +the [rules_apple examples directory](https://github.com/bazelbuild/rules_apple/tree/master/examples/). For example: * [macOS application targets](https://github.com/bazelbuild/rules_apple/tree/master/examples/macos) @@ -191,8 +185,7 @@ example: * [Multi platform applications (macOS, iOS, watchOS, tvOS)](https://github.com/bazelbuild/rules_apple/tree/master/examples/multi_platform) -For more information on build rules, see [Apple Rules for -Bazel](https://github.com/bazelbuild/rules_apple). +For more information on build rules, see [Apple Rules for Bazel](https://github.com/bazelbuild/rules_apple). At this point, it is a good idea to test the build: diff --git a/query/cquery.mdx b/query/cquery.mdx index e734f231..f7195d40 100644 --- a/query/cquery.mdx +++ b/query/cquery.mdx @@ -8,8 +8,7 @@ title: 'Configurable Query (cquery)' [`select()`](/docs/configurable-attributes) and build options' effects on the build graph. -It achieves this by running over the results of Bazel's [analysis -phase](/extending/concepts#evaluation-model), +It achieves this by running over the results of Bazel's [analysis phase](/extending/concepts#evaluation-model), which integrates these effects. `query`, by contrast, runs over the results of Bazel's loading phase, before options are evaluated. @@ -140,8 +139,7 @@ $ bazel cquery //foo --universe_scope=//foo,//genrule_with_foo_as_tool If you want to precisely declare which instance to query over, use the [`config`](#config) function. -See `query`'s [target pattern -documentation](/query/language#target-patterns) for more information on target +See `query`'s [target pattern documentation](/query/language#target-patterns) for more information on target patterns. ## Functions {#functions} @@ -543,8 +541,7 @@ different niches. Consider the following to decide which is right for you: It's therefore prone to picking up results from past queries. For example, `genrule` exerts an exec transition on its `tools` attribute - -that is, it configures its tools in the [exec configuration] -(https://bazel.build/rules/rules#configurations). +that is, it configures its tools in the [exec configuration](https://bazel.build/rules/rules#configurations). You can see the lingering effects of that transition below. diff --git a/query/language.mdx b/query/language.mdx index 53e11e57..ee539b29 100644 --- a/query/language.mdx +++ b/query/language.mdx @@ -1145,8 +1145,7 @@ is being used. ### On the ordering of results {#results-ordering} -Although query expressions always follow the "[law of -conservation of graph order](#graph-order)", _presenting_ the results may be done +Although query expressions always follow the "[law of conservation of graph order](#graph-order)", _presenting_ the results may be done in either a dependency-ordered or unordered manner. This does **not** influence the targets in the result set or how the query is computed. It only affects how the results are printed to stdout. Moreover, nodes that are @@ -1292,8 +1291,7 @@ and `maxrank` output formats print the labels of each target in the resulting graph, but instead of appearing in topological order, they appear in rank order, preceded by their rank number. These are unaffected by the result ordering -`--[no]order_results` flag (see [notes on -the ordering of results](#result-order)). +`--[no]order_results` flag (see [notes on the ordering of results](#result-order)). There are two variants of this format: `minrank` ranks each node by the length of the shortest path from a root node to it. diff --git a/reference/glossary.mdx b/reference/glossary.mdx index 40065154..7d1e7dd9 100644 --- a/reference/glossary.mdx +++ b/reference/glossary.mdx @@ -24,8 +24,7 @@ An in-memory graph of [actions](#action) and the [artifacts](#artifact) that these actions read and generate. The graph might include artifacts that exist as source files (for example, in the file system) as well as generated intermediate/final artifacts that are not mentioned in `BUILD` files. Produced -during the [analysis phase](#analysis-phase) and used during the [execution -phase](#execution-phase). +during the [analysis phase](#analysis-phase) and used during the [execution phase](#execution-phase). ### Action graph query (aquery) {#action-graph-query} @@ -43,8 +42,7 @@ invalidate individual actions deterministically. ### Analysis phase {#analysis-phase} The second phase of a build. Processes the [target graph](#target-graph) -specified in [`BUILD` files](#build-file) to produce an in-memory [action -graph](#action-graph) that determines the order of actions to run during the +specified in [`BUILD` files](#build-file) to produce an in-memory [action graph](#action-graph) that determines the order of actions to run during the [execution phase](#execution-phase). This is the phase in which rule implementations are evaluated. @@ -92,8 +90,7 @@ attributes available for a given target depend on its rule type. ### .bazelrc {#bazelrc} -Bazel’s configuration file used to change the default values for [startup -flags](#startup-flags) and [command flags](#command-flags), and to define common +Bazel’s configuration file used to change the default values for [startup flags](#startup-flags) and [command flags](#command-flags), and to define common groups of options that can then be set together on the Bazel command line using a `--config` flag. Bazel can combine settings from multiple bazelrc files (systemwide, per-workspace, per-user, or from a custom location), and a @@ -123,8 +120,7 @@ directory. ### .bzl File {#bzl-file} A file that defines rules, [macros](#macro), and constants written in -[Starlark](#starlark). These can then be imported into [`BUILD` -files](#build-file) using the `load()` function. +[Starlark](#starlark). These can then be imported into [`BUILD` files](#build-file) using the `load()` function. ### Build Event Protocol {#build-event-protocol} @@ -146,8 +142,7 @@ arguments>`. A typical example would be `bazel --host_jvm_args=-Xmx512M test ### Build graph {#build-graph} The dependency graph that Bazel constructs and traverses to perform a build. -Includes nodes like [targets](#target), [configured -targets](#configured-target), [actions](#action), and [artifacts](#artifact). A +Includes nodes like [targets](#target), [configured targets](#configured-target), [actions](#action), and [artifacts](#artifact). A build is considered complete when all [artifacts](#artifact) on which a set of requested targets depend are verified as up-to-date. @@ -193,13 +188,10 @@ graphs and restart the [analysis phase](#analysis-phase). Information outside of [rule](#rule) definitions that impacts how rules generate [actions](#action). Every build has at least one configuration specifying the -target platform, action environment variables, and command-line [build -flags](#command-flags). [Transitions](#transition) may create additional +target platform, action environment variables, and command-line [build flags](#command-flags). [Transitions](#transition) may create additional configurations, such as for host tools or cross-compilation. -A configuration is composed of one of more [configuration -fragments](#configuration-fragment), and separately contains all set [Starlark -flags](#starlark-flags). +A configuration is composed of one of more [configuration fragments](#configuration-fragment), and separately contains all set [Starlark flags](#starlark-flags). **See also:** [Configurations](/extending/rules#configurations) @@ -224,8 +216,7 @@ build cacheability. ### Configured query (cquery) {#configured-query} -A [query](#query-concept) tool that queries over [configured -targets](#configured-target) (after the [analysis phase](#analysis-phase) +A [query](#query-concept) tool that queries over [configured targets](#configured-target) (after the [analysis phase](#analysis-phase) completes). This means `select()` and [build flags](#command-flags) (such as `--platforms`) are accurately reflected in the results. @@ -243,8 +234,7 @@ build, it has two configured targets: `` and ``. A build is correct when its output faithfully reflects the state of its transitive inputs. To achieve correct builds, Bazel strives to be -[hermetic](#hermeticity), reproducible, and making [build -analysis](#analysis-phase) and [action execution](#execution-phase) +[hermetic](#hermeticity), reproducible, and making [build analysis](#analysis-phase) and [action execution](#execution-phase) deterministic. ### Dependency {#dependency} @@ -292,8 +282,7 @@ incremental and clean build times. ### Execution phase {#execution-phase} -The third phase of a build. Executes the [actions](#action) in the [action -graph](#action-graph) created during the [analysis phase](#analysis-phase). +The third phase of a build. Executes the [actions](#action) in the [action graph](#action-graph) created during the [analysis phase](#analysis-phase). These actions invoke executables (compilers, scripts) to read and write [artifacts](#artifact). *Spawn strategies* control how these actions are executed: locally, remotely, dynamically, sandboxed, docker, and so on. @@ -354,8 +343,7 @@ syntax may be omitted. The first phase of a build where Bazel executes [`BUILD` files](#build-file) to create [packages](#package). [Macros](#macro) and certain functions like `glob()` are evaluated in this phase. Interleaved with the second phase of the -build, the [analysis phase](#analysis-phase), to build up a [target -graph](#target-graph). +build, the [analysis phase](#analysis-phase), to build up a [target graph](#target-graph). ### Legacy macro {#legacy-macro} @@ -410,8 +398,7 @@ Module metadata is hosted in Bazel registries. ### Module Extension {#module-extension} A piece of logic that can be run to generate [repos](#repository) by reading -inputs from across the [module](#module) dependency graph and invoking [repo -rules](#repository-rule). Module extensions have capabilities similar to repo +inputs from across the [module](#module) dependency graph and invoking [repo rules](#repository-rule). Module extensions have capabilities similar to repo rules, allowing them to access the internet, perform file I/O, and so on. **See also:** [Module extensions](/external/extension) @@ -426,8 +413,7 @@ example, `native.cc_library` or `native.java_library`). User-defined rules ### Output base {#output-base} A [workspace](#workspace)-specific directory to store Bazel output files. Used -to separate outputs from the *workspace*'s source tree (the [main -repo](#repository)). Located in the [output user root](#output-user-root). +to separate outputs from the *workspace*'s source tree (the [main repo](#repository)). Located in the [output user root](#output-user-root). ### Output groups {#output-groups} @@ -490,8 +476,7 @@ query variants: [query](#query-command), [cquery](#configured-query), and ### query (command) {#query-command} -A [query](#query-concept) tool that operates over the build's post-[loading -phase](#loading-phase) [target graph](#target-graph). This is relatively fast, +A [query](#query-concept) tool that operates over the build's post-[loading phase](#loading-phase) [target graph](#target-graph). This is relatively fast, but can't analyze the effects of `select()`, [build flags](#command-flags), [artifacts](#artifact), or build [actions](#action). @@ -510,8 +495,7 @@ repo; multiple such files can coexist in a directory. The *main repo* is the repo in which the current Bazel command is being run. *External repos* are defined by specifying [modules](#module) in `MODULE.bazel` -files, or invoking [repo rules](#repository-rule) in [module -extensions](#module-extension). They can be fetched on demand to a predetermined +files, or invoking [repo rules](#repository-rule) in [module extensions](#module-extension). They can be fetched on demand to a predetermined "magical" location on disk. Each repo has a unique, constant *canonical* name, and potentially different @@ -523,8 +507,7 @@ Each repo has a unique, constant *canonical* name, and potentially different A shared content-addressable cache of files downloaded by Bazel for builds, shareable across [workspaces](#workspace). Enables offline builds after the -initial download. Commonly used to cache files downloaded through [repository -rules](#repository-rule) like `http_archive` and repository rule APIs like +initial download. Commonly used to cache files downloaded through [repository rules](#repository-rule) like `http_archive` and repository rule APIs like `repository_ctx.download`. Files are cached only if their SHA-256 checksums are specified for the download. @@ -561,8 +544,7 @@ Rules are instantiated to produce rule targets in the [loading phase](#loading-phase). In the [analysis phase](#analysis-phase) rule targets communicate information to their downstream dependencies in the form of [providers](#provider), and register [actions](#action) describing how to -generate their output artifacts. These actions are run in the [execution -phase](#execution-phase). +generate their output artifacts. These actions are run in the [execution phase](#execution-phase). Note: Historically the term "rule" has been used to refer to a rule target. This usage was inherited from tools like Make, but causes confusion and should @@ -630,8 +612,7 @@ support the stamp attribute. The extension language for writing [rules](/extending/rules) and [macros](#macro). A restricted subset of Python (syntactically and grammatically) aimed for the -purpose of configuration, and for better performance. Uses the [`.bzl` -file](#bzl-file) extension. [`BUILD` files](#build-file) use an even more +purpose of configuration, and for better performance. Uses the [`.bzl` file](#bzl-file) extension. [`BUILD` files](#build-file) use an even more restricted version of Starlark (such as no `def` function definitions), formerly known as Skylark. @@ -640,8 +621,7 @@ known as Skylark. ### Starlark flags {#starlark-flags} Rules can define [custom flags](/extending/config#user-defined-build-settings), -known as Starlark flags because they are implemented using [Starlark -rules](#starlark-rules). These flags control how the rule behaves at a higher +known as Starlark flags because they are implemented using [Starlark rules](#starlark-rules). These flags control how the rule behaves at a higher level than individual BUILD files. **See also**: [Configurations](/extending/config) @@ -677,8 +657,7 @@ An object that is defined in a [`BUILD` file](#build-file) and identified by a [label](#label). Targets represent the buildable units of a workspace from the perspective of the end user. -A target that is declared by instantiating a [rule](#rule) is called a [rule -target](#rule-target). Depending on the rule, these may be runnable (like +A target that is declared by instantiating a [rule](#rule) is called a [rule target](#rule-target). Depending on the rule, these may be runnable (like `cc_binary`) or testable (like `cc_test`). Rule targets typically depend on other targets via their [attributes](#attribute) (such as `deps`); these dependencies form the basis of the [target graph](#target-graph). @@ -689,15 +668,12 @@ within a `BUILD` file. As a special case, the `BUILD` file of any package is always considered a source file target in that package. Targets are discovered during the [loading phase](#loading-phase). During the -[analysis phase](#analysis-phase), targets are associated with [build -configurations](#configuration) to form [configured -targets](#configured-target). +[analysis phase](#analysis-phase), targets are associated with [build configurations](#configuration) to form [configured targets](#configured-target). ### Target graph {#target-graph} An in-memory graph of [targets](#target) and their dependencies. Produced during -the [loading phase](#loading-phase) and used as an input to the [analysis -phase](#analysis-phase). +the [loading phase](#loading-phase) and used as an input to the [analysis phase](#analysis-phase). ### Target pattern {#target-pattern} @@ -712,8 +688,7 @@ packages recursively from the root of the [workspace](#workspace). Rule [targets](#target) instantiated from test rules, and therefore contains a test executable. A return code of zero from the completion of the executable indicates test success. The exact contract between Bazel and tests (such as test -environment variables, test result collection methods) is specified in the [Test -Encyclopedia](/reference/test-encyclopedia). +environment variables, test result collection methods) is specified in the [Test Encyclopedia](/reference/test-encyclopedia). ### Toolchain {#toolchain} @@ -729,8 +704,7 @@ A build [target](#target) is top-level if it’s requested on the Bazel command line. For example, if `//:foo` depends on `//:bar`, and `bazel build //:foo` is called, then for this build, `//:foo` is top-level, and `//:bar` isn’t top-level, although both targets will need to be built. An important difference -between top-level and non-top-level targets is that [command -flags](#command-flags) set on the Bazel command line (or via +between top-level and non-top-level targets is that [command flags](#command-flags) set on the Bazel command line (or via [.bazelrc](#bazelrc)) will set the [configuration](#configuration) for top-level targets, but might be modified by a [transition](#transition) for non-top-level targets. @@ -765,8 +739,7 @@ or `.bzl` file may load a given `.bzl` file. Without context, usually ### Workspace {#workspace} -The environment shared by all Bazel commands run from the same [main -repository](#repository). +The environment shared by all Bazel commands run from the same [main repository](#repository). Note that historically the concepts of "repository" and "workspace" have been conflated; the term "workspace" has often been used to refer to the main diff --git a/reference/test-encyclopedia.mdx b/reference/test-encyclopedia.mdx index b613577b..eade94bc 100644 --- a/reference/test-encyclopedia.mdx +++ b/reference/test-encyclopedia.mdx @@ -700,8 +700,7 @@ mark it as having failed. The [execution platform](/extending/platforms) for a test action is determined via [toolchain resolution](/extending/toolchains#toolchain-resolution), just -like for any other action. Each test rule has an implicitly defined [ -`test` exec group](/extending/exec-groups#exec-groups-for-native-rules) that, +like for any other action. Each test rule has an implicitly defined [`test` exec group](/extending/exec-groups#exec-groups-for-native-rules) that, unless overridden, has a mandatory toolchain requirement on `@bazel_tools//tools/test:default_test_toolchain_type`. @@ -742,8 +741,7 @@ a default toolchain for it. Some tags in the test rules have a special meaning. See also the -[Bazel Build Encyclopedia on the `tags` attribute] -(/reference/be/common-definitions#common.tags). +[Bazel Build Encyclopedia on the `tags` attribute](/reference/be/common-definitions#common.tags). diff --git a/release/backward-compatibility.mdx b/release/backward-compatibility.mdx index 780e9f71..b838e511 100644 --- a/release/backward-compatibility.mdx +++ b/release/backward-compatibility.mdx @@ -8,11 +8,9 @@ This page provides information about how to handle backward compatibility, including migrating from one release to another and how to communicate incompatible changes. -Bazel is evolving. Minor versions released as part of an [LTS major -version](/release#bazel-versioning) are fully backward-compatible. New major LTS +Bazel is evolving. Minor versions released as part of an [LTS major version](/release#bazel-versioning) are fully backward-compatible. New major LTS releases may contain incompatible changes that require some migration effort. -For more information about Bazel's release model, please check out the [Release -Model](/release) page. +For more information about Bazel's release model, please check out the [Release Model](/release) page. ## Summary {#summary} @@ -61,8 +59,7 @@ available. ## Communicating incompatible changes {#communicating-incompatible-changes} The primary source of information about incompatible changes are GitHub issues -marked with an ["incompatible-change" -label](https://github.com/bazelbuild/bazel/issues?q=label%3Aincompatible-change). +marked with an ["incompatible-change" label](https://github.com/bazelbuild/bazel/issues?q=label%3Aincompatible-change). For every incompatible change, the issue specifies the following: diff --git a/release/index.mdx b/release/index.mdx index 0f68efe0..822c08f5 100644 --- a/release/index.mdx +++ b/release/index.mdx @@ -4,8 +4,7 @@ title: 'Release Model' -As announced in [the original blog -post](https://blog.bazel.build/2020/11/10/long-term-support-release.html), Bazel +As announced in [the original blog post](https://blog.bazel.build/2020/11/10/long-term-support-release.html), Bazel 4.0 and higher versions provides support for two release tracks: rolling releases and long term support (LTS) releases. This page covers the latest information about Bazel's release model. @@ -22,13 +21,11 @@ information about Bazel's release model. | Bazel 5 | Deprecated | [5.4.1](https://github.com/bazelbuild/bazel/releases/tag/5.4.1) | Jan 2025 | | Bazel 4 | Deprecated | [4.2.4](https://github.com/bazelbuild/bazel/releases/tag/4.2.4) | Jan 2024 | -All Bazel LTS releases can be found on the [release -page](https://github.com/bazelbuild/bazel/releases) on GitHub. +All Bazel LTS releases can be found on the [release page](https://github.com/bazelbuild/bazel/releases) on GitHub. ## Release versioning {#bazel-versioning} -Bazel uses a _major.minor.patch_ [Semantic -Versioning](https://semver.org/) scheme. +Bazel uses a _major.minor.patch_ [Semantic Versioning](https://semver.org/) scheme. * A _major release_ contains features that are not backward compatible with the previous release. Each major Bazel version is an LTS release. @@ -71,8 +68,7 @@ Bazel regularly publish releases for two release tracks. release. * Rolling releases can ship incompatible changes. Incompatible flags are recommended for major breaking changes, rolling out incompatible changes - should follow our [backward compatibility - policy](/release/backward-compatibility). + should follow our [backward compatibility policy](/release/backward-compatibility). ### LTS releases {#lts-releases} @@ -88,8 +84,7 @@ Bazel regularly publish releases for two release tracks. * A Bazel LTS release enters the Deprecated stage after being in ​​the Maintenance stage for 2 years. -For planned releases, please check our [release -issues](https://github.com/bazelbuild/bazel/issues?q=is%3Aopen+is%3Aissue+label%3Arelease) +For planned releases, please check our [release issues](https://github.com/bazelbuild/bazel/issues?q=is%3Aopen+is%3Aissue+label%3Arelease) on Github. ## Release procedure & policies {#release-procedure-policies} @@ -152,8 +147,7 @@ For LTS releases, the procedure and policies below are followed: 1. Identify release blockers and fix issues found on the release branch. * The release branch is tested with the same test suite in [postsubmit](https://buildkite.com/bazel/bazel-bazel) and - [downstream test pipeline] - (https://buildkite.com/bazel/bazel-at-head-plus-downstream) + [downstream test pipeline](https://buildkite.com/bazel/bazel-at-head-plus-downstream) on Bazel CI. The Bazel team monitors testing results of the release branch and fixes any regressions found. 1. Create a new release candidate from the release branch when all known @@ -209,5 +203,4 @@ feature. ## Rule compatibility {#rule-compatibility} If you are a rule authors and want to maintain compatibility with different -Bazel versions, please check out the [Rule -Compatibility](/release/rule-compatibility) page. +Bazel versions, please check out the [Rule Compatibility](/release/rule-compatibility) page. diff --git a/release/rule-compatibility.mdx b/release/rule-compatibility.mdx index 2a00588d..78d79dc1 100644 --- a/release/rule-compatibility.mdx +++ b/release/rule-compatibility.mdx @@ -55,18 +55,15 @@ Bazel LTS release. As Bazel rules authors, you can ensure a manageable migration process for users by following these best practices: -1. The rule should follow [Semantic - Versioning](https://semver.org/): minor versions of the same +1. The rule should follow [Semantic Versioning](https://semver.org/): minor versions of the same major version are backward compatible. 1. The rule at HEAD should be compatible with the latest Bazel LTS release. 1. The rule at HEAD should be compatible with Bazel at HEAD. To achieve this, you can * Set up your own CI testing with Bazel at HEAD - * Add your project to [Bazel downstream - testing](https://github.com/bazelbuild/continuous-integration/blob/master/docs/downstream-testing.md); + * Add your project to [Bazel downstream testing](https://github.com/bazelbuild/continuous-integration/blob/master/docs/downstream-testing.md); the Bazel team files issues to your project if breaking changes in Bazel - affect your project, and you must follow our [downstream project - policies](https://github.com/bazelbuild/continuous-integration/blob/master/docs/downstream-testing.md#downstream-project-policies) + affect your project, and you must follow our [downstream project policies](https://github.com/bazelbuild/continuous-integration/blob/master/docs/downstream-testing.md#downstream-project-policies) to address issues timely. 1. The latest major version of the rule must be compatible with the latest Bazel LTS release. diff --git a/remote/bep-glossary.mdx b/remote/bep-glossary.mdx index d40d13f9..53a93d31 100644 --- a/remote/bep-glossary.mdx +++ b/remote/bep-glossary.mdx @@ -412,5 +412,4 @@ workspace, such as the execution root. ## WorkspaceStatus {#workspacestatus} -A single `WorkspaceStatus` event contains the result of the [workspace status -command](/docs/user-manual#workspace-status). +A single `WorkspaceStatus` event contains the result of the [workspace status command](/docs/user-manual#workspace-status). diff --git a/remote/bep.mdx b/remote/bep.mdx index 2cfa555f..08ac72d2 100644 --- a/remote/bep.mdx +++ b/remote/bep.mdx @@ -4,14 +4,12 @@ title: 'Build Event Protocol' -The [Build Event -Protocol](https://github.com/bazelbuild/bazel/blob/master/src/main/java/com/google/devtools/build/lib/buildeventstream/proto/build_event_stream.proto) +The [Build Event Protocol](https://github.com/bazelbuild/bazel/blob/master/src/main/java/com/google/devtools/build/lib/buildeventstream/proto/build_event_stream.proto) (BEP) allows third-party programs to gain insight into a Bazel invocation. For example, you could use the BEP to gather information for an IDE plugin or a dashboard that displays build results. -The protocol is a set of [protocol -buffer](https://developers.google.com/protocol-buffers/) messages with some +The protocol is a set of [protocol buffer](https://developers.google.com/protocol-buffers/) messages with some semantics defined on top of it. It includes information about build and test results, build progress, the build configuration and much more. The BEP is intended to be consumed programmatically and makes parsing Bazel’s @@ -22,16 +20,13 @@ build event is a protocol buffer message consisting of a build event identifier, a set of child event identifiers, and a payload. * __Build Event Identifier:__ Depending on the kind of build event, it might be -an [opaque -string](https://github.com/bazelbuild/bazel/blob/7.1.0/src/main/java/com/google/devtools/build/lib/buildeventstream/proto/build_event_stream.proto#L131-L140) -or [structured -information](https://github.com/bazelbuild/bazel/blob/7.1.0/src/main/java/com/google/devtools/build/lib/buildeventstream/proto/build_event_stream.proto#L194-L205) +an [opaque string](https://github.com/bazelbuild/bazel/blob/7.1.0/src/main/java/com/google/devtools/build/lib/buildeventstream/proto/build_event_stream.proto#L131-L140) +or [structured information](https://github.com/bazelbuild/bazel/blob/7.1.0/src/main/java/com/google/devtools/build/lib/buildeventstream/proto/build_event_stream.proto#L194-L205) revealing more about the build event. A build event identifier is unique within a build. * __Children:__ A build event may announce other build events, by including -their build event identifiers in its [children -field](https://github.com/bazelbuild/bazel/blob/7.1.0/src/main/java/com/google/devtools/build/lib/buildeventstream/proto/build_event_stream.proto#L1276). +their build event identifiers in its [children field](https://github.com/bazelbuild/bazel/blob/7.1.0/src/main/java/com/google/devtools/build/lib/buildeventstream/proto/build_event_stream.proto#L1276). For example, the `PatternExpanded` build event announces the targets it expands to as children. The protocol guarantees that all events, except for the first event, are announced by a previous event. @@ -93,8 +88,7 @@ human-readable formats, such as text and JSON: ## Build Event Service {#build-event-service} -The [Build Event -Service](https://github.com/googleapis/googleapis/blob/master/google/devtools/build/v1/publish_build_event.proto) +The [Build Event Service](https://github.com/googleapis/googleapis/blob/master/google/devtools/build/v1/publish_build_event.proto) Protocol is a generic [gRPC](https://www.grpc.io) service for publishing build events. The Build Event Service protocol is independent of the BEP and treats BEP events as opaque bytes. Bazel ships with a gRPC client implementation of the Build Event Service protocol that @@ -138,8 +132,7 @@ For a description of each of these flags, see the The BEP typically contains many references to log files (test.log, test.xml, etc. ) stored on the machine where Bazel is running. A remote BES server typically can't access these files as they are on different machines. A way to -work around this issue is to use Bazel with [remote -caching](/remote/caching). +work around this issue is to use Bazel with [remote caching](/remote/caching). Bazel will upload all output files to the remote cache (including files referenced in the BEP) and the BES server can then fetch the referenced files from the cache. diff --git a/remote/cache-local.mdx b/remote/cache-local.mdx index 7cb59a6a..ac81188e 100644 --- a/remote/cache-local.mdx +++ b/remote/cache-local.mdx @@ -20,8 +20,7 @@ execution. However, local execution presents some additional challenges. ## Checking your cache hit rate {#cache-hits} Successful remote cache hits will show up in the status line, similar to -[Cache Hits rate with Remote -Execution](/remote/cache-remote#check-cache-hits). +[Cache Hits rate with Remote Execution](/remote/cache-remote#check-cache-hits). In the standard output of your Bazel run, you will see something like the following: @@ -70,8 +69,7 @@ the steps in this section. message you see does not give you enough information, try adding `--verbose_failures`. -2. Follow the steps from [Troubleshooting cache hits for remote - execution](/remote/cache-remote#troubleshooting_cache_hits) to +2. Follow the steps from [Troubleshooting cache hits for remote execution](/remote/cache-remote#troubleshooting_cache_hits) to ensure that your cache-writing Bazel invocations are able to get cache hits on the same machine and across machines. @@ -85,7 +83,6 @@ the steps in this section. b. Ensure your cache-reading Bazel invocations build the same targets as the cache-writing Bazel invocations. - c. Follow the same steps as to [ensure caching across - machines](/remote/cache-remote#caching-across-machines), + c. Follow the same steps as to [ensure caching across machines](/remote/cache-remote#caching-across-machines), to ensure caching from your cache-writing Bazel invocation to your cache-reading Bazel invocation. diff --git a/remote/caching.mdx b/remote/caching.mdx index 09774d21..2b93ae98 100644 --- a/remote/caching.mdx +++ b/remote/caching.mdx @@ -316,8 +316,7 @@ or for the age of individual cache entries. Bazel will automatically garbage collect the disk cache while idling between builds; the idle timer can be set with `--experimental_disk_cache_gc_idle_delay` (defaulting to 5 minutes). -As an alternative to automatic garbage collection, we also provide a [tool]( -https://github.com/bazelbuild/bazel/tree/master/src/tools/diskcache) to run a +As an alternative to automatic garbage collection, we also provide a [tool](https://github.com/bazelbuild/bazel/tree/master/src/tools/diskcache) to run a garbage collection on demand. ## Known issues {#known-issues} diff --git a/remote/dynamic.mdx b/remote/dynamic.mdx index e954e0d6..c30afa0b 100644 --- a/remote/dynamic.mdx +++ b/remote/dynamic.mdx @@ -12,8 +12,7 @@ alike. This page describes how to enable, tune, and debug dynamic execution. If you have both local and remote execution set up and are trying to adjust Bazel settings for better performance, this page is for you. If you don't already have -remote execution set up, go to the Bazel [Remote Execution -Overview](/remote/rbe) first. +remote execution set up, go to the Bazel [Remote Execution Overview](/remote/rbe) first. ## Enabling dynamic execution? {#enabling-dynamic-execution} @@ -44,14 +43,12 @@ are likely. The default value is 1000ms, but should be tuned to being just a bit longer than cache hits usually take. The actual time depends both on the remote system and on how long a round-trip takes. Usually, the value will be the same for all users of a given remote system, unless some of them are far enough away -to add roundtrip latency. You can use the [Bazel profiling -features](/rules/performance#performance-profiling) to look at how long typical +to add roundtrip latency. You can use the [Bazel profiling features](/rules/performance#performance-profiling) to look at how long typical cache hits take. Dynamic execution can be used with local sandboxed strategy as well as with [persistent workers](/remote/persistent). Persistent workers will automatically -run with sandboxing when used with dynamic execution, and cannot use [multiplex -workers](/remote/multiplex). On Darwin and Windows systems, the sandboxed +run with sandboxing when used with dynamic execution, and cannot use [multiplex workers](/remote/multiplex). On Darwin and Windows systems, the sandboxed strategy can be slow; you can pass `--reuse_sandbox_directories` to reduce overhead of creating sandboxes on these systems. @@ -67,8 +64,7 @@ entire action fails. This is an intentional choice to prevent differences between local and remote execution from going unnoticed. For more background on how dynamic execution and its locking works, see Julio -Merino's excellent [blog -posts](https://jmmv.dev/series/bazel-dynamic-execution/) +Merino's excellent [blog posts](https://jmmv.dev/series/bazel-dynamic-execution/) ## When should I use dynamic execution? {#when-to-use} diff --git a/remote/persistent.mdx b/remote/persistent.mdx index 3a7dbee0..c0e7f1da 100644 --- a/remote/persistent.mdx +++ b/remote/persistent.mdx @@ -262,7 +262,6 @@ For more information on persistent workers, see: * [Original persistent workers blog post](https://blog.bazel.build/2015/12/10/java-workers.html) * [Haskell implementation description](https://www.tweag.io/blog/2019-09-25-bazel-ghc-persistent-worker-internship/) * [Blog post by Mike Morearty](https://medium.com/@mmorearty/how-to-create-a-persistent-worker-for-bazel-7738bba2cabb) -* [Front End Development with Bazel: Angular/TypeScript and Persistent Workers - w/ Asana](https://www.youtube.com/watch?v=0pgERydGyqo) +* [Front End Development with Bazel: Angular/TypeScript and Persistent Workers w/ Asana](https://www.youtube.com/watch?v=0pgERydGyqo) * [Bazel strategies explained](https://jmmv.dev/2019/12/bazel-strategies.html) * [Informative worker strategy discussion on the bazel-discuss mailing list](https://groups.google.com/forum/#!msg/bazel-discuss/oAEnuhYOPm8/ol7hf4KWJgAJ) diff --git a/remote/rules.mdx b/remote/rules.mdx index adc445a9..e5da6a8f 100644 --- a/remote/rules.mdx +++ b/remote/rules.mdx @@ -56,8 +56,7 @@ variables that may not be set to equivalent values (or at all) in the remote execution environment. Toolchain rules currently exist for Bazel build and test rules for -[Scala](https://github.com/bazelbuild/rules_scala/blob/master/scala/scala_toolch -ain.bzl), +[Scala](https://github.com/bazelbuild/rules_scala/blob/master/scala/scala_toolch ain.bzl), [Rust](https://github.com/bazelbuild/rules_rust/blob/main/rust/toolchain.bzl), and [Go](https://github.com/bazelbuild/rules_go/blob/master/go/toolchains.rst), and new toolchain rules are under way for other languages and tools such as diff --git a/remote/workspace.mdx b/remote/workspace.mdx index c2581b27..4cba551c 100644 --- a/remote/workspace.mdx +++ b/remote/workspace.mdx @@ -13,8 +13,7 @@ on the host machine. If your workspace rules access information about the host machine for use during execution, your build is likely to break due to incompatibilities between the environments. -As part of [adapting Bazel rules for remote -execution](/remote/rules), you need to find such workspace rules +As part of [adapting Bazel rules for remote execution](/remote/rules), you need to find such workspace rules and fix them. This page describes how to find potentially problematic workspace rules using the workspace log. diff --git a/rules/language.mdx b/rules/language.mdx index a95dd7bf..8d42cfb1 100644 --- a/rules/language.mdx +++ b/rules/language.mdx @@ -109,10 +109,8 @@ values returned by rules are immutable. `BUILD` files register targets via making calls to rules. `.bzl` files provide definitions for constants, rules, macros, and functions. -[Native functions](/reference/be/functions) and [native rules]( -/reference/be/overview#language-specific-native-rules) are global symbols in -`BUILD` files. `bzl` files need to load them using the [`native` module]( -/rules/lib/toplevel/native). +[Native functions](/reference/be/functions) and [native rules](/reference/be/overview#language-specific-native-rules) are global symbols in +`BUILD` files. `bzl` files need to load them using the [`native` module](/rules/lib/toplevel/native). There are two syntactic restrictions in `BUILD` files: 1) declaring functions is illegal, and 2) `*args` and `**kwargs` arguments are not allowed. diff --git a/rules/legacy-macro-tutorial.mdx b/rules/legacy-macro-tutorial.mdx index 28b0fca8..15d08728 100644 --- a/rules/legacy-macro-tutorial.mdx +++ b/rules/legacy-macro-tutorial.mdx @@ -5,9 +5,7 @@ title: 'Creating a Legacy Macro' IMPORTANT: This tutorial is for [*legacy macros*](/extending/legacy-macros). If -you only need to support Bazel 8 or newer, we recommend using [symbolic -macros](/extending/macros) instead; take a look at [Creating a Symbolic -Macro](macro-tutorial). +you only need to support Bazel 8 or newer, we recommend using [symbolic macros](/extending/macros) instead; take a look at [Creating a Symbolic Macro](macro-tutorial). Imagine that you need to run a tool as part of your build. For example, you may want to generate or preprocess a source file, or compress a binary. In this diff --git a/rules/verbs-tutorial.mdx b/rules/verbs-tutorial.mdx index db7757e1..5e355764 100644 --- a/rules/verbs-tutorial.mdx +++ b/rules/verbs-tutorial.mdx @@ -51,8 +51,7 @@ This pattern can also be seen in the Angular project. The produces two targets. The first is a standard `nodejs_test` target which compares some generated output against a "golden" file (that is, a file containing the expected output). This can be built and run with a normal `bazel -test` invocation. In `angular-cli`, you can run [one such -target](https://github.com/angular/angular-cli/blob/e1269cb520871ee29b1a4eec6e6c0e4a94f0b5fc/etc/api/BUILD) +test` invocation. In `angular-cli`, you can run [one such target](https://github.com/angular/angular-cli/blob/e1269cb520871ee29b1a4eec6e6c0e4a94f0b5fc/etc/api/BUILD) with `bazel test //etc/api:angular_devkit_core_api`. Over time, this golden file may need to be updated for legitimate reasons. diff --git a/run/build.mdx b/run/build.mdx index a8eadc57..2f3e4825 100644 --- a/run/build.mdx +++ b/run/build.mdx @@ -633,8 +633,7 @@ Note: Hermeticity means that the action only uses its declared input files and no other files in the filesystem, and it only produces its declared output files. See [Hermeticity](/basics/hermeticity) for more details. -On some platforms such as [Google Kubernetes -Engine](https://cloud.google.com/kubernetes-engine/) cluster nodes or Debian, +On some platforms such as [Google Kubernetes Engine](https://cloud.google.com/kubernetes-engine/) cluster nodes or Debian, user namespaces are deactivated by default due to security concerns. This can be checked by looking at the file `/proc/sys/kernel/unprivileged_userns_clone`: if it exists and contains a 0, diff --git a/start/android-app.mdx b/start/android-app.mdx index 35da5828..f4ae1830 100644 --- a/start/android-app.mdx +++ b/start/android-app.mdx @@ -40,8 +40,7 @@ In this tutorial you learn how to: Before you begin the tutorial, install the following software: * **Bazel.** To install, follow the [installation instructions](/install). -* **Android Studio.** To install, follow the steps to [download Android - Studio](https://developer.android.com/sdk/index.html). +* **Android Studio.** To install, follow the steps to [download Android Studio](https://developer.android.com/sdk/index.html). Execute the setup wizard to download the SDK and configure your environment. * (Optional) **Git.** Use `git` to download the Android app project. @@ -56,8 +55,7 @@ This app has a single button that prints a greeting when clicked: **Figure 1.** Android app button greeting. -Clone the repository with `git` (or [download the ZIP file -directly](https://github.com/bazelbuild/examples/archive/master.zip)): +Clone the repository with `git` (or [download the ZIP file directly](https://github.com/bazelbuild/examples/archive/master.zip)): ```posix-terminal git clone https://github.com/bazelbuild/examples @@ -108,8 +106,7 @@ A [workspace](/concepts/build-ref#workspace) is a directory that contains the source files for one or more software projects, and has a `MODULE.bazel` file at its root. -The `MODULE.bazel` file may be empty or may contain references to [external -dependencies](/external/overview) required to build your project. +The `MODULE.bazel` file may be empty or may contain references to [external dependencies](/external/overview) required to build your project. First, run the following command to create an empty `MODULE.bazel` file: @@ -160,8 +157,7 @@ environment variable, and automatically detect the highest API level and the latest version of build tools installed within that location. You can set the `ANDROID_HOME` variable to the location of the Android SDK. Find -the path to the installed SDK using Android Studio's [SDK -Manager](https://developer.android.com/studio/intro/update#sdk-manager). +the path to the installed SDK using Android Studio's [SDK Manager](https://developer.android.com/studio/intro/update#sdk-manager). Assuming the SDK is installed to default locations, you can use the following commands to set the `ANDROID_HOME` variable: @@ -184,8 +180,7 @@ them permanent, run the following commands: **Optional:** If you want to compile native code into your Android app, you -also need to download the [Android -NDK](https://developer.android.com/ndk/downloads/index.html) +also need to download the [Android NDK](https://developer.android.com/ndk/downloads/index.html) and use `rules_android_ndk` by adding the following line to your `MODULE.bazel` file: ```python @@ -193,8 +188,7 @@ bazel_dep(name = "rules_android_ndk", version = "0.1.3") ``` -For more information, read [Using the Android Native Development Kit with -Bazel](/docs/android-ndk). +For more information, read [Using the Android Native Development Kit with Bazel](/docs/android-ndk). It's not necessary to set the API levels to the same value for the SDK and NDK. [This page](https://developer.android.com/ndk/guides/stable_apis.html) @@ -236,8 +230,7 @@ files or other dependencies. Bazel provides two build rules, build an Android app. For this tutorial, you'll first use the -`android_library` rule to tell Bazel to build an [Android library -module](http://developer.android.com/tools/projects/index.html#LibraryProjects) +`android_library` rule to tell Bazel to build an [Android library module](http://developer.android.com/tools/projects/index.html#LibraryProjects) from the app source code and resource files. You'll then use the `android_binary` rule to tell Bazel how to build the Android application package. diff --git a/start/cpp.mdx b/start/cpp.mdx index 15cda325..c47d1484 100644 --- a/start/cpp.mdx +++ b/start/cpp.mdx @@ -21,8 +21,7 @@ Estimated completion time: 30 minutes. ### Prerequisites {#prerequisites} Start by [installing Bazel](https://bazel.build/install), if you haven't -already. This tutorial uses Git for source control, so for best results [install -Git](https://git-scm.com/book/en/v2/Getting-Started-Installing-Git) as well. +already. This tutorial uses Git for source control, so for best results [install Git](https://git-scm.com/book/en/v2/Getting-Started-Installing-Git) as well. Next, retrieve the sample project from Bazel's GitHub repository by running the following in your command-line tool of choice: @@ -65,9 +64,7 @@ examples ``` There are three sets of files, each set representing a stage in this tutorial. -In the first stage, you will build a single [target] -(https://bazel.build/reference/glossary#target) residing in a single [package] -(https://bazel.build/reference/glossary#package). In the second stage, you will +In the first stage, you will build a single [target](https://bazel.build/reference/glossary#target) residing in a single [package](https://bazel.build/reference/glossary#package). In the second stage, you will build both a binary and a library from a single package. In the third and final stage, you will build a project with multiple packages and build it with multiple targets. @@ -88,8 +85,7 @@ It also contains these significant files: * The `MODULE.bazel` file, which identifies the directory and its contents as a Bazel workspace and lives at the root of the project's directory structure. It's also where you specify your external dependencies. -* One or more [`BUILD` - files](https://bazel.build/reference/glossary#build-file), which tell Bazel +* One or more [`BUILD` files](https://bazel.build/reference/glossary#build-file), which tell Bazel how to build different parts of the project. A directory within the workspace that contains a `BUILD` file is a [package](https://bazel.build/reference/glossary#package). (More on packages @@ -184,9 +180,7 @@ This results in a printed "`Hello world`" message. Here's the dependency graph of Stage 1: -![Dependency graph for hello-world displays a single target with a single source -file.](/docs/images/cpp-tutorial-stage1.png "Dependency graph for hello-world -displays a single target with a single source file.") +![Dependency graph for hello-world displays a single target with a single source file.](/docs/images/cpp-tutorial-stage1.png "Dependency graph for hello-world displays a single target with a single source file.") ### Summary: stage 1 {#summary-stage-1} @@ -233,8 +227,7 @@ cc_binary( ``` With this `BUILD` file, Bazel first builds the `hello-greet` library (using -Bazel's built-in [`cc_library` -rule](https://bazel.build/reference/be/c-cpp#cc_library)), then the +Bazel's built-in [`cc_library` rule](https://bazel.build/reference/be/c-cpp#cc_library)), then the `hello-world` binary. The `deps` attribute in the `hello-world` target tells Bazel that the `hello-greet` library is required to build the `hello-world` binary. @@ -274,10 +267,7 @@ recompiles that file. Looking at the dependency graph, you can see that `hello-world` depends on an extra input named `hello-greet`: -![Dependency graph for `hello-world` displays dependency changes after -modification to the file.](/docs/images/cpp-tutorial-stage2.png "Dependency -graph for `hello-world` displays dependency changes after modification to the -file.") +![Dependency graph for `hello-world` displays dependency changes after modification to the file.](/docs/images/cpp-tutorial-stage2.png "Dependency graph for `hello-world` displays dependency changes after modification to the file.") ### Summary: stage 2 {#summary-stage-2} @@ -345,11 +335,7 @@ in the `lib` package (hence the target label `//lib:hello-time`) - Bazel knows this through the `deps` attribute. You can see this reflected in the dependency graph: -![Dependency graph for `hello-world` displays how the target in the main package -depends on the target in the `lib` -package.](/docs/images/cpp-tutorial-stage3.png "Dependency graph for -`hello-world` displays how the target in the main package depends on the target -in the `lib` package.") +![Dependency graph for `hello-world` displays how the target in the main package depends on the target in the `lib` package.](/docs/images/cpp-tutorial-stage3.png "Dependency graph for `hello-world` displays how the target in the main package depends on the target in the `lib` package.") For the build to succeed, you make the `//lib:hello-time` target in `lib/BUILD` explicitly visible to targets in `main/BUILD` using the visibility attribute. @@ -397,15 +383,11 @@ Bazel journey. You've now completed your first basic build with Bazel, but this is just the start. Here are some more resources to continue learning with Bazel: -* To keep focusing on C++, read about common [C++ build use - cases](https://bazel.build/tutorials/cpp-use-cases). +* To keep focusing on C++, read about common [C++ build use cases](https://bazel.build/tutorials/cpp-use-cases). * To get started with building other applications with Bazel, see the - tutorials for [Java](https://bazel.build/start/java), [Android - application](https://bazel.build/start/android-app), or [iOS - application](https://bazel.build/start/ios-app). + tutorials for [Java](https://bazel.build/start/java), [Android application](https://bazel.build/start/android-app), or [iOS application](https://bazel.build/start/ios-app). * To learn more about working with local and remote repositories, read about [external dependencies](https://bazel.build/docs/external). -* To learn more about Bazel's other rules, see this [reference - guide](https://bazel.build/rules). +* To learn more about Bazel's other rules, see this [reference guide](https://bazel.build/rules). Happy building! \ No newline at end of file diff --git a/start/go.mdx b/start/go.mdx index 5fb604c8..2ce0159e 100644 --- a/start/go.mdx +++ b/start/go.mdx @@ -34,8 +34,7 @@ You can check if Go is installed by running `go version` in any directory. ### Get the sample project {#get-sample} -The Bazel examples are stored in a Git repository, so you'll need to [install -Git](https://git-scm.com/book/en/v2/Getting-Started-Installing-Git) if you +The Bazel examples are stored in a Git repository, so you'll need to [install Git](https://git-scm.com/book/en/v2/Getting-Started-Installing-Git) if you haven't already. To download the examples repository, run this command: ```posix-terminal @@ -173,10 +172,8 @@ rule. Each rule defines [actions](https://bazel.build/reference/glossary#action) Go compile and link actions that produce an executable output file. Bazel has built-in rules for a few languages like Java and C++. You can find -their [documentation in the Build -Encyclopedia](https://bazel.build/reference/be/overview#rules). You can find -rule sets for many other languages and tools on the [Bazel Central Registry -(BCR)](https://registry.bazel.build/). +their [documentation in the Build Encyclopedia](https://bazel.build/reference/be/overview#rules). You can find +rule sets for many other languages and tools on the [Bazel Central Registry (BCR)](https://registry.bazel.build/). ## Add a library {#add-library} @@ -449,11 +446,9 @@ learned some core Bazel concepts along the way. languages. - For more information on Go, see the [rules_go](https://github.com/bazel-contrib/rules_go) module, especially the - [Core Go - rules](https://github.com/bazel-contrib/rules_go/blob/master/docs/go/core/rules.md) + [Core Go rules](https://github.com/bazel-contrib/rules_go/blob/master/docs/go/core/rules.md) documentation. - To learn more about working with Bazel modules outside your project, see [external dependencies](/docs/external). In particular, for information on how to depend on Go modules and toolchains through Bazel's module system, - see [Go with - bzlmod](https://github.com/bazel-contrib/rules_go/tree/master/docs/go/core/bzlmod.md). + see [Go with bzlmod](https://github.com/bazel-contrib/rules_go/tree/master/docs/go/core/bzlmod.md). diff --git a/start/java.mdx b/start/java.mdx index b892917d..28c064c5 100644 --- a/start/java.mdx +++ b/start/java.mdx @@ -243,8 +243,7 @@ recompiles that file. Looking at the dependency graph, you can see that `ProjectRunner` depends on the same inputs as it did before, but the structure of the build is different: -![Dependency graph of the target 'ProjectRunner' after adding a dependency]( -/docs/images/tutorial_java_02.svg) +![Dependency graph of the target 'ProjectRunner' after adding a dependency](/docs/images/tutorial_java_02.svg) You've now built the project with two targets. The `ProjectRunner` target builds one source files and depends on one other target (`:greeter`), which builds diff --git a/tutorials/ccp-toolchain-config.mdx b/tutorials/ccp-toolchain-config.mdx index 205f27f9..a4dd5829 100644 --- a/tutorials/ccp-toolchain-config.mdx +++ b/tutorials/ccp-toolchain-config.mdx @@ -31,8 +31,7 @@ uses `clang version 19`, which you can install on your system. Set up your build environment as follows: -1. If you have not already done so, [download and install Bazel - 7.0.2](https://bazel.build/install) or later. +1. If you have not already done so, [download and install Bazel 7.0.2](https://bazel.build/install) or later. 2. Add an empty `MODULE.bazel` file at the root folder. @@ -456,8 +455,7 @@ The key takeaways are: - You need to specify a matching `platforms` flag in the command line for Bazel to resolve to the toolchain for the same constraint values on the - platform. The documentation holds more [information about language specific - configuration flags](/concepts/platforms). + platform. The documentation holds more [information about language specific configuration flags](/concepts/platforms). - You have to let the toolchain know where the tools live. In this tutorial there is a simplified version where you access the tools from the system. If you are interested in a more self-contained approach, you can read about @@ -470,5 +468,4 @@ The key takeaways are: ## Further reading {#further-reading} -For more details, see [C++ toolchain -configuration](/docs/cc-toolchain-config-reference) +For more details, see [C++ toolchain configuration](/docs/cc-toolchain-config-reference) diff --git a/upstream b/upstream index 95ce4c19..f29652f5 160000 --- a/upstream +++ b/upstream @@ -1 +1 @@ -Subproject commit 95ce4c19632621cbe776d7b82bbb793fe584cb87 +Subproject commit f29652f55ff6676c73baffc03a70aeaa8e9669c5 diff --git a/versions/6.5.0/community/roadmaps-configurability.mdx b/versions/6.5.0/community/roadmaps-configurability.mdx index b2ddeda8..2aba1779 100644 --- a/versions/6.5.0/community/roadmaps-configurability.mdx +++ b/versions/6.5.0/community/roadmaps-configurability.mdx @@ -26,8 +26,7 @@ title: 'Bazel Configurability 2021 Roadmap' * Builds scale well, particularly w.r.t graph size and action caching. We also support -[`cquery`](https://bazel.build/versions/6.5.0/docs/cquery), [`Starlark -configuration`](https://bazel.build/rules/config), +[`cquery`](https://bazel.build/versions/6.5.0/docs/cquery), [`Starlark configuration`](https://bazel.build/rules/config), and [`select()`](https://bazel.build/versions/6.5.0/docs/configurable-attributes). @@ -41,15 +40,13 @@ interest of accurate expectations. ### Platforms
-Q3 2021**Android rules use the new [platforms -API](https://bazel.build/concepts/platforms-intro)** +Q3 2021**Android rules use the new [platforms API](https://bazel.build/concepts/platforms-intro)** IN PROGRESS ([#11749](https://github.com/bazelbuild/bazel/issues/11749)) * This is our main priority for the beginning of 2021.
-Q3 2021**Builds support [multiple execution -platforms](https://docs.google.com/document/d/1U9HzdDmtRnm244CaRM6JV-q2408mbNODAMewcGjnnbM/)** +Q3 2021**Builds support [multiple execution platforms](https://docs.google.com/document/d/1U9HzdDmtRnm244CaRM6JV-q2408mbNODAMewcGjnnbM/)** IN PROGRESS ([#11748](https://github.com/bazelbuild/bazel/issues/11748))
diff --git a/versions/6.5.0/community/sig.mdx b/versions/6.5.0/community/sig.mdx index 150fb417..0331269a 100644 --- a/versions/6.5.0/community/sig.mdx +++ b/versions/6.5.0/community/sig.mdx @@ -4,8 +4,7 @@ title: 'Bazel Special Interest Groups' Bazel hosts Special Interest Groups (SIGs) to focus collaboration on particular -areas and to support communication and coordination between [Bazel owners, -maintainers, and contributors](/contribute/contribution-policy). This policy +areas and to support communication and coordination between [Bazel owners, maintainers, and contributors](/contribute/contribution-policy). This policy applies to [`bazelbuild`](http://github.com/bazelbuild). SIGs do their work in public. The ideal scope for a SIG covers a well-defined diff --git a/versions/6.5.0/concepts/build-files.mdx b/versions/6.5.0/concepts/build-files.mdx index b468b9f9..b05e79e0 100644 --- a/versions/6.5.0/concepts/build-files.mdx +++ b/versions/6.5.0/concepts/build-files.mdx @@ -125,10 +125,3 @@ for anyone to create new rules. programming language. Libraries can depend on other libraries, and binaries and tests can depend on libraries, with the expected separate-compilation behavior. - -
- - - - -
LabelsDependencies
diff --git a/versions/6.5.0/concepts/build-ref.mdx b/versions/6.5.0/concepts/build-ref.mdx index b7f338ee..13206da6 100644 --- a/versions/6.5.0/concepts/build-ref.mdx +++ b/versions/6.5.0/concepts/build-ref.mdx @@ -14,8 +14,7 @@ outputs can be built from the source. A _workspace_ is a directory tree on your filesystem that contains the source files for the software you want to build. Each workspace has a text file named -`WORKSPACE` which may be empty, or may contain references to [external -dependencies](/docs/external) required to build the outputs. +`WORKSPACE` which may be empty, or may contain references to [external dependencies](/docs/external) required to build the outputs. Directories containing a file called `WORKSPACE` are considered the root of a workspace. Therefore, Bazel ignores any directory trees in a workspace rooted at @@ -29,13 +28,9 @@ both files exist, `WORKSPACE.bazel` is used. Code is organized in _repositories_. The directory containing the `WORKSPACE` file is the root of the main repository, also called `@`. Other, (external) repositories are defined in the `WORKSPACE` file using workspace rules, or -generated from modules and extensions in the Bzlmod system. See [external -dependencies overview](/external/overview) for more information. +generated from modules and extensions in the Bzlmod system. See [external dependencies overview](/external/overview) for more information. -The workspace rules bundled with Bazel are documented in the [Workspace -Rules](/reference/be/workspace) section in the [Build -Encyclopedia](/reference/be/overview) and the documentation on [embedded -Starlark repository rules](/rules/lib/repo/index). +The workspace rules bundled with Bazel are documented in the [Workspace Rules](/reference/be/workspace) section in the [Build Encyclopedia](/reference/be/overview) and the documentation on [embedded Starlark repository rules](/rules/lib/repo/index). As external repositories are repositories themselves, they often contain a `WORKSPACE` file as well. However, these additional `WORKSPACE` files are @@ -107,9 +102,4 @@ have three properties: the list of packages they contain, their name, and other package groups they include. The only allowed ways to refer to them are from the `visibility` attribute of rules or from the `default_visibility` attribute of the `package` function; they do not generate or consume files. For more -information, refer to the [`package_group` -documentation](/reference/be/functions#package_group). - - - Labels - +information, refer to the [`package_group` documentation](/reference/be/functions#package_group). diff --git a/versions/6.5.0/concepts/dependencies.mdx b/versions/6.5.0/concepts/dependencies.mdx index 52f28620..345b6246 100644 --- a/versions/6.5.0/concepts/dependencies.mdx +++ b/versions/6.5.0/concepts/dependencies.mdx @@ -344,11 +344,3 @@ filegroup( ``` You can then reference the label `my_data` as the data dependency in your test. - - - - - - -
BUILD filesVisibility
- diff --git a/versions/6.5.0/concepts/labels.mdx b/versions/6.5.0/concepts/labels.mdx index 286804f7..c1506361 100644 --- a/versions/6.5.0/concepts/labels.mdx +++ b/versions/6.5.0/concepts/labels.mdx @@ -212,10 +212,3 @@ the build. This directed acyclic graph over targets is called the _target graph_ or _build dependency graph_, and is the domain over which the [Bazel Query tool](/versions/6.5.0/docs/query-how-to) operates. - - - - - - -
TargetsBUILD files
diff --git a/versions/6.5.0/concepts/platforms.mdx b/versions/6.5.0/concepts/platforms.mdx index 01de1628..2c919fdb 100644 --- a/versions/6.5.0/concepts/platforms.mdx +++ b/versions/6.5.0/concepts/platforms.mdx @@ -157,10 +157,8 @@ attributes declare a language's tools (like `compiler = this information to rules that need to build with these tools. Toolchains declare the `constraint_value`s of machines they can -[target][target_compatible_with Attribute] -(`target_compatible_with = ["@platforms//os:linux"]`) and machines their tools can -[run on][exec_compatible_with Attribute] -(`exec_compatible_with = ["@platforms//os:mac"]`). +[target][target_compatible_with Attribute](`target_compatible_with = ["@platforms//os:linux"]`) and machines their tools can +[run on][exec_compatible_with Attribute](`exec_compatible_with = ["@platforms//os:mac"]`). When building `$ bazel build //:myproject --platforms=//:myplatform`, Bazel automatically selects a toolchain that can run on the build machine and @@ -283,8 +281,7 @@ Bazel's Apple rules do not yet support platforms to select Apple toolchains. They also don't support platform-enabled C++ dependencies because they use the legacy `--crosstool_top` to set the C++ toolchain. Until this is migrated, you -can mix Apple projects with platorm-enabled C++ with [platform -mappings](#platform-mappings) +can mix Apple projects with platorm-enabled C++ with [platform mappings](#platform-mappings) ([example](https://github.com/bazelbuild/bazel/issues/8716#issuecomment-516572378)). ### Other languages {#other-languages} @@ -345,8 +342,7 @@ sets `--cpu`, `--crossstool_top`, or other legacy flags, rules that read When migrating your project to platforms, you must either convert changes like `return { "//command_line_option:cpu": "arm" }` to `return { -"//command_line_option:platforms": "//:my_arm_platform" }` or use [platform -mappings](#platform-mappings) to support both styles through the migration +"//command_line_option:platforms": "//:my_arm_platform" }` or use [platform mappings](#platform-mappings) to support both styles through the migration window. ## How to use platforms today @@ -359,8 +355,7 @@ If you're a project, language, or toolchain maintainer and your build doesn't use platforms by default, you have three options (besides waiting for the global migration): -1. Flip on the "use platforms" flag for your project's languages ([if they have - one](#status)) and do whatever testing you need to see if the projects you care +1. Flip on the "use platforms" flag for your project's languages ([if they have one](#status)) and do whatever testing you need to see if the projects you care about work. 1. If the projects you care about still depend on legacy flags like `--cpu` and diff --git a/versions/6.5.0/configure/attributes.mdx b/versions/6.5.0/configure/attributes.mdx index f3ca7de6..efa731e7 100644 --- a/versions/6.5.0/configure/attributes.mdx +++ b/versions/6.5.0/configure/attributes.mdx @@ -3,8 +3,7 @@ title: 'Configurable Build Attributes' --- -**_Configurable attributes_**, commonly known as [`select()`]( -/reference/be/functions#select), is a Bazel feature that lets users toggle the values +**_Configurable attributes_**, commonly known as [`select()`](/reference/be/functions#select), is a Bazel feature that lets users toggle the values of build rule attributes at the command line. This can be used, for example, for a multiplatform library that automatically @@ -408,8 +407,7 @@ sh_library( ) ``` -If you need a `select` to match when multiple conditions match, consider [AND -chaining](#and-chaining). +If you need a `select` to match when multiple conditions match, consider [AND chaining](#and-chaining). ## OR chaining {#or-chaining} diff --git a/versions/6.5.0/configure/integrate-cpp.mdx b/versions/6.5.0/configure/integrate-cpp.mdx index 3bb65beb..07eec40e 100644 --- a/versions/6.5.0/configure/integrate-cpp.mdx +++ b/versions/6.5.0/configure/integrate-cpp.mdx @@ -33,8 +33,7 @@ This is because when writing our own actions, they must behave consistently with the C++ toolchain - for example, passing C++ command line flags to a tool that invokes the C++ compiler behind the scenes. -C++ rules use a special way of constructing command lines based on [feature -configuration](/docs/cc-toolchain-config-reference). To construct a command line, +C++ rules use a special way of constructing command lines based on [feature configuration](/docs/cc-toolchain-config-reference). To construct a command line, you need the following: * `features` and `action_configs` - these come from the `CcToolchainConfigInfo` diff --git a/versions/6.5.0/configure/windows.mdx b/versions/6.5.0/configure/windows.mdx index 002af03d..76619416 100644 --- a/versions/6.5.0/configure/windows.mdx +++ b/versions/6.5.0/configure/windows.mdx @@ -166,8 +166,7 @@ To build C++ targets with MSVC, you need: set BAZEL_VC=C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC ``` -* The [Windows - SDK](https://developer.microsoft.com/en-us/windows/downloads/windows-10-sdk). +* The [Windows SDK](https://developer.microsoft.com/en-us/windows/downloads/windows-10-sdk). The Windows SDK contains header files and libraries you need when building Windows applications, including Bazel itself. By default, the latest Windows SDK installed will @@ -186,8 +185,7 @@ To build C++ targets with MSVC, you need: If everything is set up, you can build a C++ target now! -Try building a target from one of our [sample -projects](https://github.com/bazelbuild/bazel/tree/master/examples): +Try building a target from one of our [sample projects](https://github.com/bazelbuild/bazel/tree/master/examples): 
 
 
-To build and use Dynamically Linked Libraries (DLL files), see [this
-example](https://github.com/bazelbuild/bazel/tree/master/examples/windows/dll).
+To build and use Dynamically Linked Libraries (DLL files), see [this example](https://github.com/bazelbuild/bazel/tree/master/examples/windows/dll).
 
 **Command Line Length Limit**: To prevent the
 [Windows command line length limit issue](https://github.com/bazelbuild/bazel/issues/5163),
@@ -292,8 +289,7 @@ On Windows, Bazel builds two output files for `java_binary` rules:
 *   a `.jar` file
 *   a `.exe` file that can set up the environment for the JVM and run the binary
 
-Try building a target from one of our [sample
-projects](https://github.com/bazelbuild/bazel/tree/master/examples):
+Try building a target from one of our [sample projects](https://github.com/bazelbuild/bazel/tree/master/examples):
 
 
   
   
 
 If you are interested in details about how Bazel builds Python targets on
-Windows, check out this [design
-doc](https://github.com/bazelbuild/bazel-website/blob/master/designs/_posts/2016-09-05-build-python-on-windows.md).
+Windows, check out this [design doc](https://github.com/bazelbuild/bazel-website/blob/master/designs/_posts/2016-09-05-build-python-on-windows.md).
diff --git a/versions/6.5.0/contribute/design-documents.mdx b/versions/6.5.0/contribute/design-documents.mdx
index 1e3a24d9..9304bc67 100644
--- a/versions/6.5.0/contribute/design-documents.mdx
+++ b/versions/6.5.0/contribute/design-documents.mdx
@@ -138,8 +138,7 @@ A lead reviewer should be a domain expert who is:
 *   Objective and capable of providing constructive feedback
 *   Available for the entire review period to lead the process
 
-Consider checking the contacts for various [team
-labels](/contribute/maintainers-guide#team-labels).
+Consider checking the contacts for various [team labels](/contribute/maintainers-guide#team-labels).
 
 ## Markdown vs Google Docs {#markdown-versus-gdocs}
 
@@ -169,12 +168,10 @@ Markdown for posterity.
 
 ### Using Google Docs {#gdocs}
 
-For consistency, use the [Bazel design doc template](
-https://docs.google.com/document/d/1cE5zrjrR40RXNg64XtRFewSv6FrLV6slGkkqxBumS1w/edit).
+For consistency, use the [Bazel design doc template](https://docs.google.com/document/d/1cE5zrjrR40RXNg64XtRFewSv6FrLV6slGkkqxBumS1w/edit).
 It includes the necessary header and creates visual
 consistency with other Bazel related documents. To do that, click on **File** >
-**Make a copy** or click this link to [make a copy of the design doc
-template](https://docs.google.com/document/d/1cE5zrjrR40RXNg64XtRFewSv6FrLV6slGkkqxBumS1w/copy).
+**Make a copy** or click this link to [make a copy of the design doc template](https://docs.google.com/document/d/1cE5zrjrR40RXNg64XtRFewSv6FrLV6slGkkqxBumS1w/copy).
 
 To make your document readable to the world, click on
 **Share** > **Advanced** > **Change…**, and
diff --git a/versions/6.5.0/contribute/index.mdx b/versions/6.5.0/contribute/index.mdx
index 5ed7e317..e34e17e6 100644
--- a/versions/6.5.0/contribute/index.mdx
+++ b/versions/6.5.0/contribute/index.mdx
@@ -11,8 +11,7 @@ As you use Bazel, you may find things that can be improved.
 You can help by [reporting issues](http://github.com/bazelbuild/bazel/issues)
 when:
 
-   - Bazel crashes or you encounter a bug that can [only be resolved using `bazel
-     clean`](/docs/build#correct-incremental-rebuilds).
+   - Bazel crashes or you encounter a bug that can [only be resolved using `bazel clean`](/docs/build#correct-incremental-rebuilds).
    - The documentation is incomplete or unclear. You can also report issues
      from the page you are viewing by using the "Create issue"
      link at the top right corner of the page.
@@ -22,11 +21,9 @@ when:
 
 You can engage with the Bazel community by:
 
-   - Answering questions [on Stack Overflow](
-     https://stackoverflow.com/questions/tagged/bazel).
+   - Answering questions [on Stack Overflow](https://stackoverflow.com/questions/tagged/bazel).
    - Helping other users [on Slack](https://slack.bazel.build).
-   - Improving documentation or [contributing examples](
-     https://github.com/bazelbuild/examples).
+   - Improving documentation or [contributing examples](https://github.com/bazelbuild/examples).
    - Sharing your experience or your tips, for example, on a blog or social media.
 
 ## Contribute code {#contribute-code}
@@ -41,8 +38,7 @@ You can contribute to the Bazel ecosystem by:
    - Contributing to Bazel-related tools, for example, migration tools.
    - Improving Bazel integration with other IDEs and tools.
 
-Before making a change, [create a GitHub
-issue](http://github.com/bazelbuild/bazel/issues)
+Before making a change, [create a GitHub issue](http://github.com/bazelbuild/bazel/issues)
 or email [bazel-dev@](mailto:bazel-dev@googlegroups.com).
 
 The most helpful contributions fix bugs or add features (as opposed
diff --git a/versions/6.5.0/contribute/maintainers-guide.mdx b/versions/6.5.0/contribute/maintainers-guide.mdx
index fc543922..7f7e2bbe 100644
--- a/versions/6.5.0/contribute/maintainers-guide.mdx
+++ b/versions/6.5.0/contribute/maintainers-guide.mdx
@@ -5,8 +5,7 @@ title: 'Guide for Bazel Maintainers'
 
 This is a guide for the maintainers of the Bazel open source project.
 
-If you are looking to contribute to Bazel, please read [Contributing to
-Bazel](/contribute) instead.
+If you are looking to contribute to Bazel, please read [Contributing to Bazel](/contribute) instead.
 
 The objectives of this page are to:
 
@@ -36,10 +35,8 @@ repository.
 
 ## Lifecycle of an Issue {#lifecycle-issue}
 
-1. A user creates an issue using the [Issue
-   Template](https://github.com/bazelbuild/bazel/blob/master/ISSUE_TEMPLATE.md)
-   and it enters the pool of [unreviewed open
-   issues](https://github.com/bazelbuild/bazel/issues?utf8=%E2%9C%93&q=is%3Aissue+is%3Aopen+-label%3Auntriaged+-label%3Ap2+-label%3Ap1+-label%3Ap3+-label%3Ap4+-label%3Ateam-Starlark+-label%3Ateam-Rules-CPP+-label%3Ateam-Rules-Java+-label%3Ateam-XProduct+-label%3Ateam-Android+-label%3Ateam-Apple+-label%3Ateam-Configurability++-label%3Ateam-Performance+-label%3Ateam-Rules-Server+-label%3Ateam-Core+-label%3Ateam-Rules-Python+-label%3Ateam-Remote-Exec+-label%3Ateam-Local-Exec+-label%3Ateam-Bazel).
+1. A user creates an issue using the [Issue Template](https://github.com/bazelbuild/bazel/blob/master/ISSUE_TEMPLATE.md)
+   and it enters the pool of [unreviewed open issues](https://github.com/bazelbuild/bazel/issues?utf8=%E2%9C%93&q=is%3Aissue+is%3Aopen+-label%3Auntriaged+-label%3Ap2+-label%3Ap1+-label%3Ap3+-label%3Ap4+-label%3Ateam-Starlark+-label%3Ateam-Rules-CPP+-label%3Ateam-Rules-Java+-label%3Ateam-XProduct+-label%3Ateam-Android+-label%3Ateam-Apple+-label%3Ateam-Configurability++-label%3Ateam-Performance+-label%3Ateam-Rules-Server+-label%3Ateam-Core+-label%3Ateam-Rules-Python+-label%3Ateam-Remote-Exec+-label%3Ateam-Local-Exec+-label%3Ateam-Bazel).
 1. A member on the Developer Experience (DevEx) subteam rotation reviews the
    issue.
    1. If the issue is **not a bug** or a **feature request**, the DevEx member
@@ -53,24 +50,20 @@ repository.
       to the correct repository.
    1. If the issue is vague or has missing information, the DevEx member will
       assign the issue back to the user to request for more information before
-      continuing. This usually occurs when the user does not follow the [Issue
-      Template](https://github.com/bazelbuild/bazel/blob/master/ISSUE_TEMPLATE.md).
+      continuing. This usually occurs when the user does not follow the [Issue Template](https://github.com/bazelbuild/bazel/blob/master/ISSUE_TEMPLATE.md).
 1. After reviewing the issue, the DevEx member decides if the issue requires
    immediate attention. If it does, they will assign the **P0**
    [priority](#priority) label and an owner from the list of team leads.
-1. The DevEx member assigns the `untriaged` label and exactly one [team
-   label](#team-labels) for routing.
+1. The DevEx member assigns the `untriaged` label and exactly one [team label](#team-labels) for routing.
 1. The DevEx member also assigns exactly one `type:` label, such as `type: bug`
    or `type: feature request`, according to the type of the issue.
 1. For platform-specific issues, the DevEx member assigns one `platform:` label,
    such as `platform:apple` for Mac-specific issues.
-At this stage, the issue enters the pool of [untriaged open
-issues](https://github.com/bazelbuild/bazel/issues?q=is%3Aissue+is%3Aopen+label%3Auntriaged).
+At this stage, the issue enters the pool of [untriaged open issues](https://github.com/bazelbuild/bazel/issues?q=is%3Aissue+is%3Aopen+label%3Auntriaged).
 
 Each Bazel subteam will triage all issues under labels they own, preferably on a
 weekly basis. The subteam will review and evaluate the issue and provide a
-resolution, if possible. If you are an owner of a team label, see [this section
-](#label-own) for more information.
+resolution, if possible. If you are an owner of a team label, see [this section](#label-own) for more information.
 
 When an issue is resolved, it can be closed.
 
@@ -110,8 +103,7 @@ preferably on a weekly basis.
      issue is either P0 or P1 we assume that is actively worked on.
 1. Remove the `untriaged` label.
 
-Note that you need to be in the [bazelbuild
-organization](https://github.com/bazelbuild) to be able to add or remove labels.
+Note that you need to be in the [bazelbuild organization](https://github.com/bazelbuild) to be able to add or remove labels.
 
 ### Pull Requests {#pull-requests}
 
@@ -137,8 +129,7 @@ issues.
   unusable, or a downed service that severely impacts development of the Bazel
   project. This includes regressions introduced in a new release that blocks a
   significant number of users, or an incompatible breaking change that was not
-  compliant to the [Breaking
-  Change](https://docs.google.com/document/d/1q5GGRxKrF_mnwtaPKI487P8OdDRh2nN7jX6U-FXnHL0/edit?pli=1#heading=h.ceof6vpkb3ik)
+  compliant to the [Breaking Change](https://docs.google.com/document/d/1q5GGRxKrF_mnwtaPKI487P8OdDRh2nN7jX6U-FXnHL0/edit?pli=1#heading=h.ceof6vpkb3ik)
   policy. No practical workaround exists.
 * [**P1**](https://github.com/bazelbuild/bazel/labels/P1) - Critical defect or
   feature which should be addressed in the next release, or a serious issue that
diff --git a/versions/6.5.0/contribute/naming.mdx b/versions/6.5.0/contribute/naming.mdx
index acb37a2c..8e38985e 100644
--- a/versions/6.5.0/contribute/naming.mdx
+++ b/versions/6.5.0/contribute/naming.mdx
@@ -5,8 +5,7 @@ title: 'Naming a Bazel related project'
 
 First, thank you for contributing to the Bazel ecosystem! Please reach out to
 the Bazel community on the
-[bazel-discuss mailing list](https://groups.google.com/forum/#!forum/bazel-discuss
-) to share your project and its suggested name.
+[bazel-discuss mailing list](https://groups.google.com/forum/#!forum/bazel-discuss) to share your project and its suggested name.
 
 If you are building a Bazel related tool or sharing your Skylark rules,
 we recommend following these guidelines for the name of your project:
diff --git a/versions/6.5.0/contribute/patch-acceptance.mdx b/versions/6.5.0/contribute/patch-acceptance.mdx
index ad95245d..fc769bc1 100644
--- a/versions/6.5.0/contribute/patch-acceptance.mdx
+++ b/versions/6.5.0/contribute/patch-acceptance.mdx
@@ -12,19 +12,16 @@ code base.
    need a corresponding issue for tracking.
 1. If you're proposing significant changes, write a
    [design document](/contribute/design-documents).
-1. Ensure you've signed a [Contributor License
-   Agreement](https://cla.developers.google.com).
+1. Ensure you've signed a [Contributor License Agreement](https://cla.developers.google.com).
 1. Prepare a git commit that implements the feature. Don't forget to add tests
    and update the documentation. If your change has user-visible effects, please
    [add release notes](/contribute/release-notes). If it is an incompatible change,
    read the [guide for rolling out breaking changes](/contribute/breaking-changes).
 1. Create a pull request on
    [GitHub](https://github.com/bazelbuild/bazel/pulls). If you're new to GitHub,
-   read [about pull
-   requests](https://help.github.com/articles/about-pull-requests/). Note that
+   read [about pull requests](https://help.github.com/articles/about-pull-requests/). Note that
    we restrict permissions to create branches on the main Bazel repository, so
-   you will need to push your commit to [your own fork of the
-   repository](https://help.github.com/articles/working-with-forks/).
+   you will need to push your commit to [your own fork of the repository](https://help.github.com/articles/working-with-forks/).
 1. A Bazel maintainer should assign you a reviewer within two business days
    (excluding holidays in the USA and Germany). If you aren't assigned a
    reviewer in that time, you can request one by emailing
diff --git a/versions/6.5.0/contribute/release-notes.mdx b/versions/6.5.0/contribute/release-notes.mdx
index 4d868471..676f24cd 100644
--- a/versions/6.5.0/contribute/release-notes.mdx
+++ b/versions/6.5.0/contribute/release-notes.mdx
@@ -17,8 +17,7 @@ the release announcement.
 * If the change adds / removes / changes Bazel in a user-visible way, then it
   may be advantageous to mention it.
 
-If the change is significant, follow the [design document
-policy](/contribute/design-documents) first.
+If the change is significant, follow the [design document policy](/contribute/design-documents) first.
 
 ## Guidelines {#guidelines}
 
@@ -61,10 +60,8 @@ change is about.
 
 ## Process {#process}
 
-As part of the [release
-process](https://github.com/bazelbuild/continuous-integration/blob/master/docs/release-playbook.md),
-we collect the `RELNOTES` tags of every commit. We copy everything in a [Google
-Doc](https://docs.google.com/document/d/1wDvulLlj4NAlPZamdlEVFORks3YXJonCjyuQMUQEmB0/edit)
+As part of the [release process](https://github.com/bazelbuild/continuous-integration/blob/master/docs/release-playbook.md),
+we collect the `RELNOTES` tags of every commit. We copy everything in a [Google Doc](https://docs.google.com/document/d/1wDvulLlj4NAlPZamdlEVFORks3YXJonCjyuQMUQEmB0/edit)
 where we review, edit, and organize the notes.
 
 The release manager sends an email to the
@@ -72,6 +69,4 @@ The release manager sends an email to the
 Bazel contributors are invited to contribute to the document and make sure
 their changes are correctly reflected in the announcement.
 
-Later, the announcement will be submitted to the [Bazel
-blog](https://blog.bazel.build/), using the [bazel-blog
-repository](https://github.com/bazelbuild/bazel-blog/tree/master/_posts).
+Later, the announcement will be submitted to the [Bazel blog](https://blog.bazel.build/), using the [bazel-blog repository](https://github.com/bazelbuild/bazel-blog/tree/master/_posts).
diff --git a/versions/6.5.0/docs/android-instrumentation-test.mdx b/versions/6.5.0/docs/android-instrumentation-test.mdx
index 56fa623b..9ac7acfc 100644
--- a/versions/6.5.0/docs/android-instrumentation-test.mdx
+++ b/versions/6.5.0/docs/android-instrumentation-test.mdx
@@ -3,8 +3,7 @@ title: 'Android Instrumentation Tests'
 ---
 
 
-_If you're new to Bazel, start with the [Building Android with
-Bazel](/tutorials/android-app) tutorial._
+_If you're new to Bazel, start with the [Building Android with Bazel](/tutorials/android-app) tutorial._
 
 ![Running Android instrumentation tests in parallel](/docs/images/android_test.gif "Android instrumentation test")
 
@@ -19,9 +18,7 @@ emulators in a sandbox, ensuring that tests always run from a clean state. Each
 test gets an isolated emulator instance, allowing tests to run in parallel
 without passing states between them.
 
-For more information on Android instrumentation tests, check out the [Android
-developer
-documentation](https://developer.android.com/training/testing/unit-testing/instrumented-unit-tests.html).
+For more information on Android instrumentation tests, check out the [Android developer documentation](https://developer.android.com/training/testing/unit-testing/instrumented-unit-tests.html).
 
 Please file issues in the [GitHub issue tracker](https://github.com/bazelbuild/bazel/issues).
 
@@ -59,8 +56,7 @@ This results in output similar to the following:
 release 4.1.0
 ```
 
-- **KVM**. Bazel requires emulators to have [hardware
-  acceleration](https://developer.android.com/studio/run/emulator-acceleration.html#accel-check)
+- **KVM**. Bazel requires emulators to have [hardware acceleration](https://developer.android.com/studio/run/emulator-acceleration.html#accel-check)
   with KVM on Linux. You can follow these
   [installation instructions](https://help.ubuntu.com/community/KVM/Installation)
   for Ubuntu.
@@ -175,11 +171,9 @@ The main attributes of the rule `android_instrumentation_test` are:
 
 - `target_device`: An `android_device` target. This target describes the
   specifications of the Android emulator which Bazel uses to create, launch and
-  run the tests. See the [section on choosing an Android
-  device](#android-device-target) for more information.
+  run the tests. See the [section on choosing an Android device](#android-device-target) for more information.
 
-The test app's `AndroidManifest.xml` must include [an ``
-tag](https://developer.android.com/studio/test/#configure_instrumentation_manifest_settings).
+The test app's `AndroidManifest.xml` must include [an `` tag](https://developer.android.com/studio/test/#configure_instrumentation_manifest_settings).
 This tag must specify the attributes for the **package of the target app** and
 the **fully qualified class name of the instrumentation test runner**,
 `androidx.test.runner.AndroidJUnitRunner`.
@@ -216,8 +210,7 @@ repositories:
 - `@androidsdk`: The Android SDK. Download this through Android Studio.
 
 - `@android_test_support`: Hosts the test runner, emulator launcher, and
-  `android_device` targets. You can find the [latest release
-  here](https://github.com/android/android-test/releases).
+  `android_device` targets. You can find the [latest release here](https://github.com/android/android-test/releases).
 
 Enable these dependencies by adding the following lines to your `WORKSPACE`
 file:
@@ -242,8 +235,7 @@ android_test_repositories()
 
 ## Maven dependencies {#maven-dependencies}
 
-For managing dependencies on Maven artifacts from repositories, such as [Google
-Maven](https://maven.google.com) or [Maven Central](https://central.maven.org),
+For managing dependencies on Maven artifacts from repositories, such as [Google Maven](https://maven.google.com) or [Maven Central](https://central.maven.org),
 you should use a Maven resolver, such as
 [`rules_jvm_external`](https://github.com/bazelbuild/rules_jvm_external).
 
@@ -372,8 +364,7 @@ the device/emulator listed in `adb devices`.
 
 ## Sample projects {#sample-projects}
 
-If you are looking for canonical project samples, see the [Android testing
-samples](https://github.com/googlesamples/android-testing#experimental-bazel-support)
+If you are looking for canonical project samples, see the [Android testing samples](https://github.com/googlesamples/android-testing#experimental-bazel-support)
 for projects using Espresso and UIAutomator.
 
 ## Espresso setup {#espresso-setup}
@@ -562,8 +553,7 @@ API_LEVELS = [
 
 ## Known issues {#known-issues}
 
-- [Forked adb server processes are not terminated after
-  tests](https://github.com/bazelbuild/bazel/issues/4853)
+- [Forked adb server processes are not terminated after tests](https://github.com/bazelbuild/bazel/issues/4853)
 - While APK building works on all platforms (Linux, macOS, Windows), testing
   only works on Linux.
 - Even with `--config=local_adb`, users still need to specify
diff --git a/versions/6.5.0/docs/android-ndk.mdx b/versions/6.5.0/docs/android-ndk.mdx
index 5fa7e2f6..f39ceb2f 100644
--- a/versions/6.5.0/docs/android-ndk.mdx
+++ b/versions/6.5.0/docs/android-ndk.mdx
@@ -3,8 +3,7 @@ title: 'Using the Android Native Development Kit with Bazel'
 ---
 
 
-_If you're new to Bazel, please start with the [Building Android with
-Bazel](/tutorials/android-app) tutorial._
+_If you're new to Bazel, please start with the [Building Android with Bazel](/tutorials/android-app) tutorial._
 
 ## Overview {#overview}
 
@@ -32,8 +31,7 @@ android_ndk_repository(
 )
 ```
 
-For more information on the `android_ndk_repository` rule, see the [Build
-Encyclopedia entry](/reference/be/android#android_ndk_repository).
+For more information on the `android_ndk_repository` rule, see the [Build Encyclopedia entry](/reference/be/android#android_ndk_repository).
 
 ## Quick start {#quick-start}
 
@@ -97,13 +95,11 @@ META-INF/MANIFEST.MF
 
 Bazel compiles all of the cc_libraries into a single shared object (`.so`) file,
 targeted for the `armeabi-v7a` ABI by default. To change this or build for
-multiple ABIs at the same time, see the section on [configuring the target
-ABI](#configuring-target-abi).
+multiple ABIs at the same time, see the section on [configuring the target ABI](#configuring-target-abi).
 
 ## Example setup {#example-setup}
 
-This example is available in the [Bazel examples
-repository](https://github.com/bazelbuild/examples/tree/master/android/ndk).
+This example is available in the [Bazel examples repository](https://github.com/bazelbuild/examples/tree/master/android/ndk).
 
 In the `BUILD.bazel` file, three targets are defined with the `android_binary`,
 `android_library`, and `cc_library` rules.
@@ -174,12 +170,10 @@ For r16 and below, the default STL is `gnustl`. For r17 and above, it is
 `libc++`. For convenience, the target `@androidndk//:default_crosstool` is
 aliased to the respective default STLs.
 
-Please note that from r18 onwards, [STLport and gnustl will be
-removed](https://android.googlesource.com/platform/ndk/+/master/docs/Roadmap.md#ndk-r18),
+Please note that from r18 onwards, [STLport and gnustl will be removed](https://android.googlesource.com/platform/ndk/+/master/docs/Roadmap.md#ndk-r18),
 making `libc++` the only STL in the NDK.
 
-See the [NDK
-documentation](https://developer.android.com/ndk/guides/cpp-support)
+See the [NDK documentation](https://developer.android.com/ndk/guides/cpp-support)
 for more information on these STLs.
 
 ## Configuring the target ABI {#configuring-target-abi}
@@ -320,8 +314,7 @@ an Android-compatible configuration so that the Bazel build *just works* without
 any special flags, except for `--fat_apk_cpu` and `--android_crosstool_top` for
 ABI and STL configuration.
 
-Behind the scenes, this automatic configuration uses Android [configuration
-transitions](/rules/rules#configurations).
+Behind the scenes, this automatic configuration uses Android [configuration transitions](/rules/rules#configurations).
 
 A compatible rule, like `android_binary`, automatically changes the
 configuration of its dependencies to an Android configuration, so only
diff --git a/versions/6.5.0/docs/configurable-attributes.mdx b/versions/6.5.0/docs/configurable-attributes.mdx
index f3ca7de6..efa731e7 100644
--- a/versions/6.5.0/docs/configurable-attributes.mdx
+++ b/versions/6.5.0/docs/configurable-attributes.mdx
@@ -3,8 +3,7 @@ title: 'Configurable Build Attributes'
 ---
 
 
-**_Configurable attributes_**, commonly known as [`select()`](
-/reference/be/functions#select), is a Bazel feature that lets users toggle the values
+**_Configurable attributes_**, commonly known as [`select()`](/reference/be/functions#select), is a Bazel feature that lets users toggle the values
 of build rule attributes at the command line.
 
 This can be used, for example, for a multiplatform library that automatically
@@ -408,8 +407,7 @@ sh_library(
 )
 ```
 
-If you need a `select` to match when multiple conditions match, consider [AND
-chaining](#and-chaining).
+If you need a `select` to match when multiple conditions match, consider [AND chaining](#and-chaining).
 
 ## OR chaining {#or-chaining}
 
diff --git a/versions/6.5.0/extending/depsets.mdx b/versions/6.5.0/extending/depsets.mdx
index 1454c378..a6b146e7 100644
--- a/versions/6.5.0/extending/depsets.mdx
+++ b/versions/6.5.0/extending/depsets.mdx
@@ -112,8 +112,7 @@ need to ensure that if `B` depends on `A`, then `A.o` comes before `B.o` on the
 linker’s command line. Other tools might have the opposite requirement.
 
 Three traversal orders are supported: `postorder`, `preorder`, and
-`topological`. The first two work exactly like [tree
-traversals](https://en.wikipedia.org/wiki/Tree_traversal#Depth-first_search)
+`topological`. The first two work exactly like [tree traversals](https://en.wikipedia.org/wiki/Tree_traversal#Depth-first_search)
 except that they operate on DAGs and skip already visited nodes. The third order
 works as a topological sort from root to leaves, essentially the same as
 preorder except that shared children are listed only after all of their parents.
diff --git a/versions/6.5.0/extending/exec-groups.mdx b/versions/6.5.0/extending/exec-groups.mdx
index 42fa0416..613095a5 100644
--- a/versions/6.5.0/extending/exec-groups.mdx
+++ b/versions/6.5.0/extending/exec-groups.mdx
@@ -106,8 +106,7 @@ of:
 
 In the rule implementation, you can declare that actions should be run on the
 execution platform of an execution group. You can do this by using the `exec_group`
-param of action generating methods, specifically [`ctx.actions.run`]
-(/rules/lib/actions#run) and
+param of action generating methods, specifically [`ctx.actions.run`](/rules/lib/actions#run) and
 [`ctx.actions.run_shell`](/rules/lib/actions#run_shell).
 
 ```python
diff --git a/versions/6.5.0/extending/macros.mdx b/versions/6.5.0/extending/macros.mdx
index 4a211939..f6243d9c 100644
--- a/versions/6.5.0/extending/macros.mdx
+++ b/versions/6.5.0/extending/macros.mdx
@@ -213,8 +213,7 @@ def my_macro(name, deps, visibility=None):
     instantiate rules must have a `name` argument. This argument should not be
     optional (don't give a default value).
 
-*   Public functions should use a docstring following [Python
-    conventions](https://www.python.org/dev/peps/pep-0257/#one-line-docstrings).
+*   Public functions should use a docstring following [Python conventions](https://www.python.org/dev/peps/pep-0257/#one-line-docstrings).
 
 *   In `BUILD` files, the `name` argument of the macros must be a keyword
     argument (not a positional argument).
diff --git a/versions/6.5.0/extending/platforms.mdx b/versions/6.5.0/extending/platforms.mdx
index d1254fec..67fcbe65 100644
--- a/versions/6.5.0/extending/platforms.mdx
+++ b/versions/6.5.0/extending/platforms.mdx
@@ -226,8 +226,7 @@ cc_library(
 
 You can use the
 [`IncompatiblePlatformProvider`](/rules/lib/IncompatiblePlatformProvider)
-in `bazel cquery`'s [Starlark output
-format](/docs/cquery#output-format-definition) to distinguish
+in `bazel cquery`'s [Starlark output format](/docs/cquery#output-format-definition) to distinguish
 incompatible targets from compatible ones.
 
 This can be used to filter out incompatible targets. The example below will
@@ -248,5 +247,4 @@ $ bazel cquery //... --output=starlark --starlark:file=example.cquery
 
 ### Known Issues
 
-Incompatible targets [ignore visibility
-restrictions](https://github.com/bazelbuild/bazel/issues/16044).
+Incompatible targets [ignore visibility restrictions](https://github.com/bazelbuild/bazel/issues/16044).
diff --git a/versions/6.5.0/extending/rules.mdx b/versions/6.5.0/extending/rules.mdx
index 54f47ef3..ab56e718 100644
--- a/versions/6.5.0/extending/rules.mdx
+++ b/versions/6.5.0/extending/rules.mdx
@@ -463,8 +463,7 @@ def _example_library_impl(ctx):
 
 If `DefaultInfo` is not returned by a rule implementation or the `files`
 parameter is not specified, `DefaultInfo.files` defaults to all
-*predeclared outputs* (generally, those created by [output
-attributes](#output_attributes)).
+*predeclared outputs* (generally, those created by [output attributes](#output_attributes)).
 
 Rules that perform actions should provide default outputs, even if those outputs
 are not expected to be directly used. Actions that are not in the graph of the
diff --git a/versions/6.5.0/external/advanced.mdx b/versions/6.5.0/external/advanced.mdx
index 471c5540..af2faaf4 100644
--- a/versions/6.5.0/external/advanced.mdx
+++ b/versions/6.5.0/external/advanced.mdx
@@ -6,10 +6,8 @@ title: 'Advanced topics on external dependencies'
 
 ## Shadowing dependencies in WORKSPACE
 
-Note: This section applies to the [WORKSPACE
-system](/external/overview#workspace-system) only. For
-[Bzlmod](/external/overview#bzlmod), use a [multiple-version
-override](/external/module#multiple-version_override).
+Note: This section applies to the [WORKSPACE system](/external/overview#workspace-system) only. For
+[Bzlmod](/external/overview#bzlmod), use a [multiple-version override](/external/module#multiple-version_override).
 
 Whenever possible, have a single version policy in your project, which is
 required for dependencies that you compile against and end up in your final
@@ -130,29 +128,24 @@ preferring IPv4 if enabled. In some situations, for example when the IPv4
 network cannot resolve/reach external addresses, this can cause `Network
 unreachable` exceptions and build failures. In these cases, you can override
 Bazel's behavior to prefer IPv6 by using the
-[`java.net.preferIPv6Addresses=true` system
-property](https://docs.oracle.com/javase/8/docs/api/java/net/doc-files/net-properties.html).
+[`java.net.preferIPv6Addresses=true` system property](https://docs.oracle.com/javase/8/docs/api/java/net/doc-files/net-properties.html).
 Specifically:
 
-*   Use `--host_jvm_args=-Djava.net.preferIPv6Addresses=true` [startup
-    option](/docs/user-manual#startup-options), for example by adding the
+*   Use `--host_jvm_args=-Djava.net.preferIPv6Addresses=true` [startup option](/docs/user-manual#startup-options), for example by adding the
     following line in your [`.bazelrc` file](/run/bazelrc):
 
     `startup --host_jvm_args=-Djava.net.preferIPv6Addresses=true`
 
 *   When running Java build targets that need to connect to the internet (such
     as for integration tests), use the
-    `--jvmopt=-Djava.net.preferIPv6Addresses=true` [tool
-    flag](/docs/user-manual#jvmopt). For example, include in your [`.bazelrc`
-    file](/run/bazelrc):
+    `--jvmopt=-Djava.net.preferIPv6Addresses=true` [tool flag](/docs/user-manual#jvmopt). For example, include in your [`.bazelrc` file](/run/bazelrc):
 
     `build --jvmopt=-Djava.net.preferIPv6Addresses`
 
 *   If you are using [`rules_jvm_external`](https://github.com/bazelbuild/rules_jvm_external)
     for dependency version resolution, also add
     `-Djava.net.preferIPv6Addresses=true` to the `COURSIER_OPTS` environment
-    variable to [provide JVM options for
-    Coursier](https://github.com/bazelbuild/rules_jvm_external#provide-jvm-options-for-coursier-with-coursier_opts).
+    variable to [provide JVM options for Coursier](https://github.com/bazelbuild/rules_jvm_external#provide-jvm-options-for-coursier-with-coursier_opts).
 
 ## Offline builds
 
@@ -169,15 +162,12 @@ fetch a file with [`ctx.download`](/rules/lib/repository_ctx#download) or
 providing a hash sum of the file needed, Bazel looks for a file matching the
 basename of the first URL, and uses the local copy if the hash matches.
 
-Bazel itself uses this technique to bootstrap offline from the [distribution
-artifact](https://github.com/bazelbuild/bazel-website/blob/master/designs/_posts/2016-10-11-distribution-artifact.md).
-It does so by [collecting all the needed external
-dependencies](https://github.com/bazelbuild/bazel/blob/5cfa0303d6ac3b5bd031ff60272ce80a704af8c2/WORKSPACE#L116)
+Bazel itself uses this technique to bootstrap offline from the [distribution artifact](https://github.com/bazelbuild/bazel-website/blob/master/designs/_posts/2016-10-11-distribution-artifact.md).
+It does so by [collecting all the needed external dependencies](https://github.com/bazelbuild/bazel/blob/5cfa0303d6ac3b5bd031ff60272ce80a704af8c2/WORKSPACE#L116)
 in an internal
 [`distdir_tar`](https://github.com/bazelbuild/bazel/blob/5cfa0303d6ac3b5bd031ff60272ce80a704af8c2/distdir.bzl#L44).
 
 Bazel allows execution of arbitrary commands in repository rules without knowing
 if they call out to the network, and so cannot enforce fully offline builds. To
 test if a build works correctly offline, manually block off the network (as
-Bazel does in its [bootstrap
-test](https://cs.opensource.google/bazel/bazel/+/master:src/test/shell/bazel/BUILD;l=1073;drc=88c426e73cc0eb0a41c0d7995e36acd94e7c9a48)).
+Bazel does in its [bootstrap test](https://cs.opensource.google/bazel/bazel/+/master:src/test/shell/bazel/BUILD;l=1073;drc=88c426e73cc0eb0a41c0d7995e36acd94e7c9a48)).
diff --git a/versions/6.5.0/external/migration.mdx b/versions/6.5.0/external/migration.mdx
index f1e1ca3c..a02153d8 100644
--- a/versions/6.5.0/external/migration.mdx
+++ b/versions/6.5.0/external/migration.mdx
@@ -3,8 +3,7 @@
 title: 'Bzlmod Migration Guide'
 ---
 
-Due to the [shortcomings of
-WORKSPACE](/external/overview#workspace-shortcomings), Bzlmod is going to
+Due to the [shortcomings of WORKSPACE](/external/overview#workspace-shortcomings), Bzlmod is going to
 replace the legacy WORKSPACE system in future Bazel releases. This guide helps
 you migrate your project to Bzlmod and drop WORKSPACE for fetching external
 dependencies.
@@ -104,9 +103,7 @@ Bazel module when it also adopts Bzlmod.
 
 *   **Bzlmod**
 
-    With Bzlmod, as long as the your dependency is available in [Bazel Central
-    Registry](https://registry.bazel.build) or your custom [Bazel
-    registry](/external/registry), you can simply depend on it with a
+    With Bzlmod, as long as the your dependency is available in [Bazel Central Registry](https://registry.bazel.build) or your custom [Bazel registry](/external/registry), you can simply depend on it with a
     [`bazel_dep`](/versions/6.5.0/rules/lib/globals/module#bazel_dep) directive.
 
     ```python
@@ -541,8 +538,7 @@ macros.
 Fortunately, the flag
 [`--experimental_repository_resolved_file`][resolved_file_flag]
 can help. This flag essentially generates a "lock file" of all fetched external
-dependencies in your last Bazel command. You can find more details in this [blog
-post](https://blog.bazel.build/2018/07/09/bazel-sync-and-resolved-file.html).
+dependencies in your last Bazel command. You can find more details in this [blog post](https://blog.bazel.build/2018/07/09/bazel-sync-and-resolved-file.html).
 
 [resolved_file_flag]: /reference/command-line-reference#flag--experimental_repository_resolved_file
 
@@ -583,11 +579,9 @@ You may also know `bazel query` can be used for inspecting repository rules with
 bazel query --output=build //external:
 ```
 
-While it is more convenient and much faster, [bazel query can lie about
-external dependency version](https://github.com/bazelbuild/bazel/issues/12947),
+While it is more convenient and much faster, [bazel query can lie about external dependency version](https://github.com/bazelbuild/bazel/issues/12947),
 so be careful using it! Querying and inspecting external
-dependencies with Bzlmod is going to achieved by a [new
-subcommand](https://github.com/bazelbuild/bazel/issues/15365).
+dependencies with Bzlmod is going to achieved by a [new subcommand](https://github.com/bazelbuild/bazel/issues/15365).
 
 #### Built-in default dependencies {#builtin-default-deps}
 
@@ -634,8 +628,7 @@ your workspace root.
 #### Repository visibility {#repository-visibility}
 
 Bzlmod is able to control which other repositories are visible from a given
-repository, check [repository names and strict
-deps](/external/module#repository_names_and_strict_deps) for more details.
+repository, check [repository names and strict deps](/external/module#repository_names_and_strict_deps) for more details.
 
 Here is a summary of repository visibilities from different types of
 repositories when also taking WORKSPACE into consideration.
@@ -648,8 +641,7 @@ repositories when also taking WORKSPACE into consideration.
 | WORKSPACE Repos | All visible | Not visible | Not visible | All visible |
 
 Note: For the root module, if a repository `@foo` is defined in WORKSPACE and
-`@foo` is also used as an [apparent repository
-name](/external/overview#apparent-repo-name) in MODULE.bazel, then `@foo`
+`@foo` is also used as an [apparent repository name](/external/overview#apparent-repo-name) in MODULE.bazel, then `@foo`
 refers to the one introduced in MODULE.bazel.
 
 Note: For a module extension generated repository `@bar`, if `@foo` is used as
@@ -724,9 +716,7 @@ the project. Take note of a few things when creating the source archive:
     GitHub isn't going to guarantee the checksum of source archives generated on
     demand. In short, URLs in the form of
     `https://github.com///releases/download/...` is considered stable
-    while `https://github.com///archive/...` is not. Check [GitHub
-    Archive Checksum
-    Outage](https://blog.bazel.build/2023/02/15/github-archive-checksum.html)
+    while `https://github.com///archive/...` is not. Check [GitHub Archive Checksum Outage](https://blog.bazel.build/2023/02/15/github-archive-checksum.html)
     for more context.
 
 *   **Make sure the source tree follows the layout of the original repository.**
@@ -755,8 +745,7 @@ Pull Request.
 
 [bcr_contrib_guide]: https://github.com/bazelbuild/bazel-central-registry/tree/main/docs#contribute-a-bazel-module
 
-It is **highly recommended** to set up the [Publish to
-BCR](https://github.com/bazel-contrib/publish-to-bcr) GitHub App for your
+It is **highly recommended** to set up the [Publish to BCR](https://github.com/bazel-contrib/publish-to-bcr) GitHub App for your
 repository to automate the process of submitting your module to the BCR.
 
 ## Best practices {#best-practices}
diff --git a/versions/6.5.0/external/mod-command.mdx b/versions/6.5.0/external/mod-command.mdx
index f0950653..c9cd33a1 100644
--- a/versions/6.5.0/external/mod-command.mdx
+++ b/versions/6.5.0/external/mod-command.mdx
@@ -62,11 +62,9 @@ The available subcommands and their respective required arguments are:
 
 *   ``: All present versions of the module ``.
 
-*   `@`: The repo with the given [apparent
-    name](overview#apparent-repo-name) in the context of the `--base_module`.
+*   `@`: The repo with the given [apparent name](overview#apparent-repo-name) in the context of the `--base_module`.
 
-*   `@@`: The repo with the given [canonical
-    name](overview#canonical-repo-name).
+*   `@@`: The repo with the given [canonical name](overview#canonical-repo-name).
 
 In a context requiring specifying modules, ``s referring to repos that
 correspond to modules (as opposed to extension-generated repos) can also be
@@ -88,8 +86,7 @@ The following options only affect the subcommands that print graphs (`graph`,
     information about the version resolution of each module. If the module
     version changed during resolution, show either which version replaced it or
     what was the original version, the reason it was replaced, and which modules
-    requested the new version if the reason was [Minimal Version
-    Selection](module#version-selection).
+    requested the new version if the reason was [Minimal Version Selection](module#version-selection).
 
 *   `--include_unused` *default: "false"*: Include in the output graph the
     modules which were originally present in the dependency graph, but became
diff --git a/versions/6.5.0/external/module.mdx b/versions/6.5.0/external/module.mdx
index e9d9492f..9df43158 100644
--- a/versions/6.5.0/external/module.mdx
+++ b/versions/6.5.0/external/module.mdx
@@ -124,8 +124,7 @@ serves multiple purposes:
     version, regardless of which versions of the dependency are requested in the
     dependency graph.
 *   With the `registry` attribute, you can force this dependency to come from a
-    specific registry, instead of following the normal [registry
-    selection](/external/registry#selecting_registries) process.
+    specific registry, instead of following the normal [registry selection](/external/registry#selecting_registries) process.
 *   With the `patch*` attributes, you can specify a set of patches to apply to
     the downloaded module.
 
diff --git a/versions/6.5.0/external/overview.mdx b/versions/6.5.0/external/overview.mdx
index 22fb154d..f064ab32 100644
--- a/versions/6.5.0/external/overview.mdx
+++ b/versions/6.5.0/external/overview.mdx
@@ -118,8 +118,7 @@ bazel_dep(name = "protobuf", version = "3.19.0")
 ```
 
 A module must only list its direct dependencies, which Bzlmod looks up in a
-[Bazel registry](/versions/6.5.0/external/registry) — by default, the [Bazel Central
-Registry](https://bcr.bazel.build/). The registry provides the
+[Bazel registry](/versions/6.5.0/external/registry) — by default, the [Bazel Central Registry](https://bcr.bazel.build/). The registry provides the
 dependencies' `MODULE.bazel` files, which allows Bazel to discover the entire
 transitive dependency graph before performing version resolution.
 
@@ -189,5 +188,4 @@ many pain points, including:
         `B` and `C`; `B` and `C` both depend on different versions of `D`).
 
 Due to the shortcomings of WORKSPACE, Bzlmod is going to replace the legacy
-WORKSPACE system in future Bazel releases. Please read the [Bzlmod migration
-guide](/external/migration) on how to migrate to Bzlmod.
\ No newline at end of file
+WORKSPACE system in future Bazel releases. Please read the [Bzlmod migration guide](/external/migration) on how to migrate to Bzlmod.
\ No newline at end of file
diff --git a/versions/6.5.0/external/registry.mdx b/versions/6.5.0/external/registry.mdx
index 9ae4e805..71e774ad 100644
--- a/versions/6.5.0/external/registry.mdx
+++ b/versions/6.5.0/external/registry.mdx
@@ -34,8 +34,7 @@ An index registry must follow the format below:
             project
         *   `versions`: A list of all the versions of this module to be found in
             this registry
-        *   `yanked_versions`: A map of [*yanked*
-            versions](/external/module#yanked_versions) of this module. The keys
+        *   `yanked_versions`: A map of [*yanked* versions](/external/module#yanked_versions) of this module. The keys
             should be versions to yank and the values should be descriptions of
             why the version is yanked, ideally containing a link to more
             information
@@ -46,8 +45,7 @@ An index registry must follow the format below:
         *   The default type is "archive", representing an `http_archive` repo,
             with the following fields:
             *   `url`: The URL of the source archive
-            *   `integrity`: The [Subresource
-                Integrity](https://w3c.github.io/webappsec-subresource-integrity/#integrity-metadata-description)
+            *   `integrity`: The [Subresource Integrity](https://w3c.github.io/webappsec-subresource-integrity/#integrity-metadata-description)
                 checksum of the archive
             *   `strip_prefix`: A directory prefix to strip when extracting the
                 source archive
@@ -85,8 +83,7 @@ You can browse its contents using the web frontend at
 https://registry.bazel.build/.
 
 The Bazel community maintains the BCR, and contributors are welcome to submit
-pull requests. See the [BCR contribution
-guidelines](https://github.com/bazelbuild/bazel-central-registry/blob/main/docs/README.md).
+pull requests. See the [BCR contribution guidelines](https://github.com/bazelbuild/bazel-central-registry/blob/main/docs/README.md).
 
 In addition to following the format of a normal index registry, the BCR requires
 a `presubmit.yml` file for each module version
diff --git a/versions/6.5.0/help.mdx b/versions/6.5.0/help.mdx
index 4553b01c..47c2d0bf 100644
--- a/versions/6.5.0/help.mdx
+++ b/versions/6.5.0/help.mdx
@@ -41,5 +41,4 @@ If there are no existing answers, you can ask the community by:
 
 ## File a bug {#file-bug}
 
-If you encounter a bug or want to request a feature, file a [GitHub
-Issue](https://github.com/bazelbuild/bazel/issues).
+If you encounter a bug or want to request a feature, file a [GitHub Issue](https://github.com/bazelbuild/bazel/issues).
diff --git a/versions/6.5.0/install/bazelisk.mdx b/versions/6.5.0/install/bazelisk.mdx
index a10d4712..e418fed2 100644
--- a/versions/6.5.0/install/bazelisk.mdx
+++ b/versions/6.5.0/install/bazelisk.mdx
@@ -17,8 +17,7 @@ For more details, see
 ## Updating Bazel
 
 Bazel has a [backward compatibility policy](/release/backward-compatibility)
-(see [guidance for rolling out incompatible
-changes](/contribute/breaking-changes) if you
+(see [guidance for rolling out incompatible changes](/contribute/breaking-changes) if you
 are the author of one). That page summarizes best practices on how to test and
 migrate your project with upcoming incompatible changes and how to provide
 feedback to the incompatible change authors.
diff --git a/versions/6.5.0/install/compile-source.mdx b/versions/6.5.0/install/compile-source.mdx
index 029759f6..f27b677b 100644
--- a/versions/6.5.0/install/compile-source.mdx
+++ b/versions/6.5.0/install/compile-source.mdx
@@ -47,8 +47,7 @@ it by typing `bazel` in a terminal.
 
 **Reason**: To build Bazel from a GitHub source tree, you need a pre-existing
 Bazel binary. You can install one from a package manager or download one from
-GitHub. See [Installing Bazel](/install). (Or you can [build from
-scratch (bootstrap)](#bootstrap-bazel).)
+GitHub. See [Installing Bazel](/install). (Or you can [build from scratch (bootstrap)](#bootstrap-bazel).)
 
 **Troubleshooting**:
 
@@ -235,8 +234,7 @@ For instructions for Unix-like systems, see
     ```
 
 *   **The Visual C++ compiler.** Install the Visual C++ compiler either as part
-    of Visual Studio 2015 or newer, or by installing the latest [Build Tools
-    for Visual Studio 2017](https://aka.ms/BuildTools).
+    of Visual Studio 2015 or newer, or by installing the latest [Build Tools for Visual Studio 2017](https://aka.ms/BuildTools).
 
 *   **JDK.** Version 11 is required.
 
diff --git a/versions/6.5.0/install/ide.mdx b/versions/6.5.0/install/ide.mdx
index 8483c91b..99a3aa7f 100644
--- a/versions/6.5.0/install/ide.mdx
+++ b/versions/6.5.0/install/ide.mdx
@@ -39,10 +39,8 @@ To install, go to the IDE's plugin browser and search for `Bazel`.
 To manually install older versions, download the zip files from JetBrains'
 Plugin Repository and install the zip file from the IDE's plugin browser:
 
-*  [Android Studio
-   plugin](https://plugins.jetbrains.com/plugin/9185-android-studio-with-bazel)
-*  [IntelliJ
-   plugin](https://plugins.jetbrains.com/plugin/8609-intellij-with-bazel)
+*  [Android Studio plugin](https://plugins.jetbrains.com/plugin/9185-android-studio-with-bazel)
+*  [IntelliJ plugin](https://plugins.jetbrains.com/plugin/8609-intellij-with-bazel)
 *  [CLion plugin](https://plugins.jetbrains.com/plugin/9554-clion-with-bazel)
 
 ### Xcode {#xcode}
@@ -61,8 +59,7 @@ Features:
 * Starlark debugger for `.bzl` files during a build (set breakpoints, step
   through code, inspect variables, and so on)
 
-Find [the plugin on the Visual Studio
-marketplace](https://marketplace.visualstudio.com/items?itemName=BazelBuild.vscode-bazel).
+Find [the plugin on the Visual Studio marketplace](https://marketplace.visualstudio.com/items?itemName=BazelBuild.vscode-bazel).
 The plugin is [open source](https://github.com/bazelbuild/vscode-bazel).
 
 See also: [Autocomplete for Source Code](#autocomplete-for-source-code)
@@ -78,8 +75,7 @@ See [`bazelbuild/vim-bazel` on GitHub](https://github.com/bazelbuild/vim-bazel)
 
 ### Emacs {#emacs}
 
-See [`bazelbuild/bazel-emacs-mode` on
-GitHub](https://github.com/bazelbuild/emacs-bazel-mode)
+See [`bazelbuild/bazel-emacs-mode` on GitHub](https://github.com/bazelbuild/emacs-bazel-mode)
 
 ### Visual Studio {#visual-studio}
 
@@ -109,6 +105,5 @@ tool for building Bazel targets when source files change.
 
 ## Building your own IDE plugin {#build-own-plugin}
 
-Read the [**IDE support** blog
-post](https://blog.bazel.build/2016/06/10/ide-support.html) to learn more about
+Read the [**IDE support** blog post](https://blog.bazel.build/2016/06/10/ide-support.html) to learn more about
 the Bazel APIs to use when building an IDE plugin.
diff --git a/versions/6.5.0/install/windows.mdx b/versions/6.5.0/install/windows.mdx
index 838ff89c..c23bbb28 100644
--- a/versions/6.5.0/install/windows.mdx
+++ b/versions/6.5.0/install/windows.mdx
@@ -37,8 +37,7 @@ Also supported:
 
 Alternatively you can:
 
-*   [Download the Bazel binary (`bazel-version-windows-x86_64.exe`) from
- GitHub](https://github.com/bazelbuild/bazel/releases).
+*   [Download the Bazel binary (`bazel-version-windows-x86_64.exe`) from GitHub](https://github.com/bazelbuild/bazel/releases).
 *   [Install Bazel from Chocolatey](#chocolately)
 *   [Install Bazel from Scoop](#scoop)
 *   [Build Bazel from source](/versions/6.5.0/install/compile-source)
@@ -216,8 +215,7 @@ If that doesn't help:
     its dependencies, such as the MSYS2 shell. This will not install Visual C++
     though.
 
-See [Chocolatey installation and package maintenance
-guide](/contribute/windows-chocolatey-maintenance) for more
+See [Chocolatey installation and package maintenance guide](/contribute/windows-chocolatey-maintenance) for more
 information about the Chocolatey package.
 
 ### Using Scoop {#scoop}
@@ -234,8 +232,7 @@ information about the Chocolatey package.
     scoop install bazel
     ```
 
-See [Scoop installation and package maintenance
-guide](/contribute/windows-scoop-maintenance) for more
+See [Scoop installation and package maintenance guide](/contribute/windows-scoop-maintenance) for more
 information about the Scoop package.
 
 ### Build from source {#build-from-source}
diff --git a/versions/6.5.0/query/cquery.mdx b/versions/6.5.0/query/cquery.mdx
index 0e33d47b..732247ef 100644
--- a/versions/6.5.0/query/cquery.mdx
+++ b/versions/6.5.0/query/cquery.mdx
@@ -7,8 +7,7 @@ title: 'Configurable Query (cquery)'
 [`select()`](/docs/configurable-attributes) and build options' effects on the build
 graph.
 
-It achieves this by running over the results of Bazel's [analysis
-phase](/rules/concepts#evaluation-model),
+It achieves this by running over the results of Bazel's [analysis phase](/rules/concepts#evaluation-model),
 which integrates these effects. `query`, by constrast, runs over the results of
 Bazel's loading phase, before options are evaluated.
 
@@ -143,8 +142,7 @@ $ bazel cquery //foo --universe_scope=//foo,//genrule_with_foo_as_tool
 If you want to precisely declare which instance to query over, use
 the [`config`](#config) function.
 
-See `query`'s [target pattern
-documentation](/reference/query#target-patterns) for more information on target patterns.
+See `query`'s [target pattern documentation](/reference/query#target-patterns) for more information on target patterns.
 
 ## Functions {#functions}
 
diff --git a/versions/6.5.0/query/language.mdx b/versions/6.5.0/query/language.mdx
index 86e3aa20..b2fdbf30 100644
--- a/versions/6.5.0/query/language.mdx
+++ b/versions/6.5.0/query/language.mdx
@@ -1098,8 +1098,7 @@ is being used.
 
 ### On the ordering of results {#results-ordering}
 
-Although query expressions always follow the "[law of
-conservation of graph order](#graph-order)", _presenting_ the results may be done
+Although query expressions always follow the "[law of conservation of graph order](#graph-order)", _presenting_ the results may be done
 in either a dependency-ordered or unordered manner. This does **not**
 influence the targets in the result set or how the query is computed. It only
 affects how the results are printed to stdout. Moreover, nodes that are
@@ -1198,8 +1197,7 @@ and `maxrank` output formats print the labels of each
 target in the resulting graph, but instead of appearing in
 topological order, they appear in rank order, preceded by their
 rank number. These are unaffected by the result ordering
-`--[no]order_results` flag (see [notes on
-the ordering of results](#result-order)).
+`--[no]order_results` flag (see [notes on the ordering of results](#result-order)).
 
 There are two variants of this format: `minrank` ranks
 each node by the length of the shortest path from a root node to it.
diff --git a/versions/6.5.0/reference/glossary.mdx b/versions/6.5.0/reference/glossary.mdx
index 03dd90bc..5de5d286 100644
--- a/versions/6.5.0/reference/glossary.mdx
+++ b/versions/6.5.0/reference/glossary.mdx
@@ -22,8 +22,7 @@ An in-memory graph of [actions](#action) and the [artifacts](#artifact) that
 these actions read and generate. The graph might include artifacts that exist as
 source files (for example, in the file system) as well as generated
 intermediate/final artifacts that are not mentioned in `BUILD` files. Produced
-during the [analysis phase](#analysis-phase) and used during the [execution
-phase](#execution-phase).
+during the [analysis phase](#analysis-phase) and used during the [execution phase](#execution-phase).
 
 ### Action graph query (aquery) {#action-graph-query}
 A [query](#query-concept) tool that can query over build [actions](#action).
@@ -38,8 +37,7 @@ invalidate individual actions deterministically.
 
 ### Analysis phase {#analysis-phase}
 The second phase of a build. Processes the [target graph](#target-graph)
-specified in [`BUILD` files](#build-file) to produce an in-memory [action
-graph](#action-graph) that determines the order of actions to run during the
+specified in [`BUILD` files](#build-file) to produce an in-memory [action graph](#action-graph) that determines the order of actions to run during the
 [execution phase](#execution-phase). This is the phase in which rule
 implementations are evaluated.
 
@@ -82,8 +80,7 @@ target's source files, dependencies, and custom compiler options. The particular
 attributes available for a given target depend on its rule type.
 
 ### .bazelrc {#bazelrc}
-Bazel’s configuration file used to change the default values for [startup
-flags](#startup-flags) and [command flags](#command-flags), and to define common
+Bazel’s configuration file used to change the default values for [startup flags](#startup-flags) and [command flags](#command-flags), and to define common
 groups of options that can then be set together on the Bazel command line using
 a `--config` flag. Bazel can combine settings from multiple bazelrc files
 (systemwide, per-workspace, per-user, or from a custom location), and a
@@ -109,8 +106,7 @@ directory.
 
 ### .bzl File {#bzl-file}
 A file that defines rules, [macros](#macro), and constants written in
-[Starlark](#starlark). These can then be imported into [`BUILD`
-files](#build-file) using the `load()` function.
+[Starlark](#starlark). These can then be imported into [`BUILD` files](#build-file) using the `load()` function.
 
 // TODO: ### Build event protocol
 
@@ -118,8 +114,7 @@ files](#build-file) using the `load()` function.
 
 ### Build graph {#build-graph}
 The dependency graph that Bazel constructs and traverses to perform a build.
-Includes nodes like [targets](#target), [configured
-targets](#configured-target), [actions](#action), and [artifacts](#artifact). A
+Includes nodes like [targets](#target), [configured targets](#configured-target), [actions](#action), and [artifacts](#artifact). A
 build is considered complete when all [artifacts](#artifact) on which a set of
 requested targets depend are verified as up-to-date.
 
@@ -159,8 +154,7 @@ graphs and restart the [analysis phase](#analysis-phase).
 ### Configuration {#configuration}
 Information outside of [rule](#rule) definitions that impacts how rules generate
 [actions](#action). Every build has at least one configuration specifying the
-target platform, action environment variables, and command-line [build
-flags](#command-flags). [Transitions](#transition) may create additional
+target platform, action environment variables, and command-line [build flags](#command-flags). [Transitions](#transition) may create additional
 configurations, such as for host tools or cross-compilation.
 
 **See also:** [Configurations](/rules/rules#configurations)
@@ -175,8 +169,7 @@ configuration of `//:c` because changing `--javacopt` unnecessarily breaks C++
 build cacheability.
 
 ### Configured query (cquery) {#configured-query}
-A [query](#query-concept) tool that queries over [configured
-targets](#configured-target) (after the [analysis phase](#analysis-phase)
+A [query](#query-concept) tool that queries over [configured targets](#configured-target) (after the [analysis phase](#analysis-phase)
 completes). This means `select()` and [build flags](#command-flags) (such as
 `--platforms`) are accurately reflected in the results.
 
@@ -192,8 +185,7 @@ build, it has two configured targets: `` and ``.
 ### Correctness {#correctness}
 A build is correct when its output faithfully reflects the state of its
 transitive inputs. To achieve correct builds, Bazel strives to be
-[hermetic](#hermeticity), reproducible, and making [build
-analysis](#analysis-phase) and [action execution](#execution-phase)
+[hermetic](#hermeticity), reproducible, and making [build analysis](#analysis-phase) and [action execution](#execution-phase)
 deterministic.
 
 ### Dependency {#dependency}
@@ -232,8 +224,7 @@ compilation). A dynamic execution strategy can provide the best possible
 incremental and clean build times.
 
 ### Execution phase {#execution-phase}
-The third phase of a build. Executes the [actions](#action) in the [action
-graph](#action-graph) created during the [analysis phase](#analysis-phase).
+The third phase of a build. Executes the [actions](#action) in the [action graph](#action-graph) created during the [analysis phase](#analysis-phase).
 These actions invoke executables (compilers, scripts) to read and write
 [artifacts](#artifact). *Spawn strategies* control how these actions are
 executed: locally, remotely, dynamically, sandboxed, docker, and so on.
@@ -271,18 +262,15 @@ build.
 ### Label {#label}
 An identifier for a [target](#target). A fully-qualified label such as
 `//path/to/package:target` consists of `//` to mark the workspace root
-directory, `path/to/package` as the directory that contains the [`BUILD`
-file](#build-file) declaring the target, and `:target` as the name of the target
+directory, `path/to/package` as the directory that contains the [`BUILD` file](#build-file) declaring the target, and `:target` as the name of the target
 declared in the aforementioned `BUILD` file. May also be prefixed with
 `@my_repository//<..>` to indicate that the target is declared in an ]external
 repository] named `my_repository`.
 
 ### Loading phase {#loading-phase}
-The first phase of a build where Bazel parses `WORKSPACE`, `BUILD`, and [`.bzl`
-files](#bzl-file) to create [packages](#package). [Macros](#macro) and certain
+The first phase of a build where Bazel parses `WORKSPACE`, `BUILD`, and [`.bzl` files](#bzl-file) to create [packages](#package). [Macros](#macro) and certain
 functions like `glob()` are evaluated in this phase. Interleaved with the second
-phase of the build, the [analysis phase](#analysis-phase), to build up a [target
-graph](#target-graph).
+phase of the build, the [analysis phase](#analysis-phase), to build up a [target graph](#target-graph).
 
 ### Macro {#macro}
 A mechanism to compose multiple [rule](#rule) target declarations together under
@@ -307,8 +295,7 @@ example, `native.cc_library` or `native.java_library`). User-defined rules
 
 ### Output base {#output-base}
 A [workspace](#workspace)-specific directory to store Bazel output files. Used
-to separate outputs from the *workspace*'s source tree. Located in the [output
-user root](#output-user-root).
+to separate outputs from the *workspace*'s source tree. Located in the [output user root](#output-user-root).
 
 ### Output groups {#output-groups}
 A group of files that is expected to be built when Bazel finishes building a
@@ -363,8 +350,7 @@ query variants: [query](#query-command), [cquery](#configured-query), and
 [aquery](#action-graph-query).
 
 ### query (command) {#query-command}
-A [query](#query-concept) tool that operates over the build's post-[loading
-phase](#loading-phase) [target graph](#target-graph). This is relatively fast,
+A [query](#query-concept) tool that operates over the build's post-[loading phase](#loading-phase) [target graph](#target-graph). This is relatively fast,
 but can't analyze the effects of `select()`, [build flags](#command-flags),
 [artifacts](#artifact), or build [actions](#action).
 
@@ -399,8 +385,7 @@ Rules are instantiated to produce rule targets in the
 [loading phase](#loading-phase). In the [analysis phase](#analysis-phase) rule
 targets communicate information to their downstream dependencies in the form of
 [providers](#provider), and register [actions](#action) describing how to
-generate their output artifacts. These actions are run in the [execution
-phase](#execution-phase).
+generate their output artifacts. These actions are run in the [execution phase](#execution-phase).
 
 Note: Historically the term "rule" has been used to refer to a rule target.
 This usage was inherited from tools like Make, but causes confusion and should
@@ -444,8 +429,7 @@ support the stamp attribute.
 ### Starlark {#starlark}
 The extension language for writing [rules](/rules/rules) and [macros](#macro). A
 restricted subset of Python (syntactically and grammatically) aimed for the
-purpose of configuration, and for better performance. Uses the [`.bzl`
-file](#bzl-file) extension. [`BUILD` files](#build-file) use an even more
+purpose of configuration, and for better performance. Uses the [`.bzl` file](#bzl-file) extension. [`BUILD` files](#build-file) use an even more
 restricted version of Starlark (such as no `def` function definitions), formerly
 known as Skylark.
 
@@ -467,8 +451,7 @@ An object that is defined in a [`BUILD` file](#build-file) and identified by a
 [label](#label). Targets represent the buildable units of a workspace from
 the perspective of the end user.
 
-A target that is declared by instantiating a [rule](#rule) is called a [rule
-target](#rule-target). Depending on the rule, these may be runnable (like
+A target that is declared by instantiating a [rule](#rule) is called a [rule target](#rule-target). Depending on the rule, these may be runnable (like
 `cc_binary`) or testable (like `cc_test`). Rule targets typically depend on
 other targets via their [attributes](#attribute) (such as `deps`); these
 dependencies form the basis of the [target graph](#target-graph).
@@ -479,14 +462,11 @@ within a `BUILD` file. As a special case, the `BUILD` file of any package is
 always considered a source file target in that package.
 
 Targets are discovered during the [loading phase](#loading-phase). During the
-[analysis phase](#analysis-phase), targets are associated with [build
-configurations](#configuration) to form [configured
-targets](#configured-target).
+[analysis phase](#analysis-phase), targets are associated with [build configurations](#configuration) to form [configured targets](#configured-target).
 
 ### Target graph {#target-graph}
 An in-memory graph of [targets](#target) and their dependencies. Produced during
-the [loading phase](#loading-phase) and used as an input to the [analysis
-phase](#analysis-phase).
+the [loading phase](#loading-phase) and used as an input to the [analysis phase](#analysis-phase).
 
 ### Target pattern {#target-pattern}
 A way to specify a group of [targets](#target) on the command line. Commonly
@@ -499,8 +479,7 @@ packages recursively from the root of the [workspace](#workspace).
 Rule [targets](#target) instantiated from test rules, and therefore contains a
 test executable. A return code of zero from the completion of the executable
 indicates test success. The exact contract between Bazel and tests (such as test
-environment variables, test result collection methods) is specified in the [Test
-Encyclopedia](/reference/test-encyclopedia).
+environment variables, test result collection methods) is specified in the [Test Encyclopedia](/reference/test-encyclopedia).
 
 ### Toolchain {#toolchain}
 A set of tools to build outputs for a language. Typically, a toolchain includes
@@ -514,8 +493,7 @@ A build [target](#target) is top-level if it’s requested on the Bazel command
 line. For example, if `//:foo` depends on `//:bar`, and `bazel build //:foo` is
 called, then for this build, `//:foo` is top-level, and `//:bar` isn’t
 top-level, although both targets will need to be built. An important difference
-between top-level and non-top-level targets is that [command
-flags](#command-flags) set on the Bazel command line (or via
+between top-level and non-top-level targets is that [command flags](#command-flags) set on the Bazel command line (or via
 [.bazelrc](#bazelrc)) will set the [configuration](#configuration) for top-level
 targets, but might be modified by a [transition](#transition) for non-top-level
 targets.
diff --git a/versions/6.5.0/remote/bep-glossary.mdx b/versions/6.5.0/remote/bep-glossary.mdx
index caf317aa..5ed5b789 100644
--- a/versions/6.5.0/remote/bep-glossary.mdx
+++ b/versions/6.5.0/remote/bep-glossary.mdx
@@ -413,5 +413,4 @@ workspace, such as the execution root.
 
 ## WorkspaceStatus {#workspacestatus}
 
-A single `WorkspaceStatus` event contains the result of the [workspace status
-command](/docs/user-manual#workspace-status).
+A single `WorkspaceStatus` event contains the result of the [workspace status command](/docs/user-manual#workspace-status).
diff --git a/versions/6.5.0/remote/bep.mdx b/versions/6.5.0/remote/bep.mdx
index 1910375b..bbeaab20 100644
--- a/versions/6.5.0/remote/bep.mdx
+++ b/versions/6.5.0/remote/bep.mdx
@@ -4,14 +4,12 @@ title: 'Build Event Protocol'
 
 
 
-The [Build Event
-Protocol](https://github.com/bazelbuild/bazel/blob/master/src/main/java/com/google/devtools/build/lib/buildeventstream/proto/build_event_stream.proto)
+The [Build Event Protocol](https://github.com/bazelbuild/bazel/blob/master/src/main/java/com/google/devtools/build/lib/buildeventstream/proto/build_event_stream.proto)
 (BEP) allows third-party programs to gain insight into a Bazel invocation. For
 example, you could use the BEP to gather information for an IDE
 plugin or a dashboard that displays build results.
 
-The protocol is a set of [protocol
-buffer](https://developers.google.com/protocol-buffers/) messages with some
+The protocol is a set of [protocol buffer](https://developers.google.com/protocol-buffers/) messages with some
 semantics defined on top of it. It includes information about build and test
 results, build progress, the build configuration and much more. The BEP is
 intended to be consumed programmatically and makes parsing Bazel’s
@@ -22,16 +20,13 @@ build event is a protocol buffer message consisting of a build event identifier,
 a set of child event identifiers, and a payload.
 
 *  __Build Event Identifier:__ Depending on the kind of build event, it might be
-an [opaque
-string](https://github.com/bazelbuild/bazel/blob/16a107d/src/main/java/com/google/devtools/build/lib/buildeventstream/proto/build_event_stream.proto#L91)
-or [structured
-information](https://github.com/bazelbuild/bazel/blob/16a107d/src/main/java/com/google/devtools/build/lib/buildeventstream/proto/build_event_stream.proto#L123)
+an [opaque string](https://github.com/bazelbuild/bazel/blob/16a107d/src/main/java/com/google/devtools/build/lib/buildeventstream/proto/build_event_stream.proto#L91)
+or [structured information](https://github.com/bazelbuild/bazel/blob/16a107d/src/main/java/com/google/devtools/build/lib/buildeventstream/proto/build_event_stream.proto#L123)
 revealing more about the build event. A build event identifier is unique within
 a build.
 
 *  __Children:__ A build event may announce other build events, by including
-their build event identifiers in its [children
-field](https://github.com/bazelbuild/bazel/blob/16a107d/src/main/java/com/google/devtools/build/lib/buildeventstream/proto/build_event_stream.proto#L469).
+their build event identifiers in its [children field](https://github.com/bazelbuild/bazel/blob/16a107d/src/main/java/com/google/devtools/build/lib/buildeventstream/proto/build_event_stream.proto#L469).
 For example, the `PatternExpanded` build event announces the targets it expands
 to as children. The protocol guarantees that all events, except for the first
 event, are announced by a previous event.
@@ -93,8 +88,7 @@ human-readable formats, such as text and JSON:
 
 ## Build Event Service {#build-event-service}
 
-The [Build Event
-Service](https://github.com/googleapis/googleapis/blob/master/google/devtools/build/v1/publish_build_event.proto)
+The [Build Event Service](https://github.com/googleapis/googleapis/blob/master/google/devtools/build/v1/publish_build_event.proto)
 Protocol is a generic [gRPC](https://www.grpc.io) service for publishing build events. The Build Event
 Service protocol is independent of the BEP and treats BEP events as opaque bytes.
 Bazel ships with a gRPC client implementation of the Build Event Service protocol that
@@ -139,8 +133,7 @@ For a description of each of these flags, see the
 The BEP typically contains many references to log files (test.log, test.xml,
 etc. ) stored on the machine where Bazel is running. A remote BES server
 typically can't access these files as they are on different machines. A way to
-work around this issue is to use Bazel with [remote
-caching](/docs/remote-caching).
+work around this issue is to use Bazel with [remote caching](/docs/remote-caching).
 Bazel will upload all output files to the remote cache (including files
 referenced in the BEP) and the BES server can then fetch the referenced files
 from the cache.
diff --git a/versions/6.5.0/remote/cache-local.mdx b/versions/6.5.0/remote/cache-local.mdx
index ad576923..35007420 100644
--- a/versions/6.5.0/remote/cache-local.mdx
+++ b/versions/6.5.0/remote/cache-local.mdx
@@ -19,8 +19,7 @@ execution. However, local execution presents some additional challenges.
 ## Checking your cache hit rate {#cache-hits}
 
 Successful remote cache hits will show up in the status line, similar to
-[Cache Hits rate with Remote
-Execution](/docs/remote-execution-caching-debug#check-cache-hits).
+[Cache Hits rate with Remote Execution](/docs/remote-execution-caching-debug#check-cache-hits).
 
 In the standard output of your Bazel run, you will see something like the
 following:
@@ -69,8 +68,7 @@ the steps in this section.
    message you see does not give you enough information, try adding
    `--verbose_failures`.
 
-2. Follow the steps from [Troubleshooting cache hits for remote
-   execution](/docs/remote-execution-caching-debug#troubleshooting_cache_hits) to
+2. Follow the steps from [Troubleshooting cache hits for remote execution](/docs/remote-execution-caching-debug#troubleshooting_cache_hits) to
    ensure that your cache-writing Bazel invocations are able to get cache hits
    on the same machine and across machines.
 
@@ -84,7 +82,6 @@ the steps in this section.
    b. Ensure your cache-reading Bazel invocations build the same targets as the
       cache-writing Bazel invocations.
 
-   c. Follow the same steps as to [ensure caching across
-      machines](/docs/remote-execution-caching-debug#caching-across-machines),
+   c. Follow the same steps as to [ensure caching across machines](/docs/remote-execution-caching-debug#caching-across-machines),
       to ensure caching from your cache-writing Bazel invocation to your
       cache-reading Bazel invocation.
diff --git a/versions/6.5.0/remote/persistent.mdx b/versions/6.5.0/remote/persistent.mdx
index 72dd3bea..6be4e7c8 100644
--- a/versions/6.5.0/remote/persistent.mdx
+++ b/versions/6.5.0/remote/persistent.mdx
@@ -265,7 +265,6 @@ For more information on persistent workers, see:
 *   [Original persistent workers blog post](https://blog.bazel.build/2015/12/10/java-workers.html)
 *   [Haskell implementation description](https://www.tweag.io/blog/2019-09-25-bazel-ghc-persistent-worker-internship/)
 *   [Blog post by Mike Morearty](https://medium.com/@mmorearty/how-to-create-a-persistent-worker-for-bazel-7738bba2cabb)
-*   [Front End Development with Bazel: Angular/TypeScript and Persistent Workers
-    w/ Asana](https://www.youtube.com/watch?v=0pgERydGyqo)
+*   [Front End Development with Bazel: Angular/TypeScript and Persistent Workers w/ Asana](https://www.youtube.com/watch?v=0pgERydGyqo)
 *   [Bazel strategies explained](https://jmmv.dev/2019/12/bazel-strategies.html)
 *   [Informative worker strategy discussion on the bazel-discuss mailing list](https://groups.google.com/forum/#!msg/bazel-discuss/oAEnuhYOPm8/ol7hf4KWJgAJ)
diff --git a/versions/6.5.0/remote/rules.mdx b/versions/6.5.0/remote/rules.mdx
index 43460f8d..3be7fde2 100644
--- a/versions/6.5.0/remote/rules.mdx
+++ b/versions/6.5.0/remote/rules.mdx
@@ -55,8 +55,7 @@ variables that may not be set to equivalent values (or at all) in the remote
 execution environment.
 
 Toolchain rules currently exist for Bazel build and test rules for
-[Scala](https://github.com/bazelbuild/rules_scala/blob/master/scala/scala_toolch
-ain.bzl),
+[Scala](https://github.com/bazelbuild/rules_scala/blob/master/scala/scala_toolch ain.bzl),
 [Rust](https://github.com/bazelbuild/rules_rust/blob/main/rust/toolchain.bzl),
 and [Go](https://github.com/bazelbuild/rules_go/blob/master/go/toolchains.rst),
 and new toolchain rules are under way for other languages and tools such as
diff --git a/versions/6.5.0/remote/workspace.mdx b/versions/6.5.0/remote/workspace.mdx
index d0c08f3a..b557fc9e 100644
--- a/versions/6.5.0/remote/workspace.mdx
+++ b/versions/6.5.0/remote/workspace.mdx
@@ -12,8 +12,7 @@ on the host machine. If your workspace rules access information about the
 host machine for use during execution, your build is likely to break due to
 incompatibilities between the environments.
 
-As part of [adapting Bazel rules for remote
-execution](/docs/remote-execution-rules), you need to find such workspace rules
+As part of [adapting Bazel rules for remote execution](/docs/remote-execution-rules), you need to find such workspace rules
 and fix them. This page describes how to find potentially problematic workspace
 rules using the workspace log.
 
diff --git a/versions/6.5.0/rules/deploying.mdx b/versions/6.5.0/rules/deploying.mdx
index d21593ad..1dc127e1 100644
--- a/versions/6.5.0/rules/deploying.mdx
+++ b/versions/6.5.0/rules/deploying.mdx
@@ -87,8 +87,7 @@ At the top level, there should be a `README` that contains (at least) what
 users will need to copy-paste into their `WORKSPACE` file to use your rule.
 In general, this will be a `http_archive` pointing to your GitHub release and
 a macro call that downloads/configures any tools your rule needs. For example,
-for the [Go
-rules](https://github.com/bazelbuild/rules_go#setup), this
+for the [Go rules](https://github.com/bazelbuild/rules_go#setup), this
 looks like:
 
 ```
@@ -232,8 +231,7 @@ of basic ways that the rules can be used.
 
 ## Testing
 
-Set up Travis as described in their [getting started
-docs](https://docs.travis-ci.com/user/getting-started/). Then add a
+Set up Travis as described in their [getting started docs](https://docs.travis-ci.com/user/getting-started/). Then add a
 `.travis.yml` file to your repository with the following content:
 
 ```
diff --git a/versions/6.5.0/rules/language.mdx b/versions/6.5.0/rules/language.mdx
index e743b54b..f80e0d58 100644
--- a/versions/6.5.0/rules/language.mdx
+++ b/versions/6.5.0/rules/language.mdx
@@ -93,10 +93,8 @@ values returned by rules are immutable.
 `BUILD` files register targets via making calls to rules. `.bzl` files provide
 definitions for constants, rules, macros, and functions.
 
-[Native functions](/versions/6.5.0/reference/be/functions) and [native rules](
-/reference/be/overview#language-specific-native-rules) are global symbols in
-`BUILD` files. `bzl` files need to load them using the [`native` module](
-https://bazel.build/rules/lib/native).
+[Native functions](/versions/6.5.0/reference/be/functions) and [native rules](/reference/be/overview#language-specific-native-rules) are global symbols in
+`BUILD` files. `bzl` files need to load them using the [`native` module](https://bazel.build/rules/lib/native).
 
 There are two syntactic restrictions in `BUILD` files: 1) declaring functions is
 illegal, and 2) `*args` and `**kwargs` arguments are not allowed.
diff --git a/versions/6.5.0/rules/verbs-tutorial.mdx b/versions/6.5.0/rules/verbs-tutorial.mdx
index 37015d42..f62b360d 100644
--- a/versions/6.5.0/rules/verbs-tutorial.mdx
+++ b/versions/6.5.0/rules/verbs-tutorial.mdx
@@ -50,8 +50,7 @@ This pattern can also be seen in the Angular project. The
 produces two targets. The first is a standard `nodejs_test` target which compares
 some generated output against a "golden" file (that is, a file containing the
 expected output). This can be built and run with a normal `bazel
-test` invocation. In `angular-cli`, you can run [one such
-target](https://github.com/angular/angular-cli/blob/e1269cb520871ee29b1a4eec6e6c0e4a94f0b5fc/etc/api/BUILD)
+test` invocation. In `angular-cli`, you can run [one such target](https://github.com/angular/angular-cli/blob/e1269cb520871ee29b1a4eec6e6c0e4a94f0b5fc/etc/api/BUILD)
 with `bazel test //etc/api:angular_devkit_core_api`.
 
 Over time, this golden file may need to be updated for legitimate reasons.
diff --git a/versions/6.5.0/run/build.mdx b/versions/6.5.0/run/build.mdx
index 07e85aa3..c4238b7a 100644
--- a/versions/6.5.0/run/build.mdx
+++ b/versions/6.5.0/run/build.mdx
@@ -603,8 +603,7 @@ Note: Hermeticity means that the action only uses its declared input
 files and no other files in the filesystem, and it only produces its declared
 output files. See [Hermeticity](/versions/6.5.0/concepts/hermeticity) for more details.
 
-On some platforms such as [Google Kubernetes
-Engine](https://cloud.google.com/kubernetes-engine/) cluster nodes or Debian,
+On some platforms such as [Google Kubernetes Engine](https://cloud.google.com/kubernetes-engine/) cluster nodes or Debian,
 user namespaces are deactivated by default due to security
 concerns. This can be checked by looking at the file
 `/proc/sys/kernel/unprivileged_userns_clone`: if it exists and contains a 0,
diff --git a/versions/6.5.0/start/android-app.mdx b/versions/6.5.0/start/android-app.mdx
index 67ce43ec..bb5049b4 100644
--- a/versions/6.5.0/start/android-app.mdx
+++ b/versions/6.5.0/start/android-app.mdx
@@ -34,8 +34,7 @@ In this tutorial you learn how to:
 Before you begin the tutorial, install the following software:
 
 * **Bazel.** To install, follow the [installation instructions](/install).
-* **Android Studio.** To install, follow the steps to [download Android
-  Studio](https://developer.android.com/sdk/index.html).
+* **Android Studio.** To install, follow the steps to [download Android Studio](https://developer.android.com/sdk/index.html).
   Execute the setup wizard to download the SDK and configure your environment.
 * (Optional) **Git.** Use `git` to download the Android app project.
 
@@ -50,8 +49,7 @@ This app has a single button that prints a greeting when clicked:
 
 **Figure 1.** Android app button greeting.
 
-Clone the repository with `git` (or [download the ZIP file
-directly](https://github.com/bazelbuild/examples/archive/master.zip)):
+Clone the repository with `git` (or [download the ZIP file directly](https://github.com/bazelbuild/examples/archive/master.zip)):
 
 ```posix-terminal
 git clone https://github.com/bazelbuild/examples
@@ -102,8 +100,7 @@ A [workspace](/concepts/build-ref#workspace) is a directory that contains the
 source files for one or more software projects, and has a `WORKSPACE` file at
 its root.
 
-The `WORKSPACE` file may be empty or may contain references to [external
-dependencies](/docs/external) required to build your project.
+The `WORKSPACE` file may be empty or may contain references to [external dependencies](/docs/external) required to build your project.
 
 First, run the following command to create an empty `WORKSPACE` file:
 
@@ -146,8 +143,7 @@ environment variable, and automatically detect the highest API level and the
 latest version of build tools installed within that location.
 
 You can set the `ANDROID_HOME` variable to the location of the Android SDK. Find
-the path to the installed SDK using Android Studio's [SDK
-Manager](https://developer.android.com/studio/intro/update#sdk-manager).
+the path to the installed SDK using Android Studio's [SDK Manager](https://developer.android.com/studio/intro/update#sdk-manager).
 Assuming the SDK is installed to default locations, you can use the following
 commands to set the `ANDROID_HOME` variable:
 
@@ -196,8 +192,7 @@ android_sdk_repository(
 ```
 
 **Optional:** If you want to compile native code into your Android app, you
-also need to download the [Android
-NDK](https://developer.android.com/ndk/downloads/index.html)
+also need to download the [Android NDK](https://developer.android.com/ndk/downloads/index.html)
 and tell Bazel where to find it by adding the following line to your `WORKSPACE` file:
 
 ```python
@@ -208,8 +203,7 @@ Similar to `android_sdk_repository`, the path to the Android NDK is inferred
 from the `ANDROID_NDK_HOME` environment variable by default. The path can also
 be explicitly specified with a `path` attribute on `android_ndk_repository`.
 
-For more information, read [Using the Android Native Development Kit with
-Bazel](/docs/android-ndk).
+For more information, read [Using the Android Native Development Kit with Bazel](/docs/android-ndk).
 
 `api_level` is the version of the Android API that the SDK and NDK
 target - for example, 23 for Android 6.0 and 25 for Android 7.1. If not
@@ -256,8 +250,7 @@ files or other dependencies. Bazel provides two build rules,
 build an Android app.
 
 For this tutorial, you'll first use the
-`android_library` rule to tell Bazel to build an [Android library
-module](http://developer.android.com/tools/projects/index.html#LibraryProjects)
+`android_library` rule to tell Bazel to build an [Android library module](http://developer.android.com/tools/projects/index.html#LibraryProjects)
 from the app source code and resource files. You'll then use the
 `android_binary` rule to tell Bazel how to build the Android application package.
 
@@ -373,11 +366,9 @@ file:
 ### Run the app
 
 You can now deploy the app to a connected Android device or emulator from the
-command line using the [`bazel
-mobile-install`](/docs/user-manual#mobile-install) command. This command uses
+command line using the [`bazel mobile-install`](/docs/user-manual#mobile-install) command. This command uses
 the Android Debug Bridge (`adb`) to communicate with the device. You must set up
-your device to use `adb` following the instructions in [Android Debug
-Bridge](http://developer.android.com/tools/help/adb.html) before deployment. You
+your device to use `adb` following the instructions in [Android Debug Bridge](http://developer.android.com/tools/help/adb.html) before deployment. You
 can also choose to install the app on the Android emulator included in Android
 Studio. Make sure the emulator is running before executing the command below.
 
diff --git a/versions/6.5.0/start/cpp.mdx b/versions/6.5.0/start/cpp.mdx
index cf3e3ae7..8da239b2 100644
--- a/versions/6.5.0/start/cpp.mdx
+++ b/versions/6.5.0/start/cpp.mdx
@@ -64,9 +64,7 @@ examples
 ```
 
 There are three sets of files, each set representing a stage in this tutorial.
-In the first stage, you will build a single [target]
-(https://bazel.build/reference/glossary#target) residing in a single [package]
-(https://bazel.build/reference/glossary#package). In the second stage, you will
+In the first stage, you will build a single [target](https://bazel.build/reference/glossary#target) residing in a single [package](https://bazel.build/reference/glossary#package). In the second stage, you will
 you will build both a binary and a library from a single package. In
 the third and final stage, you will build a project with multiple packages and
 build it with multiple targets.
@@ -190,9 +188,7 @@ This results in a printed “`Hello world`” message.
 
 Here’s the dependency graph of Stage 1:
 
-![Dependency graph for hello-world displays a single target with a single source file.]
-(/docs/images/cpp-tutorial-stage1.png "Dependency graph for hello-world displays
-a single target with a single source file.")
+![Dependency graph for hello-world displays a single target with a single source file.](/docs/images/cpp-tutorial-stage1.png "Dependency graph for hello-world displays a single target with a single source file.")
 
 
 ### Summary: stage 1 {#summary-stage-1}
diff --git a/versions/6.5.0/start/java.mdx b/versions/6.5.0/start/java.mdx
index 7864b5f7..bfcefb1a 100644
--- a/versions/6.5.0/start/java.mdx
+++ b/versions/6.5.0/start/java.mdx
@@ -242,8 +242,7 @@ recompiles that file.
 Looking at the dependency graph, you can see that `ProjectRunner` depends on the
 same inputs as it did before, but the structure of the build is different:
 
-![Dependency graph of the target 'ProjectRunner' after adding a dependency](
-/docs/images/tutorial_java_02.svg)
+![Dependency graph of the target 'ProjectRunner' after adding a dependency](/docs/images/tutorial_java_02.svg)
 
 You've now built the project with two targets. The `ProjectRunner` target builds
 two source files and depends on one other target (`:greeter`), which builds
diff --git a/versions/6.5.0/versions/index.mdx b/versions/6.5.0/versions/index.mdx
index f71981be..09904b7e 100644
--- a/versions/6.5.0/versions/index.mdx
+++ b/versions/6.5.0/versions/index.mdx
@@ -10,7 +10,3 @@ version support.
 
 For now, to see documentation for older Bazel versions, go to
 [docs.bazel.build](https://docs.bazel.build/).
-
-
-  To the Archives!
-
diff --git a/versions/7.6.1/community/roadmaps-configurability.mdx b/versions/7.6.1/community/roadmaps-configurability.mdx
index 4352e5c2..ca683a29 100644
--- a/versions/7.6.1/community/roadmaps-configurability.mdx
+++ b/versions/7.6.1/community/roadmaps-configurability.mdx
@@ -26,8 +26,7 @@ title: 'Bazel Configurability 2021 Roadmap'
 * Builds scale well, particularly w.r.t graph size and action caching.
 
 We also support
-[`cquery`](https://bazel.build/versions/7.6.1/query/cquery), [`Starlark
-configuration`](https://bazel.build/extending/config),
+[`cquery`](https://bazel.build/versions/7.6.1/query/cquery), [`Starlark configuration`](https://bazel.build/extending/config),
 and
 [`select()`](https://bazel.build/versions/7.6.1/docs/configurable-attributes).
 
@@ -41,15 +40,13 @@ interest of accurate expectations.
 ### Platforms
 
 

-Q3 2021**Android rules use the new [platforms
-API](https://bazel.build/concepts/platforms)**
+Q3 2021**Android rules use the new [platforms API](https://bazel.build/concepts/platforms)**
 IN PROGRESS ([#11749](https://github.com/bazelbuild/bazel/issues/11749))
 
 * This is our main priority for the beginning of 2021.
 
 

-Q3 2021**Builds support [multiple execution
-platforms](https://docs.google.com/document/d/1U9HzdDmtRnm244CaRM6JV-q2408mbNODAMewcGjnnbM/)**
+Q3 2021**Builds support [multiple execution platforms](https://docs.google.com/document/d/1U9HzdDmtRnm244CaRM6JV-q2408mbNODAMewcGjnnbM/)**
 IN PROGRESS ([#11748](https://github.com/bazelbuild/bazel/issues/11748))
 
 

diff --git a/versions/7.6.1/community/sig.mdx b/versions/7.6.1/community/sig.mdx
index 408b363c..0a591bf7 100644
--- a/versions/7.6.1/community/sig.mdx
+++ b/versions/7.6.1/community/sig.mdx
@@ -3,8 +3,7 @@ title: 'Bazel Special Interest Groups'
 ---
 
 Bazel hosts Special Interest Groups (SIGs) to focus collaboration on particular
-areas and to support communication and coordination between [Bazel owners,
-maintainers, and contributors](/versions/7.6.1/contribute/policy). This policy
+areas and to support communication and coordination between [Bazel owners, maintainers, and contributors](/versions/7.6.1/contribute/policy). This policy
 applies to [`bazelbuild`](http://github.com/bazelbuild).
 
 SIGs do their work in public. The ideal scope for a SIG covers a well-defined
diff --git a/versions/7.6.1/concepts/build-files.mdx b/versions/7.6.1/concepts/build-files.mdx
index 4e4473fc..010e0491 100644
--- a/versions/7.6.1/concepts/build-files.mdx
+++ b/versions/7.6.1/concepts/build-files.mdx
@@ -132,10 +132,3 @@ for anyone to create new rules.
     programming language. Libraries can depend on other libraries,
     and binaries and tests can depend on libraries, with the expected
     separate-compilation behavior.
-
-
-  
-    
-    
-  
-
LabelsDependencies

diff --git a/versions/7.6.1/concepts/build-ref.mdx b/versions/7.6.1/concepts/build-ref.mdx
index 911028a7..714a69d4 100644
--- a/versions/7.6.1/concepts/build-ref.mdx
+++ b/versions/7.6.1/concepts/build-ref.mdx
@@ -17,8 +17,7 @@ its root; such a boundary marker file could be `MODULE.bazel`, `REPO.bazel`, or
 in legacy contexts, `WORKSPACE` or `WORKSPACE.bazel`.
 
 The repo in which the current Bazel command is being run is called the _main
-repo_. Other, (external) repos are defined by _repo rules_; see [external
-dependencies overview](/versions/7.6.1/external/overview) for more information.
+repo_. Other, (external) repos are defined by _repo rules_; see [external dependencies overview](/versions/7.6.1/external/overview) for more information.
 
 ## Workspace {#workspace}
 
@@ -95,9 +94,4 @@ have three properties: the list of packages they contain, their name, and other
 package groups they include. The only allowed ways to refer to them are from the
 `visibility` attribute of rules or from the `default_visibility` attribute of
 the `package` function; they do not generate or consume files. For more
-information, refer to the [`package_group`
-documentation](/versions/7.6.1/reference/be/functions#package_group).
-
-
-  Labels
-
\ No newline at end of file
+information, refer to the [`package_group` documentation](/versions/7.6.1/reference/be/functions#package_group).
diff --git a/versions/7.6.1/concepts/dependencies.mdx b/versions/7.6.1/concepts/dependencies.mdx
index 0c92f1ea..0b526039 100644
--- a/versions/7.6.1/concepts/dependencies.mdx
+++ b/versions/7.6.1/concepts/dependencies.mdx
@@ -347,8 +347,3 @@ filegroup(
 ```
 
 You can then reference the label `my_data` as the data dependency in your test.
-
-
-  
-
BUILD filesVisibility

-
diff --git a/versions/7.6.1/concepts/labels.mdx b/versions/7.6.1/concepts/labels.mdx
index 60891bc7..745b2fb0 100644
--- a/versions/7.6.1/concepts/labels.mdx
+++ b/versions/7.6.1/concepts/labels.mdx
@@ -10,8 +10,7 @@ form looks like:
 ```
 
 The first part of the label is the repository name, `@@myrepo`. The double-`@`
-syntax signifies that this is a [*canonical* repo
-name](/versions/7.6.1/external/overview#canonical-repo-name), which is unique within
+syntax signifies that this is a [*canonical* repo name](/versions/7.6.1/external/overview#canonical-repo-name), which is unique within
 the workspace. Labels with canonical repo names unambiguously identify a target
 no matter which context they appear in.
 
@@ -228,10 +227,3 @@ the build.
 This directed acyclic graph over targets is called the _target graph_ or
 _build dependency graph_, and is the domain over which the
 [Bazel Query tool](/versions/7.6.1/query/guide) operates.
-
-
-  
-    
-    
-  
-
TargetsBUILD files

diff --git a/versions/7.6.1/concepts/platforms.mdx b/versions/7.6.1/concepts/platforms.mdx
index a9984066..0a9ab872 100644
--- a/versions/7.6.1/concepts/platforms.mdx
+++ b/versions/7.6.1/concepts/platforms.mdx
@@ -77,8 +77,7 @@ To test your Android project with platforms, see
 for support.
 
 You can still use platform APIs with Apple builds (for example, when building
-with a mixture of Apple rules and pure C++) with [platform
-mappings](#platform-mappings).
+with a mixture of Apple rules and pure C++) with [platform mappings](#platform-mappings).
 
 ### Other languages {#other-languages}
 
@@ -241,8 +240,7 @@ sets `--cpu`, `--crossstool_top`, or other legacy flags, rules that read
 
 When migrating your project to platforms, you must either convert changes like
 `return { "//command_line_option:cpu": "arm" }` to `return {
-"//command_line_option:platforms": "//:my_arm_platform" }` or use [platform
-mappings](#platform-mappings) to support both styles during migration.
+"//command_line_option:platforms": "//:my_arm_platform" }` or use [platform mappings](#platform-mappings) to support both styles during migration.
 window.
 
 ## Migrating your rule set {#migrating-your-rule-set}
@@ -361,10 +359,8 @@ attributes declare a language's tools (like `compiler =
 this information to rules that need to build with these tools.
 
 Toolchains declare the `constraint_value`s of machines they can
-[target][target_compatible_with Attribute]
-(`target_compatible_with = ["@platforms//os:linux"]`) and machines their tools can
-[run on][exec_compatible_with Attribute]
-(`exec_compatible_with = ["@platforms//os:mac"]`).
+[target][target_compatible_with Attribute](`target_compatible_with = ["@platforms//os:linux"]`) and machines their tools can
+[run on][exec_compatible_with Attribute](`exec_compatible_with = ["@platforms//os:mac"]`).
 
 When building `$ bazel build //:myproject --platforms=//:myplatform`, Bazel
 automatically selects a toolchain that can run on the build machine and
diff --git a/versions/7.6.1/configure/attributes.mdx b/versions/7.6.1/configure/attributes.mdx
index b61e569f..5aba7e4d 100644
--- a/versions/7.6.1/configure/attributes.mdx
+++ b/versions/7.6.1/configure/attributes.mdx
@@ -2,8 +2,7 @@
 title: 'Configurable Build Attributes'
 ---
 
-**_Configurable attributes_**, commonly known as [`select()`](
-/reference/be/functions#select), is a Bazel feature that lets users toggle the values
+**_Configurable attributes_**, commonly known as [`select()`](/reference/be/functions#select), is a Bazel feature that lets users toggle the values
 of build rule attributes at the command line.
 
 This can be used, for example, for a multiplatform library that automatically
@@ -407,8 +406,7 @@ sh_library(
 )
 ```
 
-If you need a `select` to match when multiple conditions match, consider [AND
-chaining](#and-chaining).
+If you need a `select` to match when multiple conditions match, consider [AND chaining](#and-chaining).
 
 ## OR chaining {#or-chaining}
 
diff --git a/versions/7.6.1/configure/integrate-cpp.mdx b/versions/7.6.1/configure/integrate-cpp.mdx
index 57b72b1c..d53c079f 100644
--- a/versions/7.6.1/configure/integrate-cpp.mdx
+++ b/versions/7.6.1/configure/integrate-cpp.mdx
@@ -33,8 +33,7 @@ This is because when writing our own actions, they must behave
 consistently with the C++ toolchain - for example, passing C++ command line
 flags to a tool that invokes the C++ compiler behind the scenes.
 
-C++ rules use a special way of constructing command lines based on [feature
-configuration](/versions/7.6.1/docs/cc-toolchain-config-reference). To construct a command line,
+C++ rules use a special way of constructing command lines based on [feature configuration](/versions/7.6.1/docs/cc-toolchain-config-reference). To construct a command line,
 you need the following:
 
 * `features` and `action_configs` - these come from the `CcToolchainConfigInfo`
diff --git a/versions/7.6.1/configure/windows.mdx b/versions/7.6.1/configure/windows.mdx
index 78798ef3..aa881ba2 100644
--- a/versions/7.6.1/configure/windows.mdx
+++ b/versions/7.6.1/configure/windows.mdx
@@ -166,8 +166,7 @@ To build C++ targets with MSVC, you need:
         set BAZEL_VC=C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC
         ```
 
-*   The [Windows
-    SDK](https://developer.microsoft.com/en-us/windows/downloads/windows-10-sdk).
+*   The [Windows SDK](https://developer.microsoft.com/en-us/windows/downloads/windows-10-sdk).
 
     The Windows SDK contains header files and libraries you need when building
     Windows applications, including Bazel itself. By default, the latest Windows SDK installed will
@@ -186,8 +185,7 @@ To build C++ targets with MSVC, you need:
 
 If everything is set up, you can build a C++ target now!
 
-Try building a target from one of our [sample
-projects](https://github.com/bazelbuild/bazel/tree/master/examples):
+Try building a target from one of our [sample projects](https://github.com/bazelbuild/bazel/tree/master/examples):
 
 
 
 
-To build and use Dynamically Linked Libraries (DLL files), see [this
-example](https://github.com/bazelbuild/bazel/tree/master/examples/windows/dll).
+To build and use Dynamically Linked Libraries (DLL files), see [this example](https://github.com/bazelbuild/bazel/tree/master/examples/windows/dll).
 
 **Command Line Length Limit**: To prevent the
 [Windows command line length limit issue](https://github.com/bazelbuild/bazel/issues/5163),
@@ -292,8 +289,7 @@ On Windows, Bazel builds two output files for `java_binary` rules:
 *   a `.jar` file
 *   a `.exe` file that can set up the environment for the JVM and run the binary
 
-Try building a target from one of our [sample
-projects](https://github.com/bazelbuild/bazel/tree/master/examples):
+Try building a target from one of our [sample projects](https://github.com/bazelbuild/bazel/tree/master/examples):
 
 
   
   
 
 If you are interested in details about how Bazel builds Python targets on
-Windows, check out this [design
-doc](https://github.com/bazelbuild/bazel-website/blob/master/designs/_posts/2016-09-05-build-python-on-windows.md).
+Windows, check out this [design doc](https://github.com/bazelbuild/bazel-website/blob/master/designs/_posts/2016-09-05-build-python-on-windows.md).
diff --git a/versions/7.6.1/contribute/codebase.mdx b/versions/7.6.1/contribute/codebase.mdx
index 0e8b17e0..c763e27e 100644
--- a/versions/7.6.1/contribute/codebase.mdx
+++ b/versions/7.6.1/contribute/codebase.mdx
@@ -227,8 +227,7 @@ repository", the others are called "external repositories".
 A repository is marked by a repo boundary file (`MODULE.bazel`, `REPO.bazel`, or
 in legacy contexts, `WORKSPACE` or `WORKSPACE.bazel`) in its root directory. The
 main repo is the source tree where you're invoking Bazel from. External repos
-are defined in various ways; see [external dependencies
-overview](/versions/7.6.1/external/overview) for more information.
+are defined in various ways; see [external dependencies overview](/versions/7.6.1/external/overview) for more information.
 
 Code of external repositories is symlinked or downloaded under
 `$OUTPUT_BASE/external`.
diff --git a/versions/7.6.1/contribute/design-documents.mdx b/versions/7.6.1/contribute/design-documents.mdx
index b5a3bd2e..d389e9b1 100644
--- a/versions/7.6.1/contribute/design-documents.mdx
+++ b/versions/7.6.1/contribute/design-documents.mdx
@@ -137,8 +137,7 @@ A lead reviewer should be a domain expert who is:
 *   Objective and capable of providing constructive feedback
 *   Available for the entire review period to lead the process
 
-Consider checking the contacts for various [team
-labels](/versions/7.6.1/contribute/maintainers-guide#team-labels).
+Consider checking the contacts for various [team labels](/versions/7.6.1/contribute/maintainers-guide#team-labels).
 
 ## Markdown vs Google Docs {#markdown-versus-gdocs}
 
@@ -168,12 +167,10 @@ Markdown for posterity.
 
 ### Using Google Docs {#gdocs}
 
-For consistency, use the [Bazel design doc template](
-https://docs.google.com/document/d/1cE5zrjrR40RXNg64XtRFewSv6FrLV6slGkkqxBumS1w/edit).
+For consistency, use the [Bazel design doc template](https://docs.google.com/document/d/1cE5zrjrR40RXNg64XtRFewSv6FrLV6slGkkqxBumS1w/edit).
 It includes the necessary header and creates visual
 consistency with other Bazel related documents. To do that, click on **File** >
-**Make a copy** or click this link to [make a copy of the design doc
-template](https://docs.google.com/document/d/1cE5zrjrR40RXNg64XtRFewSv6FrLV6slGkkqxBumS1w/copy).
+**Make a copy** or click this link to [make a copy of the design doc template](https://docs.google.com/document/d/1cE5zrjrR40RXNg64XtRFewSv6FrLV6slGkkqxBumS1w/copy).
 
 To make your document readable to the world, click on
 **Share** > **Advanced** > **Change…**, and
diff --git a/versions/7.6.1/contribute/index.mdx b/versions/7.6.1/contribute/index.mdx
index f38843e9..093895f5 100644
--- a/versions/7.6.1/contribute/index.mdx
+++ b/versions/7.6.1/contribute/index.mdx
@@ -10,8 +10,7 @@ As you use Bazel, you may find things that can be improved.
 You can help by [reporting issues](http://github.com/bazelbuild/bazel/issues)
 when:
 
-   - Bazel crashes or you encounter a bug that can [only be resolved using `bazel
-     clean`](/versions/7.6.1/run/build#correct-incremental-rebuilds).
+   - Bazel crashes or you encounter a bug that can [only be resolved using `bazel clean`](/versions/7.6.1/run/build#correct-incremental-rebuilds).
    - The documentation is incomplete or unclear. You can also report issues
      from the page you are viewing by using the "Create issue"
      link at the top right corner of the page.
@@ -21,11 +20,9 @@ when:
 
 You can engage with the Bazel community by:
 
-   - Answering questions [on Stack Overflow](
-     https://stackoverflow.com/questions/tagged/bazel).
+   - Answering questions [on Stack Overflow](https://stackoverflow.com/questions/tagged/bazel).
    - Helping other users [on Slack](https://slack.bazel.build).
-   - Improving documentation or [contributing examples](
-     https://github.com/bazelbuild/examples).
+   - Improving documentation or [contributing examples](https://github.com/bazelbuild/examples).
    - Sharing your experience or your tips, for example, on a blog or social media.
 
 ## Contribute code {#contribute-code}
@@ -40,8 +37,7 @@ You can contribute to the Bazel ecosystem by:
    - Contributing to Bazel-related tools, for example, migration tools.
    - Improving Bazel integration with other IDEs and tools.
 
-Before making a change, [create a GitHub
-issue](http://github.com/bazelbuild/bazel/issues)
+Before making a change, [create a GitHub issue](http://github.com/bazelbuild/bazel/issues)
 or email [bazel-discuss@](mailto:bazel-discuss@googlegroups.com).
 
 The most helpful contributions fix bugs or add features (as opposed
diff --git a/versions/7.6.1/contribute/maintainers-guide.mdx b/versions/7.6.1/contribute/maintainers-guide.mdx
index 404a17bb..a8e83715 100644
--- a/versions/7.6.1/contribute/maintainers-guide.mdx
+++ b/versions/7.6.1/contribute/maintainers-guide.mdx
@@ -4,8 +4,7 @@ title: 'Guide for Bazel Maintainers'
 
 This is a guide for the maintainers of the Bazel open source project.
 
-If you are looking to contribute to Bazel, please read [Contributing to
-Bazel](/versions/7.6.1/contribute) instead.
+If you are looking to contribute to Bazel, please read [Contributing to Bazel](/versions/7.6.1/contribute) instead.
 
 The objectives of this page are to:
 
@@ -37,8 +36,7 @@ repository.
 
 1. A user creates an issue by choosing one of the
 [issue templates](https://github.com/bazelbuild/bazel/issues/new/choose)
-   and it enters the pool of [unreviewed open
-   issues](https://github.com/bazelbuild/bazel/issues?utf8=%E2%9C%93&q=is%3Aissue+is%3Aopen+-label%3Auntriaged+-label%3Ap2+-label%3Ap1+-label%3Ap3+-label%3Ap4+-label%3Ateam-Starlark+-label%3Ateam-Rules-CPP+-label%3Ateam-Rules-Java+-label%3Ateam-XProduct+-label%3Ateam-Android+-label%3Ateam-Apple+-label%3Ateam-Configurability++-label%3Ateam-Performance+-label%3Ateam-Rules-Server+-label%3Ateam-Core+-label%3Ateam-Rules-Python+-label%3Ateam-Remote-Exec+-label%3Ateam-Local-Exec+-label%3Ateam-Bazel).
+   and it enters the pool of [unreviewed open issues](https://github.com/bazelbuild/bazel/issues?utf8=%E2%9C%93&q=is%3Aissue+is%3Aopen+-label%3Auntriaged+-label%3Ap2+-label%3Ap1+-label%3Ap3+-label%3Ap4+-label%3Ateam-Starlark+-label%3Ateam-Rules-CPP+-label%3Ateam-Rules-Java+-label%3Ateam-XProduct+-label%3Ateam-Android+-label%3Ateam-Apple+-label%3Ateam-Configurability++-label%3Ateam-Performance+-label%3Ateam-Rules-Server+-label%3Ateam-Core+-label%3Ateam-Rules-Python+-label%3Ateam-Remote-Exec+-label%3Ateam-Local-Exec+-label%3Ateam-Bazel).
 1. A member on the Developer Experience (DevEx) subteam rotation reviews the
    issue.
    1. If the issue is **not a bug** or a **feature request**, the DevEx member
@@ -58,21 +56,18 @@ repository.
 1. After reviewing the issue, the DevEx member decides if the issue requires
    immediate attention. If it does, they will assign the **P0**
    [priority](#priority) label and an owner from the list of team leads.
-1. The DevEx member assigns the `untriaged` label and exactly one [team
-   label](#team-labels) for routing.
+1. The DevEx member assigns the `untriaged` label and exactly one [team label](#team-labels) for routing.
 1. The DevEx member also assigns exactly one `type:` label, such as `type: bug`
    or `type: feature request`, according to the type of the issue.
 1. For platform-specific issues, the DevEx member assigns one `platform:` label,
    such as `platform:apple` for Mac-specific issues.
 1. If the issue is low priority and can be worked on by a new community
    contributor, the DevEx member assigns the `good first issue` label.
-At this stage, the issue enters the pool of [untriaged open
-issues](https://github.com/bazelbuild/bazel/issues?q=is%3Aissue+is%3Aopen+label%3Auntriaged).
+At this stage, the issue enters the pool of [untriaged open issues](https://github.com/bazelbuild/bazel/issues?q=is%3Aissue+is%3Aopen+label%3Auntriaged).
 
 Each Bazel subteam will triage all issues under labels they own, preferably on a
 weekly basis. The subteam will review and evaluate the issue and provide a
-resolution, if possible. If you are an owner of a team label, see [this section
-](#label-own) for more information.
+resolution, if possible. If you are an owner of a team label, see [this section](#label-own) for more information.
 
 When an issue is resolved, it can be closed.
 
@@ -111,8 +106,7 @@ preferably on a weekly basis.
      issue is either P0 or P1 we assume that is actively worked on.
 1. Remove the `untriaged` label.
 
-Note that you need to be in the [bazelbuild
-organization](https://github.com/bazelbuild) to be able to add or remove labels.
+Note that you need to be in the [bazelbuild organization](https://github.com/bazelbuild) to be able to add or remove labels.
 
 ### Pull Requests {#pull-requests}
 
@@ -138,8 +132,7 @@ issues.
   unusable, or a downed service that severely impacts development of the Bazel
   project. This includes regressions introduced in a new release that blocks a
   significant number of users, or an incompatible breaking change that was not
-  compliant to the [Breaking
-  Change](https://docs.google.com/document/d/1q5GGRxKrF_mnwtaPKI487P8OdDRh2nN7jX6U-FXnHL0/edit?pli=1#heading=h.ceof6vpkb3ik)
+  compliant to the [Breaking Change](https://docs.google.com/document/d/1q5GGRxKrF_mnwtaPKI487P8OdDRh2nN7jX6U-FXnHL0/edit?pli=1#heading=h.ceof6vpkb3ik)
   policy. No practical workaround exists.
 * [**P1**](https://github.com/bazelbuild/bazel/labels/P1) - Critical defect or
   feature which should be addressed in the next release, or a serious issue that
diff --git a/versions/7.6.1/contribute/naming.mdx b/versions/7.6.1/contribute/naming.mdx
index 41c7a2ac..37e0c5a7 100644
--- a/versions/7.6.1/contribute/naming.mdx
+++ b/versions/7.6.1/contribute/naming.mdx
@@ -4,8 +4,7 @@ title: 'Naming a Bazel related project'
 
 First, thank you for contributing to the Bazel ecosystem! Please reach out to
 the Bazel community on the
-[bazel-discuss mailing list](https://groups.google.com/forum/#!forum/bazel-discuss
-) to share your project and its suggested name.
+[bazel-discuss mailing list](https://groups.google.com/forum/#!forum/bazel-discuss) to share your project and its suggested name.
 
 If you are building a Bazel related tool or sharing your Skylark rules,
 we recommend following these guidelines for the name of your project:
diff --git a/versions/7.6.1/contribute/patch-acceptance.mdx b/versions/7.6.1/contribute/patch-acceptance.mdx
index 846d42a0..379d6ed7 100644
--- a/versions/7.6.1/contribute/patch-acceptance.mdx
+++ b/versions/7.6.1/contribute/patch-acceptance.mdx
@@ -11,29 +11,24 @@ code base.
    need a corresponding issue for tracking.
 1. If you're proposing significant changes, write a
    [design document](/versions/7.6.1/contribute/design-documents).
-1. Ensure you've signed a [Contributor License
-   Agreement](https://cla.developers.google.com).
+1. Ensure you've signed a [Contributor License Agreement](https://cla.developers.google.com).
 1. Prepare a git commit that implements the feature. Don't forget to add tests
    and update the documentation. If your change has user-visible effects, please
    [add release notes](/versions/7.6.1/contribute/release-notes). If it is an incompatible change,
    read the [guide for rolling out breaking changes](/versions/7.6.1/contribute/breaking-changes).
 1. Create a pull request on
    [GitHub](https://github.com/bazelbuild/bazel/pulls). If you're new to GitHub,
-   read [about pull
-   requests](https://help.github.com/articles/about-pull-requests/). Note that
+   read [about pull requests](https://help.github.com/articles/about-pull-requests/). Note that
    we restrict permissions to create branches on the main Bazel repository, so
-   you will need to push your commit to [your own fork of the
-   repository](https://help.github.com/articles/working-with-forks/).
+   you will need to push your commit to [your own fork of the repository](https://help.github.com/articles/working-with-forks/).
 1. A Bazel maintainer should assign you a reviewer within two business days
    (excluding holidays in the USA and Germany). If you aren't assigned a
    reviewer in that time, you can request one by emailing
-   [bazel-discuss@googlegroups.com]
-   (mailto:bazel-discuss@googlegroups.com).
+   [bazel-discuss@googlegroups.com](mailto:bazel-discuss@googlegroups.com).
 1. Work with the reviewer to complete a code review. For each change, create a
    new commit and push it to make changes to your pull request. If the review
    takes too long (for instance, if the reviewer is unresponsive), send an email to
-   [bazel-discuss@googlegroups.com]
-   (mailto:bazel-discuss@googlegroups.com).
+   [bazel-discuss@googlegroups.com](mailto:bazel-discuss@googlegroups.com).
 1. After your review is complete, a Bazel maintainer applies your patch to
    Google's internal version control system.
 
diff --git a/versions/7.6.1/contribute/release-notes.mdx b/versions/7.6.1/contribute/release-notes.mdx
index 66f937da..16becfea 100644
--- a/versions/7.6.1/contribute/release-notes.mdx
+++ b/versions/7.6.1/contribute/release-notes.mdx
@@ -16,8 +16,7 @@ the release announcement.
 * If the change adds / removes / changes Bazel in a user-visible way, then it
   may be advantageous to mention it.
 
-If the change is significant, follow the [design document
-policy](/versions/7.6.1/contribute/design-documents) first.
+If the change is significant, follow the [design document policy](/versions/7.6.1/contribute/design-documents) first.
 
 ## Guidelines {#guidelines}
 
@@ -60,10 +59,8 @@ change is about.
 
 ## Process {#process}
 
-As part of the [release
-process](https://github.com/bazelbuild/continuous-integration/blob/master/docs/release-playbook.md),
-we collect the `RELNOTES` tags of every commit. We copy everything in a [Google
-Doc](https://docs.google.com/document/d/1wDvulLlj4NAlPZamdlEVFORks3YXJonCjyuQMUQEmB0/edit)
+As part of the [release process](https://github.com/bazelbuild/continuous-integration/blob/master/docs/release-playbook.md),
+we collect the `RELNOTES` tags of every commit. We copy everything in a [Google Doc](https://docs.google.com/document/d/1wDvulLlj4NAlPZamdlEVFORks3YXJonCjyuQMUQEmB0/edit)
 where we review, edit, and organize the notes.
 
 The release manager sends an email to the
@@ -71,6 +68,4 @@ The release manager sends an email to the
 Bazel contributors are invited to contribute to the document and make sure
 their changes are correctly reflected in the announcement.
 
-Later, the announcement will be submitted to the [Bazel
-blog](https://blog.bazel.build/), using the [bazel-blog
-repository](https://github.com/bazelbuild/bazel-blog/tree/master/_posts).
+Later, the announcement will be submitted to the [Bazel blog](https://blog.bazel.build/), using the [bazel-blog repository](https://github.com/bazelbuild/bazel-blog/tree/master/_posts).
diff --git a/versions/7.6.1/contribute/statemachine-guide.mdx b/versions/7.6.1/contribute/statemachine-guide.mdx
index bee1cc38..0657005e 100644
--- a/versions/7.6.1/contribute/statemachine-guide.mdx
+++ b/versions/7.6.1/contribute/statemachine-guide.mdx
@@ -172,8 +172,7 @@ instead, batches[^4] as many lookups as possible before doing so. The value
 might not be immediately available, for example, requiring a Skyframe restart,
 so the caller specifies what to do with the resulting value using a callback.
 
-The `StateMachine` processor ([`Driver`s and bridging to
-SkyFrame](#drivers-and-bridging)) guarantees that the value is available before
+The `StateMachine` processor ([`Driver`s and bridging to SkyFrame](#drivers-and-bridging)) guarantees that the value is available before
 the next state begins. An example follows.
 
 ```
@@ -284,8 +283,7 @@ and solutions to certain control flow problems.
 ### Sequential states
 
 This is the most common and straightforward control flow pattern. An example of
-this is shown in [Stateful computations inside
-`SkyKeyComputeState`](#stateful-computations).
+this is shown in [Stateful computations inside `SkyKeyComputeState`](#stateful-computations).
 
 ### Branching
 
@@ -545,8 +543,7 @@ section describes the propagation of data values.
 
 ### Implementing `Tasks.lookUp` callbacks
 
-There’s an example of implementing a `Tasks.lookUp` callback in [SkyValue
-lookups](#skyvalue-lookups). This section provides rationale and suggests
+There’s an example of implementing a `Tasks.lookUp` callback in [SkyValue lookups](#skyvalue-lookups). This section provides rationale and suggests
 approaches for handling multiple SkyValues.
 
 #### `Tasks.lookUp` callbacks {#tasks-lookup-callbacks}
@@ -710,8 +707,7 @@ class BarProducer implements StateMachine {
 Tip: It would be tempting to use the more concise signature void `accept(Bar
 value)` rather than the stuttery `void acceptBarValue(Bar value)` above.
 However, `Consumer` is a common overload of `void accept(Bar value)`,
-so doing this often leads to violations of the [Overloads: never
-split](https://google.github.io/styleguide/javaguide.html#s3.4.2-ordering-class-contents)
+so doing this often leads to violations of the [Overloads: never split](https://google.github.io/styleguide/javaguide.html#s3.4.2-ordering-class-contents)
 style-guide rule.
 
 Tip: Using a custom `ResultSink` type instead of a generic one from
@@ -774,14 +770,11 @@ pattern after accepting output from either a subtask or SkyValue lookup.
 Note that the implementation of `acceptBarError` eagerly forwards the result to
 the `Caller.ResultSink`, as required by [Error bubbling](#error-bubbling).
 
-Alternatives for top-level `StateMachine`s are described in [`Driver`s and
-bridging to SkyFunctions](#drivers-and-bridging).
+Alternatives for top-level `StateMachine`s are described in [`Driver`s and bridging to SkyFunctions](#drivers-and-bridging).
 
 ### Error handling {#error-handling}
 
-There's a couple of examples of error handling already in [`Tasks.lookUp`
-callbacks](#tasks-lookup-callbacks) and [Propagating values between
-`StateMachines`](#propagating-values). Exceptions, other than
+There's a couple of examples of error handling already in [`Tasks.lookUp` callbacks](#tasks-lookup-callbacks) and [Propagating values between `StateMachines`](#propagating-values). Exceptions, other than
 `InterruptedException` are not thrown, but instead passed around through
 callbacks as values. Such callbacks often have exclusive-or semantics, with
 exactly one of a value or error being passed.
@@ -1184,8 +1177,7 @@ states. Where it is possible, local stack `step` variables are young generation
 variables and efficiently GC'd.
 
 For `StateMachine` variables, breaking things down into subtasks and following
-the recommended pattern for [Propagating values between
-`StateMachine`s](#propagating-values) is also helpful. Observe that when
+the recommended pattern for [Propagating values between `StateMachine`s](#propagating-values) is also helpful. Observe that when
 following the pattern, only child `StateMachine`s have references to parent
 `StateMachine`s and not vice versa. This means that as children complete and
 update the parents using result callbacks, the children naturally fall out of
@@ -1207,8 +1199,7 @@ potentially reflecting local behavior.
 
 ### Concurrency tree diagram {#concurrency-tree-diagram}
 
-The following is an alternative view of the diagram in [Structured
-concurrency](#structured-concurrency) that better depicts the tree structure.
+The following is an alternative view of the diagram in [Structured concurrency](#structured-concurrency) that better depicts the tree structure.
 The blocks form a small tree.
 
 ![Structured Concurrency 3D](/versions/7.6.1/contribute/images/structured-concurrency-3d.svg)
diff --git a/versions/7.6.1/docs/android-instrumentation-test.mdx b/versions/7.6.1/docs/android-instrumentation-test.mdx
index 544ff179..68ba374e 100644
--- a/versions/7.6.1/docs/android-instrumentation-test.mdx
+++ b/versions/7.6.1/docs/android-instrumentation-test.mdx
@@ -2,8 +2,7 @@
 title: 'Android Instrumentation Tests'
 ---
 
-_If you're new to Bazel, start with the [Building Android with
-Bazel](/versions/7.6.1/start/android-app ) tutorial._
+_If you're new to Bazel, start with the [Building Android with Bazel](/versions/7.6.1/start/android-app) tutorial._
 
 ![Running Android instrumentation tests in parallel](/versions/7.6.1/docs/images/android_test.gif "Android instrumentation test")
 
@@ -18,9 +17,7 @@ emulators in a sandbox, ensuring that tests always run from a clean state. Each
 test gets an isolated emulator instance, allowing tests to run in parallel
 without passing states between them.
 
-For more information on Android instrumentation tests, check out the [Android
-developer
-documentation](https://developer.android.com/training/testing/unit-testing/instrumented-unit-tests.html).
+For more information on Android instrumentation tests, check out the [Android developer documentation](https://developer.android.com/training/testing/unit-testing/instrumented-unit-tests.html).
 
 Please file issues in the [GitHub issue tracker](https://github.com/bazelbuild/bazel/issues).
 
@@ -58,8 +55,7 @@ This results in output similar to the following:
 release 4.1.0
 ```
 
-- **KVM**. Bazel requires emulators to have [hardware
-  acceleration](https://developer.android.com/studio/run/emulator-acceleration.html#accel-check)
+- **KVM**. Bazel requires emulators to have [hardware acceleration](https://developer.android.com/studio/run/emulator-acceleration.html#accel-check)
   with KVM on Linux. You can follow these
   [installation instructions](https://help.ubuntu.com/community/KVM/Installation)
   for Ubuntu.
@@ -173,11 +169,9 @@ The main attributes of the rule `android_instrumentation_test` are:
 
 - `target_device`: An `android_device` target. This target describes the
   specifications of the Android emulator which Bazel uses to create, launch and
-  run the tests. See the [section on choosing an Android
-  device](#android-device-target) for more information.
+  run the tests. See the [section on choosing an Android device](#android-device-target) for more information.
 
-The test app's `AndroidManifest.xml` must include [an ``
-tag](https://developer.android.com/studio/test/#configure_instrumentation_manifest_settings).
+The test app's `AndroidManifest.xml` must include [an `` tag](https://developer.android.com/studio/test/#configure_instrumentation_manifest_settings).
 This tag must specify the attributes for the **package of the target app** and
 the **fully qualified class name of the instrumentation test runner**,
 `androidx.test.runner.AndroidJUnitRunner`.
@@ -214,8 +208,7 @@ repositories:
 - `@androidsdk`: The Android SDK. Download this through Android Studio.
 
 - `@android_test_support`: Hosts the test runner, emulator launcher, and
-  `android_device` targets. You can find the [latest release
-  here](https://github.com/android/android-test/releases).
+  `android_device` targets. You can find the [latest release here](https://github.com/android/android-test/releases).
 
 Enable these dependencies by adding the following lines to your `WORKSPACE`
 file:
@@ -240,8 +233,7 @@ android_test_repositories()
 
 ## Maven dependencies {#maven-dependencies}
 
-For managing dependencies on Maven artifacts from repositories, such as [Google
-Maven](https://maven.google.com) or [Maven Central](https://central.maven.org),
+For managing dependencies on Maven artifacts from repositories, such as [Google Maven](https://maven.google.com) or [Maven Central](https://central.maven.org),
 you should use a Maven resolver, such as
 [`rules_jvm_external`](https://github.com/bazelbuild/rules_jvm_external).
 
@@ -370,8 +362,7 @@ the device/emulator listed in `adb devices`.
 
 ## Sample projects {#sample-projects}
 
-If you are looking for canonical project samples, see the [Android testing
-samples](https://github.com/googlesamples/android-testing#experimental-bazel-support)
+If you are looking for canonical project samples, see the [Android testing samples](https://github.com/googlesamples/android-testing#experimental-bazel-support)
 for projects using Espresso and UIAutomator.
 
 ## Espresso setup {#espresso-setup}
@@ -560,8 +551,7 @@ API_LEVELS = [
 
 ## Known issues {#known-issues}
 
-- [Forked adb server processes are not terminated after
-  tests](https://github.com/bazelbuild/bazel/issues/4853)
+- [Forked adb server processes are not terminated after tests](https://github.com/bazelbuild/bazel/issues/4853)
 - While APK building works on all platforms (Linux, macOS, Windows), testing
   only works on Linux.
 - Even with `--config=local_adb`, users still need to specify
diff --git a/versions/7.6.1/docs/android-ndk.mdx b/versions/7.6.1/docs/android-ndk.mdx
index 04e02a37..4775b2ee 100644
--- a/versions/7.6.1/docs/android-ndk.mdx
+++ b/versions/7.6.1/docs/android-ndk.mdx
@@ -2,8 +2,7 @@
 title: 'Using the Android Native Development Kit with Bazel'
 ---
 
-_If you're new to Bazel, please start with the [Building Android with
-Bazel](/versions/7.6.1/start/android-app ) tutorial._
+_If you're new to Bazel, please start with the [Building Android with Bazel](/versions/7.6.1/start/android-app) tutorial._
 
 ## Overview {#overview}
 
@@ -31,8 +30,7 @@ android_ndk_repository(
 )
 ```
 
-For more information about the `android_ndk_repository` rule, see the [Build
-Encyclopedia entry](/versions/7.6.1/reference/be/android#android_ndk_repository).
+For more information about the `android_ndk_repository` rule, see the [Build Encyclopedia entry](/versions/7.6.1/reference/be/android#android_ndk_repository).
 
 If you're using a recent version of the Android NDK (r22 and beyond), use the
 Starlark implementation of `android_ndk_repository`.
@@ -101,13 +99,11 @@ META-INF/MANIFEST.MF
 
 Bazel compiles all of the cc_libraries into a single shared object (`.so`) file,
 targeted for the `armeabi-v7a` ABI by default. To change this or build for
-multiple ABIs at the same time, see the section on [configuring the target
-ABI](#configuring-target-abi).
+multiple ABIs at the same time, see the section on [configuring the target ABI](#configuring-target-abi).
 
 ## Example setup {#example-setup}
 
-This example is available in the [Bazel examples
-repository](https://github.com/bazelbuild/examples/tree/master/android/ndk).
+This example is available in the [Bazel examples repository](https://github.com/bazelbuild/examples/tree/master/android/ndk).
 
 In the `BUILD.bazel` file, three targets are defined with the `android_binary`,
 `android_library`, and `cc_library` rules.
@@ -178,12 +174,10 @@ For r16 and below, the default STL is `gnustl`. For r17 and above, it is
 `libc++`. For convenience, the target `@androidndk//:default_crosstool` is
 aliased to the respective default STLs.
 
-Please note that from r18 onwards, [STLport and gnustl will be
-removed](https://android.googlesource.com/platform/ndk/+/master/docs/Roadmap.md#ndk-r18),
+Please note that from r18 onwards, [STLport and gnustl will be removed](https://android.googlesource.com/platform/ndk/+/master/docs/Roadmap.md#ndk-r18),
 making `libc++` the only STL in the NDK.
 
-See the [NDK
-documentation](https://developer.android.com/ndk/guides/cpp-support)
+See the [NDK documentation](https://developer.android.com/ndk/guides/cpp-support)
 for more information on these STLs.
 
 ## Configuring the target ABI {#configuring-target-abi}
@@ -324,8 +318,7 @@ an Android-compatible configuration so that the Bazel build *just works* without
 any special flags, except for `--fat_apk_cpu` and `--android_crosstool_top` for
 ABI and STL configuration.
 
-Behind the scenes, this automatic configuration uses Android [configuration
-transitions](/versions/7.6.1/extending/rules#configurations).
+Behind the scenes, this automatic configuration uses Android [configuration transitions](/versions/7.6.1/extending/rules#configurations).
 
 A compatible rule, like `android_binary`, automatically changes the
 configuration of its dependencies to an Android configuration, so only
diff --git a/versions/7.6.1/docs/configurable-attributes.mdx b/versions/7.6.1/docs/configurable-attributes.mdx
index c32f9575..4b3baabb 100644
--- a/versions/7.6.1/docs/configurable-attributes.mdx
+++ b/versions/7.6.1/docs/configurable-attributes.mdx
@@ -2,8 +2,7 @@
 title: 'Configurable Build Attributes'
 ---
 
-**_Configurable attributes_**, commonly known as [`select()`](
-/reference/be/functions#select), is a Bazel feature that lets users toggle the values
+**_Configurable attributes_**, commonly known as [`select()`](/reference/be/functions#select), is a Bazel feature that lets users toggle the values
 of build rule attributes at the command line.
 
 This can be used, for example, for a multiplatform library that automatically
@@ -407,8 +406,7 @@ sh_library(
 )
 ```
 
-If you need a `select` to match when multiple conditions match, consider [AND
-chaining](#and-chaining).
+If you need a `select` to match when multiple conditions match, consider [AND chaining](#and-chaining).
 
 ## OR chaining {#or-chaining}
 
diff --git a/versions/7.6.1/docs/user-manual.mdx b/versions/7.6.1/docs/user-manual.mdx
index 04a86b67..7b84fecf 100644
--- a/versions/7.6.1/docs/user-manual.mdx
+++ b/versions/7.6.1/docs/user-manual.mdx
@@ -1163,10 +1163,7 @@ This option causes Bazel's execution phase to print the full command line
 for each command prior to executing it.
 
 
-  >>>>> # //examples/cpp:hello-world [action 'Linking examples/cpp/hello-world']
-  (cd /home/johndoe/.cache/bazel/_bazel_johndoe/4c084335afceb392cfbe7c31afee3a9f/bazel && \
-    exec env - \
-    /usr/bin/gcc -o bazel-out/local-fastbuild/bin/examples/cpp/hello-world -B/usr/bin/ -Wl,-z,relro,-z,now -no-canonical-prefixes -pass-exit-codes -Wl,-S -Wl,@bazel-out/local_linux-fastbuild/bin/examples/cpp/hello-world-2.params)
+  >>>>> # //examples/cpp:hello-world [action 'Linking examples/cpp/hello-world'](cd /home/johndoe/.cache/bazel/_bazel_johndoe/4c084335afceb392cfbe7c31afee3a9f/bazel && \ exec env - \ /usr/bin/gcc -o bazel-out/local-fastbuild/bin/examples/cpp/hello-world -B/usr/bin/ -Wl,-z,relro,-z,now -no-canonical-prefixes -pass-exit-codes -Wl,-S -Wl,@bazel-out/local_linux-fastbuild/bin/examples/cpp/hello-world-2.params)
 

 
 Where possible, commands are printed in a Bourne shell compatible syntax,
diff --git a/versions/7.6.1/extending/depsets.mdx b/versions/7.6.1/extending/depsets.mdx
index dab55b2a..0a59c013 100644
--- a/versions/7.6.1/extending/depsets.mdx
+++ b/versions/7.6.1/extending/depsets.mdx
@@ -111,8 +111,7 @@ need to ensure that if `B` depends on `A`, then `A.o` comes before `B.o` on the
 linker’s command line. Other tools might have the opposite requirement.
 
 Three traversal orders are supported: `postorder`, `preorder`, and
-`topological`. The first two work exactly like [tree
-traversals](https://en.wikipedia.org/wiki/Tree_traversal#Depth-first_search)
+`topological`. The first two work exactly like [tree traversals](https://en.wikipedia.org/wiki/Tree_traversal#Depth-first_search)
 except that they operate on DAGs and skip already visited nodes. The third order
 works as a topological sort from root to leaves, essentially the same as
 preorder except that shared children are listed only after all of their parents.
diff --git a/versions/7.6.1/extending/exec-groups.mdx b/versions/7.6.1/extending/exec-groups.mdx
index 7ffb8b2d..2016e9db 100644
--- a/versions/7.6.1/extending/exec-groups.mdx
+++ b/versions/7.6.1/extending/exec-groups.mdx
@@ -63,8 +63,7 @@ test rules.
 
 In the rule implementation, you can declare that actions should be run on the
 execution platform of an execution group. You can do this by using the `exec_group`
-param of action generating methods, specifically [`ctx.actions.run`]
-(/rules/lib/builtins/actions#run) and
+param of action generating methods, specifically [`ctx.actions.run`](/rules/lib/builtins/actions#run) and
 [`ctx.actions.run_shell`](/versions/7.6.1/rules/lib/builtins/actions#run_shell).
 
 ```python
diff --git a/versions/7.6.1/extending/macros.mdx b/versions/7.6.1/extending/macros.mdx
index dbbddf10..02f98f59 100644
--- a/versions/7.6.1/extending/macros.mdx
+++ b/versions/7.6.1/extending/macros.mdx
@@ -212,8 +212,7 @@ def my_macro(name, deps, visibility=None):
     instantiate rules must have a `name` argument. This argument should not be
     optional (don't give a default value).
 
-*   Public functions should use a docstring following [Python
-    conventions](https://www.python.org/dev/peps/pep-0257/#one-line-docstrings).
+*   Public functions should use a docstring following [Python conventions](https://www.python.org/dev/peps/pep-0257/#one-line-docstrings).
 
 *   In `BUILD` files, the `name` argument of the macros must be a keyword
     argument (not a positional argument).
diff --git a/versions/7.6.1/extending/platforms.mdx b/versions/7.6.1/extending/platforms.mdx
index 63057f12..e92c723c 100644
--- a/versions/7.6.1/extending/platforms.mdx
+++ b/versions/7.6.1/extending/platforms.mdx
@@ -245,8 +245,7 @@ cc_library(
 
 You can use the
 [`IncompatiblePlatformProvider`](/versions/7.6.1/rules/lib/providers/IncompatiblePlatformProvider)
-in `bazel cquery`'s [Starlark output
-format](/versions/7.6.1/query/cquery#output-format-definition) to distinguish
+in `bazel cquery`'s [Starlark output format](/versions/7.6.1/query/cquery#output-format-definition) to distinguish
 incompatible targets from compatible ones.
 
 This can be used to filter out incompatible targets. The example below will
@@ -266,5 +265,4 @@ $ bazel cquery //... --output=starlark --starlark:file=example.cquery
 
 ### Known Issues
 
-Incompatible targets [ignore visibility
-restrictions](https://github.com/bazelbuild/bazel/issues/16044).
+Incompatible targets [ignore visibility restrictions](https://github.com/bazelbuild/bazel/issues/16044).
diff --git a/versions/7.6.1/extending/repo.mdx b/versions/7.6.1/extending/repo.mdx
index 1f091434..73d1b390 100644
--- a/versions/7.6.1/extending/repo.mdx
+++ b/versions/7.6.1/extending/repo.mdx
@@ -74,8 +74,7 @@ specified.
 
 The input parameter `repository_ctx` can be used to access attribute values, and
 non-hermetic functions (finding a binary, executing a binary, creating a file in
-the repository or downloading a file from the Internet). See [the API
-docs](/versions/7.6.1/rules/lib/builtins/repository_ctx) for more context. Example:
+the repository or downloading a file from the Internet). See [the API docs](/versions/7.6.1/rules/lib/builtins/repository_ctx) for more context. Example:
 
 ```python
 def _impl(repository_ctx):
@@ -144,8 +143,7 @@ definition has the `configure` attribute set, use `bazel fetch --force
 
 ## Examples
 
--   [C++ auto-configured
-    toolchain](https://cs.opensource.google/bazel/bazel/+/master:tools/cpp/cc_configure.bzl;drc=644b7d41748e09eff9e47cbab2be2263bb71f29a;l=176):
+-   [C++ auto-configured toolchain](https://cs.opensource.google/bazel/bazel/+/master:tools/cpp/cc_configure.bzl;drc=644b7d41748e09eff9e47cbab2be2263bb71f29a;l=176):
     it uses a repo rule to automatically create the C++ configuration files for
     Bazel by looking for the local C++ compiler, the environment and the flags
     the C++ compiler supports.
diff --git a/versions/7.6.1/extending/rules.mdx b/versions/7.6.1/extending/rules.mdx
index fe64dfb4..31a3ef37 100644
--- a/versions/7.6.1/extending/rules.mdx
+++ b/versions/7.6.1/extending/rules.mdx
@@ -462,8 +462,7 @@ def _example_library_impl(ctx):
 
 If `DefaultInfo` is not returned by a rule implementation or the `files`
 parameter is not specified, `DefaultInfo.files` defaults to all
-*predeclared outputs* (generally, those created by [output
-attributes](#output_attributes)).
+*predeclared outputs* (generally, those created by [output attributes](#output_attributes)).
 
 Rules that perform actions should provide default outputs, even if those outputs
 are not expected to be directly used. Actions that are not in the graph of the
diff --git a/versions/7.6.1/external/advanced.mdx b/versions/7.6.1/external/advanced.mdx
index 5fa44562..a93d379c 100644
--- a/versions/7.6.1/external/advanced.mdx
+++ b/versions/7.6.1/external/advanced.mdx
@@ -4,10 +4,8 @@ title: 'Advanced topics on external dependencies'
 
 ## Shadowing dependencies in WORKSPACE
 
-Note: This section applies to the [WORKSPACE
-system](/versions/7.6.1/external/overview#workspace-system) only. For
-[Bzlmod](/versions/7.6.1/external/overview#bzlmod), use a [multiple-version
-override](/versions/7.6.1/external/module#multiple-version_override).
+Note: This section applies to the [WORKSPACE system](/versions/7.6.1/external/overview#workspace-system) only. For
+[Bzlmod](/versions/7.6.1/external/overview#bzlmod), use a [multiple-version override](/versions/7.6.1/external/module#multiple-version_override).
 
 Whenever possible, have a single version policy in your project, which is
 required for dependencies that you compile against and end up in your final
@@ -128,29 +126,24 @@ preferring IPv4 if enabled. In some situations, for example when the IPv4
 network cannot resolve/reach external addresses, this can cause `Network
 unreachable` exceptions and build failures. In these cases, you can override
 Bazel's behavior to prefer IPv6 by using the
-[`java.net.preferIPv6Addresses=true` system
-property](https://docs.oracle.com/javase/8/docs/api/java/net/doc-files/net-properties.html).
+[`java.net.preferIPv6Addresses=true` system property](https://docs.oracle.com/javase/8/docs/api/java/net/doc-files/net-properties.html).
 Specifically:
 
-*   Use `--host_jvm_args=-Djava.net.preferIPv6Addresses=true` [startup
-    option](/versions/7.6.1/docs/user-manual#startup-options), for example by adding the
+*   Use `--host_jvm_args=-Djava.net.preferIPv6Addresses=true` [startup option](/versions/7.6.1/docs/user-manual#startup-options), for example by adding the
     following line in your [`.bazelrc` file](/versions/7.6.1/run/bazelrc):
 
     `startup --host_jvm_args=-Djava.net.preferIPv6Addresses=true`
 
 *   When running Java build targets that need to connect to the internet (such
     as for integration tests), use the
-    `--jvmopt=-Djava.net.preferIPv6Addresses=true` [tool
-    flag](/versions/7.6.1/docs/user-manual#jvmopt). For example, include in your [`.bazelrc`
-    file](/versions/7.6.1/run/bazelrc):
+    `--jvmopt=-Djava.net.preferIPv6Addresses=true` [tool flag](/versions/7.6.1/docs/user-manual#jvmopt). For example, include in your [`.bazelrc` file](/versions/7.6.1/run/bazelrc):
 
     `build --jvmopt=-Djava.net.preferIPv6Addresses`
 
 *   If you are using [`rules_jvm_external`](https://github.com/bazelbuild/rules_jvm_external)
     for dependency version resolution, also add
     `-Djava.net.preferIPv6Addresses=true` to the `COURSIER_OPTS` environment
-    variable to [provide JVM options for
-    Coursier](https://github.com/bazelbuild/rules_jvm_external#provide-jvm-options-for-coursier-with-coursier_opts).
+    variable to [provide JVM options for Coursier](https://github.com/bazelbuild/rules_jvm_external#provide-jvm-options-for-coursier-with-coursier_opts).
 
 ## Offline builds
 
@@ -167,15 +160,12 @@ fetch a file with [`ctx.download`](/versions/7.6.1/rules/lib/builtins/repository
 providing a hash sum of the file needed, Bazel looks for a file matching the
 basename of the first URL, and uses the local copy if the hash matches.
 
-Bazel itself uses this technique to bootstrap offline from the [distribution
-artifact](https://github.com/bazelbuild/bazel-website/blob/master/designs/_posts/2016-10-11-distribution-artifact.md).
-It does so by [collecting all the needed external
-dependencies](https://github.com/bazelbuild/bazel/blob/5cfa0303d6ac3b5bd031ff60272ce80a704af8c2/WORKSPACE#L116)
+Bazel itself uses this technique to bootstrap offline from the [distribution artifact](https://github.com/bazelbuild/bazel-website/blob/master/designs/_posts/2016-10-11-distribution-artifact.md).
+It does so by [collecting all the needed external dependencies](https://github.com/bazelbuild/bazel/blob/5cfa0303d6ac3b5bd031ff60272ce80a704af8c2/WORKSPACE#L116)
 in an internal
 [`distdir_tar`](https://github.com/bazelbuild/bazel/blob/5cfa0303d6ac3b5bd031ff60272ce80a704af8c2/distdir.bzl#L44).
 
 Bazel allows execution of arbitrary commands in repository rules without knowing
 if they call out to the network, and so cannot enforce fully offline builds. To
 test if a build works correctly offline, manually block off the network (as
-Bazel does in its [bootstrap
-test](https://cs.opensource.google/bazel/bazel/+/master:src/test/shell/bazel/BUILD;l=1073;drc=88c426e73cc0eb0a41c0d7995e36acd94e7c9a48)).
\ No newline at end of file
+Bazel does in its [bootstrap test](https://cs.opensource.google/bazel/bazel/+/master:src/test/shell/bazel/BUILD;l=1073;drc=88c426e73cc0eb0a41c0d7995e36acd94e7c9a48)).
\ No newline at end of file
diff --git a/versions/7.6.1/external/migration.mdx b/versions/7.6.1/external/migration.mdx
index 6aa95faf..c6c61d66 100644
--- a/versions/7.6.1/external/migration.mdx
+++ b/versions/7.6.1/external/migration.mdx
@@ -2,8 +2,7 @@
 title: 'Bzlmod Migration Guide'
 ---
 
-Due to the [shortcomings of
-WORKSPACE](/versions/7.6.1/external/overview#workspace-shortcomings), Bzlmod is going to
+Due to the [shortcomings of WORKSPACE](/versions/7.6.1/external/overview#workspace-shortcomings), Bzlmod is going to
 replace the legacy WORKSPACE system in future Bazel releases. This guide helps
 you migrate your project to Bzlmod and drop WORKSPACE for fetching external
 dependencies.
@@ -116,9 +115,7 @@ Bazel module when it also adopts Bzlmod.
 
 *   **Bzlmod**
 
-    With Bzlmod, as long as the your dependency is available in [Bazel Central
-    Registry](https://registry.bazel.build) or your custom [Bazel
-    registry](/versions/7.6.1/external/registry), you can simply depend on it with a
+    With Bzlmod, as long as the your dependency is available in [Bazel Central Registry](https://registry.bazel.build) or your custom [Bazel registry](/versions/7.6.1/external/registry), you can simply depend on it with a
     [`bazel_dep`](/versions/7.6.1/rules/lib/globals/module#bazel_dep) directive.
 
     ```python
@@ -149,8 +146,7 @@ repository.
 
 If your dependency is not a Bazel project or not yet available in any Bazel
 registry, you can introduce it using
-[`use_repo_rule`](/versions/7.6.1/external/module#use_repo_rule) or [module
-extensions](/versions/7.6.1/external/extension).
+[`use_repo_rule`](/versions/7.6.1/external/module#use_repo_rule) or [module extensions](/versions/7.6.1/external/extension).
 
 *   **WORKSPACE**
 
@@ -583,8 +579,7 @@ macros.
 Fortunately, the flag
 [`--experimental_repository_resolved_file`][resolved_file_flag]
 can help. This flag essentially generates a "lock file" of all fetched external
-dependencies in your last Bazel command. You can find more details in this [blog
-post](https://blog.bazel.build/2018/07/09/bazel-sync-and-resolved-file.html).
+dependencies in your last Bazel command. You can find more details in this [blog post](https://blog.bazel.build/2018/07/09/bazel-sync-and-resolved-file.html).
 
 [resolved_file_flag]: /reference/command-line-reference#flag--experimental_repository_resolved_file
 
@@ -625,11 +620,9 @@ You may also know `bazel query` can be used for inspecting repository rules with
 bazel query --output=build //external:
 ```
 
-While it is more convenient and much faster, [bazel query can lie about
-external dependency version](https://github.com/bazelbuild/bazel/issues/12947),
+While it is more convenient and much faster, [bazel query can lie about external dependency version](https://github.com/bazelbuild/bazel/issues/12947),
 so be careful using it! Querying and inspecting external
-dependencies with Bzlmod is going to achieved by a [new
-subcommand](https://github.com/bazelbuild/bazel/issues/15365).
+dependencies with Bzlmod is going to achieved by a [new subcommand](https://github.com/bazelbuild/bazel/issues/15365).
 
 #### Built-in default dependencies {#builtin-default-deps}
 
@@ -676,8 +669,7 @@ your workspace root.
 #### Repository visibility {#repository-visibility}
 
 Bzlmod is able to control which other repositories are visible from a given
-repository, check [repository names and strict
-deps](/versions/7.6.1/external/module#repository_names_and_strict_deps) for more details.
+repository, check [repository names and strict deps](/versions/7.6.1/external/module#repository_names_and_strict_deps) for more details.
 
 Here is a summary of repository visibilities from different types of
 repositories when also taking WORKSPACE into consideration.
@@ -690,8 +682,7 @@ repositories when also taking WORKSPACE into consideration.
 | WORKSPACE Repos | All visible | Not visible | Not visible | All visible |
 
 Note: For the root module, if a repository `@foo` is defined in WORKSPACE and
-`@foo` is also used as an [apparent repository
-name](/versions/7.6.1/external/overview#apparent-repo-name) in MODULE.bazel, then `@foo`
+`@foo` is also used as an [apparent repository name](/versions/7.6.1/external/overview#apparent-repo-name) in MODULE.bazel, then `@foo`
 refers to the one introduced in MODULE.bazel.
 
 Note: For a module extension generated repository `@bar`, if `@foo` is used as
@@ -766,9 +757,7 @@ the project. Take note of a few things when creating the source archive:
     GitHub isn't going to guarantee the checksum of source archives generated on
     demand. In short, URLs in the form of
     `https://github.com///releases/download/...` is considered stable
-    while `https://github.com///archive/...` is not. Check [GitHub
-    Archive Checksum
-    Outage](https://blog.bazel.build/2023/02/15/github-archive-checksum.html)
+    while `https://github.com///archive/...` is not. Check [GitHub Archive Checksum Outage](https://blog.bazel.build/2023/02/15/github-archive-checksum.html)
     for more context.
 
 *   **Make sure the source tree follows the layout of the original repository.**
@@ -797,8 +786,7 @@ Pull Request.
 
 [bcr_contrib_guide]: https://github.com/bazelbuild/bazel-central-registry/tree/main/docs#contribute-a-bazel-module
 
-It is **highly recommended** to set up the [Publish to
-BCR](https://github.com/bazel-contrib/publish-to-bcr) GitHub App for your
+It is **highly recommended** to set up the [Publish to BCR](https://github.com/bazel-contrib/publish-to-bcr) GitHub App for your
 repository to automate the process of submitting your module to the BCR.
 
 ## Best practices {#best-practices}
diff --git a/versions/7.6.1/external/mod-command.mdx b/versions/7.6.1/external/mod-command.mdx
index 6d7636ad..7b40275f 100644
--- a/versions/7.6.1/external/mod-command.mdx
+++ b/versions/7.6.1/external/mod-command.mdx
@@ -61,11 +61,9 @@ The available subcommands and their respective required arguments are:
 
 *   ``: All present versions of the module ``.
 
-*   `@`: The repo with the given [apparent
-    name](overview#apparent-repo-name) in the context of the `--base_module`.
+*   `@`: The repo with the given [apparent name](overview#apparent-repo-name) in the context of the `--base_module`.
 
-*   `@@`: The repo with the given [canonical
-    name](overview#canonical-repo-name).
+*   `@@`: The repo with the given [canonical name](overview#canonical-repo-name).
 
 In a context requiring specifying modules, ``s referring to repos that
 correspond to modules (as opposed to extension-generated repos) can also be
@@ -87,8 +85,7 @@ The following options only affect the subcommands that print graphs (`graph`,
     information about the version resolution of each module. If the module
     version changed during resolution, show either which version replaced it or
     what was the original version, the reason it was replaced, and which modules
-    requested the new version if the reason was [Minimal Version
-    Selection](module#version-selection).
+    requested the new version if the reason was [Minimal Version Selection](module#version-selection).
 
 *   `--include_unused` *default: "false"*: Include in the output graph the
     modules which were originally present in the dependency graph, but became
diff --git a/versions/7.6.1/external/module.mdx b/versions/7.6.1/external/module.mdx
index 9a48e4db..a59cb0cc 100644
--- a/versions/7.6.1/external/module.mdx
+++ b/versions/7.6.1/external/module.mdx
@@ -122,8 +122,7 @@ serves multiple purposes:
     version, regardless of which versions of the dependency are requested in the
     dependency graph.
 *   With the `registry` attribute, you can force this dependency to come from a
-    specific registry, instead of following the normal [registry
-    selection](/versions/7.6.1/external/registry#selecting_registries) process.
+    specific registry, instead of following the normal [registry selection](/versions/7.6.1/external/registry#selecting_registries) process.
 *   With the `patch*` attributes, you can specify a set of patches to apply to
     the downloaded module.
 
@@ -176,13 +175,11 @@ With `bazel_dep`, you can define repos that represent other Bazel modules.
 Sometimes there is a need to define a repo that does _not_ represent a Bazel
 module; for example, one that contains a plain JSON file to be read as data.
 
-In this case, you could use the [`use_repo_rule`
-directive](/versions/7.6.1/rules/lib/globals/module#use_repo_rule) to directly define a repo
+In this case, you could use the [`use_repo_rule` directive](/versions/7.6.1/rules/lib/globals/module#use_repo_rule) to directly define a repo
 by invoking a repo rule. This repo will only be visible to the module it's
 defined in.
 
-Under the hood, this is implemented using the same mechanism as [module
-extensions](/versions/7.6.1/external/extension), which lets you define repos with more
+Under the hood, this is implemented using the same mechanism as [module extensions](/versions/7.6.1/external/extension), which lets you define repos with more
 flexibility.
 
 ## Repository names and strict deps
diff --git a/versions/7.6.1/external/overview.mdx b/versions/7.6.1/external/overview.mdx
index cca6d04d..29842bfd 100644
--- a/versions/7.6.1/external/overview.mdx
+++ b/versions/7.6.1/external/overview.mdx
@@ -128,8 +128,7 @@ for all build targets inside the repo.
 
 The syntax of a `REPO.bazel` file is similar to `BUILD` files, except that no
 `load` statements are supported, and only a single function, `repo()`, is
-available. `repo()` takes the same arguments as the [`package()`
-function](/versions/7.6.1/reference/be/functions#package) in `BUILD` files; whereas `package()`
+available. `repo()` takes the same arguments as the [`package()` function](/versions/7.6.1/reference/be/functions#package) in `BUILD` files; whereas `package()`
 specifies common attributes for all build targets inside the package, `repo()`
 analogously does so for all build targets inside the repo.
 
@@ -163,8 +162,7 @@ bazel_dep(name = "protobuf", version = "3.19.0")
 ```
 
 A module must only list its direct dependencies, which Bzlmod looks up in a
-[Bazel registry](/versions/7.6.1/external/registry) — by default, the [Bazel Central
-Registry](https://bcr.bazel.build/). The registry provides the
+[Bazel registry](/versions/7.6.1/external/registry) — by default, the [Bazel Central Registry](https://bcr.bazel.build/). The registry provides the
 dependencies' `MODULE.bazel` files, which allows Bazel to discover the entire
 transitive dependency graph before performing version resolution.
 
@@ -235,5 +233,4 @@ many pain points, including:
         `B` and `C`; `B` and `C` both depend on different versions of `D`).
 
 Due to the shortcomings of WORKSPACE, Bzlmod is going to replace the legacy
-WORKSPACE system in future Bazel releases. Please read the [Bzlmod migration
-guide](/versions/7.6.1/external/migration) on how to migrate to Bzlmod.
\ No newline at end of file
+WORKSPACE system in future Bazel releases. Please read the [Bzlmod migration guide](/versions/7.6.1/external/migration) on how to migrate to Bzlmod.
\ No newline at end of file
diff --git a/versions/7.6.1/external/registry.mdx b/versions/7.6.1/external/registry.mdx
index e5f7ae4b..9d8a23f4 100644
--- a/versions/7.6.1/external/registry.mdx
+++ b/versions/7.6.1/external/registry.mdx
@@ -42,8 +42,7 @@ An index registry must follow the format below:
             project
         *   `versions`: A list of all the versions of this module to be found in
             this registry
-        *   `yanked_versions`: A map of [*yanked*
-            versions](/versions/7.6.1/external/module#yanked_versions) of this module. The keys
+        *   `yanked_versions`: A map of [*yanked* versions](/versions/7.6.1/external/module#yanked_versions) of this module. The keys
             should be versions to yank and the values should be descriptions of
             why the version is yanked, ideally containing a link to more
             information
@@ -54,8 +53,7 @@ An index registry must follow the format below:
         *   The default type is "archive", representing an `http_archive` repo,
             with the following fields:
             *   `url`: The URL of the source archive
-            *   `integrity`: The [Subresource
-                Integrity](https://w3c.github.io/webappsec-subresource-integrity/#integrity-metadata-description)
+            *   `integrity`: The [Subresource Integrity](https://w3c.github.io/webappsec-subresource-integrity/#integrity-metadata-description)
                 checksum of the archive
             *   `strip_prefix`: A directory prefix to strip when extracting the
                 source archive
@@ -103,8 +101,7 @@ You can browse its contents using the web frontend at
 https://registry.bazel.build/.
 
 The Bazel community maintains the BCR, and contributors are welcome to submit
-pull requests. See the [BCR contribution
-guidelines](https://github.com/bazelbuild/bazel-central-registry/blob/main/docs/README.md).
+pull requests. See the [BCR contribution guidelines](https://github.com/bazelbuild/bazel-central-registry/blob/main/docs/README.md).
 
 In addition to following the format of a normal index registry, the BCR requires
 a `presubmit.yml` file for each module version
diff --git a/versions/7.6.1/external/vendor.mdx b/versions/7.6.1/external/vendor.mdx
index 820936c7..5717874c 100644
--- a/versions/7.6.1/external/vendor.mdx
+++ b/versions/7.6.1/external/vendor.mdx
@@ -23,9 +23,7 @@ absolute path.
 ## Vendor a specific external repository {#vendor-specific-repository}
 
 You can use the `vendor` command with the `--repo` flag to specify which repo
-to vendor, it accepts both [canonical repo
-name](/versions/7.6.1/external/overview#canonical-repo-name) and [apparent repo
-name](/versions/7.6.1/external/overview#apparent-repo-name).
+to vendor, it accepts both [canonical repo name](/versions/7.6.1/external/overview#canonical-repo-name) and [apparent repo name](/versions/7.6.1/external/overview#apparent-repo-name).
 
 For example, running:
 
diff --git a/versions/7.6.1/help.mdx b/versions/7.6.1/help.mdx
index e60e034a..aa8e9b52 100644
--- a/versions/7.6.1/help.mdx
+++ b/versions/7.6.1/help.mdx
@@ -45,5 +45,4 @@ what level of support Bazel provides.
 
 ## File a bug {#file-bug}
 
-If you encounter a bug or want to request a feature, file a [GitHub
-Issue](https://github.com/bazelbuild/bazel/issues).
+If you encounter a bug or want to request a feature, file a [GitHub Issue](https://github.com/bazelbuild/bazel/issues).
diff --git a/versions/7.6.1/install/bazelisk.mdx b/versions/7.6.1/install/bazelisk.mdx
index 161ddb9e..38bf4c70 100644
--- a/versions/7.6.1/install/bazelisk.mdx
+++ b/versions/7.6.1/install/bazelisk.mdx
@@ -16,8 +16,7 @@ For more details, see
 ## Updating Bazel
 
 Bazel has a [backward compatibility policy](/versions/7.6.1/release/backward-compatibility)
-(see [guidance for rolling out incompatible
-changes](/versions/7.6.1/contribute/breaking-changes) if you
+(see [guidance for rolling out incompatible changes](/versions/7.6.1/contribute/breaking-changes) if you
 are the author of one). That page summarizes best practices on how to test and
 migrate your project with upcoming incompatible changes and how to provide
 feedback to the incompatible change authors.
diff --git a/versions/7.6.1/install/compile-source.mdx b/versions/7.6.1/install/compile-source.mdx
index 43cefc6d..32f0e203 100644
--- a/versions/7.6.1/install/compile-source.mdx
+++ b/versions/7.6.1/install/compile-source.mdx
@@ -45,8 +45,7 @@ it by typing `bazel` in a terminal.
 
 **Reason**: To build Bazel from a GitHub source tree, you need a pre-existing
 Bazel binary. You can install one from a package manager or download one from
-GitHub. See [Installing Bazel](/versions/7.6.1/install). (Or you can [build from
-scratch (bootstrap)](#bootstrap-bazel).)
+GitHub. See [Installing Bazel](/versions/7.6.1/install). (Or you can [build from scratch (bootstrap)](#bootstrap-bazel).)
 
 **Troubleshooting**:
 
@@ -233,8 +232,7 @@ For instructions for Unix-like systems, see
     ```
 
 *   **The Visual C++ compiler.** Install the Visual C++ compiler either as part
-    of Visual Studio 2015 or newer, or by installing the latest [Build Tools
-    for Visual Studio 2017](https://aka.ms/BuildTools).
+    of Visual Studio 2015 or newer, or by installing the latest [Build Tools for Visual Studio 2017](https://aka.ms/BuildTools).
 
 *   **JDK.** Version 21 is required.
 
diff --git a/versions/7.6.1/install/ide.mdx b/versions/7.6.1/install/ide.mdx
index 561d0e02..c42d95e9 100644
--- a/versions/7.6.1/install/ide.mdx
+++ b/versions/7.6.1/install/ide.mdx
@@ -38,10 +38,8 @@ To install, go to the IDE's plugin browser and search for `Bazel`.
 To manually install older versions, download the zip files from JetBrains'
 Plugin Repository and install the zip file from the IDE's plugin browser:
 
-*  [Android Studio
-   plugin](https://plugins.jetbrains.com/plugin/9185-android-studio-with-bazel)
-*  [IntelliJ
-   plugin](https://plugins.jetbrains.com/plugin/8609-intellij-with-bazel)
+*  [Android Studio plugin](https://plugins.jetbrains.com/plugin/9185-android-studio-with-bazel)
+*  [IntelliJ plugin](https://plugins.jetbrains.com/plugin/8609-intellij-with-bazel)
 *  [CLion plugin](https://plugins.jetbrains.com/plugin/9554-clion-with-bazel)
 
 ### Xcode {#xcode}
@@ -61,8 +59,7 @@ Features:
 * Starlark debugger for `.bzl` files during a build (set breakpoints, step
   through code, inspect variables, and so on)
 
-Find [the plugin on the Visual Studio
-marketplace](https://marketplace.visualstudio.com/items?itemName=BazelBuild.vscode-bazel).
+Find [the plugin on the Visual Studio marketplace](https://marketplace.visualstudio.com/items?itemName=BazelBuild.vscode-bazel).
 The plugin is [open source](https://github.com/bazelbuild/vscode-bazel).
 
 See also: [Autocomplete for Source Code](#autocomplete-for-source-code)
@@ -82,8 +79,7 @@ See also: [Autocomplete for Source Code](#autocomplete-for-source-code)
 
 ### Emacs {#emacs}
 
-See [`bazelbuild/bazel-emacs-mode` on
-GitHub](https://github.com/bazelbuild/emacs-bazel-mode)
+See [`bazelbuild/bazel-emacs-mode` on GitHub](https://github.com/bazelbuild/emacs-bazel-mode)
 
 See also: [Autocomplete for Source Code](#autocomplete-for-source-code)
 
@@ -115,6 +111,5 @@ tool for building Bazel targets when source files change.
 
 ## Building your own IDE plugin {#build-own-plugin}
 
-Read the [**IDE support** blog
-post](https://blog.bazel.build/2016/06/10/ide-support.html) to learn more about
+Read the [**IDE support** blog post](https://blog.bazel.build/2016/06/10/ide-support.html) to learn more about
 the Bazel APIs to use when building an IDE plugin.
diff --git a/versions/7.6.1/install/windows.mdx b/versions/7.6.1/install/windows.mdx
index aaf8cdea..ba4cfde3 100644
--- a/versions/7.6.1/install/windows.mdx
+++ b/versions/7.6.1/install/windows.mdx
@@ -31,8 +31,7 @@ To check your Windows version:
 
 Alternatively you can:
 
-*   [Download the Bazel binary (`bazel-version-windows-x86_64.exe`) from
- GitHub](https://github.com/bazelbuild/bazel/releases).
+*   [Download the Bazel binary (`bazel-version-windows-x86_64.exe`) from GitHub](https://github.com/bazelbuild/bazel/releases).
 *   [Install Bazel from Chocolatey](#chocolately)
 *   [Install Bazel from Scoop](#scoop)
 *   [Build Bazel from source](/versions/7.6.1/install/compile-source)
@@ -208,8 +207,7 @@ If that doesn't help:
     its dependencies, such as the MSYS2 shell. This will not install Visual C++
     though.
 
-See [Chocolatey installation and package maintenance
-guide](/versions/7.6.1/contribute/windows-chocolatey-maintenance) for more
+See [Chocolatey installation and package maintenance guide](/versions/7.6.1/contribute/windows-chocolatey-maintenance) for more
 information about the Chocolatey package.
 
 ### Using Scoop {#scoop}
@@ -226,8 +224,7 @@ information about the Chocolatey package.
     scoop install bazel
     ```
 
-See [Scoop installation and package maintenance
-guide](/versions/7.6.1/contribute/windows-scoop-maintenance) for more
+See [Scoop installation and package maintenance guide](/versions/7.6.1/contribute/windows-scoop-maintenance) for more
 information about the Scoop package.
 
 ### Build from source {#build-from-source}
diff --git a/versions/7.6.1/query/cquery.mdx b/versions/7.6.1/query/cquery.mdx
index 61996faa..19a445c6 100644
--- a/versions/7.6.1/query/cquery.mdx
+++ b/versions/7.6.1/query/cquery.mdx
@@ -6,8 +6,7 @@ title: ' Configurable Query (cquery)'
 [`select()`](/versions/7.6.1/docs/configurable-attributes) and build options' effects on the build
 graph.
 
-It achieves this by running over the results of Bazel's [analysis
-phase](/versions/7.6.1/extending/concepts#evaluation-model),
+It achieves this by running over the results of Bazel's [analysis phase](/versions/7.6.1/extending/concepts#evaluation-model),
 which integrates these effects. `query`, by contrast, runs over the results of
 Bazel's loading phase, before options are evaluated.
 
@@ -137,8 +136,7 @@ $ bazel cquery //foo --universe_scope=//foo,//genrule_with_foo_as_tool
 If you want to precisely declare which instance to query over, use
 the [`config`](#config) function.
 
-See `query`'s [target pattern
-documentation](/versions/7.6.1/query/language#target-patterns) for more information on target patterns.
+See `query`'s [target pattern documentation](/versions/7.6.1/query/language#target-patterns) for more information on target patterns.
 
 ## Functions {#functions}
 
diff --git a/versions/7.6.1/query/language.mdx b/versions/7.6.1/query/language.mdx
index f1ca2e60..db4d586d 100644
--- a/versions/7.6.1/query/language.mdx
+++ b/versions/7.6.1/query/language.mdx
@@ -1100,8 +1100,7 @@ is being used.
 
 ### On the ordering of results {#results-ordering}
 
-Although query expressions always follow the "[law of
-conservation of graph order](#graph-order)", _presenting_ the results may be done
+Although query expressions always follow the "[law of conservation of graph order](#graph-order)", _presenting_ the results may be done
 in either a dependency-ordered or unordered manner. This does **not**
 influence the targets in the result set or how the query is computed. It only
 affects how the results are printed to stdout. Moreover, nodes that are
@@ -1246,8 +1245,7 @@ and `maxrank` output formats print the labels of each
 target in the resulting graph, but instead of appearing in
 topological order, they appear in rank order, preceded by their
 rank number. These are unaffected by the result ordering
-`--[no]order_results` flag (see [notes on
-the ordering of results](#result-order)).
+`--[no]order_results` flag (see [notes on the ordering of results](#result-order)).
 
 There are two variants of this format: `minrank` ranks
 each node by the length of the shortest path from a root node to it.
diff --git a/versions/7.6.1/reference/be/android.mdx b/versions/7.6.1/reference/be/android.mdx
index 44c3165c..ce167ab9 100644
--- a/versions/7.6.1/reference/be/android.mdx
+++ b/versions/7.6.1/reference/be/android.mdx
@@ -355,8 +355,7 @@ writing Robolectric tests.
 #### Examples
 
 To use Robolectric with `android_local_test`, add
-[Robolectric's
-repository](https://github.com/robolectric/robolectric-bazel/tree/master/bazel) to your `WORKSPACE` file:
+[Robolectric's repository](https://github.com/robolectric/robolectric-bazel/tree/master/bazel) to your `WORKSPACE` file:
 
 ```
 http_archive(
diff --git a/versions/7.6.1/reference/be/functions.mdx b/versions/7.6.1/reference/be/functions.mdx
index 84be7609..be678155 100644
--- a/versions/7.6.1/reference/be/functions.mdx
+++ b/versions/7.6.1/reference/be/functions.mdx
@@ -250,8 +250,7 @@ There are several important limitations and caveats:
    package called "Foo.java" (which is allowed, though Bazel warns about it),
    then the consumer of the `glob()` will use the "Foo.java" rule
    (its outputs) instead of the "Foo.java" file. See
-   [GitHub
-   issue #10395](https://github.com/bazelbuild/bazel/issues/10395#issuecomment-583714657) for more details.
+   [GitHub issue #10395](https://github.com/bazelbuild/bazel/issues/10395#issuecomment-583714657) for more details.
 3. Globs may match files in subdirectories. And subdirectory names
    may be wildcarded. However...
 4. Labels are not allowed to cross the package boundary and glob does
diff --git a/versions/7.6.1/reference/be/java.mdx b/versions/7.6.1/reference/be/java.mdx
index 89311e5c..59395539 100644
--- a/versions/7.6.1/reference/be/java.mdx
+++ b/versions/7.6.1/reference/be/java.mdx
@@ -287,8 +287,7 @@ test code. The test runner's main method is invoked instead of the main class be
   [java\_binary](#java_binary) for more details.
 
 See the section on [java\_binary()](/versions/7.6.1/reference/be/java#java_binary_args) arguments. This rule also
-supports all [attributes common
-to all test rules (\*\_test)](/versions/7.6.1/reference/be/common-definitions#common-attributes-tests).
+supports all [attributes common to all test rules (\*\_test)](/versions/7.6.1/reference/be/common-definitions#common-attributes-tests).
 
 #### Examples
 
diff --git a/versions/7.6.1/reference/be/make-variables.mdx b/versions/7.6.1/reference/be/make-variables.mdx
index 66ee726d..c23f0b3d 100644
--- a/versions/7.6.1/reference/be/make-variables.mdx
+++ b/versions/7.6.1/reference/be/make-variables.mdx
@@ -19,8 +19,7 @@ targets, and *custom* variables, which are defined in dependency targets
 and only available to targets that depend on them.
 
 The reason for the term "Make" is historical: the syntax and semantics of
-these variables were originally intended to match [GNU
-Make](https://www.gnu.org/software/make/manual/html_node/Using-Variables.html).
+these variables were originally intended to match [GNU Make](https://www.gnu.org/software/make/manual/html_node/Using-Variables.html).
 
 ## Use
 
@@ -64,8 +63,7 @@ and look at the top output lines with capital letters.
 **Toolchain option variables**
 
 * `COMPILATION_MODE`:
-  `fastbuild`, `dbg`, or `opt`. ([more
-  details](https://bazel.build/versions/7.6.1/docs/user-manual#flag--compilation_mode))
+  `fastbuild`, `dbg`, or `opt`. ([more details](https://bazel.build/versions/7.6.1/docs/user-manual#flag--compilation_mode))
 
 **Path variables**
 
diff --git a/versions/7.6.1/reference/be/objective-c.mdx b/versions/7.6.1/reference/be/objective-c.mdx
index 80fd0435..80786056 100644
--- a/versions/7.6.1/reference/be/objective-c.mdx
+++ b/versions/7.6.1/reference/be/objective-c.mdx
@@ -21,8 +21,7 @@ j2objc_library(name, deps, compatible_with, deprecation, distribs, entry_classes
 
 This rule uses [J2ObjC](https://github.com/google/j2objc) to translate Java source
 files to Objective-C, which then can be used used as dependencies of objc\_library and objc\_binary
-rules. Detailed information about J2ObjC itself can be found at [the
-J2ObjC site](http://j2objc.org)
+rules. Detailed information about J2ObjC itself can be found at [the J2ObjC site](http://j2objc.org)
 
 Custom J2ObjC transpilation flags can be specified using the build flag
 `--j2objc_translation_flags` in the command line.
diff --git a/versions/7.6.1/reference/be/workspace.mdx b/versions/7.6.1/reference/be/workspace.mdx
index 356f8044..3078875e 100644
--- a/versions/7.6.1/reference/be/workspace.mdx
+++ b/versions/7.6.1/reference/be/workspace.mdx
@@ -25,8 +25,7 @@ bind(name, actual, compatible_with, deprecation, distribs, features, licenses, r
 
 *Warning: use of `bind()` is not recommended. See "[Consider removing bind](https://github.com/bazelbuild/bazel/issues/1952)" for a long
 discussion of its issues and alternatives. In particular, consider the use of
-[`repo_mapping`
-repository attributes](https://bazel.build/versions/7.6.1/rules/repository_rules#attributes).*
+[`repo_mapping` repository attributes](https://bazel.build/versions/7.6.1/rules/repository_rules#attributes).*
 
 *Warning: `select()` cannot be used in `bind()`. See the [Configurable Attributes FAQ](/versions/7.6.1/docs/configurable-attributes#bind-select) for
 details.*
@@ -114,8 +113,7 @@ local_repository(name, path, repo_mapping)
 ```
 
 Allows targets from a local directory to be bound. This means that the current repository can
-use targets defined in this other directory. See the [bind
-section](/versions/7.6.1/reference/be/workspace#bind_examples) for more details.
+use targets defined in this other directory. See the [bind section](/versions/7.6.1/reference/be/workspace#bind_examples) for more details.
 
 #### Examples
 
diff --git a/versions/7.6.1/reference/glossary.mdx b/versions/7.6.1/reference/glossary.mdx
index 93fab572..f8c04ab8 100644
--- a/versions/7.6.1/reference/glossary.mdx
+++ b/versions/7.6.1/reference/glossary.mdx
@@ -21,8 +21,7 @@ An in-memory graph of [actions](#action) and the [artifacts](#artifact) that
 these actions read and generate. The graph might include artifacts that exist as
 source files (for example, in the file system) as well as generated
 intermediate/final artifacts that are not mentioned in `BUILD` files. Produced
-during the [analysis phase](#analysis-phase) and used during the [execution
-phase](#execution-phase).
+during the [analysis phase](#analysis-phase) and used during the [execution phase](#execution-phase).
 
 ### Action graph query (aquery) {#action-graph-query}
 A [query](#query-concept) tool that can query over build [actions](#action).
@@ -37,8 +36,7 @@ invalidate individual actions deterministically.
 
 ### Analysis phase {#analysis-phase}
 The second phase of a build. Processes the [target graph](#target-graph)
-specified in [`BUILD` files](#build-file) to produce an in-memory [action
-graph](#action-graph) that determines the order of actions to run during the
+specified in [`BUILD` files](#build-file) to produce an in-memory [action graph](#action-graph) that determines the order of actions to run during the
 [execution phase](#execution-phase). This is the phase in which rule
 implementations are evaluated.
 
@@ -81,8 +79,7 @@ target's source files, dependencies, and custom compiler options. The particular
 attributes available for a given target depend on its rule type.
 
 ### .bazelrc {#bazelrc}
-Bazel’s configuration file used to change the default values for [startup
-flags](#startup-flags) and [command flags](#command-flags), and to define common
+Bazel’s configuration file used to change the default values for [startup flags](#startup-flags) and [command flags](#command-flags), and to define common
 groups of options that can then be set together on the Bazel command line using
 a `--config` flag. Bazel can combine settings from multiple bazelrc files
 (systemwide, per-workspace, per-user, or from a custom location), and a
@@ -108,8 +105,7 @@ directory.
 
 ### .bzl File {#bzl-file}
 A file that defines rules, [macros](#macro), and constants written in
-[Starlark](#starlark). These can then be imported into [`BUILD`
-files](#build-file) using the `load()` function.
+[Starlark](#starlark). These can then be imported into [`BUILD` files](#build-file) using the `load()` function.
 
 {/* TODO: ### Build event protocol */}
 
@@ -117,8 +113,7 @@ files](#build-file) using the `load()` function.
 
 ### Build graph {#build-graph}
 The dependency graph that Bazel constructs and traverses to perform a build.
-Includes nodes like [targets](#target), [configured
-targets](#configured-target), [actions](#action), and [artifacts](#artifact). A
+Includes nodes like [targets](#target), [configured targets](#configured-target), [actions](#action), and [artifacts](#artifact). A
 build is considered complete when all [artifacts](#artifact) on which a set of
 requested targets depend are verified as up-to-date.
 
@@ -158,8 +153,7 @@ graphs and restart the [analysis phase](#analysis-phase).
 ### Configuration {#configuration}
 Information outside of [rule](#rule) definitions that impacts how rules generate
 [actions](#action). Every build has at least one configuration specifying the
-target platform, action environment variables, and command-line [build
-flags](#command-flags). [Transitions](#transition) may create additional
+target platform, action environment variables, and command-line [build flags](#command-flags). [Transitions](#transition) may create additional
 configurations, such as for host tools or cross-compilation.
 
 **See also:** [Configurations](/versions/7.6.1/extending/rules#configurations)
@@ -174,8 +168,7 @@ configuration of `//:c` because changing `--javacopt` unnecessarily breaks C++
 build cacheability.
 
 ### Configured query (cquery) {#configured-query}
-A [query](#query-concept) tool that queries over [configured
-targets](#configured-target) (after the [analysis phase](#analysis-phase)
+A [query](#query-concept) tool that queries over [configured targets](#configured-target) (after the [analysis phase](#analysis-phase)
 completes). This means `select()` and [build flags](#command-flags) (such as
 `--platforms`) are accurately reflected in the results.
 
@@ -191,8 +184,7 @@ build, it has two configured targets: `` and ``.
 ### Correctness {#correctness}
 A build is correct when its output faithfully reflects the state of its
 transitive inputs. To achieve correct builds, Bazel strives to be
-[hermetic](#hermeticity), reproducible, and making [build
-analysis](#analysis-phase) and [action execution](#execution-phase)
+[hermetic](#hermeticity), reproducible, and making [build analysis](#analysis-phase) and [action execution](#execution-phase)
 deterministic.
 
 ### Dependency {#dependency}
@@ -234,8 +226,7 @@ compilation). A dynamic execution strategy can provide the best possible
 incremental and clean build times.
 
 ### Execution phase {#execution-phase}
-The third phase of a build. Executes the [actions](#action) in the [action
-graph](#action-graph) created during the [analysis phase](#analysis-phase).
+The third phase of a build. Executes the [actions](#action) in the [action graph](#action-graph) created during the [analysis phase](#analysis-phase).
 These actions invoke executables (compilers, scripts) to read and write
 [artifacts](#artifact). *Spawn strategies* control how these actions are
 executed: locally, remotely, dynamically, sandboxed, docker, and so on.
@@ -285,8 +276,7 @@ syntax may be omitted.
 The first phase of a build where Bazel executes [`BUILD` files](#build-file) to
 create [packages](#package). [Macros](#macro) and certain functions like
 `glob()` are evaluated in this phase. Interleaved with the second phase of the
-build, the [analysis phase](#analysis-phase), to build up a [target
-graph](#target-graph).
+build, the [analysis phase](#analysis-phase), to build up a [target graph](#target-graph).
 
 ### Macro {#macro}
 A mechanism to compose multiple [rule](#rule) target declarations together under
@@ -321,8 +311,7 @@ Module metadata is hosted in Bazel registries.
 
 ### Module Extension {#module-extension}
 A piece of logic that can be run to generate [repos](#repository) by reading
-inputs from across the [module](#module) dependency graph and invoking [repo
-rules](#repository-rule). Module extensions have capabilities similar to repo
+inputs from across the [module](#module) dependency graph and invoking [repo rules](#repository-rule). Module extensions have capabilities similar to repo
 rules, allowing them to access the internet, perform file I/O, and so on.
 
 **See also:** [Module extensions](/versions/7.6.1/external/extension)
@@ -335,8 +324,7 @@ example, `native.cc_library` or `native.java_library`). User-defined rules
 
 ### Output base {#output-base}
 A [workspace](#workspace)-specific directory to store Bazel output files. Used
-to separate outputs from the *workspace*'s source tree (the [main
-repo](#repository)). Located in the [output user root](#output-user-root).
+to separate outputs from the *workspace*'s source tree (the [main repo](#repository)). Located in the [output user root](#output-user-root).
 
 ### Output groups {#output-groups}
 A group of files that is expected to be built when Bazel finishes building a
@@ -391,8 +379,7 @@ query variants: [query](#query-command), [cquery](#configured-query), and
 [aquery](#action-graph-query).
 
 ### query (command) {#query-command}
-A [query](#query-concept) tool that operates over the build's post-[loading
-phase](#loading-phase) [target graph](#target-graph). This is relatively fast,
+A [query](#query-concept) tool that operates over the build's post-[loading phase](#loading-phase) [target graph](#target-graph). This is relatively fast,
 but can't analyze the effects of `select()`, [build flags](#command-flags),
 [artifacts](#artifact), or build [actions](#action).
 
@@ -410,8 +397,7 @@ repo; multiple such files can coexist in a directory.
 The *main repo* is the repo in which the current Bazel command is being run.
 
 *External repos* are defined by specifying [modules](#module) in `MODULE.bazel`
-files, or invoking [repo rules](#repository-rule) in [module
-extensions](#module-extension). They can be fetched on demand to a predetermined
+files, or invoking [repo rules](#repository-rule) in [module extensions](#module-extension). They can be fetched on demand to a predetermined
 "magical" location on disk.
 
 Each repo has a unique, constant *canonical* name, and potentially different
@@ -422,8 +408,7 @@ Each repo has a unique, constant *canonical* name, and potentially different
 ### Repository cache {#repo-cache}
 A shared content-addressable cache of files downloaded by Bazel for builds,
 shareable across [workspaces](#workspace). Enables offline builds after the
-initial download. Commonly used to cache files downloaded through [repository
-rules](#repository-rule) like `http_archive` and repository rule APIs like
+initial download. Commonly used to cache files downloaded through [repository rules](#repository-rule) like `http_archive` and repository rule APIs like
 `repository_ctx.download`. Files are cached only if their SHA-256 checksums are
 specified for the download.
 
@@ -457,8 +442,7 @@ Rules are instantiated to produce rule targets in the
 [loading phase](#loading-phase). In the [analysis phase](#analysis-phase) rule
 targets communicate information to their downstream dependencies in the form of
 [providers](#provider), and register [actions](#action) describing how to
-generate their output artifacts. These actions are run in the [execution
-phase](#execution-phase).
+generate their output artifacts. These actions are run in the [execution phase](#execution-phase).
 
 Note: Historically the term "rule" has been used to refer to a rule target.
 This usage was inherited from tools like Make, but causes confusion and should
@@ -502,8 +486,7 @@ support the stamp attribute.
 ### Starlark {#starlark}
 The extension language for writing [rules](/versions/7.6.1/extending/rules) and [macros](#macro). A
 restricted subset of Python (syntactically and grammatically) aimed for the
-purpose of configuration, and for better performance. Uses the [`.bzl`
-file](#bzl-file) extension. [`BUILD` files](#build-file) use an even more
+purpose of configuration, and for better performance. Uses the [`.bzl` file](#bzl-file) extension. [`BUILD` files](#build-file) use an even more
 restricted version of Starlark (such as no `def` function definitions), formerly
 known as Skylark.
 
@@ -525,8 +508,7 @@ An object that is defined in a [`BUILD` file](#build-file) and identified by a
 [label](#label). Targets represent the buildable units of a workspace from
 the perspective of the end user.
 
-A target that is declared by instantiating a [rule](#rule) is called a [rule
-target](#rule-target). Depending on the rule, these may be runnable (like
+A target that is declared by instantiating a [rule](#rule) is called a [rule target](#rule-target). Depending on the rule, these may be runnable (like
 `cc_binary`) or testable (like `cc_test`). Rule targets typically depend on
 other targets via their [attributes](#attribute) (such as `deps`); these
 dependencies form the basis of the [target graph](#target-graph).
@@ -537,14 +519,11 @@ within a `BUILD` file. As a special case, the `BUILD` file of any package is
 always considered a source file target in that package.
 
 Targets are discovered during the [loading phase](#loading-phase). During the
-[analysis phase](#analysis-phase), targets are associated with [build
-configurations](#configuration) to form [configured
-targets](#configured-target).
+[analysis phase](#analysis-phase), targets are associated with [build configurations](#configuration) to form [configured targets](#configured-target).
 
 ### Target graph {#target-graph}
 An in-memory graph of [targets](#target) and their dependencies. Produced during
-the [loading phase](#loading-phase) and used as an input to the [analysis
-phase](#analysis-phase).
+the [loading phase](#loading-phase) and used as an input to the [analysis phase](#analysis-phase).
 
 ### Target pattern {#target-pattern}
 A way to specify a group of [targets](#target) on the command line. Commonly
@@ -557,8 +536,7 @@ packages recursively from the root of the [workspace](#workspace).
 Rule [targets](#target) instantiated from test rules, and therefore contains a
 test executable. A return code of zero from the completion of the executable
 indicates test success. The exact contract between Bazel and tests (such as test
-environment variables, test result collection methods) is specified in the [Test
-Encyclopedia](/versions/7.6.1/reference/test-encyclopedia).
+environment variables, test result collection methods) is specified in the [Test Encyclopedia](/versions/7.6.1/reference/test-encyclopedia).
 
 ### Toolchain {#toolchain}
 A set of tools to build outputs for a language. Typically, a toolchain includes
@@ -572,8 +550,7 @@ A build [target](#target) is top-level if it’s requested on the Bazel command
 line. For example, if `//:foo` depends on `//:bar`, and `bazel build //:foo` is
 called, then for this build, `//:foo` is top-level, and `//:bar` isn’t
 top-level, although both targets will need to be built. An important difference
-between top-level and non-top-level targets is that [command
-flags](#command-flags) set on the Bazel command line (or via
+between top-level and non-top-level targets is that [command flags](#command-flags) set on the Bazel command line (or via
 [.bazelrc](#bazelrc)) will set the [configuration](#configuration) for top-level
 targets, but might be modified by a [transition](#transition) for non-top-level
 targets.
@@ -604,8 +581,7 @@ or `.bzl` file may load a given `.bzl` file. Without context, usually
 **See also:** [Visibility documentation](/versions/7.6.1/concepts/visibility)
 
 ### Workspace {#workspace}
-The environment shared by all Bazel commands run from the same [main
-repository](#repository).
+The environment shared by all Bazel commands run from the same [main repository](#repository).
 
 Note that historically the concepts of "repository" and "workspace" have been
 conflated; the term "workspace" has often been used to refer to the main
diff --git a/versions/7.6.1/release/backward-compatibility.mdx b/versions/7.6.1/release/backward-compatibility.mdx
index ae0b831b..bb8183ea 100644
--- a/versions/7.6.1/release/backward-compatibility.mdx
+++ b/versions/7.6.1/release/backward-compatibility.mdx
@@ -6,11 +6,9 @@ This page provides information about how to handle backward compatibility,
 including migrating from one release to another and how to communicate
 incompatible changes.
 
-Bazel is evolving. Minor versions released as part of an [LTS major
-version](/versions/7.6.1/release#bazel-versioning) are fully backward-compatible. New major LTS
+Bazel is evolving. Minor versions released as part of an [LTS major version](/versions/7.6.1/release#bazel-versioning) are fully backward-compatible. New major LTS
 releases may contain incompatible changes that require some migration effort.
-For more information about Bazel's release model, please check out the [Release
-Model](/versions/7.6.1/release) page.
+For more information about Bazel's release model, please check out the [Release Model](/versions/7.6.1/release) page.
 
 ## Summary {#summary}
 
@@ -59,8 +57,7 @@ available.
 ## Communicating incompatible changes {#communicating-incompatible-changes}
 
 The primary source of information about incompatible changes are GitHub issues
-marked with an ["incompatible-change"
-label](https://github.com/bazelbuild/bazel/issues?q=label%3Aincompatible-change).
+marked with an ["incompatible-change" label](https://github.com/bazelbuild/bazel/issues?q=label%3Aincompatible-change).
 
 For every incompatible change, the issue specifies the following:
 
diff --git a/versions/7.6.1/release/index.mdx b/versions/7.6.1/release/index.mdx
index d3dc9925..7abbb747 100644
--- a/versions/7.6.1/release/index.mdx
+++ b/versions/7.6.1/release/index.mdx
@@ -2,16 +2,14 @@
 title: 'Release Model'
 ---
 
-As announced in [the original blog
-post](https://blog.bazel.build/2020/11/10/long-term-support-release.html), Bazel
+As announced in [the original blog post](https://blog.bazel.build/2020/11/10/long-term-support-release.html), Bazel
 4.0 and higher versions provides support for two release tracks: rolling
 releases and long term support (LTS) releases. This page covers the latest
 information about Bazel's release model.
 
 ## Release versioning {#bazel-versioning}
 
-Bazel uses a _major.minor.patch_ [Semantic
-Versioning](https://semver.org/) scheme.
+Bazel uses a _major.minor.patch_ [Semantic Versioning](https://semver.org/) scheme.
 
 *   A _major release_ contains features that are not backward compatible with
     the previous release. Each major Bazel version is an LTS release.
@@ -54,8 +52,7 @@ Bazel regularly publish releases for two release tracks.
     release.
 *   Rolling releases can ship incompatible changes. Incompatible flags are
     recommended for major breaking changes, rolling out incompatible changes
-    should follow our [backward compatibility
-    policy](/versions/7.6.1/release/backward-compatibility).
+    should follow our [backward compatibility policy](/versions/7.6.1/release/backward-compatibility).
 
 ### LTS releases {#lts-releases}
 
@@ -71,8 +68,7 @@ Bazel regularly publish releases for two release tracks.
 *   A Bazel LTS release enters the Deprecated stage after being in ​​the
     Maintenance stage for 2 years.
 
-For planned releases, please check our [release
-issues](https://github.com/bazelbuild/bazel/issues?q=is%3Aopen+is%3Aissue+label%3Arelease)
+For planned releases, please check our [release issues](https://github.com/bazelbuild/bazel/issues?q=is%3Aopen+is%3Aissue+label%3Arelease)
 on Github.
 
 ## Support matrix {#support-matrix}
@@ -84,8 +80,7 @@ on Github.
 | Bazel 5 | Maintenance | [5.4.1](https://github.com/bazelbuild/bazel/releases/tag/5.4.1) | Jan 2025 |
 | Bazel 4 | Maintenance | [4.2.4](https://github.com/bazelbuild/bazel/releases/tag/4.2.4) | Jan 2024 |
 
-All Bazel releases can be found on the [release
-page](https://github.com/bazelbuild/bazel/releases) on GitHub.
+All Bazel releases can be found on the [release page](https://github.com/bazelbuild/bazel/releases) on GitHub.
 
 Note: Bazel version older than Bazel 4 are no longer supported, Bazel users are
 recommended to upgrade to the latest LTS release or use rolling releases if you
@@ -117,8 +112,7 @@ For LTS releases, the procedure and policies below are followed:
 1.  Identify release blockers and fix issues found on the release branch.
     *   The release branch is tested with the same test suite in
         [postsubmit](https://buildkite.com/bazel/bazel-bazel) and
-        [downstream test pipeline]
-        (https://buildkite.com/bazel/bazel-at-head-plus-downstream)
+        [downstream test pipeline](https://buildkite.com/bazel/bazel-at-head-plus-downstream)
         on Bazel CI. The Bazel team monitors testing results of the release
         branch and fixes any regressions found.
 1.  Create a new release candidate from the release branch when all known
@@ -170,5 +164,4 @@ feature.
 ## Rule compatibility {#rule-compatibility}
 
 If you are a rule authors and want to maintain compatibility with different
-Bazel versions, please check out the [Rule
-Compatibility](/versions/7.6.1/release/rule-compatibility) page.
\ No newline at end of file
+Bazel versions, please check out the [Rule Compatibility](/versions/7.6.1/release/rule-compatibility) page.
\ No newline at end of file
diff --git a/versions/7.6.1/release/rule-compatibility.mdx b/versions/7.6.1/release/rule-compatibility.mdx
index f7daa8fe..d34fc01b 100644
--- a/versions/7.6.1/release/rule-compatibility.mdx
+++ b/versions/7.6.1/release/rule-compatibility.mdx
@@ -53,18 +53,15 @@ Bazel LTS release.
 As Bazel rules authors, you can ensure a manageable migration process for users
 by following these best practices:
 
-1.  The rule should follow [Semantic
-    Versioning](https://semver.org/): minor versions of the same
+1.  The rule should follow [Semantic Versioning](https://semver.org/): minor versions of the same
     major version are backward compatible.
 1.  The rule at HEAD should be compatible with the latest Bazel LTS release.
 1.  The rule at HEAD should be compatible with Bazel at HEAD. To achieve this,
     you can
     *   Set up your own CI testing with Bazel at HEAD
-    *   Add your project to [Bazel downstream
-        testing](https://github.com/bazelbuild/continuous-integration/blob/master/docs/downstream-testing.md);
+    *   Add your project to [Bazel downstream testing](https://github.com/bazelbuild/continuous-integration/blob/master/docs/downstream-testing.md);
         the Bazel team files issues to your project if breaking changes in Bazel
-        affect your project, and you must follow our [downstream project
-        policies](https://github.com/bazelbuild/continuous-integration/blob/master/docs/downstream-testing.md#downstream-project-policies)
+        affect your project, and you must follow our [downstream project policies](https://github.com/bazelbuild/continuous-integration/blob/master/docs/downstream-testing.md#downstream-project-policies)
         to address issues timely.
 1.  The latest major version of the rule must be compatible with the latest
     Bazel LTS release.
diff --git a/versions/7.6.1/remote/bep-glossary.mdx b/versions/7.6.1/remote/bep-glossary.mdx
index 128352c1..6adbf07d 100644
--- a/versions/7.6.1/remote/bep-glossary.mdx
+++ b/versions/7.6.1/remote/bep-glossary.mdx
@@ -411,5 +411,4 @@ workspace, such as the execution root.
 
 ## WorkspaceStatus {#workspacestatus}
 
-A single `WorkspaceStatus` event contains the result of the [workspace status
-command](/versions/7.6.1/docs/user-manual#workspace-status).
+A single `WorkspaceStatus` event contains the result of the [workspace status command](/versions/7.6.1/docs/user-manual#workspace-status).
diff --git a/versions/7.6.1/remote/bep.mdx b/versions/7.6.1/remote/bep.mdx
index 72cae7c3..85ebca18 100644
--- a/versions/7.6.1/remote/bep.mdx
+++ b/versions/7.6.1/remote/bep.mdx
@@ -2,14 +2,12 @@
 title: 'Build Event Protocol'
 ---
 
-The [Build Event
-Protocol](https://github.com/bazelbuild/bazel/blob/master/src/main/java/com/google/devtools/build/lib/buildeventstream/proto/build_event_stream.proto)
+The [Build Event Protocol](https://github.com/bazelbuild/bazel/blob/master/src/main/java/com/google/devtools/build/lib/buildeventstream/proto/build_event_stream.proto)
 (BEP) allows third-party programs to gain insight into a Bazel invocation. For
 example, you could use the BEP to gather information for an IDE
 plugin or a dashboard that displays build results.
 
-The protocol is a set of [protocol
-buffer](https://developers.google.com/protocol-buffers/) messages with some
+The protocol is a set of [protocol buffer](https://developers.google.com/protocol-buffers/) messages with some
 semantics defined on top of it. It includes information about build and test
 results, build progress, the build configuration and much more. The BEP is
 intended to be consumed programmatically and makes parsing Bazel’s
@@ -20,16 +18,13 @@ build event is a protocol buffer message consisting of a build event identifier,
 a set of child event identifiers, and a payload.
 
 *  __Build Event Identifier:__ Depending on the kind of build event, it might be
-an [opaque
-string](https://github.com/bazelbuild/bazel/blob/16a107d/src/main/java/com/google/devtools/build/lib/buildeventstream/proto/build_event_stream.proto#L91)
-or [structured
-information](https://github.com/bazelbuild/bazel/blob/16a107d/src/main/java/com/google/devtools/build/lib/buildeventstream/proto/build_event_stream.proto#L123)
+an [opaque string](https://github.com/bazelbuild/bazel/blob/16a107d/src/main/java/com/google/devtools/build/lib/buildeventstream/proto/build_event_stream.proto#L91)
+or [structured information](https://github.com/bazelbuild/bazel/blob/16a107d/src/main/java/com/google/devtools/build/lib/buildeventstream/proto/build_event_stream.proto#L123)
 revealing more about the build event. A build event identifier is unique within
 a build.
 
 *  __Children:__ A build event may announce other build events, by including
-their build event identifiers in its [children
-field](https://github.com/bazelbuild/bazel/blob/16a107d/src/main/java/com/google/devtools/build/lib/buildeventstream/proto/build_event_stream.proto#L469).
+their build event identifiers in its [children field](https://github.com/bazelbuild/bazel/blob/16a107d/src/main/java/com/google/devtools/build/lib/buildeventstream/proto/build_event_stream.proto#L469).
 For example, the `PatternExpanded` build event announces the targets it expands
 to as children. The protocol guarantees that all events, except for the first
 event, are announced by a previous event.
@@ -91,8 +86,7 @@ human-readable formats, such as text and JSON:
 
 ## Build Event Service {#build-event-service}
 
-The [Build Event
-Service](https://github.com/googleapis/googleapis/blob/master/google/devtools/build/v1/publish_build_event.proto)
+The [Build Event Service](https://github.com/googleapis/googleapis/blob/master/google/devtools/build/v1/publish_build_event.proto)
 Protocol is a generic [gRPC](https://www.grpc.io) service for publishing build events. The Build Event
 Service protocol is independent of the BEP and treats BEP events as opaque bytes.
 Bazel ships with a gRPC client implementation of the Build Event Service protocol that
@@ -137,8 +131,7 @@ For a description of each of these flags, see the
 The BEP typically contains many references to log files (test.log, test.xml,
 etc. ) stored on the machine where Bazel is running. A remote BES server
 typically can't access these files as they are on different machines. A way to
-work around this issue is to use Bazel with [remote
-caching](/versions/7.6.1/remote/caching).
+work around this issue is to use Bazel with [remote caching](/versions/7.6.1/remote/caching).
 Bazel will upload all output files to the remote cache (including files
 referenced in the BEP) and the BES server can then fetch the referenced files
 from the cache.
diff --git a/versions/7.6.1/remote/cache-local.mdx b/versions/7.6.1/remote/cache-local.mdx
index f91577a4..8f08c4dc 100644
--- a/versions/7.6.1/remote/cache-local.mdx
+++ b/versions/7.6.1/remote/cache-local.mdx
@@ -18,8 +18,7 @@ execution. However, local execution presents some additional challenges.
 ## Checking your cache hit rate {#cache-hits}
 
 Successful remote cache hits will show up in the status line, similar to
-[Cache Hits rate with Remote
-Execution](/versions/7.6.1/remote/cache-remote#check-cache-hits).
+[Cache Hits rate with Remote Execution](/versions/7.6.1/remote/cache-remote#check-cache-hits).
 
 In the standard output of your Bazel run, you will see something like the
 following:
@@ -66,8 +65,7 @@ the steps in this section.
    message you see does not give you enough information, try adding
    `--verbose_failures`.
 
-2. Follow the steps from [Troubleshooting cache hits for remote
-   execution](/versions/7.6.1/remote/cache-remote#troubleshooting_cache_hits) to
+2. Follow the steps from [Troubleshooting cache hits for remote execution](/versions/7.6.1/remote/cache-remote#troubleshooting_cache_hits) to
    ensure that your cache-writing Bazel invocations are able to get cache hits
    on the same machine and across machines.
 
@@ -81,7 +79,6 @@ the steps in this section.
    b. Ensure your cache-reading Bazel invocations build the same targets as the
       cache-writing Bazel invocations.
 
-   c. Follow the same steps as to [ensure caching across
-      machines](/versions/7.6.1/remote/cache-remote#caching-across-machines),
+   c. Follow the same steps as to [ensure caching across machines](/versions/7.6.1/remote/cache-remote#caching-across-machines),
       to ensure caching from your cache-writing Bazel invocation to your
       cache-reading Bazel invocation.
diff --git a/versions/7.6.1/remote/caching.mdx b/versions/7.6.1/remote/caching.mdx
index 587c3d9a..6abf7ed1 100644
--- a/versions/7.6.1/remote/caching.mdx
+++ b/versions/7.6.1/remote/caching.mdx
@@ -308,8 +308,7 @@ or for the age of individual cache entries. Bazel will automatically garbage
 collect the disk cache while idling between builds; the idle timer can be set
 with `--experimental_disk_cache_gc_idle_delay` (defaulting to 5 minutes).
 
-As an alternative to automatic garbage collection, we also provide a [tool](
-https://github.com/bazelbuild/bazel/tree/master/src/tools/diskcache) to run a
+As an alternative to automatic garbage collection, we also provide a [tool](https://github.com/bazelbuild/bazel/tree/master/src/tools/diskcache) to run a
 garbage collection on demand.
 
 ## Known issues {#known-issues}
diff --git a/versions/7.6.1/remote/dynamic.mdx b/versions/7.6.1/remote/dynamic.mdx
index 17990a2e..791684d3 100644
--- a/versions/7.6.1/remote/dynamic.mdx
+++ b/versions/7.6.1/remote/dynamic.mdx
@@ -12,8 +12,7 @@ alike.
 This page describes how to enable, tune, and debug dynamic execution. If you
 have both local and remote execution set up and are trying to adjust Bazel
 settings for better performance, this page is for you. If you don't already have
-remote execution set up, go to the Bazel [Remote Execution
-Overview](/versions/7.6.1/remote/rbe) first.
+remote execution set up, go to the Bazel [Remote Execution Overview](/versions/7.6.1/remote/rbe) first.
 
 ## Enabling dynamic execution? {#enabling-dynamic-execution}
 
@@ -44,14 +43,12 @@ are likely. The default value is 1000ms, but should be tuned to being just a bit
 longer than cache hits usually take. The actual time depends both on the remote
 system and on how long a round-trip takes. Usually, the value will be the same
 for all users of a given remote system, unless some of them are far enough away
-to add roundtrip latency. You can use the [Bazel profiling
-features](/versions/7.6.1/rules/performance#performance-profiling) to look at how long typical
+to add roundtrip latency. You can use the [Bazel profiling features](/versions/7.6.1/rules/performance#performance-profiling) to look at how long typical
 cache hits take.
 
 Dynamic execution can be used with local sandboxed strategy as well as with
 [persistent workers](/versions/7.6.1/remote/persistent). Persistent workers will automatically
-run with sandboxing when used with dynamic execution, and cannot use [multiplex
-workers](/versions/7.6.1/remote/multiplex). On Darwin and Windows systems, the sandboxed
+run with sandboxing when used with dynamic execution, and cannot use [multiplex workers](/versions/7.6.1/remote/multiplex). On Darwin and Windows systems, the sandboxed
 strategy can be slow; you can pass `--reuse_sandbox_directories` to reduce
 overhead of creating sandboxes on these systems.
 
@@ -67,8 +64,7 @@ entire action fails. This is an intentional choice to prevent differences
 between local and remote execution from going unnoticed.
 
 For more background on how dynamic execution and its locking works, see Julio
-Merino's excellent [blog
-posts](https://jmmv.dev/series/bazel-dynamic-execution/)
+Merino's excellent [blog posts](https://jmmv.dev/series/bazel-dynamic-execution/)
 
 ## When should I use dynamic execution? {#when-to-use}
 
diff --git a/versions/7.6.1/remote/persistent.mdx b/versions/7.6.1/remote/persistent.mdx
index f295cbee..c14d4fa1 100644
--- a/versions/7.6.1/remote/persistent.mdx
+++ b/versions/7.6.1/remote/persistent.mdx
@@ -264,7 +264,6 @@ For more information on persistent workers, see:
 *   [Original persistent workers blog post](https://blog.bazel.build/2015/12/10/java-workers.html)
 *   [Haskell implementation description](https://www.tweag.io/blog/2019-09-25-bazel-ghc-persistent-worker-internship/)
 *   [Blog post by Mike Morearty](https://medium.com/@mmorearty/how-to-create-a-persistent-worker-for-bazel-7738bba2cabb)
-*   [Front End Development with Bazel: Angular/TypeScript and Persistent Workers
-    w/ Asana](https://www.youtube.com/watch?v=0pgERydGyqo)
+*   [Front End Development with Bazel: Angular/TypeScript and Persistent Workers w/ Asana](https://www.youtube.com/watch?v=0pgERydGyqo)
 *   [Bazel strategies explained](https://jmmv.dev/2019/12/bazel-strategies.html)
 *   [Informative worker strategy discussion on the bazel-discuss mailing list](https://groups.google.com/forum/#!msg/bazel-discuss/oAEnuhYOPm8/ol7hf4KWJgAJ)
diff --git a/versions/7.6.1/remote/rules.mdx b/versions/7.6.1/remote/rules.mdx
index b42b1f9e..2ddc704d 100644
--- a/versions/7.6.1/remote/rules.mdx
+++ b/versions/7.6.1/remote/rules.mdx
@@ -54,8 +54,7 @@ variables that may not be set to equivalent values (or at all) in the remote
 execution environment.
 
 Toolchain rules currently exist for Bazel build and test rules for
-[Scala](https://github.com/bazelbuild/rules_scala/blob/master/scala/scala_toolch
-ain.bzl),
+[Scala](https://github.com/bazelbuild/rules_scala/blob/master/scala/scala_toolch ain.bzl),
 [Rust](https://github.com/bazelbuild/rules_rust/blob/main/rust/toolchain.bzl),
 and [Go](https://github.com/bazelbuild/rules_go/blob/master/go/toolchains.rst),
 and new toolchain rules are under way for other languages and tools such as
diff --git a/versions/7.6.1/remote/workspace.mdx b/versions/7.6.1/remote/workspace.mdx
index add704c1..2e6e5c4f 100644
--- a/versions/7.6.1/remote/workspace.mdx
+++ b/versions/7.6.1/remote/workspace.mdx
@@ -11,8 +11,7 @@ on the host machine. If your workspace rules access information about the
 host machine for use during execution, your build is likely to break due to
 incompatibilities between the environments.
 
-As part of [adapting Bazel rules for remote
-execution](/versions/7.6.1/remote/rules), you need to find such workspace rules
+As part of [adapting Bazel rules for remote execution](/versions/7.6.1/remote/rules), you need to find such workspace rules
 and fix them. This page describes how to find potentially problematic workspace
 rules using the workspace log.
 
diff --git a/versions/7.6.1/rules/deploying.mdx b/versions/7.6.1/rules/deploying.mdx
index b51c6c94..e6395e2e 100644
--- a/versions/7.6.1/rules/deploying.mdx
+++ b/versions/7.6.1/rules/deploying.mdx
@@ -91,8 +91,7 @@ At the top level, there should be a `README` that contains (at least) what
 users will need to copy-paste into their `WORKSPACE` file to use your rule.
 In general, this will be a `http_archive` pointing to your GitHub release and
 a macro call that downloads/configures any tools your rule needs. For example,
-for the [Go
-rules](https://github.com/bazelbuild/rules_go#setup), this
+for the [Go rules](https://github.com/bazelbuild/rules_go#setup), this
 looks like:
 
 ```
diff --git a/versions/7.6.1/rules/language.mdx b/versions/7.6.1/rules/language.mdx
index 50be47e6..e03a5fc1 100644
--- a/versions/7.6.1/rules/language.mdx
+++ b/versions/7.6.1/rules/language.mdx
@@ -93,10 +93,8 @@ values returned by rules are immutable.
 `BUILD` files register targets via making calls to rules. `.bzl` files provide
 definitions for constants, rules, macros, and functions.
 
-[Native functions](/versions/7.6.1/reference/be/functions) and [native rules](
-/reference/be/overview#language-specific-native-rules) are global symbols in
-`BUILD` files. `bzl` files need to load them using the [`native` module](
-/rules/lib/toplevel/native).
+[Native functions](/versions/7.6.1/reference/be/functions) and [native rules](/reference/be/overview#language-specific-native-rules) are global symbols in
+`BUILD` files. `bzl` files need to load them using the [`native` module](/rules/lib/toplevel/native).
 
 There are two syntactic restrictions in `BUILD` files: 1) declaring functions is
 illegal, and 2) `*args` and `**kwargs` arguments are not allowed.
diff --git a/versions/7.6.1/rules/verbs-tutorial.mdx b/versions/7.6.1/rules/verbs-tutorial.mdx
index 9eef6f5d..4a73918c 100644
--- a/versions/7.6.1/rules/verbs-tutorial.mdx
+++ b/versions/7.6.1/rules/verbs-tutorial.mdx
@@ -49,8 +49,7 @@ This pattern can also be seen in the Angular project. The
 produces two targets. The first is a standard `nodejs_test` target which compares
 some generated output against a "golden" file (that is, a file containing the
 expected output). This can be built and run with a normal `bazel
-test` invocation. In `angular-cli`, you can run [one such
-target](https://github.com/angular/angular-cli/blob/e1269cb520871ee29b1a4eec6e6c0e4a94f0b5fc/etc/api/BUILD)
+test` invocation. In `angular-cli`, you can run [one such target](https://github.com/angular/angular-cli/blob/e1269cb520871ee29b1a4eec6e6c0e4a94f0b5fc/etc/api/BUILD)
 with `bazel test //etc/api:angular_devkit_core_api`.
 
 Over time, this golden file may need to be updated for legitimate reasons.
diff --git a/versions/7.6.1/run/build.mdx b/versions/7.6.1/run/build.mdx
index 67767890..f4411bd4 100644
--- a/versions/7.6.1/run/build.mdx
+++ b/versions/7.6.1/run/build.mdx
@@ -575,8 +575,7 @@ Note: Hermeticity means that the action only uses its declared input
 files and no other files in the filesystem, and it only produces its declared
 output files. See [Hermeticity](/versions/7.6.1/basics/hermeticity) for more details.
 
-On some platforms such as [Google Kubernetes
-Engine](https://cloud.google.com/kubernetes-engine/) cluster nodes or Debian,
+On some platforms such as [Google Kubernetes Engine](https://cloud.google.com/kubernetes-engine/) cluster nodes or Debian,
 user namespaces are deactivated by default due to security
 concerns. This can be checked by looking at the file
 `/proc/sys/kernel/unprivileged_userns_clone`: if it exists and contains a 0,
diff --git a/versions/7.6.1/start/android-app.mdx b/versions/7.6.1/start/android-app.mdx
index 8957c420..882b36d1 100644
--- a/versions/7.6.1/start/android-app.mdx
+++ b/versions/7.6.1/start/android-app.mdx
@@ -36,8 +36,7 @@ In this tutorial you learn how to:
 Before you begin the tutorial, install the following software:
 
 * **Bazel.** To install, follow the [installation instructions](/versions/7.6.1/install).
-* **Android Studio.** To install, follow the steps to [download Android
-  Studio](https://developer.android.com/sdk/index.html).
+* **Android Studio.** To install, follow the steps to [download Android Studio](https://developer.android.com/sdk/index.html).
   Execute the setup wizard to download the SDK and configure your environment.
 * (Optional) **Git.** Use `git` to download the Android app project.
 
@@ -52,8 +51,7 @@ This app has a single button that prints a greeting when clicked:
 
 **Figure 1.** Android app button greeting.
 
-Clone the repository with `git` (or [download the ZIP file
-directly](https://github.com/bazelbuild/examples/archive/master.zip)):
+Clone the repository with `git` (or [download the ZIP file directly](https://github.com/bazelbuild/examples/archive/master.zip)):
 
 ```posix-terminal
 git clone https://github.com/bazelbuild/examples
@@ -103,8 +101,7 @@ A [workspace](/versions/7.6.1/concepts/build-ref#workspace) is a directory that
 source files for one or more software projects, and has a `WORKSPACE` file at
 its root.
 
-The `WORKSPACE` file may be empty or may contain references to [external
-dependencies](/versions/7.6.1/docs/external) required to build your project.
+The `WORKSPACE` file may be empty or may contain references to [external dependencies](/versions/7.6.1/docs/external) required to build your project.
 
 First, run the following command to create an empty `WORKSPACE` file:
 
@@ -147,8 +144,7 @@ environment variable, and automatically detect the highest API level and the
 latest version of build tools installed within that location.
 
 You can set the `ANDROID_HOME` variable to the location of the Android SDK. Find
-the path to the installed SDK using Android Studio's [SDK
-Manager](https://developer.android.com/studio/intro/update#sdk-manager).
+the path to the installed SDK using Android Studio's [SDK Manager](https://developer.android.com/studio/intro/update#sdk-manager).
 Assuming the SDK is installed to default locations, you can use the following
 commands to set the `ANDROID_HOME` variable:
 
@@ -197,8 +193,7 @@ android_sdk_repository(
 ```
 
 **Optional:** If you want to compile native code into your Android app, you
-also need to download the [Android
-NDK](https://developer.android.com/ndk/downloads/index.html)
+also need to download the [Android NDK](https://developer.android.com/ndk/downloads/index.html)
 and tell Bazel where to find it by adding the following line to your `WORKSPACE` file:
 
 ```python
@@ -209,8 +204,7 @@ Similar to `android_sdk_repository`, the path to the Android NDK is inferred
 from the `ANDROID_NDK_HOME` environment variable by default. The path can also
 be explicitly specified with a `path` attribute on `android_ndk_repository`.
 
-For more information, read [Using the Android Native Development Kit with
-Bazel](/versions/7.6.1/docs/android-ndk).
+For more information, read [Using the Android Native Development Kit with Bazel](/versions/7.6.1/docs/android-ndk).
 
 `api_level` is the version of the Android API that the SDK and NDK
 target - for example, 23 for Android 6.0 and 25 for Android 7.1. If not
@@ -257,8 +251,7 @@ files or other dependencies. Bazel provides two build rules,
 build an Android app.
 
 For this tutorial, you'll first use the
-`android_library` rule to tell Bazel to build an [Android library
-module](http://developer.android.com/tools/projects/index.html#LibraryProjects)
+`android_library` rule to tell Bazel to build an [Android library module](http://developer.android.com/tools/projects/index.html#LibraryProjects)
 from the app source code and resource files. You'll then use the
 `android_binary` rule to tell Bazel how to build the Android application package.
 
@@ -373,11 +366,9 @@ file:
 ### Run the app
 
 You can now deploy the app to a connected Android device or emulator from the
-command line using the [`bazel
-mobile-install`](/versions/7.6.1/docs/user-manual#mobile-install) command. This command uses
+command line using the [`bazel mobile-install`](/versions/7.6.1/docs/user-manual#mobile-install) command. This command uses
 the Android Debug Bridge (`adb`) to communicate with the device. You must set up
-your device to use `adb` following the instructions in [Android Debug
-Bridge](http://developer.android.com/tools/help/adb.html) before deployment. You
+your device to use `adb` following the instructions in [Android Debug Bridge](http://developer.android.com/tools/help/adb.html) before deployment. You
 can also choose to install the app on the Android emulator included in Android
 Studio. Make sure the emulator is running before executing the command below.
 
diff --git a/versions/7.6.1/start/cpp.mdx b/versions/7.6.1/start/cpp.mdx
index 0fcc1258..1c094065 100644
--- a/versions/7.6.1/start/cpp.mdx
+++ b/versions/7.6.1/start/cpp.mdx
@@ -63,9 +63,7 @@ examples
 ```
 
 There are three sets of files, each set representing a stage in this tutorial.
-In the first stage, you will build a single [target]
-(https://bazel.build/reference/glossary#target) residing in a single [package]
-(https://bazel.build/reference/glossary#package). In the second stage, you will
+In the first stage, you will build a single [target](https://bazel.build/reference/glossary#target) residing in a single [package](https://bazel.build/reference/glossary#package). In the second stage, you will
 build both a binary and a library from a single package. In
 the third and final stage, you will build a project with multiple packages and
 build it with multiple targets.
diff --git a/versions/7.6.1/start/java.mdx b/versions/7.6.1/start/java.mdx
index 979b0d45..783cbf37 100644
--- a/versions/7.6.1/start/java.mdx
+++ b/versions/7.6.1/start/java.mdx
@@ -241,8 +241,7 @@ recompiles that file.
 Looking at the dependency graph, you can see that `ProjectRunner` depends on the
 same inputs as it did before, but the structure of the build is different:
 
-![Dependency graph of the target 'ProjectRunner' after adding a dependency](
-/docs/images/tutorial_java_02.svg)
+![Dependency graph of the target 'ProjectRunner' after adding a dependency](/docs/images/tutorial_java_02.svg)
 
 You've now built the project with two targets. The `ProjectRunner` target builds
 two source files and depends on one other target (`:greeter`), which builds
diff --git a/versions/7.6.1/versions/index.mdx b/versions/7.6.1/versions/index.mdx
index c92a15b6..ad1492e5 100644
--- a/versions/7.6.1/versions/index.mdx
+++ b/versions/7.6.1/versions/index.mdx
@@ -11,7 +11,3 @@ version support.
 
 For now, to see documentation for older Bazel versions, go to
 [docs.bazel.build](https://docs.bazel.build/).
-
-
-  To the Archives!
-
diff --git a/versions/7.7.1/community/roadmaps-configurability.mdx b/versions/7.7.1/community/roadmaps-configurability.mdx
index 3c06112f..663d872a 100644
--- a/versions/7.7.1/community/roadmaps-configurability.mdx
+++ b/versions/7.7.1/community/roadmaps-configurability.mdx
@@ -26,8 +26,7 @@ title: 'Bazel Configurability 2021 Roadmap'
 * Builds scale well, particularly w.r.t graph size and action caching.
 
 We also support
-[`cquery`](https://bazel.build/versions/7.7.1/query/cquery), [`Starlark
-configuration`](https://bazel.build/extending/config),
+[`cquery`](https://bazel.build/versions/7.7.1/query/cquery), [`Starlark configuration`](https://bazel.build/extending/config),
 and
 [`select()`](https://bazel.build/versions/7.7.1/docs/configurable-attributes).
 
@@ -41,15 +40,13 @@ interest of accurate expectations.
 ### Platforms
 
 

-Q3 2021**Android rules use the new [platforms
-API](https://bazel.build/concepts/platforms)**
+Q3 2021**Android rules use the new [platforms API](https://bazel.build/concepts/platforms)**
 IN PROGRESS ([#11749](https://github.com/bazelbuild/bazel/issues/11749))
 
 * This is our main priority for the beginning of 2021.
 
 

-Q3 2021**Builds support [multiple execution
-platforms](https://docs.google.com/document/d/1U9HzdDmtRnm244CaRM6JV-q2408mbNODAMewcGjnnbM/)**
+Q3 2021**Builds support [multiple execution platforms](https://docs.google.com/document/d/1U9HzdDmtRnm244CaRM6JV-q2408mbNODAMewcGjnnbM/)**
 IN PROGRESS ([#11748](https://github.com/bazelbuild/bazel/issues/11748))
 
 

diff --git a/versions/7.7.1/community/sig.mdx b/versions/7.7.1/community/sig.mdx
index 462a8840..91314925 100644
--- a/versions/7.7.1/community/sig.mdx
+++ b/versions/7.7.1/community/sig.mdx
@@ -3,8 +3,7 @@ title: 'Bazel Special Interest Groups'
 ---
 
 Bazel hosts Special Interest Groups (SIGs) to focus collaboration on particular
-areas and to support communication and coordination between [Bazel owners,
-maintainers, and contributors](/versions/7.7.1/contribute/policy). This policy
+areas and to support communication and coordination between [Bazel owners, maintainers, and contributors](/versions/7.7.1/contribute/policy). This policy
 applies to [`bazelbuild`](http://github.com/bazelbuild).
 
 SIGs do their work in public. The ideal scope for a SIG covers a well-defined
diff --git a/versions/7.7.1/concepts/build-files.mdx b/versions/7.7.1/concepts/build-files.mdx
index bcd6ef60..819f2374 100644
--- a/versions/7.7.1/concepts/build-files.mdx
+++ b/versions/7.7.1/concepts/build-files.mdx
@@ -132,10 +132,3 @@ for anyone to create new rules.
     programming language. Libraries can depend on other libraries,
     and binaries and tests can depend on libraries, with the expected
     separate-compilation behavior.
-
-
-  
-    
-    
-  
-
LabelsDependencies

diff --git a/versions/7.7.1/concepts/build-ref.mdx b/versions/7.7.1/concepts/build-ref.mdx
index b2b952a6..bca6d2a1 100644
--- a/versions/7.7.1/concepts/build-ref.mdx
+++ b/versions/7.7.1/concepts/build-ref.mdx
@@ -17,8 +17,7 @@ its root; such a boundary marker file could be `MODULE.bazel`, `REPO.bazel`, or
 in legacy contexts, `WORKSPACE` or `WORKSPACE.bazel`.
 
 The repo in which the current Bazel command is being run is called the _main
-repo_. Other, (external) repos are defined by _repo rules_; see [external
-dependencies overview](/versions/7.7.1/external/overview) for more information.
+repo_. Other, (external) repos are defined by _repo rules_; see [external dependencies overview](/versions/7.7.1/external/overview) for more information.
 
 ## Workspace {#workspace}
 
@@ -95,9 +94,4 @@ have three properties: the list of packages they contain, their name, and other
 package groups they include. The only allowed ways to refer to them are from the
 `visibility` attribute of rules or from the `default_visibility` attribute of
 the `package` function; they do not generate or consume files. For more
-information, refer to the [`package_group`
-documentation](/versions/7.7.1/reference/be/functions#package_group).
-
-
-  Labels
-
\ No newline at end of file
+information, refer to the [`package_group` documentation](/versions/7.7.1/reference/be/functions#package_group).
diff --git a/versions/7.7.1/concepts/dependencies.mdx b/versions/7.7.1/concepts/dependencies.mdx
index 0df26784..3358c7c1 100644
--- a/versions/7.7.1/concepts/dependencies.mdx
+++ b/versions/7.7.1/concepts/dependencies.mdx
@@ -325,11 +325,3 @@ filegroup(
 ```
 
 You can then reference the label `my_data` as the data dependency in your test.
-
-
-  
-    
-    
-  
-
BUILD filesVisibility

-
diff --git a/versions/7.7.1/concepts/labels.mdx b/versions/7.7.1/concepts/labels.mdx
index 520dfec2..3129efb7 100644
--- a/versions/7.7.1/concepts/labels.mdx
+++ b/versions/7.7.1/concepts/labels.mdx
@@ -10,8 +10,7 @@ form looks like:
 ```
 
 The first part of the label is the repository name, `@@myrepo`. The double-`@`
-syntax signifies that this is a [*canonical* repo
-name](/versions/7.7.1/external/overview#canonical-repo-name), which is unique within
+syntax signifies that this is a [*canonical* repo name](/versions/7.7.1/external/overview#canonical-repo-name), which is unique within
 the workspace. Labels with canonical repo names unambiguously identify a target
 no matter which context they appear in.
 
@@ -228,10 +227,3 @@ the build.
 This directed acyclic graph over targets is called the _target graph_ or
 _build dependency graph_, and is the domain over which the
 [Bazel Query tool](/versions/7.7.1/query/guide) operates.
-
-
-  
-    
-    
-  
-
TargetsBUILD files

diff --git a/versions/7.7.1/concepts/platforms.mdx b/versions/7.7.1/concepts/platforms.mdx
index c846eab8..b9f348c6 100644
--- a/versions/7.7.1/concepts/platforms.mdx
+++ b/versions/7.7.1/concepts/platforms.mdx
@@ -77,8 +77,7 @@ To test your Android project with platforms, see
 for support.
 
 You can still use platform APIs with Apple builds (for example, when building
-with a mixture of Apple rules and pure C++) with [platform
-mappings](#platform-mappings).
+with a mixture of Apple rules and pure C++) with [platform mappings](#platform-mappings).
 
 ### Other languages {#other-languages}
 
@@ -241,8 +240,7 @@ sets `--cpu`, `--crossstool_top`, or other legacy flags, rules that read
 
 When migrating your project to platforms, you must either convert changes like
 `return { "//command_line_option:cpu": "arm" }` to `return {
-"//command_line_option:platforms": "//:my_arm_platform" }` or use [platform
-mappings](#platform-mappings) to support both styles during migration.
+"//command_line_option:platforms": "//:my_arm_platform" }` or use [platform mappings](#platform-mappings) to support both styles during migration.
 window.
 
 ## Migrating your rule set {#migrating-your-rule-set}
@@ -361,10 +359,8 @@ attributes declare a language's tools (like `compiler =
 this information to rules that need to build with these tools.
 
 Toolchains declare the `constraint_value`s of machines they can
-[target][target_compatible_with Attribute]
-(`target_compatible_with = ["@platforms//os:linux"]`) and machines their tools can
-[run on][exec_compatible_with Attribute]
-(`exec_compatible_with = ["@platforms//os:mac"]`).
+[target][target_compatible_with Attribute](`target_compatible_with = ["@platforms//os:linux"]`) and machines their tools can
+[run on][exec_compatible_with Attribute](`exec_compatible_with = ["@platforms//os:mac"]`).
 
 When building `$ bazel build //:myproject --platforms=//:myplatform`, Bazel
 automatically selects a toolchain that can run on the build machine and
diff --git a/versions/7.7.1/configure/attributes.mdx b/versions/7.7.1/configure/attributes.mdx
index 9678e0d1..40cb7471 100644
--- a/versions/7.7.1/configure/attributes.mdx
+++ b/versions/7.7.1/configure/attributes.mdx
@@ -2,8 +2,7 @@
 title: 'Configurable Build Attributes'
 ---
 
-**_Configurable attributes_**, commonly known as [`select()`](
-/reference/be/functions#select), is a Bazel feature that lets users toggle the values
+**_Configurable attributes_**, commonly known as [`select()`](/reference/be/functions#select), is a Bazel feature that lets users toggle the values
 of build rule attributes at the command line.
 
 This can be used, for example, for a multiplatform library that automatically
@@ -407,8 +406,7 @@ sh_library(
 )
 ```
 
-If you need a `select` to match when multiple conditions match, consider [AND
-chaining](#and-chaining).
+If you need a `select` to match when multiple conditions match, consider [AND chaining](#and-chaining).
 
 ## OR chaining {#or-chaining}
 
diff --git a/versions/7.7.1/configure/integrate-cpp.mdx b/versions/7.7.1/configure/integrate-cpp.mdx
index bec529c9..f20b55f6 100644
--- a/versions/7.7.1/configure/integrate-cpp.mdx
+++ b/versions/7.7.1/configure/integrate-cpp.mdx
@@ -33,8 +33,7 @@ This is because when writing our own actions, they must behave
 consistently with the C++ toolchain - for example, passing C++ command line
 flags to a tool that invokes the C++ compiler behind the scenes.
 
-C++ rules use a special way of constructing command lines based on [feature
-configuration](/versions/7.7.1/docs/cc-toolchain-config-reference). To construct a command line,
+C++ rules use a special way of constructing command lines based on [feature configuration](/versions/7.7.1/docs/cc-toolchain-config-reference). To construct a command line,
 you need the following:
 
 * `features` and `action_configs` - these come from the `CcToolchainConfigInfo`
diff --git a/versions/7.7.1/configure/windows.mdx b/versions/7.7.1/configure/windows.mdx
index ab04d210..d5b412dc 100644
--- a/versions/7.7.1/configure/windows.mdx
+++ b/versions/7.7.1/configure/windows.mdx
@@ -166,8 +166,7 @@ To build C++ targets with MSVC, you need:
         set BAZEL_VC=C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC
         ```
 
-*   The [Windows
-    SDK](https://developer.microsoft.com/en-us/windows/downloads/windows-10-sdk).
+*   The [Windows SDK](https://developer.microsoft.com/en-us/windows/downloads/windows-10-sdk).
 
     The Windows SDK contains header files and libraries you need when building
     Windows applications, including Bazel itself. By default, the latest Windows SDK installed will
@@ -186,8 +185,7 @@ To build C++ targets with MSVC, you need:
 
 If everything is set up, you can build a C++ target now!
 
-Try building a target from one of our [sample
-projects](https://github.com/bazelbuild/bazel/tree/master/examples):
+Try building a target from one of our [sample projects](https://github.com/bazelbuild/bazel/tree/master/examples):
 
 
 
 
-To build and use Dynamically Linked Libraries (DLL files), see [this
-example](https://github.com/bazelbuild/bazel/tree/master/examples/windows/dll).
+To build and use Dynamically Linked Libraries (DLL files), see [this example](https://github.com/bazelbuild/bazel/tree/master/examples/windows/dll).
 
 **Command Line Length Limit**: To prevent the
 [Windows command line length limit issue](https://github.com/bazelbuild/bazel/issues/5163),
@@ -292,8 +289,7 @@ On Windows, Bazel builds two output files for `java_binary` rules:
 *   a `.jar` file
 *   a `.exe` file that can set up the environment for the JVM and run the binary
 
-Try building a target from one of our [sample
-projects](https://github.com/bazelbuild/bazel/tree/master/examples):
+Try building a target from one of our [sample projects](https://github.com/bazelbuild/bazel/tree/master/examples):
 
 
   
   
 
 If you are interested in details about how Bazel builds Python targets on
-Windows, check out this [design
-doc](https://github.com/bazelbuild/bazel-website/blob/master/designs/_posts/2016-09-05-build-python-on-windows.md).
+Windows, check out this [design doc](https://github.com/bazelbuild/bazel-website/blob/master/designs/_posts/2016-09-05-build-python-on-windows.md).
diff --git a/versions/7.7.1/contribute/codebase.mdx b/versions/7.7.1/contribute/codebase.mdx
index a9f17d71..200dde44 100644
--- a/versions/7.7.1/contribute/codebase.mdx
+++ b/versions/7.7.1/contribute/codebase.mdx
@@ -227,8 +227,7 @@ repository", the others are called "external repositories".
 A repository is marked by a repo boundary file (`MODULE.bazel`, `REPO.bazel`, or
 in legacy contexts, `WORKSPACE` or `WORKSPACE.bazel`) in its root directory. The
 main repo is the source tree where you're invoking Bazel from. External repos
-are defined in various ways; see [external dependencies
-overview](/versions/7.7.1/external/overview) for more information.
+are defined in various ways; see [external dependencies overview](/versions/7.7.1/external/overview) for more information.
 
 Code of external repositories is symlinked or downloaded under
 `$OUTPUT_BASE/external`.
diff --git a/versions/7.7.1/contribute/design-documents.mdx b/versions/7.7.1/contribute/design-documents.mdx
index 60f69495..4b8a8682 100644
--- a/versions/7.7.1/contribute/design-documents.mdx
+++ b/versions/7.7.1/contribute/design-documents.mdx
@@ -137,8 +137,7 @@ A lead reviewer should be a domain expert who is:
 *   Objective and capable of providing constructive feedback
 *   Available for the entire review period to lead the process
 
-Consider checking the contacts for various [team
-labels](/versions/7.7.1/contribute/maintainers-guide#team-labels).
+Consider checking the contacts for various [team labels](/versions/7.7.1/contribute/maintainers-guide#team-labels).
 
 ## Markdown vs Google Docs {#markdown-versus-gdocs}
 
@@ -168,12 +167,10 @@ Markdown for posterity.
 
 ### Using Google Docs {#gdocs}
 
-For consistency, use the [Bazel design doc template](
-https://docs.google.com/document/d/1cE5zrjrR40RXNg64XtRFewSv6FrLV6slGkkqxBumS1w/edit).
+For consistency, use the [Bazel design doc template](https://docs.google.com/document/d/1cE5zrjrR40RXNg64XtRFewSv6FrLV6slGkkqxBumS1w/edit).
 It includes the necessary header and creates visual
 consistency with other Bazel related documents. To do that, click on **File** >
-**Make a copy** or click this link to [make a copy of the design doc
-template](https://docs.google.com/document/d/1cE5zrjrR40RXNg64XtRFewSv6FrLV6slGkkqxBumS1w/copy).
+**Make a copy** or click this link to [make a copy of the design doc template](https://docs.google.com/document/d/1cE5zrjrR40RXNg64XtRFewSv6FrLV6slGkkqxBumS1w/copy).
 
 To make your document readable to the world, click on
 **Share** > **Advanced** > **Change…**, and
diff --git a/versions/7.7.1/contribute/index.mdx b/versions/7.7.1/contribute/index.mdx
index 2619db31..c7d01b46 100644
--- a/versions/7.7.1/contribute/index.mdx
+++ b/versions/7.7.1/contribute/index.mdx
@@ -10,8 +10,7 @@ As you use Bazel, you may find things that can be improved.
 You can help by [reporting issues](http://github.com/bazelbuild/bazel/issues)
 when:
 
-   - Bazel crashes or you encounter a bug that can [only be resolved using `bazel
-     clean`](/versions/7.7.1/run/build#correct-incremental-rebuilds).
+   - Bazel crashes or you encounter a bug that can [only be resolved using `bazel clean`](/versions/7.7.1/run/build#correct-incremental-rebuilds).
    - The documentation is incomplete or unclear. You can also report issues
      from the page you are viewing by using the "Create issue"
      link at the top right corner of the page.
@@ -21,11 +20,9 @@ when:
 
 You can engage with the Bazel community by:
 
-   - Answering questions [on Stack Overflow](
-     https://stackoverflow.com/questions/tagged/bazel).
+   - Answering questions [on Stack Overflow](https://stackoverflow.com/questions/tagged/bazel).
    - Helping other users [on Slack](https://slack.bazel.build).
-   - Improving documentation or [contributing examples](
-     https://github.com/bazelbuild/examples).
+   - Improving documentation or [contributing examples](https://github.com/bazelbuild/examples).
    - Sharing your experience or your tips, for example, on a blog or social media.
 
 ## Contribute code {#contribute-code}
@@ -40,8 +37,7 @@ You can contribute to the Bazel ecosystem by:
    - Contributing to Bazel-related tools, for example, migration tools.
    - Improving Bazel integration with other IDEs and tools.
 
-Before making a change, [create a GitHub
-issue](http://github.com/bazelbuild/bazel/issues)
+Before making a change, [create a GitHub issue](http://github.com/bazelbuild/bazel/issues)
 or email [bazel-discuss@](mailto:bazel-discuss@googlegroups.com).
 
 The most helpful contributions fix bugs or add features (as opposed
diff --git a/versions/7.7.1/contribute/maintainers-guide.mdx b/versions/7.7.1/contribute/maintainers-guide.mdx
index dbb45ada..516cf0b1 100644
--- a/versions/7.7.1/contribute/maintainers-guide.mdx
+++ b/versions/7.7.1/contribute/maintainers-guide.mdx
@@ -4,8 +4,7 @@ title: 'Guide for Bazel Maintainers'
 
 This is a guide for the maintainers of the Bazel open source project.
 
-If you are looking to contribute to Bazel, please read [Contributing to
-Bazel](/versions/7.7.1/contribute) instead.
+If you are looking to contribute to Bazel, please read [Contributing to Bazel](/versions/7.7.1/contribute) instead.
 
 The objectives of this page are to:
 
@@ -37,8 +36,7 @@ repository.
 
 1. A user creates an issue by choosing one of the
 [issue templates](https://github.com/bazelbuild/bazel/issues/new/choose)
-   and it enters the pool of [unreviewed open
-   issues](https://github.com/bazelbuild/bazel/issues?utf8=%E2%9C%93&q=is%3Aissue+is%3Aopen+-label%3Auntriaged+-label%3Ap2+-label%3Ap1+-label%3Ap3+-label%3Ap4+-label%3Ateam-Starlark+-label%3Ateam-Rules-CPP+-label%3Ateam-Rules-Java+-label%3Ateam-XProduct+-label%3Ateam-Android+-label%3Ateam-Apple+-label%3Ateam-Configurability++-label%3Ateam-Performance+-label%3Ateam-Rules-Server+-label%3Ateam-Core+-label%3Ateam-Rules-Python+-label%3Ateam-Remote-Exec+-label%3Ateam-Local-Exec+-label%3Ateam-Bazel).
+   and it enters the pool of [unreviewed open issues](https://github.com/bazelbuild/bazel/issues?utf8=%E2%9C%93&q=is%3Aissue+is%3Aopen+-label%3Auntriaged+-label%3Ap2+-label%3Ap1+-label%3Ap3+-label%3Ap4+-label%3Ateam-Starlark+-label%3Ateam-Rules-CPP+-label%3Ateam-Rules-Java+-label%3Ateam-XProduct+-label%3Ateam-Android+-label%3Ateam-Apple+-label%3Ateam-Configurability++-label%3Ateam-Performance+-label%3Ateam-Rules-Server+-label%3Ateam-Core+-label%3Ateam-Rules-Python+-label%3Ateam-Remote-Exec+-label%3Ateam-Local-Exec+-label%3Ateam-Bazel).
 1. A member on the Developer Experience (DevEx) subteam rotation reviews the
    issue.
    1. If the issue is **not a bug** or a **feature request**, the DevEx member
@@ -58,21 +56,18 @@ repository.
 1. After reviewing the issue, the DevEx member decides if the issue requires
    immediate attention. If it does, they will assign the **P0**
    [priority](#priority) label and an owner from the list of team leads.
-1. The DevEx member assigns the `untriaged` label and exactly one [team
-   label](#team-labels) for routing.
+1. The DevEx member assigns the `untriaged` label and exactly one [team label](#team-labels) for routing.
 1. The DevEx member also assigns exactly one `type:` label, such as `type: bug`
    or `type: feature request`, according to the type of the issue.
 1. For platform-specific issues, the DevEx member assigns one `platform:` label,
    such as `platform:apple` for Mac-specific issues.
 1. If the issue is low priority and can be worked on by a new community
    contributor, the DevEx member assigns the `good first issue` label.
-At this stage, the issue enters the pool of [untriaged open
-issues](https://github.com/bazelbuild/bazel/issues?q=is%3Aissue+is%3Aopen+label%3Auntriaged).
+At this stage, the issue enters the pool of [untriaged open issues](https://github.com/bazelbuild/bazel/issues?q=is%3Aissue+is%3Aopen+label%3Auntriaged).
 
 Each Bazel subteam will triage all issues under labels they own, preferably on a
 weekly basis. The subteam will review and evaluate the issue and provide a
-resolution, if possible. If you are an owner of a team label, see [this section
-](#label-own) for more information.
+resolution, if possible. If you are an owner of a team label, see [this section](#label-own) for more information.
 
 When an issue is resolved, it can be closed.
 
@@ -111,8 +106,7 @@ preferably on a weekly basis.
      issue is either P0 or P1 we assume that is actively worked on.
 1. Remove the `untriaged` label.
 
-Note that you need to be in the [bazelbuild
-organization](https://github.com/bazelbuild) to be able to add or remove labels.
+Note that you need to be in the [bazelbuild organization](https://github.com/bazelbuild) to be able to add or remove labels.
 
 ### Pull Requests {#pull-requests}
 
@@ -138,8 +132,7 @@ issues.
   unusable, or a downed service that severely impacts development of the Bazel
   project. This includes regressions introduced in a new release that blocks a
   significant number of users, or an incompatible breaking change that was not
-  compliant to the [Breaking
-  Change](https://docs.google.com/document/d/1q5GGRxKrF_mnwtaPKI487P8OdDRh2nN7jX6U-FXnHL0/edit?pli=1#heading=h.ceof6vpkb3ik)
+  compliant to the [Breaking Change](https://docs.google.com/document/d/1q5GGRxKrF_mnwtaPKI487P8OdDRh2nN7jX6U-FXnHL0/edit?pli=1#heading=h.ceof6vpkb3ik)
   policy. No practical workaround exists.
 * [**P1**](https://github.com/bazelbuild/bazel/labels/P1) - Critical defect or
   feature which should be addressed in the next release, or a serious issue that
diff --git a/versions/7.7.1/contribute/naming.mdx b/versions/7.7.1/contribute/naming.mdx
index 672c7dac..03652c5f 100644
--- a/versions/7.7.1/contribute/naming.mdx
+++ b/versions/7.7.1/contribute/naming.mdx
@@ -4,8 +4,7 @@ title: 'Naming a Bazel related project'
 
 First, thank you for contributing to the Bazel ecosystem! Please reach out to
 the Bazel community on the
-[bazel-discuss mailing list](https://groups.google.com/forum/#!forum/bazel-discuss
-) to share your project and its suggested name.
+[bazel-discuss mailing list](https://groups.google.com/forum/#!forum/bazel-discuss) to share your project and its suggested name.
 
 If you are building a Bazel related tool or sharing your Skylark rules,
 we recommend following these guidelines for the name of your project:
diff --git a/versions/7.7.1/contribute/patch-acceptance.mdx b/versions/7.7.1/contribute/patch-acceptance.mdx
index f78087ca..667f1633 100644
--- a/versions/7.7.1/contribute/patch-acceptance.mdx
+++ b/versions/7.7.1/contribute/patch-acceptance.mdx
@@ -11,29 +11,24 @@ code base.
    need a corresponding issue for tracking.
 1. If you're proposing significant changes, write a
    [design document](/versions/7.7.1/contribute/design-documents).
-1. Ensure you've signed a [Contributor License
-   Agreement](https://cla.developers.google.com).
+1. Ensure you've signed a [Contributor License Agreement](https://cla.developers.google.com).
 1. Prepare a git commit that implements the feature. Don't forget to add tests
    and update the documentation. If your change has user-visible effects, please
    [add release notes](/versions/7.7.1/contribute/release-notes). If it is an incompatible change,
    read the [guide for rolling out breaking changes](/versions/7.7.1/contribute/breaking-changes).
 1. Create a pull request on
    [GitHub](https://github.com/bazelbuild/bazel/pulls). If you're new to GitHub,
-   read [about pull
-   requests](https://help.github.com/articles/about-pull-requests/). Note that
+   read [about pull requests](https://help.github.com/articles/about-pull-requests/). Note that
    we restrict permissions to create branches on the main Bazel repository, so
-   you will need to push your commit to [your own fork of the
-   repository](https://help.github.com/articles/working-with-forks/).
+   you will need to push your commit to [your own fork of the repository](https://help.github.com/articles/working-with-forks/).
 1. A Bazel maintainer should assign you a reviewer within two business days
    (excluding holidays in the USA and Germany). If you aren't assigned a
    reviewer in that time, you can request one by emailing
-   [bazel-discuss@googlegroups.com]
-   (mailto:bazel-discuss@googlegroups.com).
+   [bazel-discuss@googlegroups.com](mailto:bazel-discuss@googlegroups.com).
 1. Work with the reviewer to complete a code review. For each change, create a
    new commit and push it to make changes to your pull request. If the review
    takes too long (for instance, if the reviewer is unresponsive), send an email to
-   [bazel-discuss@googlegroups.com]
-   (mailto:bazel-discuss@googlegroups.com).
+   [bazel-discuss@googlegroups.com](mailto:bazel-discuss@googlegroups.com).
 1. After your review is complete, a Bazel maintainer applies your patch to
    Google's internal version control system.
 
diff --git a/versions/7.7.1/contribute/release-notes.mdx b/versions/7.7.1/contribute/release-notes.mdx
index fc20f422..a1d8b6de 100644
--- a/versions/7.7.1/contribute/release-notes.mdx
+++ b/versions/7.7.1/contribute/release-notes.mdx
@@ -16,8 +16,7 @@ the release announcement.
 * If the change adds / removes / changes Bazel in a user-visible way, then it
   may be advantageous to mention it.
 
-If the change is significant, follow the [design document
-policy](/versions/7.7.1/contribute/design-documents) first.
+If the change is significant, follow the [design document policy](/versions/7.7.1/contribute/design-documents) first.
 
 ## Guidelines {#guidelines}
 
@@ -60,10 +59,8 @@ change is about.
 
 ## Process {#process}
 
-As part of the [release
-process](https://github.com/bazelbuild/continuous-integration/blob/master/docs/release-playbook.md),
-we collect the `RELNOTES` tags of every commit. We copy everything in a [Google
-Doc](https://docs.google.com/document/d/1wDvulLlj4NAlPZamdlEVFORks3YXJonCjyuQMUQEmB0/edit)
+As part of the [release process](https://github.com/bazelbuild/continuous-integration/blob/master/docs/release-playbook.md),
+we collect the `RELNOTES` tags of every commit. We copy everything in a [Google Doc](https://docs.google.com/document/d/1wDvulLlj4NAlPZamdlEVFORks3YXJonCjyuQMUQEmB0/edit)
 where we review, edit, and organize the notes.
 
 The release manager sends an email to the
@@ -71,6 +68,4 @@ The release manager sends an email to the
 Bazel contributors are invited to contribute to the document and make sure
 their changes are correctly reflected in the announcement.
 
-Later, the announcement will be submitted to the [Bazel
-blog](https://blog.bazel.build/), using the [bazel-blog
-repository](https://github.com/bazelbuild/bazel-blog/tree/master/_posts).
+Later, the announcement will be submitted to the [Bazel blog](https://blog.bazel.build/), using the [bazel-blog repository](https://github.com/bazelbuild/bazel-blog/tree/master/_posts).
diff --git a/versions/7.7.1/contribute/statemachine-guide.mdx b/versions/7.7.1/contribute/statemachine-guide.mdx
index b7d2d8b7..7b325891 100644
--- a/versions/7.7.1/contribute/statemachine-guide.mdx
+++ b/versions/7.7.1/contribute/statemachine-guide.mdx
@@ -172,8 +172,7 @@ instead, batches[^4] as many lookups as possible before doing so. The value
 might not be immediately available, for example, requiring a Skyframe restart,
 so the caller specifies what to do with the resulting value using a callback.
 
-The `StateMachine` processor ([`Driver`s and bridging to
-SkyFrame](#drivers-and-bridging)) guarantees that the value is available before
+The `StateMachine` processor ([`Driver`s and bridging to SkyFrame](#drivers-and-bridging)) guarantees that the value is available before
 the next state begins. An example follows.
 
 ```
@@ -284,8 +283,7 @@ and solutions to certain control flow problems.
 ### Sequential states
 
 This is the most common and straightforward control flow pattern. An example of
-this is shown in [Stateful computations inside
-`SkyKeyComputeState`](#stateful-computations).
+this is shown in [Stateful computations inside `SkyKeyComputeState`](#stateful-computations).
 
 ### Branching
 
@@ -545,8 +543,7 @@ section describes the propagation of data values.
 
 ### Implementing `Tasks.lookUp` callbacks
 
-There’s an example of implementing a `Tasks.lookUp` callback in [SkyValue
-lookups](#skyvalue-lookups). This section provides rationale and suggests
+There’s an example of implementing a `Tasks.lookUp` callback in [SkyValue lookups](#skyvalue-lookups). This section provides rationale and suggests
 approaches for handling multiple SkyValues.
 
 #### `Tasks.lookUp` callbacks {#tasks-lookup-callbacks}
@@ -710,8 +707,7 @@ class BarProducer implements StateMachine {
 Tip: It would be tempting to use the more concise signature void `accept(Bar
 value)` rather than the stuttery `void acceptBarValue(Bar value)` above.
 However, `Consumer` is a common overload of `void accept(Bar value)`,
-so doing this often leads to violations of the [Overloads: never
-split](https://google.github.io/styleguide/javaguide.html#s3.4.2-ordering-class-contents)
+so doing this often leads to violations of the [Overloads: never split](https://google.github.io/styleguide/javaguide.html#s3.4.2-ordering-class-contents)
 style-guide rule.
 
 Tip: Using a custom `ResultSink` type instead of a generic one from
@@ -774,14 +770,11 @@ pattern after accepting output from either a subtask or SkyValue lookup.
 Note that the implementation of `acceptBarError` eagerly forwards the result to
 the `Caller.ResultSink`, as required by [Error bubbling](#error-bubbling).
 
-Alternatives for top-level `StateMachine`s are described in [`Driver`s and
-bridging to SkyFunctions](#drivers-and-bridging).
+Alternatives for top-level `StateMachine`s are described in [`Driver`s and bridging to SkyFunctions](#drivers-and-bridging).
 
 ### Error handling {#error-handling}
 
-There's a couple of examples of error handling already in [`Tasks.lookUp`
-callbacks](#tasks-lookup-callbacks) and [Propagating values between
-`StateMachines`](#propagating-values). Exceptions, other than
+There's a couple of examples of error handling already in [`Tasks.lookUp` callbacks](#tasks-lookup-callbacks) and [Propagating values between `StateMachines`](#propagating-values). Exceptions, other than
 `InterruptedException` are not thrown, but instead passed around through
 callbacks as values. Such callbacks often have exclusive-or semantics, with
 exactly one of a value or error being passed.
@@ -1184,8 +1177,7 @@ states. Where it is possible, local stack `step` variables are young generation
 variables and efficiently GC'd.
 
 For `StateMachine` variables, breaking things down into subtasks and following
-the recommended pattern for [Propagating values between
-`StateMachine`s](#propagating-values) is also helpful. Observe that when
+the recommended pattern for [Propagating values between `StateMachine`s](#propagating-values) is also helpful. Observe that when
 following the pattern, only child `StateMachine`s have references to parent
 `StateMachine`s and not vice versa. This means that as children complete and
 update the parents using result callbacks, the children naturally fall out of
@@ -1207,8 +1199,7 @@ potentially reflecting local behavior.
 
 ### Concurrency tree diagram {#concurrency-tree-diagram}
 
-The following is an alternative view of the diagram in [Structured
-concurrency](#structured-concurrency) that better depicts the tree structure.
+The following is an alternative view of the diagram in [Structured concurrency](#structured-concurrency) that better depicts the tree structure.
 The blocks form a small tree.
 
 ![Structured Concurrency 3D](/versions/7.7.1/contribute/images/structured-concurrency-3d.svg)
diff --git a/versions/7.7.1/docs/android-instrumentation-test.mdx b/versions/7.7.1/docs/android-instrumentation-test.mdx
index 9a40baf2..c6d61580 100644
--- a/versions/7.7.1/docs/android-instrumentation-test.mdx
+++ b/versions/7.7.1/docs/android-instrumentation-test.mdx
@@ -2,8 +2,7 @@
 title: 'Android Instrumentation Tests'
 ---
 
-_If you're new to Bazel, start with the [Building Android with
-Bazel](/versions/7.7.1/start/android-app ) tutorial._
+_If you're new to Bazel, start with the [Building Android with Bazel](/versions/7.7.1/start/android-app) tutorial._
 
 ![Running Android instrumentation tests in parallel](/versions/7.7.1/docs/images/android_test.gif "Android instrumentation test")
 
@@ -18,9 +17,7 @@ emulators in a sandbox, ensuring that tests always run from a clean state. Each
 test gets an isolated emulator instance, allowing tests to run in parallel
 without passing states between them.
 
-For more information on Android instrumentation tests, check out the [Android
-developer
-documentation](https://developer.android.com/training/testing/unit-testing/instrumented-unit-tests.html).
+For more information on Android instrumentation tests, check out the [Android developer documentation](https://developer.android.com/training/testing/unit-testing/instrumented-unit-tests.html).
 
 Please file issues in the [GitHub issue tracker](https://github.com/bazelbuild/bazel/issues).
 
@@ -58,8 +55,7 @@ This results in output similar to the following:
 release 4.1.0
 ```
 
-- **KVM**. Bazel requires emulators to have [hardware
-  acceleration](https://developer.android.com/studio/run/emulator-acceleration.html#accel-check)
+- **KVM**. Bazel requires emulators to have [hardware acceleration](https://developer.android.com/studio/run/emulator-acceleration.html#accel-check)
   with KVM on Linux. You can follow these
   [installation instructions](https://help.ubuntu.com/community/KVM/Installation)
   for Ubuntu.
@@ -173,11 +169,9 @@ The main attributes of the rule `android_instrumentation_test` are:
 
 - `target_device`: An `android_device` target. This target describes the
   specifications of the Android emulator which Bazel uses to create, launch and
-  run the tests. See the [section on choosing an Android
-  device](#android-device-target) for more information.
+  run the tests. See the [section on choosing an Android device](#android-device-target) for more information.
 
-The test app's `AndroidManifest.xml` must include [an ``
-tag](https://developer.android.com/studio/test/#configure_instrumentation_manifest_settings).
+The test app's `AndroidManifest.xml` must include [an `` tag](https://developer.android.com/studio/test/#configure_instrumentation_manifest_settings).
 This tag must specify the attributes for the **package of the target app** and
 the **fully qualified class name of the instrumentation test runner**,
 `androidx.test.runner.AndroidJUnitRunner`.
@@ -214,8 +208,7 @@ repositories:
 - `@androidsdk`: The Android SDK. Download this through Android Studio.
 
 - `@android_test_support`: Hosts the test runner, emulator launcher, and
-  `android_device` targets. You can find the [latest release
-  here](https://github.com/android/android-test/releases).
+  `android_device` targets. You can find the [latest release here](https://github.com/android/android-test/releases).
 
 Enable these dependencies by adding the following lines to your `WORKSPACE`
 file:
@@ -240,8 +233,7 @@ android_test_repositories()
 
 ## Maven dependencies {#maven-dependencies}
 
-For managing dependencies on Maven artifacts from repositories, such as [Google
-Maven](https://maven.google.com) or [Maven Central](https://central.maven.org),
+For managing dependencies on Maven artifacts from repositories, such as [Google Maven](https://maven.google.com) or [Maven Central](https://central.maven.org),
 you should use a Maven resolver, such as
 [`rules_jvm_external`](https://github.com/bazelbuild/rules_jvm_external).
 
@@ -370,8 +362,7 @@ the device/emulator listed in `adb devices`.
 
 ## Sample projects {#sample-projects}
 
-If you are looking for canonical project samples, see the [Android testing
-samples](https://github.com/googlesamples/android-testing#experimental-bazel-support)
+If you are looking for canonical project samples, see the [Android testing samples](https://github.com/googlesamples/android-testing#experimental-bazel-support)
 for projects using Espresso and UIAutomator.
 
 ## Espresso setup {#espresso-setup}
@@ -560,8 +551,7 @@ API_LEVELS = [
 
 ## Known issues {#known-issues}
 
-- [Forked adb server processes are not terminated after
-  tests](https://github.com/bazelbuild/bazel/issues/4853)
+- [Forked adb server processes are not terminated after tests](https://github.com/bazelbuild/bazel/issues/4853)
 - While APK building works on all platforms (Linux, macOS, Windows), testing
   only works on Linux.
 - Even with `--config=local_adb`, users still need to specify
diff --git a/versions/7.7.1/docs/android-ndk.mdx b/versions/7.7.1/docs/android-ndk.mdx
index f1c5e54c..cf2a1a70 100644
--- a/versions/7.7.1/docs/android-ndk.mdx
+++ b/versions/7.7.1/docs/android-ndk.mdx
@@ -2,8 +2,7 @@
 title: 'Using the Android Native Development Kit with Bazel'
 ---
 
-_If you're new to Bazel, please start with the [Building Android with
-Bazel](/versions/7.7.1/start/android-app ) tutorial._
+_If you're new to Bazel, please start with the [Building Android with Bazel](/versions/7.7.1/start/android-app) tutorial._
 
 ## Overview {#overview}
 
@@ -31,8 +30,7 @@ android_ndk_repository(
 )
 ```
 
-For more information about the `android_ndk_repository` rule, see the [Build
-Encyclopedia entry](/versions/7.7.1/reference/be/android#android_ndk_repository).
+For more information about the `android_ndk_repository` rule, see the [Build Encyclopedia entry](/versions/7.7.1/reference/be/android#android_ndk_repository).
 
 If you're using a recent version of the Android NDK (r22 and beyond), use the
 Starlark implementation of `android_ndk_repository`.
@@ -101,13 +99,11 @@ META-INF/MANIFEST.MF
 
 Bazel compiles all of the cc_libraries into a single shared object (`.so`) file,
 targeted for the `armeabi-v7a` ABI by default. To change this or build for
-multiple ABIs at the same time, see the section on [configuring the target
-ABI](#configuring-target-abi).
+multiple ABIs at the same time, see the section on [configuring the target ABI](#configuring-target-abi).
 
 ## Example setup {#example-setup}
 
-This example is available in the [Bazel examples
-repository](https://github.com/bazelbuild/examples/tree/master/android/ndk).
+This example is available in the [Bazel examples repository](https://github.com/bazelbuild/examples/tree/master/android/ndk).
 
 In the `BUILD.bazel` file, three targets are defined with the `android_binary`,
 `android_library`, and `cc_library` rules.
@@ -178,12 +174,10 @@ For r16 and below, the default STL is `gnustl`. For r17 and above, it is
 `libc++`. For convenience, the target `@androidndk//:default_crosstool` is
 aliased to the respective default STLs.
 
-Please note that from r18 onwards, [STLport and gnustl will be
-removed](https://android.googlesource.com/platform/ndk/+/master/docs/Roadmap.md#ndk-r18),
+Please note that from r18 onwards, [STLport and gnustl will be removed](https://android.googlesource.com/platform/ndk/+/master/docs/Roadmap.md#ndk-r18),
 making `libc++` the only STL in the NDK.
 
-See the [NDK
-documentation](https://developer.android.com/ndk/guides/cpp-support)
+See the [NDK documentation](https://developer.android.com/ndk/guides/cpp-support)
 for more information on these STLs.
 
 ## Configuring the target ABI {#configuring-target-abi}
@@ -324,8 +318,7 @@ an Android-compatible configuration so that the Bazel build *just works* without
 any special flags, except for `--fat_apk_cpu` and `--android_crosstool_top` for
 ABI and STL configuration.
 
-Behind the scenes, this automatic configuration uses Android [configuration
-transitions](/versions/7.7.1/extending/rules#configurations).
+Behind the scenes, this automatic configuration uses Android [configuration transitions](/versions/7.7.1/extending/rules#configurations).
 
 A compatible rule, like `android_binary`, automatically changes the
 configuration of its dependencies to an Android configuration, so only
diff --git a/versions/7.7.1/docs/configurable-attributes.mdx b/versions/7.7.1/docs/configurable-attributes.mdx
index 342f6c74..765969b2 100644
--- a/versions/7.7.1/docs/configurable-attributes.mdx
+++ b/versions/7.7.1/docs/configurable-attributes.mdx
@@ -2,8 +2,7 @@
 title: 'Configurable Build Attributes'
 ---
 
-**_Configurable attributes_**, commonly known as [`select()`](
-/reference/be/functions#select), is a Bazel feature that lets users toggle the values
+**_Configurable attributes_**, commonly known as [`select()`](/reference/be/functions#select), is a Bazel feature that lets users toggle the values
 of build rule attributes at the command line.
 
 This can be used, for example, for a multiplatform library that automatically
@@ -407,8 +406,7 @@ sh_library(
 )
 ```
 
-If you need a `select` to match when multiple conditions match, consider [AND
-chaining](#and-chaining).
+If you need a `select` to match when multiple conditions match, consider [AND chaining](#and-chaining).
 
 ## OR chaining {#or-chaining}
 
diff --git a/versions/7.7.1/extending/depsets.mdx b/versions/7.7.1/extending/depsets.mdx
index a64fcf24..c9f14ca0 100644
--- a/versions/7.7.1/extending/depsets.mdx
+++ b/versions/7.7.1/extending/depsets.mdx
@@ -111,8 +111,7 @@ need to ensure that if `B` depends on `A`, then `A.o` comes before `B.o` on the
 linker’s command line. Other tools might have the opposite requirement.
 
 Three traversal orders are supported: `postorder`, `preorder`, and
-`topological`. The first two work exactly like [tree
-traversals](https://en.wikipedia.org/wiki/Tree_traversal#Depth-first_search)
+`topological`. The first two work exactly like [tree traversals](https://en.wikipedia.org/wiki/Tree_traversal#Depth-first_search)
 except that they operate on DAGs and skip already visited nodes. The third order
 works as a topological sort from root to leaves, essentially the same as
 preorder except that shared children are listed only after all of their parents.
diff --git a/versions/7.7.1/extending/exec-groups.mdx b/versions/7.7.1/extending/exec-groups.mdx
index 22808d61..c4b25b3b 100644
--- a/versions/7.7.1/extending/exec-groups.mdx
+++ b/versions/7.7.1/extending/exec-groups.mdx
@@ -63,8 +63,7 @@ test rules.
 
 In the rule implementation, you can declare that actions should be run on the
 execution platform of an execution group. You can do this by using the `exec_group`
-param of action generating methods, specifically [`ctx.actions.run`]
-(/rules/lib/builtins/actions#run) and
+param of action generating methods, specifically [`ctx.actions.run`](/rules/lib/builtins/actions#run) and
 [`ctx.actions.run_shell`](/versions/7.7.1/rules/lib/builtins/actions#run_shell).
 
 ```python
diff --git a/versions/7.7.1/extending/macros.mdx b/versions/7.7.1/extending/macros.mdx
index d35987d2..63e63f4c 100644
--- a/versions/7.7.1/extending/macros.mdx
+++ b/versions/7.7.1/extending/macros.mdx
@@ -212,8 +212,7 @@ def my_macro(name, deps, visibility=None):
     instantiate rules must have a `name` argument. This argument should not be
     optional (don't give a default value).
 
-*   Public functions should use a docstring following [Python
-    conventions](https://www.python.org/dev/peps/pep-0257/#one-line-docstrings).
+*   Public functions should use a docstring following [Python conventions](https://www.python.org/dev/peps/pep-0257/#one-line-docstrings).
 
 *   In `BUILD` files, the `name` argument of the macros must be a keyword
     argument (not a positional argument).
diff --git a/versions/7.7.1/extending/platforms.mdx b/versions/7.7.1/extending/platforms.mdx
index bdddc9a5..a16a241d 100644
--- a/versions/7.7.1/extending/platforms.mdx
+++ b/versions/7.7.1/extending/platforms.mdx
@@ -245,8 +245,7 @@ cc_library(
 
 You can use the
 [`IncompatiblePlatformProvider`](/versions/7.7.1/rules/lib/providers/IncompatiblePlatformProvider)
-in `bazel cquery`'s [Starlark output
-format](/versions/7.7.1/query/cquery#output-format-definition) to distinguish
+in `bazel cquery`'s [Starlark output format](/versions/7.7.1/query/cquery#output-format-definition) to distinguish
 incompatible targets from compatible ones.
 
 This can be used to filter out incompatible targets. The example below will
@@ -266,5 +265,4 @@ $ bazel cquery //... --output=starlark --starlark:file=example.cquery
 
 ### Known Issues
 
-Incompatible targets [ignore visibility
-restrictions](https://github.com/bazelbuild/bazel/issues/16044).
+Incompatible targets [ignore visibility restrictions](https://github.com/bazelbuild/bazel/issues/16044).
diff --git a/versions/7.7.1/extending/repo.mdx b/versions/7.7.1/extending/repo.mdx
index 8e879276..6296d90c 100644
--- a/versions/7.7.1/extending/repo.mdx
+++ b/versions/7.7.1/extending/repo.mdx
@@ -74,8 +74,7 @@ specified.
 
 The input parameter `repository_ctx` can be used to access attribute values, and
 non-hermetic functions (finding a binary, executing a binary, creating a file in
-the repository or downloading a file from the Internet). See [the API
-docs](/versions/7.7.1/rules/lib/builtins/repository_ctx) for more context. Example:
+the repository or downloading a file from the Internet). See [the API docs](/versions/7.7.1/rules/lib/builtins/repository_ctx) for more context. Example:
 
 ```python
 def _impl(repository_ctx):
@@ -144,8 +143,7 @@ definition has the `configure` attribute set, use `bazel fetch --force
 
 ## Examples
 
--   [C++ auto-configured
-    toolchain](https://cs.opensource.google/bazel/bazel/+/master:tools/cpp/cc_configure.bzl;drc=644b7d41748e09eff9e47cbab2be2263bb71f29a;l=176):
+-   [C++ auto-configured toolchain](https://cs.opensource.google/bazel/bazel/+/master:tools/cpp/cc_configure.bzl;drc=644b7d41748e09eff9e47cbab2be2263bb71f29a;l=176):
     it uses a repo rule to automatically create the C++ configuration files for
     Bazel by looking for the local C++ compiler, the environment and the flags
     the C++ compiler supports.
diff --git a/versions/7.7.1/extending/rules.mdx b/versions/7.7.1/extending/rules.mdx
index 3f298134..d8643b76 100644
--- a/versions/7.7.1/extending/rules.mdx
+++ b/versions/7.7.1/extending/rules.mdx
@@ -462,8 +462,7 @@ def _example_library_impl(ctx):
 
 If `DefaultInfo` is not returned by a rule implementation or the `files`
 parameter is not specified, `DefaultInfo.files` defaults to all
-*predeclared outputs* (generally, those created by [output
-attributes](#output_attributes)).
+*predeclared outputs* (generally, those created by [output attributes](#output_attributes)).
 
 Rules that perform actions should provide default outputs, even if those outputs
 are not expected to be directly used. Actions that are not in the graph of the
diff --git a/versions/7.7.1/external/advanced.mdx b/versions/7.7.1/external/advanced.mdx
index 1806c7b0..407e8059 100644
--- a/versions/7.7.1/external/advanced.mdx
+++ b/versions/7.7.1/external/advanced.mdx
@@ -4,10 +4,8 @@ title: 'Advanced topics on external dependencies'
 
 ## Shadowing dependencies in WORKSPACE
 
-Note: This section applies to the [WORKSPACE
-system](/versions/7.7.1/external/overview#workspace-system) only. For
-[Bzlmod](/versions/7.7.1/external/overview#bzlmod), use a [multiple-version
-override](/versions/7.7.1/external/module#multiple-version_override).
+Note: This section applies to the [WORKSPACE system](/versions/7.7.1/external/overview#workspace-system) only. For
+[Bzlmod](/versions/7.7.1/external/overview#bzlmod), use a [multiple-version override](/versions/7.7.1/external/module#multiple-version_override).
 
 Whenever possible, have a single version policy in your project, which is
 required for dependencies that you compile against and end up in your final
@@ -128,29 +126,24 @@ preferring IPv4 if enabled. In some situations, for example when the IPv4
 network cannot resolve/reach external addresses, this can cause `Network
 unreachable` exceptions and build failures. In these cases, you can override
 Bazel's behavior to prefer IPv6 by using the
-[`java.net.preferIPv6Addresses=true` system
-property](https://docs.oracle.com/javase/8/docs/api/java/net/doc-files/net-properties.html).
+[`java.net.preferIPv6Addresses=true` system property](https://docs.oracle.com/javase/8/docs/api/java/net/doc-files/net-properties.html).
 Specifically:
 
-*   Use `--host_jvm_args=-Djava.net.preferIPv6Addresses=true` [startup
-    option](/versions/7.7.1/docs/user-manual#startup-options), for example by adding the
+*   Use `--host_jvm_args=-Djava.net.preferIPv6Addresses=true` [startup option](/versions/7.7.1/docs/user-manual#startup-options), for example by adding the
     following line in your [`.bazelrc` file](/versions/7.7.1/run/bazelrc):
 
     `startup --host_jvm_args=-Djava.net.preferIPv6Addresses=true`
 
 *   When running Java build targets that need to connect to the internet (such
     as for integration tests), use the
-    `--jvmopt=-Djava.net.preferIPv6Addresses=true` [tool
-    flag](/versions/7.7.1/docs/user-manual#jvmopt). For example, include in your [`.bazelrc`
-    file](/versions/7.7.1/run/bazelrc):
+    `--jvmopt=-Djava.net.preferIPv6Addresses=true` [tool flag](/versions/7.7.1/docs/user-manual#jvmopt). For example, include in your [`.bazelrc` file](/versions/7.7.1/run/bazelrc):
 
     `build --jvmopt=-Djava.net.preferIPv6Addresses`
 
 *   If you are using [`rules_jvm_external`](https://github.com/bazelbuild/rules_jvm_external)
     for dependency version resolution, also add
     `-Djava.net.preferIPv6Addresses=true` to the `COURSIER_OPTS` environment
-    variable to [provide JVM options for
-    Coursier](https://github.com/bazelbuild/rules_jvm_external#provide-jvm-options-for-coursier-with-coursier_opts).
+    variable to [provide JVM options for Coursier](https://github.com/bazelbuild/rules_jvm_external#provide-jvm-options-for-coursier-with-coursier_opts).
 
 ## Offline builds
 
@@ -167,15 +160,12 @@ fetch a file with [`ctx.download`](/versions/7.7.1/rules/lib/builtins/repository
 providing a hash sum of the file needed, Bazel looks for a file matching the
 basename of the first URL, and uses the local copy if the hash matches.
 
-Bazel itself uses this technique to bootstrap offline from the [distribution
-artifact](https://github.com/bazelbuild/bazel-website/blob/master/designs/_posts/2016-10-11-distribution-artifact.md).
-It does so by [collecting all the needed external
-dependencies](https://github.com/bazelbuild/bazel/blob/5cfa0303d6ac3b5bd031ff60272ce80a704af8c2/WORKSPACE#L116)
+Bazel itself uses this technique to bootstrap offline from the [distribution artifact](https://github.com/bazelbuild/bazel-website/blob/master/designs/_posts/2016-10-11-distribution-artifact.md).
+It does so by [collecting all the needed external dependencies](https://github.com/bazelbuild/bazel/blob/5cfa0303d6ac3b5bd031ff60272ce80a704af8c2/WORKSPACE#L116)
 in an internal
 [`distdir_tar`](https://github.com/bazelbuild/bazel/blob/5cfa0303d6ac3b5bd031ff60272ce80a704af8c2/distdir.bzl#L44).
 
 Bazel allows execution of arbitrary commands in repository rules without knowing
 if they call out to the network, and so cannot enforce fully offline builds. To
 test if a build works correctly offline, manually block off the network (as
-Bazel does in its [bootstrap
-test](https://cs.opensource.google/bazel/bazel/+/master:src/test/shell/bazel/BUILD;l=1073;drc=88c426e73cc0eb0a41c0d7995e36acd94e7c9a48)).
\ No newline at end of file
+Bazel does in its [bootstrap test](https://cs.opensource.google/bazel/bazel/+/master:src/test/shell/bazel/BUILD;l=1073;drc=88c426e73cc0eb0a41c0d7995e36acd94e7c9a48)).
\ No newline at end of file
diff --git a/versions/7.7.1/external/migration.mdx b/versions/7.7.1/external/migration.mdx
index 9aa7e447..25fb84da 100644
--- a/versions/7.7.1/external/migration.mdx
+++ b/versions/7.7.1/external/migration.mdx
@@ -2,8 +2,7 @@
 title: 'Bzlmod Migration Guide'
 ---
 
-Due to the [shortcomings of
-WORKSPACE](/versions/7.7.1/external/overview#workspace-shortcomings), Bzlmod is going to
+Due to the [shortcomings of WORKSPACE](/versions/7.7.1/external/overview#workspace-shortcomings), Bzlmod is going to
 replace the legacy WORKSPACE system in future Bazel releases. This guide helps
 you migrate your project to Bzlmod and drop WORKSPACE for fetching external
 dependencies.
@@ -116,9 +115,7 @@ Bazel module when it also adopts Bzlmod.
 
 *   **Bzlmod**
 
-    With Bzlmod, as long as the your dependency is available in [Bazel Central
-    Registry](https://registry.bazel.build) or your custom [Bazel
-    registry](/versions/7.7.1/external/registry), you can simply depend on it with a
+    With Bzlmod, as long as the your dependency is available in [Bazel Central Registry](https://registry.bazel.build) or your custom [Bazel registry](/versions/7.7.1/external/registry), you can simply depend on it with a
     [`bazel_dep`](/versions/7.7.1/rules/lib/globals/module#bazel_dep) directive.
 
     ```python
@@ -149,8 +146,7 @@ repository.
 
 If your dependency is not a Bazel project or not yet available in any Bazel
 registry, you can introduce it using
-[`use_repo_rule`](/versions/7.7.1/external/module#use_repo_rule) or [module
-extensions](/versions/7.7.1/external/extension).
+[`use_repo_rule`](/versions/7.7.1/external/module#use_repo_rule) or [module extensions](/versions/7.7.1/external/extension).
 
 *   **WORKSPACE**
 
@@ -583,8 +579,7 @@ macros.
 Fortunately, the flag
 [`--experimental_repository_resolved_file`][resolved_file_flag]
 can help. This flag essentially generates a "lock file" of all fetched external
-dependencies in your last Bazel command. You can find more details in this [blog
-post](https://blog.bazel.build/2018/07/09/bazel-sync-and-resolved-file.html).
+dependencies in your last Bazel command. You can find more details in this [blog post](https://blog.bazel.build/2018/07/09/bazel-sync-and-resolved-file.html).
 
 [resolved_file_flag]: /reference/command-line-reference#flag--experimental_repository_resolved_file
 
@@ -625,11 +620,9 @@ You may also know `bazel query` can be used for inspecting repository rules with
 bazel query --output=build //external:
 ```
 
-While it is more convenient and much faster, [bazel query can lie about
-external dependency version](https://github.com/bazelbuild/bazel/issues/12947),
+While it is more convenient and much faster, [bazel query can lie about external dependency version](https://github.com/bazelbuild/bazel/issues/12947),
 so be careful using it! Querying and inspecting external
-dependencies with Bzlmod is going to achieved by a [new
-subcommand](https://github.com/bazelbuild/bazel/issues/15365).
+dependencies with Bzlmod is going to achieved by a [new subcommand](https://github.com/bazelbuild/bazel/issues/15365).
 
 #### Built-in default dependencies {#builtin-default-deps}
 
@@ -676,8 +669,7 @@ your workspace root.
 #### Repository visibility {#repository-visibility}
 
 Bzlmod is able to control which other repositories are visible from a given
-repository, check [repository names and strict
-deps](/versions/7.7.1/external/module#repository_names_and_strict_deps) for more details.
+repository, check [repository names and strict deps](/versions/7.7.1/external/module#repository_names_and_strict_deps) for more details.
 
 Here is a summary of repository visibilities from different types of
 repositories when also taking WORKSPACE into consideration.
@@ -690,8 +682,7 @@ repositories when also taking WORKSPACE into consideration.
 | WORKSPACE Repos | All visible | Not visible | Not visible | All visible |
 
 Note: For the root module, if a repository `@foo` is defined in WORKSPACE and
-`@foo` is also used as an [apparent repository
-name](/versions/7.7.1/external/overview#apparent-repo-name) in MODULE.bazel, then `@foo`
+`@foo` is also used as an [apparent repository name](/versions/7.7.1/external/overview#apparent-repo-name) in MODULE.bazel, then `@foo`
 refers to the one introduced in MODULE.bazel.
 
 Note: For a module extension generated repository `@bar`, if `@foo` is used as
@@ -766,9 +757,7 @@ the project. Take note of a few things when creating the source archive:
     GitHub isn't going to guarantee the checksum of source archives generated on
     demand. In short, URLs in the form of
     `https://github.com///releases/download/...` is considered stable
-    while `https://github.com///archive/...` is not. Check [GitHub
-    Archive Checksum
-    Outage](https://blog.bazel.build/2023/02/15/github-archive-checksum.html)
+    while `https://github.com///archive/...` is not. Check [GitHub Archive Checksum Outage](https://blog.bazel.build/2023/02/15/github-archive-checksum.html)
     for more context.
 
 *   **Make sure the source tree follows the layout of the original repository.**
@@ -797,8 +786,7 @@ Pull Request.
 
 [bcr_contrib_guide]: https://github.com/bazelbuild/bazel-central-registry/tree/main/docs#contribute-a-bazel-module
 
-It is **highly recommended** to set up the [Publish to
-BCR](https://github.com/bazel-contrib/publish-to-bcr) GitHub App for your
+It is **highly recommended** to set up the [Publish to BCR](https://github.com/bazel-contrib/publish-to-bcr) GitHub App for your
 repository to automate the process of submitting your module to the BCR.
 
 ## Best practices {#best-practices}
diff --git a/versions/7.7.1/external/mod-command.mdx b/versions/7.7.1/external/mod-command.mdx
index 7a2a9cce..4e1aa255 100644
--- a/versions/7.7.1/external/mod-command.mdx
+++ b/versions/7.7.1/external/mod-command.mdx
@@ -62,11 +62,9 @@ The available subcommands and their respective required arguments are:
 
 *   ``: All present versions of the module ``.
 
-*   `@`: The repo with the given [apparent
-    name](overview#apparent-repo-name) in the context of the `--base_module`.
+*   `@`: The repo with the given [apparent name](overview#apparent-repo-name) in the context of the `--base_module`.
 
-*   `@@`: The repo with the given [canonical
-    name](overview#canonical-repo-name).
+*   `@@`: The repo with the given [canonical name](overview#canonical-repo-name).
 
 In a context requiring specifying modules, ``s referring to repos that
 correspond to modules (as opposed to extension-generated repos) can also be
@@ -88,8 +86,7 @@ The following options only affect the subcommands that print graphs (`graph`,
     information about the version resolution of each module. If the module
     version changed during resolution, show either which version replaced it or
     what was the original version, the reason it was replaced, and which modules
-    requested the new version if the reason was [Minimal Version
-    Selection](module#version-selection).
+    requested the new version if the reason was [Minimal Version Selection](module#version-selection).
 
 *   `--include_unused` *default: "false"*: Include in the output graph the
     modules which were originally present in the dependency graph, but became
diff --git a/versions/7.7.1/external/module.mdx b/versions/7.7.1/external/module.mdx
index 8737fd70..62e7515d 100644
--- a/versions/7.7.1/external/module.mdx
+++ b/versions/7.7.1/external/module.mdx
@@ -122,8 +122,7 @@ serves multiple purposes:
     version, regardless of which versions of the dependency are requested in the
     dependency graph.
 *   With the `registry` attribute, you can force this dependency to come from a
-    specific registry, instead of following the normal [registry
-    selection](/versions/7.7.1/external/registry#selecting_registries) process.
+    specific registry, instead of following the normal [registry selection](/versions/7.7.1/external/registry#selecting_registries) process.
 *   With the `patch*` attributes, you can specify a set of patches to apply to
     the downloaded module.
 
@@ -176,13 +175,11 @@ With `bazel_dep`, you can define repos that represent other Bazel modules.
 Sometimes there is a need to define a repo that does _not_ represent a Bazel
 module; for example, one that contains a plain JSON file to be read as data.
 
-In this case, you could use the [`use_repo_rule`
-directive](/versions/7.7.1/rules/lib/globals/module#use_repo_rule) to directly define a repo
+In this case, you could use the [`use_repo_rule` directive](/versions/7.7.1/rules/lib/globals/module#use_repo_rule) to directly define a repo
 by invoking a repo rule. This repo will only be visible to the module it's
 defined in.
 
-Under the hood, this is implemented using the same mechanism as [module
-extensions](/versions/7.7.1/external/extension), which lets you define repos with more
+Under the hood, this is implemented using the same mechanism as [module extensions](/versions/7.7.1/external/extension), which lets you define repos with more
 flexibility.
 
 ## Repository names and strict deps
diff --git a/versions/7.7.1/external/overview.mdx b/versions/7.7.1/external/overview.mdx
index b04f978c..ee2ccc02 100644
--- a/versions/7.7.1/external/overview.mdx
+++ b/versions/7.7.1/external/overview.mdx
@@ -128,8 +128,7 @@ for all build targets inside the repo.
 
 The syntax of a `REPO.bazel` file is similar to `BUILD` files, except that no
 `load` statements are supported, and only a single function, `repo()`, is
-available. `repo()` takes the same arguments as the [`package()`
-function](/versions/7.7.1/reference/be/functions#package) in `BUILD` files; whereas `package()`
+available. `repo()` takes the same arguments as the [`package()` function](/versions/7.7.1/reference/be/functions#package) in `BUILD` files; whereas `package()`
 specifies common attributes for all build targets inside the package, `repo()`
 analogously does so for all build targets inside the repo.
 
@@ -163,8 +162,7 @@ bazel_dep(name = "protobuf", version = "3.19.0")
 ```
 
 A module must only list its direct dependencies, which Bzlmod looks up in a
-[Bazel registry](/versions/7.7.1/external/registry) — by default, the [Bazel Central
-Registry](https://bcr.bazel.build/). The registry provides the
+[Bazel registry](/versions/7.7.1/external/registry) — by default, the [Bazel Central Registry](https://bcr.bazel.build/). The registry provides the
 dependencies' `MODULE.bazel` files, which allows Bazel to discover the entire
 transitive dependency graph before performing version resolution.
 
@@ -235,5 +233,4 @@ many pain points, including:
         `B` and `C`; `B` and `C` both depend on different versions of `D`).
 
 Due to the shortcomings of WORKSPACE, Bzlmod is going to replace the legacy
-WORKSPACE system in future Bazel releases. Please read the [Bzlmod migration
-guide](/versions/7.7.1/external/migration) on how to migrate to Bzlmod.
\ No newline at end of file
+WORKSPACE system in future Bazel releases. Please read the [Bzlmod migration guide](/versions/7.7.1/external/migration) on how to migrate to Bzlmod.
\ No newline at end of file
diff --git a/versions/7.7.1/external/registry.mdx b/versions/7.7.1/external/registry.mdx
index 57b6ac6a..adc77646 100644
--- a/versions/7.7.1/external/registry.mdx
+++ b/versions/7.7.1/external/registry.mdx
@@ -42,8 +42,7 @@ An index registry must follow the format below:
             project
         *   `versions`: A list of all the versions of this module to be found in
             this registry
-        *   `yanked_versions`: A map of [*yanked*
-            versions](/versions/7.7.1/external/module#yanked_versions) of this module. The keys
+        *   `yanked_versions`: A map of [*yanked* versions](/versions/7.7.1/external/module#yanked_versions) of this module. The keys
             should be versions to yank and the values should be descriptions of
             why the version is yanked, ideally containing a link to more
             information
@@ -54,8 +53,7 @@ An index registry must follow the format below:
         *   The default type is "archive", representing an `http_archive` repo,
             with the following fields:
             *   `url`: The URL of the source archive
-            *   `integrity`: The [Subresource
-                Integrity](https://w3c.github.io/webappsec-subresource-integrity/#integrity-metadata-description)
+            *   `integrity`: The [Subresource Integrity](https://w3c.github.io/webappsec-subresource-integrity/#integrity-metadata-description)
                 checksum of the archive
             *   `strip_prefix`: A directory prefix to strip when extracting the
                 source archive
@@ -102,8 +100,7 @@ module, with the following fields:
 *   `versions`: An array of strings, each denoting a version of the module
     available in this registry. This array should match the children of the
     module directory.
-*   `yanked_versions`: A JSON object specifying the [*yanked*
-    versions](/versions/7.7.1/external/module#yanked_versions) of this module. The keys
+*   `yanked_versions`: A JSON object specifying the [*yanked* versions](/versions/7.7.1/external/module#yanked_versions) of this module. The keys
     should be versions to yank, and the values should be descriptions of
     why the version is yanked, ideally containing a link to more
     information.
@@ -171,8 +168,7 @@ You can browse its contents using the web frontend at
 https://registry.bazel.build/.
 
 The Bazel community maintains the BCR, and contributors are welcome to submit
-pull requests. See the [BCR contribution
-guidelines](https://github.com/bazelbuild/bazel-central-registry/blob/main/docs/README.md).
+pull requests. See the [BCR contribution guidelines](https://github.com/bazelbuild/bazel-central-registry/blob/main/docs/README.md).
 
 In addition to following the format of a normal index registry, the BCR requires
 a `presubmit.yml` file for each module version
diff --git a/versions/7.7.1/external/vendor.mdx b/versions/7.7.1/external/vendor.mdx
index 6efd16fe..89ed0877 100644
--- a/versions/7.7.1/external/vendor.mdx
+++ b/versions/7.7.1/external/vendor.mdx
@@ -23,9 +23,7 @@ absolute path.
 ## Vendor a specific external repository {#vendor-specific-repository}
 
 You can use the `vendor` command with the `--repo` flag to specify which repo
-to vendor, it accepts both [canonical repo
-name](/versions/7.7.1/external/overview#canonical-repo-name) and [apparent repo
-name](/versions/7.7.1/external/overview#apparent-repo-name).
+to vendor, it accepts both [canonical repo name](/versions/7.7.1/external/overview#canonical-repo-name) and [apparent repo name](/versions/7.7.1/external/overview#apparent-repo-name).
 
 For example, running:
 
diff --git a/versions/7.7.1/help.mdx b/versions/7.7.1/help.mdx
index 909c1074..47ae2300 100644
--- a/versions/7.7.1/help.mdx
+++ b/versions/7.7.1/help.mdx
@@ -45,5 +45,4 @@ what level of support Bazel provides.
 
 ## File a bug {#file-bug}
 
-If you encounter a bug or want to request a feature, file a [GitHub
-Issue](https://github.com/bazelbuild/bazel/issues).
+If you encounter a bug or want to request a feature, file a [GitHub Issue](https://github.com/bazelbuild/bazel/issues).
diff --git a/versions/7.7.1/install/bazelisk.mdx b/versions/7.7.1/install/bazelisk.mdx
index e9c3aaec..5ab2f98c 100644
--- a/versions/7.7.1/install/bazelisk.mdx
+++ b/versions/7.7.1/install/bazelisk.mdx
@@ -16,8 +16,7 @@ For more details, see
 ## Updating Bazel
 
 Bazel has a [backward compatibility policy](/versions/7.7.1/release/backward-compatibility)
-(see [guidance for rolling out incompatible
-changes](/versions/7.7.1/contribute/breaking-changes) if you
+(see [guidance for rolling out incompatible changes](/versions/7.7.1/contribute/breaking-changes) if you
 are the author of one). That page summarizes best practices on how to test and
 migrate your project with upcoming incompatible changes and how to provide
 feedback to the incompatible change authors.
diff --git a/versions/7.7.1/install/compile-source.mdx b/versions/7.7.1/install/compile-source.mdx
index 4dcb89fb..061badda 100644
--- a/versions/7.7.1/install/compile-source.mdx
+++ b/versions/7.7.1/install/compile-source.mdx
@@ -45,8 +45,7 @@ it by typing `bazel` in a terminal.
 
 **Reason**: To build Bazel from a GitHub source tree, you need a pre-existing
 Bazel binary. You can install one from a package manager or download one from
-GitHub. See [Installing Bazel](/versions/7.7.1/install). (Or you can [build from
-scratch (bootstrap)](#bootstrap-bazel).)
+GitHub. See [Installing Bazel](/versions/7.7.1/install). (Or you can [build from scratch (bootstrap)](#bootstrap-bazel).)
 
 **Troubleshooting**:
 
@@ -233,8 +232,7 @@ For instructions for Unix-like systems, see
     ```
 
 *   **The Visual C++ compiler.** Install the Visual C++ compiler either as part
-    of Visual Studio 2015 or newer, or by installing the latest [Build Tools
-    for Visual Studio 2017](https://aka.ms/BuildTools).
+    of Visual Studio 2015 or newer, or by installing the latest [Build Tools for Visual Studio 2017](https://aka.ms/BuildTools).
 
 *   **JDK.** Version 21 is required.
 
diff --git a/versions/7.7.1/install/ide.mdx b/versions/7.7.1/install/ide.mdx
index 561d0e02..c42d95e9 100644
--- a/versions/7.7.1/install/ide.mdx
+++ b/versions/7.7.1/install/ide.mdx
@@ -38,10 +38,8 @@ To install, go to the IDE's plugin browser and search for `Bazel`.
 To manually install older versions, download the zip files from JetBrains'
 Plugin Repository and install the zip file from the IDE's plugin browser:
 
-*  [Android Studio
-   plugin](https://plugins.jetbrains.com/plugin/9185-android-studio-with-bazel)
-*  [IntelliJ
-   plugin](https://plugins.jetbrains.com/plugin/8609-intellij-with-bazel)
+*  [Android Studio plugin](https://plugins.jetbrains.com/plugin/9185-android-studio-with-bazel)
+*  [IntelliJ plugin](https://plugins.jetbrains.com/plugin/8609-intellij-with-bazel)
 *  [CLion plugin](https://plugins.jetbrains.com/plugin/9554-clion-with-bazel)
 
 ### Xcode {#xcode}
@@ -61,8 +59,7 @@ Features:
 * Starlark debugger for `.bzl` files during a build (set breakpoints, step
   through code, inspect variables, and so on)
 
-Find [the plugin on the Visual Studio
-marketplace](https://marketplace.visualstudio.com/items?itemName=BazelBuild.vscode-bazel).
+Find [the plugin on the Visual Studio marketplace](https://marketplace.visualstudio.com/items?itemName=BazelBuild.vscode-bazel).
 The plugin is [open source](https://github.com/bazelbuild/vscode-bazel).
 
 See also: [Autocomplete for Source Code](#autocomplete-for-source-code)
@@ -82,8 +79,7 @@ See also: [Autocomplete for Source Code](#autocomplete-for-source-code)
 
 ### Emacs {#emacs}
 
-See [`bazelbuild/bazel-emacs-mode` on
-GitHub](https://github.com/bazelbuild/emacs-bazel-mode)
+See [`bazelbuild/bazel-emacs-mode` on GitHub](https://github.com/bazelbuild/emacs-bazel-mode)
 
 See also: [Autocomplete for Source Code](#autocomplete-for-source-code)
 
@@ -115,6 +111,5 @@ tool for building Bazel targets when source files change.
 
 ## Building your own IDE plugin {#build-own-plugin}
 
-Read the [**IDE support** blog
-post](https://blog.bazel.build/2016/06/10/ide-support.html) to learn more about
+Read the [**IDE support** blog post](https://blog.bazel.build/2016/06/10/ide-support.html) to learn more about
 the Bazel APIs to use when building an IDE plugin.
diff --git a/versions/7.7.1/install/windows.mdx b/versions/7.7.1/install/windows.mdx
index 65b93501..51143ce4 100644
--- a/versions/7.7.1/install/windows.mdx
+++ b/versions/7.7.1/install/windows.mdx
@@ -31,8 +31,7 @@ To check your Windows version:
 
 Alternatively you can:
 
-*   [Download the Bazel binary (`bazel-version-windows-x86_64.exe`) from
- GitHub](https://github.com/bazelbuild/bazel/releases).
+*   [Download the Bazel binary (`bazel-version-windows-x86_64.exe`) from GitHub](https://github.com/bazelbuild/bazel/releases).
 *   [Install Bazel from Chocolatey](#chocolately)
 *   [Install Bazel from Scoop](#scoop)
 *   [Build Bazel from source](/versions/7.7.1/install/compile-source)
@@ -208,8 +207,7 @@ If that doesn't help:
     its dependencies, such as the MSYS2 shell. This will not install Visual C++
     though.
 
-See [Chocolatey installation and package maintenance
-guide](/versions/7.7.1/contribute/windows-chocolatey-maintenance) for more
+See [Chocolatey installation and package maintenance guide](/versions/7.7.1/contribute/windows-chocolatey-maintenance) for more
 information about the Chocolatey package.
 
 ### Using Scoop {#scoop}
@@ -226,8 +224,7 @@ information about the Chocolatey package.
     scoop install bazel
     ```
 
-See [Scoop installation and package maintenance
-guide](/versions/7.7.1/contribute/windows-scoop-maintenance) for more
+See [Scoop installation and package maintenance guide](/versions/7.7.1/contribute/windows-scoop-maintenance) for more
 information about the Scoop package.
 
 ### Build from source {#build-from-source}
diff --git a/versions/7.7.1/query/cquery.mdx b/versions/7.7.1/query/cquery.mdx
index 58d4be98..28a72c23 100644
--- a/versions/7.7.1/query/cquery.mdx
+++ b/versions/7.7.1/query/cquery.mdx
@@ -6,8 +6,7 @@ title: ' Configurable Query (cquery)'
 [`select()`](/versions/7.7.1/docs/configurable-attributes) and build options' effects on the build
 graph.
 
-It achieves this by running over the results of Bazel's [analysis
-phase](/versions/7.7.1/extending/concepts#evaluation-model),
+It achieves this by running over the results of Bazel's [analysis phase](/versions/7.7.1/extending/concepts#evaluation-model),
 which integrates these effects. `query`, by contrast, runs over the results of
 Bazel's loading phase, before options are evaluated.
 
@@ -137,8 +136,7 @@ $ bazel cquery //foo --universe_scope=//foo,//genrule_with_foo_as_tool
 If you want to precisely declare which instance to query over, use
 the [`config`](#config) function.
 
-See `query`'s [target pattern
-documentation](/versions/7.7.1/query/language#target-patterns) for more information on target patterns.
+See `query`'s [target pattern documentation](/versions/7.7.1/query/language#target-patterns) for more information on target patterns.
 
 ## Functions {#functions}
 
diff --git a/versions/7.7.1/query/language.mdx b/versions/7.7.1/query/language.mdx
index 91c2be1f..979961fd 100644
--- a/versions/7.7.1/query/language.mdx
+++ b/versions/7.7.1/query/language.mdx
@@ -1100,8 +1100,7 @@ is being used.
 
 ### On the ordering of results {#results-ordering}
 
-Although query expressions always follow the "[law of
-conservation of graph order](#graph-order)", _presenting_ the results may be done
+Although query expressions always follow the "[law of conservation of graph order](#graph-order)", _presenting_ the results may be done
 in either a dependency-ordered or unordered manner. This does **not**
 influence the targets in the result set or how the query is computed. It only
 affects how the results are printed to stdout. Moreover, nodes that are
@@ -1246,8 +1245,7 @@ and `maxrank` output formats print the labels of each
 target in the resulting graph, but instead of appearing in
 topological order, they appear in rank order, preceded by their
 rank number. These are unaffected by the result ordering
-`--[no]order_results` flag (see [notes on
-the ordering of results](#result-order)).
+`--[no]order_results` flag (see [notes on the ordering of results](#result-order)).
 
 There are two variants of this format: `minrank` ranks
 each node by the length of the shortest path from a root node to it.
diff --git a/versions/7.7.1/reference/be/android.mdx b/versions/7.7.1/reference/be/android.mdx
index be748def..5e16b9f0 100644
--- a/versions/7.7.1/reference/be/android.mdx
+++ b/versions/7.7.1/reference/be/android.mdx
@@ -355,8 +355,7 @@ writing Robolectric tests.
 #### Examples
 
 To use Robolectric with `android_local_test`, add
-[Robolectric's
-repository](https://github.com/robolectric/robolectric-bazel/tree/master/bazel) to your `WORKSPACE` file:
+[Robolectric's repository](https://github.com/robolectric/robolectric-bazel/tree/master/bazel) to your `WORKSPACE` file:
 
 ```
 http_archive(
diff --git a/versions/7.7.1/reference/be/functions.mdx b/versions/7.7.1/reference/be/functions.mdx
index cee5bdd0..098bac21 100644
--- a/versions/7.7.1/reference/be/functions.mdx
+++ b/versions/7.7.1/reference/be/functions.mdx
@@ -250,8 +250,7 @@ There are several important limitations and caveats:
    package called "Foo.java" (which is allowed, though Bazel warns about it),
    then the consumer of the `glob()` will use the "Foo.java" rule
    (its outputs) instead of the "Foo.java" file. See
-   [GitHub
-   issue #10395](https://github.com/bazelbuild/bazel/issues/10395#issuecomment-583714657) for more details.
+   [GitHub issue #10395](https://github.com/bazelbuild/bazel/issues/10395#issuecomment-583714657) for more details.
 3. Globs may match files in subdirectories. And subdirectory names
    may be wildcarded. However...
 4. Labels are not allowed to cross the package boundary and glob does
diff --git a/versions/7.7.1/reference/be/java.mdx b/versions/7.7.1/reference/be/java.mdx
index 612d546b..89d89e4e 100644
--- a/versions/7.7.1/reference/be/java.mdx
+++ b/versions/7.7.1/reference/be/java.mdx
@@ -287,8 +287,7 @@ test code. The test runner's main method is invoked instead of the main class be
   [java\_binary](#java_binary) for more details.
 
 See the section on [java\_binary()](/versions/7.7.1/reference/be/java#java_binary_args) arguments. This rule also
-supports all [attributes common
-to all test rules (\*\_test)](/versions/7.7.1/reference/be/common-definitions#common-attributes-tests).
+supports all [attributes common to all test rules (\*\_test)](/versions/7.7.1/reference/be/common-definitions#common-attributes-tests).
 
 #### Examples
 
diff --git a/versions/7.7.1/reference/be/make-variables.mdx b/versions/7.7.1/reference/be/make-variables.mdx
index 3a021a01..e8579a8d 100644
--- a/versions/7.7.1/reference/be/make-variables.mdx
+++ b/versions/7.7.1/reference/be/make-variables.mdx
@@ -19,8 +19,7 @@ targets, and *custom* variables, which are defined in dependency targets
 and only available to targets that depend on them.
 
 The reason for the term "Make" is historical: the syntax and semantics of
-these variables were originally intended to match [GNU
-Make](https://www.gnu.org/software/make/manual/html_node/Using-Variables.html).
+these variables were originally intended to match [GNU Make](https://www.gnu.org/software/make/manual/html_node/Using-Variables.html).
 
 ## Use
 
@@ -64,8 +63,7 @@ and look at the top output lines with capital letters.
 **Toolchain option variables**
 
 * `COMPILATION_MODE`:
-  `fastbuild`, `dbg`, or `opt`. ([more
-  details](https://bazel.build/versions/7.7.1/docs/user-manual#flag--compilation_mode))
+  `fastbuild`, `dbg`, or `opt`. ([more details](https://bazel.build/versions/7.7.1/docs/user-manual#flag--compilation_mode))
 
 **Path variables**
 
diff --git a/versions/7.7.1/reference/be/objective-c.mdx b/versions/7.7.1/reference/be/objective-c.mdx
index a1ba1263..ada7583d 100644
--- a/versions/7.7.1/reference/be/objective-c.mdx
+++ b/versions/7.7.1/reference/be/objective-c.mdx
@@ -21,8 +21,7 @@ j2objc_library(name, deps, compatible_with, deprecation, distribs, entry_classes
 
 This rule uses [J2ObjC](https://github.com/google/j2objc) to translate Java source
 files to Objective-C, which then can be used used as dependencies of objc\_library and objc\_binary
-rules. Detailed information about J2ObjC itself can be found at [the
-J2ObjC site](http://j2objc.org)
+rules. Detailed information about J2ObjC itself can be found at [the J2ObjC site](http://j2objc.org)
 
 Custom J2ObjC transpilation flags can be specified using the build flag
 `--j2objc_translation_flags` in the command line.
diff --git a/versions/7.7.1/reference/be/workspace.mdx b/versions/7.7.1/reference/be/workspace.mdx
index 0a2eb48e..7134279b 100644
--- a/versions/7.7.1/reference/be/workspace.mdx
+++ b/versions/7.7.1/reference/be/workspace.mdx
@@ -25,8 +25,7 @@ bind(name, actual, compatible_with, deprecation, distribs, features, licenses, r
 
 *Warning: use of `bind()` is not recommended. See "[Consider removing bind](https://github.com/bazelbuild/bazel/issues/1952)" for a long
 discussion of its issues and alternatives. In particular, consider the use of
-[`repo_mapping`
-repository attributes](https://bazel.build/versions/7.7.1/rules/repository_rules#attributes).*
+[`repo_mapping` repository attributes](https://bazel.build/versions/7.7.1/rules/repository_rules#attributes).*
 
 *Warning: `select()` cannot be used in `bind()`. See the [Configurable Attributes FAQ](/versions/7.7.1/docs/configurable-attributes#bind-select) for
 details.*
@@ -114,8 +113,7 @@ local_repository(name, path, repo_mapping)
 ```
 
 Allows targets from a local directory to be bound. This means that the current repository can
-use targets defined in this other directory. See the [bind
-section](/versions/7.7.1/reference/be/workspace#bind_examples) for more details.
+use targets defined in this other directory. See the [bind section](/versions/7.7.1/reference/be/workspace#bind_examples) for more details.
 
 #### Examples
 
diff --git a/versions/7.7.1/reference/glossary.mdx b/versions/7.7.1/reference/glossary.mdx
index 2ea19b3a..8a607d09 100644
--- a/versions/7.7.1/reference/glossary.mdx
+++ b/versions/7.7.1/reference/glossary.mdx
@@ -21,8 +21,7 @@ An in-memory graph of [actions](#action) and the [artifacts](#artifact) that
 these actions read and generate. The graph might include artifacts that exist as
 source files (for example, in the file system) as well as generated
 intermediate/final artifacts that are not mentioned in `BUILD` files. Produced
-during the [analysis phase](#analysis-phase) and used during the [execution
-phase](#execution-phase).
+during the [analysis phase](#analysis-phase) and used during the [execution phase](#execution-phase).
 
 ### Action graph query (aquery) {#action-graph-query}
 A [query](#query-concept) tool that can query over build [actions](#action).
@@ -37,8 +36,7 @@ invalidate individual actions deterministically.
 
 ### Analysis phase {#analysis-phase}
 The second phase of a build. Processes the [target graph](#target-graph)
-specified in [`BUILD` files](#build-file) to produce an in-memory [action
-graph](#action-graph) that determines the order of actions to run during the
+specified in [`BUILD` files](#build-file) to produce an in-memory [action graph](#action-graph) that determines the order of actions to run during the
 [execution phase](#execution-phase). This is the phase in which rule
 implementations are evaluated.
 
@@ -81,8 +79,7 @@ target's source files, dependencies, and custom compiler options. The particular
 attributes available for a given target depend on its rule type.
 
 ### .bazelrc {#bazelrc}
-Bazel’s configuration file used to change the default values for [startup
-flags](#startup-flags) and [command flags](#command-flags), and to define common
+Bazel’s configuration file used to change the default values for [startup flags](#startup-flags) and [command flags](#command-flags), and to define common
 groups of options that can then be set together on the Bazel command line using
 a `--config` flag. Bazel can combine settings from multiple bazelrc files
 (systemwide, per-workspace, per-user, or from a custom location), and a
@@ -108,8 +105,7 @@ directory.
 
 ### .bzl File {#bzl-file}
 A file that defines rules, [macros](#macro), and constants written in
-[Starlark](#starlark). These can then be imported into [`BUILD`
-files](#build-file) using the `load()` function.
+[Starlark](#starlark). These can then be imported into [`BUILD` files](#build-file) using the `load()` function.
 
 {/* TODO: ### Build event protocol */}
 
@@ -117,8 +113,7 @@ files](#build-file) using the `load()` function.
 
 ### Build graph {#build-graph}
 The dependency graph that Bazel constructs and traverses to perform a build.
-Includes nodes like [targets](#target), [configured
-targets](#configured-target), [actions](#action), and [artifacts](#artifact). A
+Includes nodes like [targets](#target), [configured targets](#configured-target), [actions](#action), and [artifacts](#artifact). A
 build is considered complete when all [artifacts](#artifact) on which a set of
 requested targets depend are verified as up-to-date.
 
@@ -158,8 +153,7 @@ graphs and restart the [analysis phase](#analysis-phase).
 ### Configuration {#configuration}
 Information outside of [rule](#rule) definitions that impacts how rules generate
 [actions](#action). Every build has at least one configuration specifying the
-target platform, action environment variables, and command-line [build
-flags](#command-flags). [Transitions](#transition) may create additional
+target platform, action environment variables, and command-line [build flags](#command-flags). [Transitions](#transition) may create additional
 configurations, such as for host tools or cross-compilation.
 
 **See also:** [Configurations](/versions/7.7.1/extending/rules#configurations)
@@ -174,8 +168,7 @@ configuration of `//:c` because changing `--javacopt` unnecessarily breaks C++
 build cacheability.
 
 ### Configured query (cquery) {#configured-query}
-A [query](#query-concept) tool that queries over [configured
-targets](#configured-target) (after the [analysis phase](#analysis-phase)
+A [query](#query-concept) tool that queries over [configured targets](#configured-target) (after the [analysis phase](#analysis-phase)
 completes). This means `select()` and [build flags](#command-flags) (such as
 `--platforms`) are accurately reflected in the results.
 
@@ -191,8 +184,7 @@ build, it has two configured targets: `` and ``.
 ### Correctness {#correctness}
 A build is correct when its output faithfully reflects the state of its
 transitive inputs. To achieve correct builds, Bazel strives to be
-[hermetic](#hermeticity), reproducible, and making [build
-analysis](#analysis-phase) and [action execution](#execution-phase)
+[hermetic](#hermeticity), reproducible, and making [build analysis](#analysis-phase) and [action execution](#execution-phase)
 deterministic.
 
 ### Dependency {#dependency}
@@ -234,8 +226,7 @@ compilation). A dynamic execution strategy can provide the best possible
 incremental and clean build times.
 
 ### Execution phase {#execution-phase}
-The third phase of a build. Executes the [actions](#action) in the [action
-graph](#action-graph) created during the [analysis phase](#analysis-phase).
+The third phase of a build. Executes the [actions](#action) in the [action graph](#action-graph) created during the [analysis phase](#analysis-phase).
 These actions invoke executables (compilers, scripts) to read and write
 [artifacts](#artifact). *Spawn strategies* control how these actions are
 executed: locally, remotely, dynamically, sandboxed, docker, and so on.
@@ -285,8 +276,7 @@ syntax may be omitted.
 The first phase of a build where Bazel executes [`BUILD` files](#build-file) to
 create [packages](#package). [Macros](#macro) and certain functions like
 `glob()` are evaluated in this phase. Interleaved with the second phase of the
-build, the [analysis phase](#analysis-phase), to build up a [target
-graph](#target-graph).
+build, the [analysis phase](#analysis-phase), to build up a [target graph](#target-graph).
 
 ### Macro {#macro}
 A mechanism to compose multiple [rule](#rule) target declarations together under
@@ -321,8 +311,7 @@ Module metadata is hosted in Bazel registries.
 
 ### Module Extension {#module-extension}
 A piece of logic that can be run to generate [repos](#repository) by reading
-inputs from across the [module](#module) dependency graph and invoking [repo
-rules](#repository-rule). Module extensions have capabilities similar to repo
+inputs from across the [module](#module) dependency graph and invoking [repo rules](#repository-rule). Module extensions have capabilities similar to repo
 rules, allowing them to access the internet, perform file I/O, and so on.
 
 **See also:** [Module extensions](/versions/7.7.1/external/extension)
@@ -335,8 +324,7 @@ example, `native.cc_library` or `native.java_library`). User-defined rules
 
 ### Output base {#output-base}
 A [workspace](#workspace)-specific directory to store Bazel output files. Used
-to separate outputs from the *workspace*'s source tree (the [main
-repo](#repository)). Located in the [output user root](#output-user-root).
+to separate outputs from the *workspace*'s source tree (the [main repo](#repository)). Located in the [output user root](#output-user-root).
 
 ### Output groups {#output-groups}
 A group of files that is expected to be built when Bazel finishes building a
@@ -391,8 +379,7 @@ query variants: [query](#query-command), [cquery](#configured-query), and
 [aquery](#action-graph-query).
 
 ### query (command) {#query-command}
-A [query](#query-concept) tool that operates over the build's post-[loading
-phase](#loading-phase) [target graph](#target-graph). This is relatively fast,
+A [query](#query-concept) tool that operates over the build's post-[loading phase](#loading-phase) [target graph](#target-graph). This is relatively fast,
 but can't analyze the effects of `select()`, [build flags](#command-flags),
 [artifacts](#artifact), or build [actions](#action).
 
@@ -410,8 +397,7 @@ repo; multiple such files can coexist in a directory.
 The *main repo* is the repo in which the current Bazel command is being run.
 
 *External repos* are defined by specifying [modules](#module) in `MODULE.bazel`
-files, or invoking [repo rules](#repository-rule) in [module
-extensions](#module-extension). They can be fetched on demand to a predetermined
+files, or invoking [repo rules](#repository-rule) in [module extensions](#module-extension). They can be fetched on demand to a predetermined
 "magical" location on disk.
 
 Each repo has a unique, constant *canonical* name, and potentially different
@@ -422,8 +408,7 @@ Each repo has a unique, constant *canonical* name, and potentially different
 ### Repository cache {#repo-cache}
 A shared content-addressable cache of files downloaded by Bazel for builds,
 shareable across [workspaces](#workspace). Enables offline builds after the
-initial download. Commonly used to cache files downloaded through [repository
-rules](#repository-rule) like `http_archive` and repository rule APIs like
+initial download. Commonly used to cache files downloaded through [repository rules](#repository-rule) like `http_archive` and repository rule APIs like
 `repository_ctx.download`. Files are cached only if their SHA-256 checksums are
 specified for the download.
 
@@ -457,8 +442,7 @@ Rules are instantiated to produce rule targets in the
 [loading phase](#loading-phase). In the [analysis phase](#analysis-phase) rule
 targets communicate information to their downstream dependencies in the form of
 [providers](#provider), and register [actions](#action) describing how to
-generate their output artifacts. These actions are run in the [execution
-phase](#execution-phase).
+generate their output artifacts. These actions are run in the [execution phase](#execution-phase).
 
 Note: Historically the term "rule" has been used to refer to a rule target.
 This usage was inherited from tools like Make, but causes confusion and should
@@ -502,8 +486,7 @@ support the stamp attribute.
 ### Starlark {#starlark}
 The extension language for writing [rules](/versions/7.7.1/extending/rules) and [macros](#macro). A
 restricted subset of Python (syntactically and grammatically) aimed for the
-purpose of configuration, and for better performance. Uses the [`.bzl`
-file](#bzl-file) extension. [`BUILD` files](#build-file) use an even more
+purpose of configuration, and for better performance. Uses the [`.bzl` file](#bzl-file) extension. [`BUILD` files](#build-file) use an even more
 restricted version of Starlark (such as no `def` function definitions), formerly
 known as Skylark.
 
@@ -525,8 +508,7 @@ An object that is defined in a [`BUILD` file](#build-file) and identified by a
 [label](#label). Targets represent the buildable units of a workspace from
 the perspective of the end user.
 
-A target that is declared by instantiating a [rule](#rule) is called a [rule
-target](#rule-target). Depending on the rule, these may be runnable (like
+A target that is declared by instantiating a [rule](#rule) is called a [rule target](#rule-target). Depending on the rule, these may be runnable (like
 `cc_binary`) or testable (like `cc_test`). Rule targets typically depend on
 other targets via their [attributes](#attribute) (such as `deps`); these
 dependencies form the basis of the [target graph](#target-graph).
@@ -537,14 +519,11 @@ within a `BUILD` file. As a special case, the `BUILD` file of any package is
 always considered a source file target in that package.
 
 Targets are discovered during the [loading phase](#loading-phase). During the
-[analysis phase](#analysis-phase), targets are associated with [build
-configurations](#configuration) to form [configured
-targets](#configured-target).
+[analysis phase](#analysis-phase), targets are associated with [build configurations](#configuration) to form [configured targets](#configured-target).
 
 ### Target graph {#target-graph}
 An in-memory graph of [targets](#target) and their dependencies. Produced during
-the [loading phase](#loading-phase) and used as an input to the [analysis
-phase](#analysis-phase).
+the [loading phase](#loading-phase) and used as an input to the [analysis phase](#analysis-phase).
 
 ### Target pattern {#target-pattern}
 A way to specify a group of [targets](#target) on the command line. Commonly
@@ -557,8 +536,7 @@ packages recursively from the root of the [workspace](#workspace).
 Rule [targets](#target) instantiated from test rules, and therefore contains a
 test executable. A return code of zero from the completion of the executable
 indicates test success. The exact contract between Bazel and tests (such as test
-environment variables, test result collection methods) is specified in the [Test
-Encyclopedia](/versions/7.7.1/reference/test-encyclopedia).
+environment variables, test result collection methods) is specified in the [Test Encyclopedia](/versions/7.7.1/reference/test-encyclopedia).
 
 ### Toolchain {#toolchain}
 A set of tools to build outputs for a language. Typically, a toolchain includes
@@ -572,8 +550,7 @@ A build [target](#target) is top-level if it’s requested on the Bazel command
 line. For example, if `//:foo` depends on `//:bar`, and `bazel build //:foo` is
 called, then for this build, `//:foo` is top-level, and `//:bar` isn’t
 top-level, although both targets will need to be built. An important difference
-between top-level and non-top-level targets is that [command
-flags](#command-flags) set on the Bazel command line (or via
+between top-level and non-top-level targets is that [command flags](#command-flags) set on the Bazel command line (or via
 [.bazelrc](#bazelrc)) will set the [configuration](#configuration) for top-level
 targets, but might be modified by a [transition](#transition) for non-top-level
 targets.
@@ -604,8 +581,7 @@ or `.bzl` file may load a given `.bzl` file. Without context, usually
 **See also:** [Visibility documentation](/versions/7.7.1/concepts/visibility)
 
 ### Workspace {#workspace}
-The environment shared by all Bazel commands run from the same [main
-repository](#repository).
+The environment shared by all Bazel commands run from the same [main repository](#repository).
 
 Note that historically the concepts of "repository" and "workspace" have been
 conflated; the term "workspace" has often been used to refer to the main
diff --git a/versions/7.7.1/release/backward-compatibility.mdx b/versions/7.7.1/release/backward-compatibility.mdx
index 6a92d718..d5a2024a 100644
--- a/versions/7.7.1/release/backward-compatibility.mdx
+++ b/versions/7.7.1/release/backward-compatibility.mdx
@@ -6,11 +6,9 @@ This page provides information about how to handle backward compatibility,
 including migrating from one release to another and how to communicate
 incompatible changes.
 
-Bazel is evolving. Minor versions released as part of an [LTS major
-version](/versions/7.7.1/release#bazel-versioning) are fully backward-compatible. New major LTS
+Bazel is evolving. Minor versions released as part of an [LTS major version](/versions/7.7.1/release#bazel-versioning) are fully backward-compatible. New major LTS
 releases may contain incompatible changes that require some migration effort.
-For more information about Bazel's release model, please check out the [Release
-Model](/versions/7.7.1/release) page.
+For more information about Bazel's release model, please check out the [Release Model](/versions/7.7.1/release) page.
 
 ## Summary {#summary}
 
@@ -59,8 +57,7 @@ available.
 ## Communicating incompatible changes {#communicating-incompatible-changes}
 
 The primary source of information about incompatible changes are GitHub issues
-marked with an ["incompatible-change"
-label](https://github.com/bazelbuild/bazel/issues?q=label%3Aincompatible-change).
+marked with an ["incompatible-change" label](https://github.com/bazelbuild/bazel/issues?q=label%3Aincompatible-change).
 
 For every incompatible change, the issue specifies the following:
 
diff --git a/versions/7.7.1/release/index.mdx b/versions/7.7.1/release/index.mdx
index 0b924197..f07c1475 100644
--- a/versions/7.7.1/release/index.mdx
+++ b/versions/7.7.1/release/index.mdx
@@ -2,16 +2,14 @@
 title: 'Release Model'
 ---
 
-As announced in [the original blog
-post](https://blog.bazel.build/2020/11/10/long-term-support-release.html), Bazel
+As announced in [the original blog post](https://blog.bazel.build/2020/11/10/long-term-support-release.html), Bazel
 4.0 and higher versions provides support for two release tracks: rolling
 releases and long term support (LTS) releases. This page covers the latest
 information about Bazel's release model.
 
 ## Release versioning {#bazel-versioning}
 
-Bazel uses a _major.minor.patch_ [Semantic
-Versioning](https://semver.org/) scheme.
+Bazel uses a _major.minor.patch_ [Semantic Versioning](https://semver.org/) scheme.
 
 *   A _major release_ contains features that are not backward compatible with
     the previous release. Each major Bazel version is an LTS release.
@@ -54,8 +52,7 @@ Bazel regularly publish releases for two release tracks.
     release.
 *   Rolling releases can ship incompatible changes. Incompatible flags are
     recommended for major breaking changes, rolling out incompatible changes
-    should follow our [backward compatibility
-    policy](/versions/7.7.1/release/backward-compatibility).
+    should follow our [backward compatibility policy](/versions/7.7.1/release/backward-compatibility).
 
 ### LTS releases {#lts-releases}
 
@@ -71,8 +68,7 @@ Bazel regularly publish releases for two release tracks.
 *   A Bazel LTS release enters the Deprecated stage after being in ​​the
     Maintenance stage for 2 years.
 
-For planned releases, please check our [release
-issues](https://github.com/bazelbuild/bazel/issues?q=is%3Aopen+is%3Aissue+label%3Arelease)
+For planned releases, please check our [release issues](https://github.com/bazelbuild/bazel/issues?q=is%3Aopen+is%3Aissue+label%3Arelease)
 on Github.
 
 ## Support matrix {#support-matrix}
@@ -84,8 +80,7 @@ on Github.
 | Bazel 5 | Maintenance | [5.4.1](https://github.com/bazelbuild/bazel/releases/tag/5.4.1) | Jan 2025 |
 | Bazel 4 | Maintenance | [4.2.4](https://github.com/bazelbuild/bazel/releases/tag/4.2.4) | Jan 2024 |
 
-All Bazel releases can be found on the [release
-page](https://github.com/bazelbuild/bazel/releases) on GitHub.
+All Bazel releases can be found on the [release page](https://github.com/bazelbuild/bazel/releases) on GitHub.
 
 Note: Bazel version older than Bazel 4 are no longer supported, Bazel users are
 recommended to upgrade to the latest LTS release or use rolling releases if you
@@ -117,8 +112,7 @@ For LTS releases, the procedure and policies below are followed:
 1.  Identify release blockers and fix issues found on the release branch.
     *   The release branch is tested with the same test suite in
         [postsubmit](https://buildkite.com/bazel/bazel-bazel) and
-        [downstream test pipeline]
-        (https://buildkite.com/bazel/bazel-at-head-plus-downstream)
+        [downstream test pipeline](https://buildkite.com/bazel/bazel-at-head-plus-downstream)
         on Bazel CI. The Bazel team monitors testing results of the release
         branch and fixes any regressions found.
 1.  Create a new release candidate from the release branch when all known
@@ -170,5 +164,4 @@ feature.
 ## Rule compatibility {#rule-compatibility}
 
 If you are a rule authors and want to maintain compatibility with different
-Bazel versions, please check out the [Rule
-Compatibility](/versions/7.7.1/release/rule-compatibility) page.
\ No newline at end of file
+Bazel versions, please check out the [Rule Compatibility](/versions/7.7.1/release/rule-compatibility) page.
\ No newline at end of file
diff --git a/versions/7.7.1/release/rule-compatibility.mdx b/versions/7.7.1/release/rule-compatibility.mdx
index c9ee8aef..91a192d5 100644
--- a/versions/7.7.1/release/rule-compatibility.mdx
+++ b/versions/7.7.1/release/rule-compatibility.mdx
@@ -53,18 +53,15 @@ Bazel LTS release.
 As Bazel rules authors, you can ensure a manageable migration process for users
 by following these best practices:
 
-1.  The rule should follow [Semantic
-    Versioning](https://semver.org/): minor versions of the same
+1.  The rule should follow [Semantic Versioning](https://semver.org/): minor versions of the same
     major version are backward compatible.
 1.  The rule at HEAD should be compatible with the latest Bazel LTS release.
 1.  The rule at HEAD should be compatible with Bazel at HEAD. To achieve this,
     you can
     *   Set up your own CI testing with Bazel at HEAD
-    *   Add your project to [Bazel downstream
-        testing](https://github.com/bazelbuild/continuous-integration/blob/master/docs/downstream-testing.md);
+    *   Add your project to [Bazel downstream testing](https://github.com/bazelbuild/continuous-integration/blob/master/docs/downstream-testing.md);
         the Bazel team files issues to your project if breaking changes in Bazel
-        affect your project, and you must follow our [downstream project
-        policies](https://github.com/bazelbuild/continuous-integration/blob/master/docs/downstream-testing.md#downstream-project-policies)
+        affect your project, and you must follow our [downstream project policies](https://github.com/bazelbuild/continuous-integration/blob/master/docs/downstream-testing.md#downstream-project-policies)
         to address issues timely.
 1.  The latest major version of the rule must be compatible with the latest
     Bazel LTS release.
diff --git a/versions/7.7.1/remote/bep-glossary.mdx b/versions/7.7.1/remote/bep-glossary.mdx
index 1b3a10f9..0aa17c5d 100644
--- a/versions/7.7.1/remote/bep-glossary.mdx
+++ b/versions/7.7.1/remote/bep-glossary.mdx
@@ -411,5 +411,4 @@ workspace, such as the execution root.
 
 ## WorkspaceStatus {#workspacestatus}
 
-A single `WorkspaceStatus` event contains the result of the [workspace status
-command](/versions/7.7.1/docs/user-manual#workspace-status).
+A single `WorkspaceStatus` event contains the result of the [workspace status command](/versions/7.7.1/docs/user-manual#workspace-status).
diff --git a/versions/7.7.1/remote/bep.mdx b/versions/7.7.1/remote/bep.mdx
index a76b0949..641b2e7f 100644
--- a/versions/7.7.1/remote/bep.mdx
+++ b/versions/7.7.1/remote/bep.mdx
@@ -2,14 +2,12 @@
 title: 'Build Event Protocol'
 ---
 
-The [Build Event
-Protocol](https://github.com/bazelbuild/bazel/blob/master/src/main/java/com/google/devtools/build/lib/buildeventstream/proto/build_event_stream.proto)
+The [Build Event Protocol](https://github.com/bazelbuild/bazel/blob/master/src/main/java/com/google/devtools/build/lib/buildeventstream/proto/build_event_stream.proto)
 (BEP) allows third-party programs to gain insight into a Bazel invocation. For
 example, you could use the BEP to gather information for an IDE
 plugin or a dashboard that displays build results.
 
-The protocol is a set of [protocol
-buffer](https://developers.google.com/protocol-buffers/) messages with some
+The protocol is a set of [protocol buffer](https://developers.google.com/protocol-buffers/) messages with some
 semantics defined on top of it. It includes information about build and test
 results, build progress, the build configuration and much more. The BEP is
 intended to be consumed programmatically and makes parsing Bazel’s
@@ -20,16 +18,13 @@ build event is a protocol buffer message consisting of a build event identifier,
 a set of child event identifiers, and a payload.
 
 *  __Build Event Identifier:__ Depending on the kind of build event, it might be
-an [opaque
-string](https://github.com/bazelbuild/bazel/blob/16a107d/src/main/java/com/google/devtools/build/lib/buildeventstream/proto/build_event_stream.proto#L91)
-or [structured
-information](https://github.com/bazelbuild/bazel/blob/16a107d/src/main/java/com/google/devtools/build/lib/buildeventstream/proto/build_event_stream.proto#L123)
+an [opaque string](https://github.com/bazelbuild/bazel/blob/16a107d/src/main/java/com/google/devtools/build/lib/buildeventstream/proto/build_event_stream.proto#L91)
+or [structured information](https://github.com/bazelbuild/bazel/blob/16a107d/src/main/java/com/google/devtools/build/lib/buildeventstream/proto/build_event_stream.proto#L123)
 revealing more about the build event. A build event identifier is unique within
 a build.
 
 *  __Children:__ A build event may announce other build events, by including
-their build event identifiers in its [children
-field](https://github.com/bazelbuild/bazel/blob/16a107d/src/main/java/com/google/devtools/build/lib/buildeventstream/proto/build_event_stream.proto#L469).
+their build event identifiers in its [children field](https://github.com/bazelbuild/bazel/blob/16a107d/src/main/java/com/google/devtools/build/lib/buildeventstream/proto/build_event_stream.proto#L469).
 For example, the `PatternExpanded` build event announces the targets it expands
 to as children. The protocol guarantees that all events, except for the first
 event, are announced by a previous event.
@@ -91,8 +86,7 @@ human-readable formats, such as text and JSON:
 
 ## Build Event Service {#build-event-service}
 
-The [Build Event
-Service](https://github.com/googleapis/googleapis/blob/master/google/devtools/build/v1/publish_build_event.proto)
+The [Build Event Service](https://github.com/googleapis/googleapis/blob/master/google/devtools/build/v1/publish_build_event.proto)
 Protocol is a generic [gRPC](https://www.grpc.io) service for publishing build events. The Build Event
 Service protocol is independent of the BEP and treats BEP events as opaque bytes.
 Bazel ships with a gRPC client implementation of the Build Event Service protocol that
@@ -137,8 +131,7 @@ For a description of each of these flags, see the
 The BEP typically contains many references to log files (test.log, test.xml,
 etc. ) stored on the machine where Bazel is running. A remote BES server
 typically can't access these files as they are on different machines. A way to
-work around this issue is to use Bazel with [remote
-caching](/versions/7.7.1/remote/caching).
+work around this issue is to use Bazel with [remote caching](/versions/7.7.1/remote/caching).
 Bazel will upload all output files to the remote cache (including files
 referenced in the BEP) and the BES server can then fetch the referenced files
 from the cache.
diff --git a/versions/7.7.1/remote/cache-local.mdx b/versions/7.7.1/remote/cache-local.mdx
index fedb8871..7332f9dd 100644
--- a/versions/7.7.1/remote/cache-local.mdx
+++ b/versions/7.7.1/remote/cache-local.mdx
@@ -18,8 +18,7 @@ execution. However, local execution presents some additional challenges.
 ## Checking your cache hit rate {#cache-hits}
 
 Successful remote cache hits will show up in the status line, similar to
-[Cache Hits rate with Remote
-Execution](/versions/7.7.1/remote/cache-remote#check-cache-hits).
+[Cache Hits rate with Remote Execution](/versions/7.7.1/remote/cache-remote#check-cache-hits).
 
 In the standard output of your Bazel run, you will see something like the
 following:
@@ -66,8 +65,7 @@ the steps in this section.
    message you see does not give you enough information, try adding
    `--verbose_failures`.
 
-2. Follow the steps from [Troubleshooting cache hits for remote
-   execution](/versions/7.7.1/remote/cache-remote#troubleshooting_cache_hits) to
+2. Follow the steps from [Troubleshooting cache hits for remote execution](/versions/7.7.1/remote/cache-remote#troubleshooting_cache_hits) to
    ensure that your cache-writing Bazel invocations are able to get cache hits
    on the same machine and across machines.
 
@@ -81,7 +79,6 @@ the steps in this section.
    b. Ensure your cache-reading Bazel invocations build the same targets as the
       cache-writing Bazel invocations.
 
-   c. Follow the same steps as to [ensure caching across
-      machines](/versions/7.7.1/remote/cache-remote#caching-across-machines),
+   c. Follow the same steps as to [ensure caching across machines](/versions/7.7.1/remote/cache-remote#caching-across-machines),
       to ensure caching from your cache-writing Bazel invocation to your
       cache-reading Bazel invocation.
diff --git a/versions/7.7.1/remote/caching.mdx b/versions/7.7.1/remote/caching.mdx
index 5a52f250..d760b36c 100644
--- a/versions/7.7.1/remote/caching.mdx
+++ b/versions/7.7.1/remote/caching.mdx
@@ -308,8 +308,7 @@ or for the age of individual cache entries. Bazel will automatically garbage
 collect the disk cache while idling between builds; the idle timer can be set
 with `--experimental_disk_cache_gc_idle_delay` (defaulting to 5 minutes).
 
-As an alternative to automatic garbage collection, we also provide a [tool](
-https://github.com/bazelbuild/bazel/tree/master/src/tools/diskcache) to run a
+As an alternative to automatic garbage collection, we also provide a [tool](https://github.com/bazelbuild/bazel/tree/master/src/tools/diskcache) to run a
 garbage collection on demand.
 
 ## Known issues {#known-issues}
diff --git a/versions/7.7.1/remote/dynamic.mdx b/versions/7.7.1/remote/dynamic.mdx
index 74e224f2..7500c537 100644
--- a/versions/7.7.1/remote/dynamic.mdx
+++ b/versions/7.7.1/remote/dynamic.mdx
@@ -12,8 +12,7 @@ alike.
 This page describes how to enable, tune, and debug dynamic execution. If you
 have both local and remote execution set up and are trying to adjust Bazel
 settings for better performance, this page is for you. If you don't already have
-remote execution set up, go to the Bazel [Remote Execution
-Overview](/versions/7.7.1/remote/rbe) first.
+remote execution set up, go to the Bazel [Remote Execution Overview](/versions/7.7.1/remote/rbe) first.
 
 ## Enabling dynamic execution? {#enabling-dynamic-execution}
 
@@ -44,14 +43,12 @@ are likely. The default value is 1000ms, but should be tuned to being just a bit
 longer than cache hits usually take. The actual time depends both on the remote
 system and on how long a round-trip takes. Usually, the value will be the same
 for all users of a given remote system, unless some of them are far enough away
-to add roundtrip latency. You can use the [Bazel profiling
-features](/versions/7.7.1/rules/performance#performance-profiling) to look at how long typical
+to add roundtrip latency. You can use the [Bazel profiling features](/versions/7.7.1/rules/performance#performance-profiling) to look at how long typical
 cache hits take.
 
 Dynamic execution can be used with local sandboxed strategy as well as with
 [persistent workers](/versions/7.7.1/remote/persistent). Persistent workers will automatically
-run with sandboxing when used with dynamic execution, and cannot use [multiplex
-workers](/versions/7.7.1/remote/multiplex). On Darwin and Windows systems, the sandboxed
+run with sandboxing when used with dynamic execution, and cannot use [multiplex workers](/versions/7.7.1/remote/multiplex). On Darwin and Windows systems, the sandboxed
 strategy can be slow; you can pass `--reuse_sandbox_directories` to reduce
 overhead of creating sandboxes on these systems.
 
@@ -67,8 +64,7 @@ entire action fails. This is an intentional choice to prevent differences
 between local and remote execution from going unnoticed.
 
 For more background on how dynamic execution and its locking works, see Julio
-Merino's excellent [blog
-posts](https://jmmv.dev/series/bazel-dynamic-execution/)
+Merino's excellent [blog posts](https://jmmv.dev/series/bazel-dynamic-execution/)
 
 ## When should I use dynamic execution? {#when-to-use}
 
diff --git a/versions/7.7.1/remote/persistent.mdx b/versions/7.7.1/remote/persistent.mdx
index e2a12ab7..eb9a580c 100644
--- a/versions/7.7.1/remote/persistent.mdx
+++ b/versions/7.7.1/remote/persistent.mdx
@@ -264,7 +264,6 @@ For more information on persistent workers, see:
 *   [Original persistent workers blog post](https://blog.bazel.build/2015/12/10/java-workers.html)
 *   [Haskell implementation description](https://www.tweag.io/blog/2019-09-25-bazel-ghc-persistent-worker-internship/)
 *   [Blog post by Mike Morearty](https://medium.com/@mmorearty/how-to-create-a-persistent-worker-for-bazel-7738bba2cabb)
-*   [Front End Development with Bazel: Angular/TypeScript and Persistent Workers
-    w/ Asana](https://www.youtube.com/watch?v=0pgERydGyqo)
+*   [Front End Development with Bazel: Angular/TypeScript and Persistent Workers w/ Asana](https://www.youtube.com/watch?v=0pgERydGyqo)
 *   [Bazel strategies explained](https://jmmv.dev/2019/12/bazel-strategies.html)
 *   [Informative worker strategy discussion on the bazel-discuss mailing list](https://groups.google.com/forum/#!msg/bazel-discuss/oAEnuhYOPm8/ol7hf4KWJgAJ)
diff --git a/versions/7.7.1/remote/rules.mdx b/versions/7.7.1/remote/rules.mdx
index c065ebaa..e4377311 100644
--- a/versions/7.7.1/remote/rules.mdx
+++ b/versions/7.7.1/remote/rules.mdx
@@ -54,8 +54,7 @@ variables that may not be set to equivalent values (or at all) in the remote
 execution environment.
 
 Toolchain rules currently exist for Bazel build and test rules for
-[Scala](https://github.com/bazelbuild/rules_scala/blob/master/scala/scala_toolch
-ain.bzl),
+[Scala](https://github.com/bazelbuild/rules_scala/blob/master/scala/scala_toolch ain.bzl),
 [Rust](https://github.com/bazelbuild/rules_rust/blob/main/rust/toolchain.bzl),
 and [Go](https://github.com/bazelbuild/rules_go/blob/master/go/toolchains.rst),
 and new toolchain rules are under way for other languages and tools such as
diff --git a/versions/7.7.1/remote/workspace.mdx b/versions/7.7.1/remote/workspace.mdx
index 87007e39..4d7649f7 100644
--- a/versions/7.7.1/remote/workspace.mdx
+++ b/versions/7.7.1/remote/workspace.mdx
@@ -11,8 +11,7 @@ on the host machine. If your workspace rules access information about the
 host machine for use during execution, your build is likely to break due to
 incompatibilities between the environments.
 
-As part of [adapting Bazel rules for remote
-execution](/versions/7.7.1/remote/rules), you need to find such workspace rules
+As part of [adapting Bazel rules for remote execution](/versions/7.7.1/remote/rules), you need to find such workspace rules
 and fix them. This page describes how to find potentially problematic workspace
 rules using the workspace log.
 
diff --git a/versions/7.7.1/rules/deploying.mdx b/versions/7.7.1/rules/deploying.mdx
index b572e5a9..d98f7012 100644
--- a/versions/7.7.1/rules/deploying.mdx
+++ b/versions/7.7.1/rules/deploying.mdx
@@ -91,8 +91,7 @@ At the top level, there should be a `README` that contains (at least) what
 users will need to copy-paste into their `WORKSPACE` file to use your rule.
 In general, this will be a `http_archive` pointing to your GitHub release and
 a macro call that downloads/configures any tools your rule needs. For example,
-for the [Go
-rules](https://github.com/bazelbuild/rules_go#setup), this
+for the [Go rules](https://github.com/bazelbuild/rules_go#setup), this
 looks like:
 
 ```
diff --git a/versions/7.7.1/rules/language.mdx b/versions/7.7.1/rules/language.mdx
index 67be0486..bdface59 100644
--- a/versions/7.7.1/rules/language.mdx
+++ b/versions/7.7.1/rules/language.mdx
@@ -93,10 +93,8 @@ values returned by rules are immutable.
 `BUILD` files register targets via making calls to rules. `.bzl` files provide
 definitions for constants, rules, macros, and functions.
 
-[Native functions](/versions/7.7.1/reference/be/functions) and [native rules](
-/reference/be/overview#language-specific-native-rules) are global symbols in
-`BUILD` files. `bzl` files need to load them using the [`native` module](
-/rules/lib/toplevel/native).
+[Native functions](/versions/7.7.1/reference/be/functions) and [native rules](/reference/be/overview#language-specific-native-rules) are global symbols in
+`BUILD` files. `bzl` files need to load them using the [`native` module](/rules/lib/toplevel/native).
 
 There are two syntactic restrictions in `BUILD` files: 1) declaring functions is
 illegal, and 2) `*args` and `**kwargs` arguments are not allowed.
diff --git a/versions/7.7.1/rules/verbs-tutorial.mdx b/versions/7.7.1/rules/verbs-tutorial.mdx
index 7999f2c0..2bb5c2c2 100644
--- a/versions/7.7.1/rules/verbs-tutorial.mdx
+++ b/versions/7.7.1/rules/verbs-tutorial.mdx
@@ -49,8 +49,7 @@ This pattern can also be seen in the Angular project. The
 produces two targets. The first is a standard `nodejs_test` target which compares
 some generated output against a "golden" file (that is, a file containing the
 expected output). This can be built and run with a normal `bazel
-test` invocation. In `angular-cli`, you can run [one such
-target](https://github.com/angular/angular-cli/blob/e1269cb520871ee29b1a4eec6e6c0e4a94f0b5fc/etc/api/BUILD)
+test` invocation. In `angular-cli`, you can run [one such target](https://github.com/angular/angular-cli/blob/e1269cb520871ee29b1a4eec6e6c0e4a94f0b5fc/etc/api/BUILD)
 with `bazel test //etc/api:angular_devkit_core_api`.
 
 Over time, this golden file may need to be updated for legitimate reasons.
diff --git a/versions/7.7.1/run/build.mdx b/versions/7.7.1/run/build.mdx
index 035ed129..7262b72b 100644
--- a/versions/7.7.1/run/build.mdx
+++ b/versions/7.7.1/run/build.mdx
@@ -575,8 +575,7 @@ Note: Hermeticity means that the action only uses its declared input
 files and no other files in the filesystem, and it only produces its declared
 output files. See [Hermeticity](/versions/7.7.1/basics/hermeticity) for more details.
 
-On some platforms such as [Google Kubernetes
-Engine](https://cloud.google.com/kubernetes-engine/) cluster nodes or Debian,
+On some platforms such as [Google Kubernetes Engine](https://cloud.google.com/kubernetes-engine/) cluster nodes or Debian,
 user namespaces are deactivated by default due to security
 concerns. This can be checked by looking at the file
 `/proc/sys/kernel/unprivileged_userns_clone`: if it exists and contains a 0,
diff --git a/versions/7.7.1/start/android-app.mdx b/versions/7.7.1/start/android-app.mdx
index dcbb7809..85e6fa41 100644
--- a/versions/7.7.1/start/android-app.mdx
+++ b/versions/7.7.1/start/android-app.mdx
@@ -36,8 +36,7 @@ In this tutorial you learn how to:
 Before you begin the tutorial, install the following software:
 
 * **Bazel.** To install, follow the [installation instructions](/versions/7.7.1/install).
-* **Android Studio.** To install, follow the steps to [download Android
-  Studio](https://developer.android.com/sdk/index.html).
+* **Android Studio.** To install, follow the steps to [download Android Studio](https://developer.android.com/sdk/index.html).
   Execute the setup wizard to download the SDK and configure your environment.
 * (Optional) **Git.** Use `git` to download the Android app project.
 
@@ -52,8 +51,7 @@ This app has a single button that prints a greeting when clicked:
 
 **Figure 1.** Android app button greeting.
 
-Clone the repository with `git` (or [download the ZIP file
-directly](https://github.com/bazelbuild/examples/archive/master.zip)):
+Clone the repository with `git` (or [download the ZIP file directly](https://github.com/bazelbuild/examples/archive/master.zip)):
 
 ```posix-terminal
 git clone https://github.com/bazelbuild/examples
@@ -103,8 +101,7 @@ A [workspace](/versions/7.7.1/concepts/build-ref#workspace) is a directory that
 source files for one or more software projects, and has a `WORKSPACE` file at
 its root.
 
-The `WORKSPACE` file may be empty or may contain references to [external
-dependencies](/versions/7.7.1/docs/external) required to build your project.
+The `WORKSPACE` file may be empty or may contain references to [external dependencies](/versions/7.7.1/docs/external) required to build your project.
 
 First, run the following command to create an empty `WORKSPACE` file:
 
@@ -147,8 +144,7 @@ environment variable, and automatically detect the highest API level and the
 latest version of build tools installed within that location.
 
 You can set the `ANDROID_HOME` variable to the location of the Android SDK. Find
-the path to the installed SDK using Android Studio's [SDK
-Manager](https://developer.android.com/studio/intro/update#sdk-manager).
+the path to the installed SDK using Android Studio's [SDK Manager](https://developer.android.com/studio/intro/update#sdk-manager).
 Assuming the SDK is installed to default locations, you can use the following
 commands to set the `ANDROID_HOME` variable:
 
@@ -197,8 +193,7 @@ android_sdk_repository(
 ```
 
 **Optional:** If you want to compile native code into your Android app, you
-also need to download the [Android
-NDK](https://developer.android.com/ndk/downloads/index.html)
+also need to download the [Android NDK](https://developer.android.com/ndk/downloads/index.html)
 and tell Bazel where to find it by adding the following line to your `WORKSPACE` file:
 
 ```python
@@ -209,8 +204,7 @@ Similar to `android_sdk_repository`, the path to the Android NDK is inferred
 from the `ANDROID_NDK_HOME` environment variable by default. The path can also
 be explicitly specified with a `path` attribute on `android_ndk_repository`.
 
-For more information, read [Using the Android Native Development Kit with
-Bazel](/versions/7.7.1/docs/android-ndk).
+For more information, read [Using the Android Native Development Kit with Bazel](/versions/7.7.1/docs/android-ndk).
 
 `api_level` is the version of the Android API that the SDK and NDK
 target - for example, 23 for Android 6.0 and 25 for Android 7.1. If not
@@ -257,8 +251,7 @@ files or other dependencies. Bazel provides two build rules,
 build an Android app.
 
 For this tutorial, you'll first use the
-`android_library` rule to tell Bazel to build an [Android library
-module](http://developer.android.com/tools/projects/index.html#LibraryProjects)
+`android_library` rule to tell Bazel to build an [Android library module](http://developer.android.com/tools/projects/index.html#LibraryProjects)
 from the app source code and resource files. You'll then use the
 `android_binary` rule to tell Bazel how to build the Android application package.
 
@@ -373,11 +366,9 @@ file:
 ### Run the app
 
 You can now deploy the app to a connected Android device or emulator from the
-command line using the [`bazel
-mobile-install`](/versions/7.7.1/docs/user-manual#mobile-install) command. This command uses
+command line using the [`bazel mobile-install`](/versions/7.7.1/docs/user-manual#mobile-install) command. This command uses
 the Android Debug Bridge (`adb`) to communicate with the device. You must set up
-your device to use `adb` following the instructions in [Android Debug
-Bridge](http://developer.android.com/tools/help/adb.html) before deployment. You
+your device to use `adb` following the instructions in [Android Debug Bridge](http://developer.android.com/tools/help/adb.html) before deployment. You
 can also choose to install the app on the Android emulator included in Android
 Studio. Make sure the emulator is running before executing the command below.
 
diff --git a/versions/7.7.1/start/cpp.mdx b/versions/7.7.1/start/cpp.mdx
index ebb86951..780cbbbc 100644
--- a/versions/7.7.1/start/cpp.mdx
+++ b/versions/7.7.1/start/cpp.mdx
@@ -63,9 +63,7 @@ examples
 ```
 
 There are three sets of files, each set representing a stage in this tutorial.
-In the first stage, you will build a single [target]
-(https://bazel.build/reference/glossary#target) residing in a single [package]
-(https://bazel.build/reference/glossary#package). In the second stage, you will
+In the first stage, you will build a single [target](https://bazel.build/reference/glossary#target) residing in a single [package](https://bazel.build/reference/glossary#package). In the second stage, you will
 build both a binary and a library from a single package. In
 the third and final stage, you will build a project with multiple packages and
 build it with multiple targets.
diff --git a/versions/7.7.1/start/java.mdx b/versions/7.7.1/start/java.mdx
index eb5bec3c..f063008a 100644
--- a/versions/7.7.1/start/java.mdx
+++ b/versions/7.7.1/start/java.mdx
@@ -241,8 +241,7 @@ recompiles that file.
 Looking at the dependency graph, you can see that `ProjectRunner` depends on the
 same inputs as it did before, but the structure of the build is different:
 
-![Dependency graph of the target 'ProjectRunner' after adding a dependency](
-/docs/images/tutorial_java_02.svg)
+![Dependency graph of the target 'ProjectRunner' after adding a dependency](/docs/images/tutorial_java_02.svg)
 
 You've now built the project with two targets. The `ProjectRunner` target builds
 two source files and depends on one other target (`:greeter`), which builds
diff --git a/versions/8.0.1/about/roadmap.mdx b/versions/8.0.1/about/roadmap.mdx
index 4812b752..152a68b9 100644
--- a/versions/8.0.1/about/roadmap.mdx
+++ b/versions/8.0.1/about/roadmap.mdx
@@ -13,8 +13,7 @@ projects.
 
 ## Bazel 8.0 Release
 
-We plan to bring Bazel 8.0 [long term support
-(LTS)](https://bazel.build/release/versioning) to you in late 2024.
+We plan to bring Bazel 8.0 [long term support (LTS)](https://bazel.build/release/versioning) to you in late 2024.
 The following features are planned to be implemented.
 
 ### Bzlmod: external dependency management system
@@ -29,8 +28,7 @@ support will be removed. Starting with Bazel 7.1, you can set
 `--noenable_workspace` to opt into the new behavior.
 
 Bazel 8.0 will contain a number of enhancements to
-[Bazel's external dependency management]
-(https://docs.google.com/document/d/1moQfNcEIttsk6vYanNKIy3ZuK53hQUFq1b1r0rmsYVg/edit#heading=h.lgyp7ubwxmjc)
+[Bazel's external dependency management](https://docs.google.com/document/d/1moQfNcEIttsk6vYanNKIy3ZuK53hQUFq1b1r0rmsYVg/edit#heading=h.lgyp7ubwxmjc)
 functionality, including:
 
 *   The new flag `--enable_workspace` can be set to `false` to completely
diff --git a/versions/8.0.1/basics/dependencies.mdx b/versions/8.0.1/basics/dependencies.mdx
index 326b6850..e8a300fa 100644
--- a/versions/8.0.1/basics/dependencies.mdx
+++ b/versions/8.0.1/basics/dependencies.mdx
@@ -65,8 +65,7 @@ targets, we’ve made some strides in mitigating the downside by investing in
 tooling to automatically manage `BUILD` files to avoid burdening developers.
 
 Some of these tools, such as `buildifier` and `buildozer`, are available with
-Bazel in the [`buildtools`
-directory](https://github.com/bazelbuild/buildtools).
+Bazel in the [`buildtools` directory](https://github.com/bazelbuild/buildtools).
 
 ## Minimizing Module Visibility
 
@@ -106,8 +105,7 @@ transitive dependencies (Figure 1). Suppose target A depends on target B, which
 depends on a common library target C. Should target A be able to use classes
 defined in target C?
 
-[![Transitive
-dependencies](/versions/8.0.1/images/transitive-dependencies.png)](/versions/8.0.1/images/transitive-dependencies.png)
+[![Transitive dependencies](/versions/8.0.1/images/transitive-dependencies.png)](/versions/8.0.1/images/transitive-dependencies.png)
 
 **Figure 1**. Transitive dependencies
 
@@ -141,9 +139,7 @@ dependencies and adding them to a `BUILD` files without any developer
 intervention. But even without such tools, we’ve found the trade-off to be well
 worth it as the codebase scales: explicitly adding a dependency to `BUILD` file
 is a one-time cost, but dealing with implicit transitive dependencies can cause
-ongoing problems as long as the build target exists. Bazel [enforces strict
-transitive
-dependencies](https://blog.bazel.build/2017/06/28/sjd-unused_deps.html)
+ongoing problems as long as the build target exists. Bazel [enforces strict transitive dependencies](https://blog.bazel.build/2017/06/28/sjd-unused_deps.html)
 on Java code by default.
 
 ### External dependencies
@@ -192,8 +188,7 @@ so in theory there’s no reason that different versions of the same external
 dependency couldn’t both be declared in the build system under different names.
 That way, each target could choose which version of the dependency it wanted to
 use. This causes a lot of problems in practice, so Google enforces a strict
-[One-Version
-Rule](https://opensource.google/docs/thirdparty/oneversion/) for
+[One-Version Rule](https://opensource.google/docs/thirdparty/oneversion/) for
 all third-party dependencies in our codebase.
 
 The biggest problem with allowing multiple versions is the diamond dependency
@@ -232,8 +227,7 @@ Bazel did not use to automatically download transitive dependencies. It used to
 employ a `WORKSPACE` file that required all transitive dependencies to be
 listed, which led to a lot of pain when managing external dependencies. Bazel
 has since added support for automatic transitive external dependency management
-in the form of the `MODULE.bazel` file. See [external dependency
-overview](/versions/8.0.1/external/overview) for more details.
+in the form of the `MODULE.bazel` file. See [external dependency overview](/versions/8.0.1/external/overview) for more details.
 
 Yet again, the choice here is one between convenience and scalability. Small
 projects might prefer not having to worry about managing transitive dependencies
diff --git a/versions/8.0.1/community/roadmaps-configurability.mdx b/versions/8.0.1/community/roadmaps-configurability.mdx
index d922c632..9ca8ed2a 100644
--- a/versions/8.0.1/community/roadmaps-configurability.mdx
+++ b/versions/8.0.1/community/roadmaps-configurability.mdx
@@ -26,8 +26,7 @@ title: 'Bazel Configurability 2021 Roadmap'
 * Builds scale well, particularly w.r.t graph size and action caching.
 
 We also support
-[`cquery`](https://bazel.build/versions/8.0.1/query/cquery), [`Starlark
-configuration`](https://bazel.build/extending/config),
+[`cquery`](https://bazel.build/versions/8.0.1/query/cquery), [`Starlark configuration`](https://bazel.build/extending/config),
 and
 [`select()`](https://bazel.build/versions/8.0.1/docs/configurable-attributes).
 
@@ -41,15 +40,13 @@ interest of accurate expectations.
 ### Platforms
 
 

-Q3 2021**Android rules use the new [platforms
-API](https://bazel.build/concepts/platforms)**
+Q3 2021**Android rules use the new [platforms API](https://bazel.build/concepts/platforms)**
 IN PROGRESS ([#11749](https://github.com/bazelbuild/bazel/issues/11749))
 
 * This is our main priority for the beginning of 2021.
 
 

-Q3 2021**Builds support [multiple execution
-platforms](https://docs.google.com/document/d/1U9HzdDmtRnm244CaRM6JV-q2408mbNODAMewcGjnnbM/)**
+Q3 2021**Builds support [multiple execution platforms](https://docs.google.com/document/d/1U9HzdDmtRnm244CaRM6JV-q2408mbNODAMewcGjnnbM/)**
 IN PROGRESS ([#11748](https://github.com/bazelbuild/bazel/issues/11748))
 
 

diff --git a/versions/8.0.1/community/sig.mdx b/versions/8.0.1/community/sig.mdx
index 407873a6..29461bd0 100644
--- a/versions/8.0.1/community/sig.mdx
+++ b/versions/8.0.1/community/sig.mdx
@@ -3,8 +3,7 @@ title: 'Bazel Special Interest Groups'
 ---
 
 Bazel hosts Special Interest Groups (SIGs) to focus collaboration on particular
-areas and to support communication and coordination between [Bazel owners,
-maintainers, and contributors](/versions/8.0.1/contribute/policy). This policy
+areas and to support communication and coordination between [Bazel owners, maintainers, and contributors](/versions/8.0.1/contribute/policy). This policy
 applies to [`bazelbuild`](http://github.com/bazelbuild).
 
 SIGs do their work in public. The ideal scope for a SIG covers a well-defined
diff --git a/versions/8.0.1/community/users.mdx b/versions/8.0.1/community/users.mdx
index 217a8d40..07ccc98e 100644
--- a/versions/8.0.1/community/users.mdx
+++ b/versions/8.0.1/community/users.mdx
@@ -304,11 +304,9 @@ safety systems_.
 Pigweed is an open-source solution for sustained, robust, and rapid embedded
 product development for large teams. Pigweed has shipped in millions of
 devices, including Google's suite of Pixel devices, Nest thermostats,
-[satellites](https://www.spinlaunch.com/), and [autonomous aerial
-drones](https://www.flyzipline.com/).
+[satellites](https://www.spinlaunch.com/), and [autonomous aerial drones](https://www.flyzipline.com/).
 
-Pigweed [uses Bazel as its primary build
-system](https://pigweed.dev/seed/0111-build-systems.html). The [Bazel for
+Pigweed [uses Bazel as its primary build system](https://pigweed.dev/seed/0111-build-systems.html). The [Bazel for
 Embedded][pw-bazel-great] blog post discusses why we think it's a great build
 system for embedded projects!
 
diff --git a/versions/8.0.1/concepts/build-files.mdx b/versions/8.0.1/concepts/build-files.mdx
index 662aec5e..7e730fd3 100644
--- a/versions/8.0.1/concepts/build-files.mdx
+++ b/versions/8.0.1/concepts/build-files.mdx
@@ -132,12 +132,3 @@ for anyone to create new rules.
     programming language. Libraries can depend on other libraries,
     and binaries and tests can depend on libraries, with the expected
     separate-compilation behavior.
-
-
-  
-    
-    
-  
-
LabelsDependencies

diff --git a/versions/8.0.1/concepts/build-ref.mdx b/versions/8.0.1/concepts/build-ref.mdx
index 130ec5e5..918243bb 100644
--- a/versions/8.0.1/concepts/build-ref.mdx
+++ b/versions/8.0.1/concepts/build-ref.mdx
@@ -17,8 +17,7 @@ its root; such a boundary marker file could be `MODULE.bazel`, `REPO.bazel`, or
 in legacy contexts, `WORKSPACE` or `WORKSPACE.bazel`.
 
 The repo in which the current Bazel command is being run is called the _main
-repo_. Other, (external) repos are defined by _repo rules_; see [external
-dependencies overview](/versions/8.0.1/external/overview) for more information.
+repo_. Other, (external) repos are defined by _repo rules_; see [external dependencies overview](/versions/8.0.1/external/overview) for more information.
 
 ## Workspace {#workspace}
 
@@ -95,9 +94,4 @@ have three properties: the list of packages they contain, their name, and other
 package groups they include. The only allowed ways to refer to them are from the
 `visibility` attribute of rules or from the `default_visibility` attribute of
 the `package` function; they do not generate or consume files. For more
-information, refer to the [`package_group`
-documentation](/versions/8.0.1/reference/be/functions#package_group).
-
-
-  Labels
-
\ No newline at end of file
+information, refer to the [`package_group` documentation](/versions/8.0.1/reference/be/functions#package_group).
diff --git a/versions/8.0.1/concepts/dependencies.mdx b/versions/8.0.1/concepts/dependencies.mdx
index 0bc129e6..5711e4fc 100644
--- a/versions/8.0.1/concepts/dependencies.mdx
+++ b/versions/8.0.1/concepts/dependencies.mdx
@@ -296,13 +296,3 @@ filegroup(
 ```
 
 You can then reference the label `my_data` as the data dependency in your test.
-
-
-  
-    
-    
-  
-
BUILD filesVisibility

-
diff --git a/versions/8.0.1/concepts/labels.mdx b/versions/8.0.1/concepts/labels.mdx
index f02c9395..75958364 100644
--- a/versions/8.0.1/concepts/labels.mdx
+++ b/versions/8.0.1/concepts/labels.mdx
@@ -10,8 +10,7 @@ form looks like:
 ```
 
 The first part of the label is the repository name, `@@myrepo`. The double-`@`
-syntax signifies that this is a [*canonical* repo
-name](/versions/8.0.1/external/overview#canonical-repo-name), which is unique within
+syntax signifies that this is a [*canonical* repo name](/versions/8.0.1/external/overview#canonical-repo-name), which is unique within
 the workspace. Labels with canonical repo names unambiguously identify a target
 no matter which context they appear in.
 
@@ -239,12 +238,3 @@ the build.
 This directed acyclic graph over targets is called the _target graph_ or
 _build dependency graph_, and is the domain over which the
 [Bazel Query tool](/versions/8.0.1/query/guide) operates.
-
-
-  
-    
-    
-  
-
TargetsBUILD files

diff --git a/versions/8.0.1/concepts/platforms.mdx b/versions/8.0.1/concepts/platforms.mdx
index 89fc8929..df6a6cf7 100644
--- a/versions/8.0.1/concepts/platforms.mdx
+++ b/versions/8.0.1/concepts/platforms.mdx
@@ -77,8 +77,7 @@ To test your Android project with platforms, see
 for support.
 
 You can still use platform APIs with Apple builds (for example, when building
-with a mixture of Apple rules and pure C++) with [platform
-mappings](#platform-mappings).
+with a mixture of Apple rules and pure C++) with [platform mappings](#platform-mappings).
 
 ### Other languages {#other-languages}
 
@@ -241,8 +240,7 @@ sets `--cpu`, `--crossstool_top`, or other legacy flags, rules that read
 
 When migrating your project to platforms, you must either convert changes like
 `return { "//command_line_option:cpu": "arm" }` to `return {
-"//command_line_option:platforms": "//:my_arm_platform" }` or use [platform
-mappings](#platform-mappings) to support both styles during migration.
+"//command_line_option:platforms": "//:my_arm_platform" }` or use [platform mappings](#platform-mappings) to support both styles during migration.
 window.
 
 ## Migrating your rule set {#migrating-your-rule-set}
@@ -361,10 +359,8 @@ attributes declare a language's tools (like `compiler =
 this information to rules that need to build with these tools.
 
 Toolchains declare the `constraint_value`s of machines they can
-[target][target_compatible_with Attribute]
-(`target_compatible_with = ["@platforms//os:linux"]`) and machines their tools can
-[run on][exec_compatible_with Attribute]
-(`exec_compatible_with = ["@platforms//os:mac"]`).
+[target][target_compatible_with Attribute](`target_compatible_with = ["@platforms//os:linux"]`) and machines their tools can
+[run on][exec_compatible_with Attribute](`exec_compatible_with = ["@platforms//os:mac"]`).
 
 When building `$ bazel build //:myproject --platforms=//:myplatform`, Bazel
 automatically selects a toolchain that can run on the build machine and
diff --git a/versions/8.0.1/configure/attributes.mdx b/versions/8.0.1/configure/attributes.mdx
index 75c15e29..c6d80a35 100644
--- a/versions/8.0.1/configure/attributes.mdx
+++ b/versions/8.0.1/configure/attributes.mdx
@@ -2,8 +2,7 @@
 title: 'Configurable Build Attributes'
 ---
 
-**_Configurable attributes_**, commonly known as [`select()`](
-/reference/be/functions#select), is a Bazel feature that lets users toggle the values
+**_Configurable attributes_**, commonly known as [`select()`](/reference/be/functions#select), is a Bazel feature that lets users toggle the values
 of build rule attributes at the command line.
 
 This can be used, for example, for a multiplatform library that automatically
@@ -407,8 +406,7 @@ sh_library(
 )
 ```
 
-If you need a `select` to match when multiple conditions match, consider [AND
-chaining](#and-chaining).
+If you need a `select` to match when multiple conditions match, consider [AND chaining](#and-chaining).
 
 ## OR chaining {#or-chaining}
 
diff --git a/versions/8.0.1/configure/integrate-cpp.mdx b/versions/8.0.1/configure/integrate-cpp.mdx
index e03a0207..8d87da31 100644
--- a/versions/8.0.1/configure/integrate-cpp.mdx
+++ b/versions/8.0.1/configure/integrate-cpp.mdx
@@ -33,8 +33,7 @@ This is because when writing our own actions, they must behave
 consistently with the C++ toolchain - for example, passing C++ command line
 flags to a tool that invokes the C++ compiler behind the scenes.
 
-C++ rules use a special way of constructing command lines based on [feature
-configuration](/versions/8.0.1/docs/cc-toolchain-config-reference). To construct a command line,
+C++ rules use a special way of constructing command lines based on [feature configuration](/versions/8.0.1/docs/cc-toolchain-config-reference). To construct a command line,
 you need the following:
 
 * `features` and `action_configs` - these come from the `CcToolchainConfigInfo`
diff --git a/versions/8.0.1/configure/windows.mdx b/versions/8.0.1/configure/windows.mdx
index 7637f93e..098fbcc5 100644
--- a/versions/8.0.1/configure/windows.mdx
+++ b/versions/8.0.1/configure/windows.mdx
@@ -166,8 +166,7 @@ To build C++ targets with MSVC, you need:
         set BAZEL_VC=C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC
         ```
 
-*   The [Windows
-    SDK](https://developer.microsoft.com/en-us/windows/downloads/windows-10-sdk).
+*   The [Windows SDK](https://developer.microsoft.com/en-us/windows/downloads/windows-10-sdk).
 
     The Windows SDK contains header files and libraries you need when building
     Windows applications, including Bazel itself. By default, the latest Windows SDK installed will
@@ -186,8 +185,7 @@ To build C++ targets with MSVC, you need:
 
 If everything is set up, you can build a C++ target now!
 
-Try building a target from one of our [sample
-projects](https://github.com/bazelbuild/bazel/tree/master/examples):
+Try building a target from one of our [sample projects](https://github.com/bazelbuild/bazel/tree/master/examples):
 
 
 
 
-To build and use Dynamically Linked Libraries (DLL files), see [this
-example](https://github.com/bazelbuild/bazel/tree/master/examples/windows/dll).
+To build and use Dynamically Linked Libraries (DLL files), see [this example](https://github.com/bazelbuild/bazel/tree/master/examples/windows/dll).
 
 **Command Line Length Limit**: To prevent the
 [Windows command line length limit issue](https://github.com/bazelbuild/bazel/issues/5163),
@@ -292,8 +289,7 @@ On Windows, Bazel builds two output files for `java_binary` rules:
 *   a `.jar` file
 *   a `.exe` file that can set up the environment for the JVM and run the binary
 
-Try building a target from one of our [sample
-projects](https://github.com/bazelbuild/bazel/tree/master/examples):
+Try building a target from one of our [sample projects](https://github.com/bazelbuild/bazel/tree/master/examples):
 
 
   bazel build //examples/java-native/src/main/java/com/example/myproject:hello-world
@@ -315,8 +311,7 @@ On Windows, Bazel builds two output files for `py_binary` rules:
 You can either run the executable file (it has a `.exe` extension) or you can run
 Python with the self-extracting zip file as the argument.
 
-Try building a target from one of our [sample
-projects](https://github.com/bazelbuild/bazel/tree/master/examples):
+Try building a target from one of our [sample projects](https://github.com/bazelbuild/bazel/tree/master/examples):
 
 
   
 
 If you are interested in details about how Bazel builds Python targets on
-Windows, check out this [design
-doc](https://github.com/bazelbuild/bazel-website/blob/master/designs/_posts/2016-09-05-build-python-on-windows.md).
+Windows, check out this [design doc](https://github.com/bazelbuild/bazel-website/blob/master/designs/_posts/2016-09-05-build-python-on-windows.md).
diff --git a/versions/8.0.1/contribute/codebase.mdx b/versions/8.0.1/contribute/codebase.mdx
index 463bd7da..84fa45f1 100644
--- a/versions/8.0.1/contribute/codebase.mdx
+++ b/versions/8.0.1/contribute/codebase.mdx
@@ -227,8 +227,7 @@ repository", the others are called "external repositories".
 A repository is marked by a repo boundary file (`MODULE.bazel`, `REPO.bazel`, or
 in legacy contexts, `WORKSPACE` or `WORKSPACE.bazel`) in its root directory. The
 main repo is the source tree where you're invoking Bazel from. External repos
-are defined in various ways; see [external dependencies
-overview](/versions/8.0.1/external/overview) for more information.
+are defined in various ways; see [external dependencies overview](/versions/8.0.1/external/overview) for more information.
 
 Code of external repositories is symlinked or downloaded under
 `$OUTPUT_BASE/external`.
diff --git a/versions/8.0.1/contribute/design-documents.mdx b/versions/8.0.1/contribute/design-documents.mdx
index 66371e47..deed74c1 100644
--- a/versions/8.0.1/contribute/design-documents.mdx
+++ b/versions/8.0.1/contribute/design-documents.mdx
@@ -137,8 +137,7 @@ A lead reviewer should be a domain expert who is:
 *   Objective and capable of providing constructive feedback
 *   Available for the entire review period to lead the process
 
-Consider checking the contacts for various [team
-labels](/versions/8.0.1/contribute/maintainers-guide#team-labels).
+Consider checking the contacts for various [team labels](/versions/8.0.1/contribute/maintainers-guide#team-labels).
 
 ## Markdown vs Google Docs {#markdown-versus-gdocs}
 
@@ -168,12 +167,10 @@ Markdown for posterity.
 
 ### Using Google Docs {#gdocs}
 
-For consistency, use the [Bazel design doc template](
-https://docs.google.com/document/d/1cE5zrjrR40RXNg64XtRFewSv6FrLV6slGkkqxBumS1w/edit).
+For consistency, use the [Bazel design doc template](https://docs.google.com/document/d/1cE5zrjrR40RXNg64XtRFewSv6FrLV6slGkkqxBumS1w/edit).
 It includes the necessary header and creates visual
 consistency with other Bazel related documents. To do that, click on **File** >
-**Make a copy** or click this link to [make a copy of the design doc
-template](https://docs.google.com/document/d/1cE5zrjrR40RXNg64XtRFewSv6FrLV6slGkkqxBumS1w/copy).
+**Make a copy** or click this link to [make a copy of the design doc template](https://docs.google.com/document/d/1cE5zrjrR40RXNg64XtRFewSv6FrLV6slGkkqxBumS1w/copy).
 
 To make your document readable to the world, click on
 **Share** > **Advanced** > **Change…**, and
diff --git a/versions/8.0.1/contribute/index.mdx b/versions/8.0.1/contribute/index.mdx
index 20acafc1..20ae49bc 100644
--- a/versions/8.0.1/contribute/index.mdx
+++ b/versions/8.0.1/contribute/index.mdx
@@ -10,8 +10,7 @@ As you use Bazel, you may find things that can be improved.
 You can help by [reporting issues](http://github.com/bazelbuild/bazel/issues)
 when:
 
-   - Bazel crashes or you encounter a bug that can [only be resolved using `bazel
-     clean`](/versions/8.0.1/run/build#correct-incremental-rebuilds).
+   - Bazel crashes or you encounter a bug that can [only be resolved using `bazel clean`](/versions/8.0.1/run/build#correct-incremental-rebuilds).
    - The documentation is incomplete or unclear. You can also report issues
      from the page you are viewing by using the "Create issue"
      link at the top right corner of the page.
@@ -21,11 +20,9 @@ when:
 
 You can engage with the Bazel community by:
 
-   - Answering questions [on Stack Overflow](
-     https://stackoverflow.com/questions/tagged/bazel).
+   - Answering questions [on Stack Overflow](https://stackoverflow.com/questions/tagged/bazel).
    - Helping other users [on Slack](https://slack.bazel.build).
-   - Improving documentation or [contributing examples](
-     https://github.com/bazelbuild/examples).
+   - Improving documentation or [contributing examples](https://github.com/bazelbuild/examples).
    - Sharing your experience or your tips, for example, on a blog or social media.
 
 ## Contribute code {#contribute-code}
@@ -40,8 +37,7 @@ You can contribute to the Bazel ecosystem by:
    - Contributing to Bazel-related tools, for example, migration tools.
    - Improving Bazel integration with other IDEs and tools.
 
-Before making a change, [create a GitHub
-issue](http://github.com/bazelbuild/bazel/issues)
+Before making a change, [create a GitHub issue](http://github.com/bazelbuild/bazel/issues)
 or email [bazel-discuss@](mailto:bazel-discuss@googlegroups.com).
 
 The most helpful contributions fix bugs or add features (as opposed
diff --git a/versions/8.0.1/contribute/maintainers-guide.mdx b/versions/8.0.1/contribute/maintainers-guide.mdx
index a5cc4f29..8a4a5c1b 100644
--- a/versions/8.0.1/contribute/maintainers-guide.mdx
+++ b/versions/8.0.1/contribute/maintainers-guide.mdx
@@ -4,8 +4,7 @@ title: 'Guide for Bazel Maintainers'
 
 This is a guide for the maintainers of the Bazel open source project.
 
-If you are looking to contribute to Bazel, please read [Contributing to
-Bazel](/versions/8.0.1/contribute) instead.
+If you are looking to contribute to Bazel, please read [Contributing to Bazel](/versions/8.0.1/contribute) instead.
 
 The objectives of this page are to:
 
@@ -37,8 +36,7 @@ repository.
 
 1. A user creates an issue by choosing one of the
 [issue templates](https://github.com/bazelbuild/bazel/issues/new/choose)
-   and it enters the pool of [unreviewed open
-   issues](https://github.com/bazelbuild/bazel/issues?utf8=%E2%9C%93&q=is%3Aissue+is%3Aopen+-label%3Auntriaged+-label%3Ap2+-label%3Ap1+-label%3Ap3+-label%3Ap4+-label%3Ateam-Starlark+-label%3Ateam-Rules-CPP+-label%3Ateam-Rules-Java+-label%3Ateam-XProduct+-label%3Ateam-Android+-label%3Ateam-Apple+-label%3Ateam-Configurability++-label%3Ateam-Performance+-label%3Ateam-Rules-Server+-label%3Ateam-Core+-label%3Ateam-Rules-Python+-label%3Ateam-Remote-Exec+-label%3Ateam-Local-Exec+-label%3Ateam-Bazel).
+   and it enters the pool of [unreviewed open issues](https://github.com/bazelbuild/bazel/issues?utf8=%E2%9C%93&q=is%3Aissue+is%3Aopen+-label%3Auntriaged+-label%3Ap2+-label%3Ap1+-label%3Ap3+-label%3Ap4+-label%3Ateam-Starlark+-label%3Ateam-Rules-CPP+-label%3Ateam-Rules-Java+-label%3Ateam-XProduct+-label%3Ateam-Android+-label%3Ateam-Apple+-label%3Ateam-Configurability++-label%3Ateam-Performance+-label%3Ateam-Rules-Server+-label%3Ateam-Core+-label%3Ateam-Rules-Python+-label%3Ateam-Remote-Exec+-label%3Ateam-Local-Exec+-label%3Ateam-Bazel).
 1. A member on the Developer Experience (DevEx) subteam rotation reviews the
    issue.
    1. If the issue is **not a bug** or a **feature request**, the DevEx member
@@ -58,21 +56,18 @@ repository.
 1. After reviewing the issue, the DevEx member decides if the issue requires
    immediate attention. If it does, they will assign the **P0**
    [priority](#priority) label and an owner from the list of team leads.
-1. The DevEx member assigns the `untriaged` label and exactly one [team
-   label](#team-labels) for routing.
+1. The DevEx member assigns the `untriaged` label and exactly one [team label](#team-labels) for routing.
 1. The DevEx member also assigns exactly one `type:` label, such as `type: bug`
    or `type: feature request`, according to the type of the issue.
 1. For platform-specific issues, the DevEx member assigns one `platform:` label,
    such as `platform:apple` for Mac-specific issues.
 1. If the issue is low priority and can be worked on by a new community
    contributor, the DevEx member assigns the `good first issue` label.
-At this stage, the issue enters the pool of [untriaged open
-issues](https://github.com/bazelbuild/bazel/issues?q=is%3Aissue+is%3Aopen+label%3Auntriaged).
+At this stage, the issue enters the pool of [untriaged open issues](https://github.com/bazelbuild/bazel/issues?q=is%3Aissue+is%3Aopen+label%3Auntriaged).
 
 Each Bazel subteam will triage all issues under labels they own, preferably on a
 weekly basis. The subteam will review and evaluate the issue and provide a
-resolution, if possible. If you are an owner of a team label, see [this section
-](#label-own) for more information.
+resolution, if possible. If you are an owner of a team label, see [this section](#label-own) for more information.
 
 When an issue is resolved, it can be closed.
 
@@ -111,8 +106,7 @@ preferably on a weekly basis.
      issue is either P0 or P1 we assume that is actively worked on.
 1. Remove the `untriaged` label.
 
-Note that you need to be in the [bazelbuild
-organization](https://github.com/bazelbuild) to be able to add or remove labels.
+Note that you need to be in the [bazelbuild organization](https://github.com/bazelbuild) to be able to add or remove labels.
 
 ### Pull Requests {#pull-requests}
 
@@ -138,8 +132,7 @@ issues.
   unusable, or a downed service that severely impacts development of the Bazel
   project. This includes regressions introduced in a new release that blocks a
   significant number of users, or an incompatible breaking change that was not
-  compliant to the [Breaking
-  Change](https://docs.google.com/document/d/1q5GGRxKrF_mnwtaPKI487P8OdDRh2nN7jX6U-FXnHL0/edit?pli=1#heading=h.ceof6vpkb3ik)
+  compliant to the [Breaking Change](https://docs.google.com/document/d/1q5GGRxKrF_mnwtaPKI487P8OdDRh2nN7jX6U-FXnHL0/edit?pli=1#heading=h.ceof6vpkb3ik)
   policy. No practical workaround exists.
 * [**P1**](https://github.com/bazelbuild/bazel/labels/P1) - Critical defect or
   feature which should be addressed in the next release, or a serious issue that
diff --git a/versions/8.0.1/contribute/naming.mdx b/versions/8.0.1/contribute/naming.mdx
index 61b3dcb6..c1e87ad9 100644
--- a/versions/8.0.1/contribute/naming.mdx
+++ b/versions/8.0.1/contribute/naming.mdx
@@ -4,8 +4,7 @@ title: 'Naming a Bazel related project'
 
 First, thank you for contributing to the Bazel ecosystem! Please reach out to
 the Bazel community on the
-[bazel-discuss mailing list](https://groups.google.com/forum/#!forum/bazel-discuss
-) to share your project and its suggested name.
+[bazel-discuss mailing list](https://groups.google.com/forum/#!forum/bazel-discuss) to share your project and its suggested name.
 
 If you are building a Bazel related tool or sharing your Skylark rules,
 we recommend following these guidelines for the name of your project:
diff --git a/versions/8.0.1/contribute/patch-acceptance.mdx b/versions/8.0.1/contribute/patch-acceptance.mdx
index 10efe92f..74253795 100644
--- a/versions/8.0.1/contribute/patch-acceptance.mdx
+++ b/versions/8.0.1/contribute/patch-acceptance.mdx
@@ -11,29 +11,24 @@ code base.
    need a corresponding issue for tracking.
 1. If you're proposing significant changes, write a
    [design document](/versions/8.0.1/contribute/design-documents).
-1. Ensure you've signed a [Contributor License
-   Agreement](https://cla.developers.google.com).
+1. Ensure you've signed a [Contributor License Agreement](https://cla.developers.google.com).
 1. Prepare a git commit that implements the feature. Don't forget to add tests
    and update the documentation. If your change has user-visible effects, please
    [add release notes](/versions/8.0.1/contribute/release-notes). If it is an incompatible change,
    read the [guide for rolling out breaking changes](/versions/8.0.1/contribute/breaking-changes).
 1. Create a pull request on
    [GitHub](https://github.com/bazelbuild/bazel/pulls). If you're new to GitHub,
-   read [about pull
-   requests](https://help.github.com/articles/about-pull-requests/). Note that
+   read [about pull requests](https://help.github.com/articles/about-pull-requests/). Note that
    we restrict permissions to create branches on the main Bazel repository, so
-   you will need to push your commit to [your own fork of the
-   repository](https://help.github.com/articles/working-with-forks/).
+   you will need to push your commit to [your own fork of the repository](https://help.github.com/articles/working-with-forks/).
 1. A Bazel maintainer should assign you a reviewer within two business days
    (excluding holidays in the USA and Germany). If you aren't assigned a
    reviewer in that time, you can request one by emailing
-   [bazel-discuss@googlegroups.com]
-   (mailto:bazel-discuss@googlegroups.com).
+   [bazel-discuss@googlegroups.com](mailto:bazel-discuss@googlegroups.com).
 1. Work with the reviewer to complete a code review. For each change, create a
    new commit and push it to make changes to your pull request. If the review
    takes too long (for instance, if the reviewer is unresponsive), send an email to
-   [bazel-discuss@googlegroups.com]
-   (mailto:bazel-discuss@googlegroups.com).
+   [bazel-discuss@googlegroups.com](mailto:bazel-discuss@googlegroups.com).
 1. After your review is complete, a Bazel maintainer applies your patch to
    Google's internal version control system.
 
diff --git a/versions/8.0.1/contribute/release-notes.mdx b/versions/8.0.1/contribute/release-notes.mdx
index e29106e5..1f782fcd 100644
--- a/versions/8.0.1/contribute/release-notes.mdx
+++ b/versions/8.0.1/contribute/release-notes.mdx
@@ -16,8 +16,7 @@ the release announcement.
 * If the change adds / removes / changes Bazel in a user-visible way, then it
   may be advantageous to mention it.
 
-If the change is significant, follow the [design document
-policy](/versions/8.0.1/contribute/design-documents) first.
+If the change is significant, follow the [design document policy](/versions/8.0.1/contribute/design-documents) first.
 
 ## Guidelines {#guidelines}
 
@@ -60,10 +59,8 @@ change is about.
 
 ## Process {#process}
 
-As part of the [release
-process](https://github.com/bazelbuild/continuous-integration/blob/master/docs/release-playbook.md),
-we collect the `RELNOTES` tags of every commit. We copy everything in a [Google
-Doc](https://docs.google.com/document/d/1wDvulLlj4NAlPZamdlEVFORks3YXJonCjyuQMUQEmB0/edit)
+As part of the [release process](https://github.com/bazelbuild/continuous-integration/blob/master/docs/release-playbook.md),
+we collect the `RELNOTES` tags of every commit. We copy everything in a [Google Doc](https://docs.google.com/document/d/1wDvulLlj4NAlPZamdlEVFORks3YXJonCjyuQMUQEmB0/edit)
 where we review, edit, and organize the notes.
 
 The release manager sends an email to the
@@ -71,6 +68,4 @@ The release manager sends an email to the
 Bazel contributors are invited to contribute to the document and make sure
 their changes are correctly reflected in the announcement.
 
-Later, the announcement will be submitted to the [Bazel
-blog](https://blog.bazel.build/), using the [bazel-blog
-repository](https://github.com/bazelbuild/bazel-blog/tree/master/_posts).
+Later, the announcement will be submitted to the [Bazel blog](https://blog.bazel.build/), using the [bazel-blog repository](https://github.com/bazelbuild/bazel-blog/tree/master/_posts).
diff --git a/versions/8.0.1/contribute/statemachine-guide.mdx b/versions/8.0.1/contribute/statemachine-guide.mdx
index 47a5e081..ba9e86c1 100644
--- a/versions/8.0.1/contribute/statemachine-guide.mdx
+++ b/versions/8.0.1/contribute/statemachine-guide.mdx
@@ -172,8 +172,7 @@ instead, batches[^4] as many lookups as possible before doing so. The value
 might not be immediately available, for example, requiring a Skyframe restart,
 so the caller specifies what to do with the resulting value using a callback.
 
-The `StateMachine` processor ([`Driver`s and bridging to
-SkyFrame](#drivers-and-bridging)) guarantees that the value is available before
+The `StateMachine` processor ([`Driver`s and bridging to SkyFrame](#drivers-and-bridging)) guarantees that the value is available before
 the next state begins. An example follows.
 
 ```
@@ -284,8 +283,7 @@ and solutions to certain control flow problems.
 ### Sequential states
 
 This is the most common and straightforward control flow pattern. An example of
-this is shown in [Stateful computations inside
-`SkyKeyComputeState`](#stateful-computations).
+this is shown in [Stateful computations inside `SkyKeyComputeState`](#stateful-computations).
 
 ### Branching
 
@@ -545,8 +543,7 @@ section describes the propagation of data values.
 
 ### Implementing `Tasks.lookUp` callbacks
 
-There’s an example of implementing a `Tasks.lookUp` callback in [SkyValue
-lookups](#skyvalue-lookups). This section provides rationale and suggests
+There’s an example of implementing a `Tasks.lookUp` callback in [SkyValue lookups](#skyvalue-lookups). This section provides rationale and suggests
 approaches for handling multiple SkyValues.
 
 #### `Tasks.lookUp` callbacks {#tasks-lookup-callbacks}
@@ -710,8 +707,7 @@ class BarProducer implements StateMachine {
 Tip: It would be tempting to use the more concise signature void `accept(Bar
 value)` rather than the stuttery `void acceptBarValue(Bar value)` above.
 However, `Consumer` is a common overload of `void accept(Bar value)`,
-so doing this often leads to violations of the [Overloads: never
-split](https://google.github.io/styleguide/javaguide.html#s3.4.2-ordering-class-contents)
+so doing this often leads to violations of the [Overloads: never split](https://google.github.io/styleguide/javaguide.html#s3.4.2-ordering-class-contents)
 style-guide rule.
 
 Tip: Using a custom `ResultSink` type instead of a generic one from
@@ -774,14 +770,11 @@ pattern after accepting output from either a subtask or SkyValue lookup.
 Note that the implementation of `acceptBarError` eagerly forwards the result to
 the `Caller.ResultSink`, as required by [Error bubbling](#error-bubbling).
 
-Alternatives for top-level `StateMachine`s are described in [`Driver`s and
-bridging to SkyFunctions](#drivers-and-bridging).
+Alternatives for top-level `StateMachine`s are described in [`Driver`s and bridging to SkyFunctions](#drivers-and-bridging).
 
 ### Error handling {#error-handling}
 
-There's a couple of examples of error handling already in [`Tasks.lookUp`
-callbacks](#tasks-lookup-callbacks) and [Propagating values between
-`StateMachines`](#propagating-values). Exceptions, other than
+There's a couple of examples of error handling already in [`Tasks.lookUp` callbacks](#tasks-lookup-callbacks) and [Propagating values between `StateMachines`](#propagating-values). Exceptions, other than
 `InterruptedException` are not thrown, but instead passed around through
 callbacks as values. Such callbacks often have exclusive-or semantics, with
 exactly one of a value or error being passed.
@@ -1184,8 +1177,7 @@ states. Where it is possible, local stack `step` variables are young generation
 variables and efficiently GC'd.
 
 For `StateMachine` variables, breaking things down into subtasks and following
-the recommended pattern for [Propagating values between
-`StateMachine`s](#propagating-values) is also helpful. Observe that when
+the recommended pattern for [Propagating values between `StateMachine`s](#propagating-values) is also helpful. Observe that when
 following the pattern, only child `StateMachine`s have references to parent
 `StateMachine`s and not vice versa. This means that as children complete and
 update the parents using result callbacks, the children naturally fall out of
@@ -1207,8 +1199,7 @@ potentially reflecting local behavior.
 
 ### Concurrency tree diagram {#concurrency-tree-diagram}
 
-The following is an alternative view of the diagram in [Structured
-concurrency](#structured-concurrency) that better depicts the tree structure.
+The following is an alternative view of the diagram in [Structured concurrency](#structured-concurrency) that better depicts the tree structure.
 The blocks form a small tree.
 
 ![Structured Concurrency 3D](/versions/8.0.1/contribute/images/structured-concurrency-3d.svg)
diff --git a/versions/8.0.1/docs/android-instrumentation-test.mdx b/versions/8.0.1/docs/android-instrumentation-test.mdx
index 07975fd6..bd620635 100644
--- a/versions/8.0.1/docs/android-instrumentation-test.mdx
+++ b/versions/8.0.1/docs/android-instrumentation-test.mdx
@@ -2,8 +2,7 @@
 title: 'Android Instrumentation Tests'
 ---
 
-_If you're new to Bazel, start with the [Building Android with
-Bazel](/versions/8.0.1/start/android-app ) tutorial._
+_If you're new to Bazel, start with the [Building Android with Bazel](/versions/8.0.1/start/android-app) tutorial._
 
 ![Running Android instrumentation tests in parallel](/versions/8.0.1/docs/images/android_test.gif "Android instrumentation test")
 
@@ -18,9 +17,7 @@ emulators in a sandbox, ensuring that tests always run from a clean state. Each
 test gets an isolated emulator instance, allowing tests to run in parallel
 without passing states between them.
 
-For more information on Android instrumentation tests, check out the [Android
-developer
-documentation](https://developer.android.com/training/testing/unit-testing/instrumented-unit-tests.html).
+For more information on Android instrumentation tests, check out the [Android developer documentation](https://developer.android.com/training/testing/unit-testing/instrumented-unit-tests.html).
 
 Please file issues in the [GitHub issue tracker](https://github.com/bazelbuild/bazel/issues).
 
@@ -58,8 +55,7 @@ This results in output similar to the following:
 release 4.1.0
 ```
 
-- **KVM**. Bazel requires emulators to have [hardware
-  acceleration](https://developer.android.com/studio/run/emulator-acceleration.html#accel-check)
+- **KVM**. Bazel requires emulators to have [hardware acceleration](https://developer.android.com/studio/run/emulator-acceleration.html#accel-check)
   with KVM on Linux. You can follow these
   [installation instructions](https://help.ubuntu.com/community/KVM/Installation)
   for Ubuntu.
@@ -173,11 +169,9 @@ The main attributes of the rule `android_instrumentation_test` are:
 
 - `target_device`: An `android_device` target. This target describes the
   specifications of the Android emulator which Bazel uses to create, launch and
-  run the tests. See the [section on choosing an Android
-  device](#android-device-target) for more information.
+  run the tests. See the [section on choosing an Android device](#android-device-target) for more information.
 
-The test app's `AndroidManifest.xml` must include [an ``
-tag](https://developer.android.com/studio/test/#configure_instrumentation_manifest_settings).
+The test app's `AndroidManifest.xml` must include [an `` tag](https://developer.android.com/studio/test/#configure_instrumentation_manifest_settings).
 This tag must specify the attributes for the **package of the target app** and
 the **fully qualified class name of the instrumentation test runner**,
 `androidx.test.runner.AndroidJUnitRunner`.
@@ -214,8 +208,7 @@ repositories:
 - `@androidsdk`: The Android SDK. Download this through Android Studio.
 
 - `@android_test_support`: Hosts the test runner, emulator launcher, and
-  `android_device` targets. You can find the [latest release
-  here](https://github.com/android/android-test/releases).
+  `android_device` targets. You can find the [latest release here](https://github.com/android/android-test/releases).
 
 Enable these dependencies by adding the following lines to your `WORKSPACE`
 file:
@@ -240,8 +233,7 @@ android_test_repositories()
 
 ## Maven dependencies {#maven-dependencies}
 
-For managing dependencies on Maven artifacts from repositories, such as [Google
-Maven](https://maven.google.com) or [Maven Central](https://central.maven.org),
+For managing dependencies on Maven artifacts from repositories, such as [Google Maven](https://maven.google.com) or [Maven Central](https://central.maven.org),
 you should use a Maven resolver, such as
 [`rules_jvm_external`](https://github.com/bazelbuild/rules_jvm_external).
 
@@ -370,8 +362,7 @@ the device/emulator listed in `adb devices`.
 
 ## Sample projects {#sample-projects}
 
-If you are looking for canonical project samples, see the [Android testing
-samples](https://github.com/googlesamples/android-testing#experimental-bazel-support)
+If you are looking for canonical project samples, see the [Android testing samples](https://github.com/googlesamples/android-testing#experimental-bazel-support)
 for projects using Espresso and UIAutomator.
 
 ## Espresso setup {#espresso-setup}
@@ -560,8 +551,7 @@ API_LEVELS = [
 
 ## Known issues {#known-issues}
 
-- [Forked adb server processes are not terminated after
-  tests](https://github.com/bazelbuild/bazel/issues/4853)
+- [Forked adb server processes are not terminated after tests](https://github.com/bazelbuild/bazel/issues/4853)
 - While APK building works on all platforms (Linux, macOS, Windows), testing
   only works on Linux.
 - Even with `--config=local_adb`, users still need to specify
diff --git a/versions/8.0.1/docs/android-ndk.mdx b/versions/8.0.1/docs/android-ndk.mdx
index cd3af2d5..f05a2451 100644
--- a/versions/8.0.1/docs/android-ndk.mdx
+++ b/versions/8.0.1/docs/android-ndk.mdx
@@ -2,8 +2,7 @@
 title: 'Using the Android Native Development Kit with Bazel'
 ---
 
-_If you're new to Bazel, please start with the [Building Android with
-Bazel](/versions/8.0.1/start/android-app ) tutorial._
+_If you're new to Bazel, please start with the [Building Android with Bazel](/versions/8.0.1/start/android-app) tutorial._
 
 ## Overview {#overview}
 
@@ -31,8 +30,7 @@ android_ndk_repository(
 )
 ```
 
-For more information about the `android_ndk_repository` rule, see the [Build
-Encyclopedia entry](/versions/8.0.1/reference/be/android#android_ndk_repository).
+For more information about the `android_ndk_repository` rule, see the [Build Encyclopedia entry](/versions/8.0.1/reference/be/android#android_ndk_repository).
 
 If you're using a recent version of the Android NDK (r22 and beyond), use the
 Starlark implementation of `android_ndk_repository`.
@@ -101,13 +99,11 @@ META-INF/MANIFEST.MF
 
 Bazel compiles all of the cc_libraries into a single shared object (`.so`) file,
 targeted for the `armeabi-v7a` ABI by default. To change this or build for
-multiple ABIs at the same time, see the section on [configuring the target
-ABI](#configuring-target-abi).
+multiple ABIs at the same time, see the section on [configuring the target ABI](#configuring-target-abi).
 
 ## Example setup {#example-setup}
 
-This example is available in the [Bazel examples
-repository](https://github.com/bazelbuild/examples/tree/master/android/ndk).
+This example is available in the [Bazel examples repository](https://github.com/bazelbuild/examples/tree/master/android/ndk).
 
 In the `BUILD.bazel` file, three targets are defined with the `android_binary`,
 `android_library`, and `cc_library` rules.
diff --git a/versions/8.0.1/docs/configurable-attributes.mdx b/versions/8.0.1/docs/configurable-attributes.mdx
index 2dd09964..4ba941e7 100644
--- a/versions/8.0.1/docs/configurable-attributes.mdx
+++ b/versions/8.0.1/docs/configurable-attributes.mdx
@@ -2,8 +2,7 @@
 title: 'Configurable Build Attributes'
 ---
 
-**_Configurable attributes_**, commonly known as [`select()`](
-/reference/be/functions#select), is a Bazel feature that lets users toggle the values
+**_Configurable attributes_**, commonly known as [`select()`](/reference/be/functions#select), is a Bazel feature that lets users toggle the values
 of build rule attributes at the command line.
 
 This can be used, for example, for a multiplatform library that automatically
@@ -407,8 +406,7 @@ sh_library(
 )
 ```
 
-If you need a `select` to match when multiple conditions match, consider [AND
-chaining](#and-chaining).
+If you need a `select` to match when multiple conditions match, consider [AND chaining](#and-chaining).
 
 ## OR chaining {#or-chaining}
 
diff --git a/versions/8.0.1/docs/user-manual.mdx b/versions/8.0.1/docs/user-manual.mdx
index 4a6b407b..e39522f4 100644
--- a/versions/8.0.1/docs/user-manual.mdx
+++ b/versions/8.0.1/docs/user-manual.mdx
@@ -1144,10 +1144,7 @@ This option causes Bazel's execution phase to print the full command line
 for each command prior to executing it.
 
 
-  >>>>> # //examples/cpp:hello-world [action 'Linking examples/cpp/hello-world']
-  (cd /home/johndoe/.cache/bazel/_bazel_johndoe/4c084335afceb392cfbe7c31afee3a9f/bazel && \
-    exec env - \
-    /usr/bin/gcc -o bazel-out/local-fastbuild/bin/examples/cpp/hello-world -B/usr/bin/ -Wl,-z,relro,-z,now -no-canonical-prefixes -pass-exit-codes -Wl,-S -Wl,@bazel-out/local_linux-fastbuild/bin/examples/cpp/hello-world-2.params)
+  >>>>> # //examples/cpp:hello-world [action 'Linking examples/cpp/hello-world'](cd /home/johndoe/.cache/bazel/_bazel_johndoe/4c084335afceb392cfbe7c31afee3a9f/bazel && \ exec env - \ /usr/bin/gcc -o bazel-out/local-fastbuild/bin/examples/cpp/hello-world -B/usr/bin/ -Wl,-z,relro,-z,now -no-canonical-prefixes -pass-exit-codes -Wl,-S -Wl,@bazel-out/local_linux-fastbuild/bin/examples/cpp/hello-world-2.params)
 

 
 Where possible, commands are printed in a Bourne shell compatible syntax,
diff --git a/versions/8.0.1/extending/auto-exec-groups.mdx b/versions/8.0.1/extending/auto-exec-groups.mdx
index 9c3d0d33..d7cef622 100644
--- a/versions/8.0.1/extending/auto-exec-groups.mdx
+++ b/versions/8.0.1/extending/auto-exec-groups.mdx
@@ -27,9 +27,7 @@ doesn't detect that ([the error](#first-error-message) is raised), you can set
 
 If you need to use multiple toolchains on a single execution platform (an action
 uses executable or tools from two or more toolchains), you need to manually
-define [exec_groups][exec_groups] (check
-[When should I use a custom exec_group?][multiple_toolchains_exec_groups]
-section).
+define [exec_groups][exec_groups](check [When should I use a custom exec_group?][multiple_toolchains_exec_groups] section).
 
 ## History {#history}
 
@@ -42,8 +40,7 @@ my_rule = rule(
 )
 ```
 
-Rule `my_rule` registers two toolchain types. This means that the [Toolchain
-Resolution](https://bazel.build/extending/toolchains#toolchain-resolution) used
+Rule `my_rule` registers two toolchain types. This means that the [Toolchain Resolution](https://bazel.build/extending/toolchains#toolchain-resolution) used
 to find an execution platform which supports both toolchain types. The selected
 execution platform was used for each registered action inside the rule, unless
 specified differently with [exec_groups][exec_groups].
diff --git a/versions/8.0.1/extending/concepts.mdx b/versions/8.0.1/extending/concepts.mdx
index 908ba37e..ae782bc1 100644
--- a/versions/8.0.1/extending/concepts.mdx
+++ b/versions/8.0.1/extending/concepts.mdx
@@ -20,16 +20,14 @@ Before learning the more advanced concepts, first:
 ## Macros and rules {#macros-and-rules}
 
 A macro is a function that instantiates rules. Macros come in two flavors:
-[symbolic macros](/versions/8.0.1/extending/macros) (new in Bazel 8) and [legacy
-macros](/versions/8.0.1/extending/legacy-macros). The two flavors of macros are defined
+[symbolic macros](/versions/8.0.1/extending/macros) (new in Bazel 8) and [legacy macros](/versions/8.0.1/extending/legacy-macros). The two flavors of macros are defined
 differently, but behave almost the same from the point of view of a user. A
 macro is useful when a `BUILD` file is getting too repetitive or too complex, as
 it lets you reuse some code. The function is evaluated as soon as the `BUILD`
 file is read. After the evaluation of the `BUILD` file, Bazel has little
 information about macros. If your macro generates a `genrule`, Bazel will
 behave *almost* as if you declared that `genrule` in the `BUILD` file. (The one
-exception is that targets declared in a symbolic macro have [special visibility
-semantics](/versions/8.0.1/extending/macros#visibility): a symbolic macro can hide its internal
+exception is that targets declared in a symbolic macro have [special visibility semantics](/versions/8.0.1/extending/macros#visibility): a symbolic macro can hide its internal
 targets from the rest of the package.)
 
 A [rule](/versions/8.0.1/extending/rules) is more powerful than a macro. It can access Bazel
@@ -76,8 +74,7 @@ they will not be executed.
 ## Creating extensions
 
 * [Create your first macro](/versions/8.0.1/rules/macro-tutorial) in order to reuse some code.
-  Then [learn more about macros](/versions/8.0.1/extending/macros) and [using them to create
-  "custom verbs"](/versions/8.0.1/rules/verbs-tutorial).
+  Then [learn more about macros](/versions/8.0.1/extending/macros) and [using them to create "custom verbs"](/versions/8.0.1/rules/verbs-tutorial).
 
 * [Follow the rules tutorial](/versions/8.0.1/rules/rules-tutorial) to get started with rules.
   Next, you can read more about the [rules concepts](/versions/8.0.1/extending/rules).
@@ -92,8 +89,7 @@ them within reach:
 ## Going further
 
 In addition to [macros](/versions/8.0.1/extending/macros) and [rules](/versions/8.0.1/extending/rules), you
-may want to write [aspects](/versions/8.0.1/extending/aspects) and [repository
-rules](/versions/8.0.1/extending/repo).
+may want to write [aspects](/versions/8.0.1/extending/aspects) and [repository rules](/versions/8.0.1/extending/repo).
 
 * Use [Buildifier](https://github.com/bazelbuild/buildtools)
   consistently to format and lint your code.
diff --git a/versions/8.0.1/extending/depsets.mdx b/versions/8.0.1/extending/depsets.mdx
index 0e66a853..0df2765f 100644
--- a/versions/8.0.1/extending/depsets.mdx
+++ b/versions/8.0.1/extending/depsets.mdx
@@ -111,8 +111,7 @@ need to ensure that if `B` depends on `A`, then `A.o` comes before `B.o` on the
 linker’s command line. Other tools might have the opposite requirement.
 
 Three traversal orders are supported: `postorder`, `preorder`, and
-`topological`. The first two work exactly like [tree
-traversals](https://en.wikipedia.org/wiki/Tree_traversal#Depth-first_search)
+`topological`. The first two work exactly like [tree traversals](https://en.wikipedia.org/wiki/Tree_traversal#Depth-first_search)
 except that they operate on DAGs and skip already visited nodes. The third order
 works as a topological sort from root to leaves, essentially the same as
 preorder except that shared children are listed only after all of their parents.
diff --git a/versions/8.0.1/extending/exec-groups.mdx b/versions/8.0.1/extending/exec-groups.mdx
index ac4b4de3..6ff64092 100644
--- a/versions/8.0.1/extending/exec-groups.mdx
+++ b/versions/8.0.1/extending/exec-groups.mdx
@@ -63,8 +63,7 @@ test rules.
 
 In the rule implementation, you can declare that actions should be run on the
 execution platform of an execution group. You can do this by using the `exec_group`
-param of action generating methods, specifically [`ctx.actions.run`]
-(/rules/lib/builtins/actions#run) and
+param of action generating methods, specifically [`ctx.actions.run`](/rules/lib/builtins/actions#run) and
 [`ctx.actions.run_shell`](/versions/8.0.1/rules/lib/builtins/actions#run_shell).
 
 ```python
diff --git a/versions/8.0.1/extending/macros.mdx b/versions/8.0.1/extending/macros.mdx
index 03f49d16..923b36c7 100644
--- a/versions/8.0.1/extending/macros.mdx
+++ b/versions/8.0.1/extending/macros.mdx
@@ -31,8 +31,7 @@ two required parameters: `attrs` and `implementation`.
 
 ### Attributes {#attributes}
 
-`attrs` accepts a dictionary of attribute name to [attribute
-types](https://bazel.build/rules/lib/toplevel/attr#members), which represents
+`attrs` accepts a dictionary of attribute name to [attribute types](https://bazel.build/rules/lib/toplevel/attr#members), which represents
 the arguments to the macro. Two common attributes – `name` and `visibility` –
 are implicitly added to all macros and are not included in the dictionary passed
 to `attrs`.
@@ -66,9 +65,7 @@ To support this pattern, a macro can *inherit attributes* from a rule or another
 macro by passing the [rule](https://bazel.build/versions/8.0.1/rules/lib/builtins/rule) or
 [macro symbol](https://bazel.build/versions/8.0.1/rules/lib/builtins/macro) to `macro()`'s
 `inherit_attrs` argument. (You can also use the special string `"common"`
-instead of a rule or macro symbol to inherit the [common attributes defined for
-all Starlark build
-rules](https://bazel.build/reference/be/common-definitions#common-attributes).)
+instead of a rule or macro symbol to inherit the [common attributes defined for all Starlark build rules](https://bazel.build/reference/be/common-definitions#common-attributes).)
 Only public attributes get inherited, and the attributes in the macro's own
 `attrs` dictionary override inherited attributes with the same name. You can
 also *remove* inherited attributes by using `None` as a value in the `attrs`
diff --git a/versions/8.0.1/extending/platforms.mdx b/versions/8.0.1/extending/platforms.mdx
index 94df0b11..c3ca08b3 100644
--- a/versions/8.0.1/extending/platforms.mdx
+++ b/versions/8.0.1/extending/platforms.mdx
@@ -245,8 +245,7 @@ cc_library(
 
 You can use the
 [`IncompatiblePlatformProvider`](/versions/8.0.1/rules/lib/providers/IncompatiblePlatformProvider)
-in `bazel cquery`'s [Starlark output
-format](/versions/8.0.1/query/cquery#output-format-definition) to distinguish
+in `bazel cquery`'s [Starlark output format](/versions/8.0.1/query/cquery#output-format-definition) to distinguish
 incompatible targets from compatible ones.
 
 This can be used to filter out incompatible targets. The example below will
@@ -266,5 +265,4 @@ $ bazel cquery //... --output=starlark --starlark:file=example.cquery
 
 ### Known Issues
 
-Incompatible targets [ignore visibility
-restrictions](https://github.com/bazelbuild/bazel/issues/16044).
+Incompatible targets [ignore visibility restrictions](https://github.com/bazelbuild/bazel/issues/16044).
diff --git a/versions/8.0.1/extending/repo.mdx b/versions/8.0.1/extending/repo.mdx
index d463fd7d..4f0523b4 100644
--- a/versions/8.0.1/extending/repo.mdx
+++ b/versions/8.0.1/extending/repo.mdx
@@ -74,8 +74,7 @@ specified.
 
 The input parameter `repository_ctx` can be used to access attribute values, and
 non-hermetic functions (finding a binary, executing a binary, creating a file in
-the repository or downloading a file from the Internet). See [the API
-docs](/versions/8.0.1/rules/lib/builtins/repository_ctx) for more context. Example:
+the repository or downloading a file from the Internet). See [the API docs](/versions/8.0.1/rules/lib/builtins/repository_ctx) for more context. Example:
 
 ```python
 def _impl(repository_ctx):
@@ -144,8 +143,7 @@ definition has the `configure` attribute set, use `bazel fetch --force
 
 ## Examples
 
--   [C++ auto-configured
-    toolchain](https://cs.opensource.google/bazel/bazel/+/master:tools/cpp/cc_configure.bzl;drc=644b7d41748e09eff9e47cbab2be2263bb71f29a;l=176):
+-   [C++ auto-configured toolchain](https://cs.opensource.google/bazel/bazel/+/master:tools/cpp/cc_configure.bzl;drc=644b7d41748e09eff9e47cbab2be2263bb71f29a;l=176):
     it uses a repo rule to automatically create the C++ configuration files for
     Bazel by looking for the local C++ compiler, the environment and the flags
     the C++ compiler supports.
diff --git a/versions/8.0.1/extending/rules.mdx b/versions/8.0.1/extending/rules.mdx
index 0cc97712..7db43643 100644
--- a/versions/8.0.1/extending/rules.mdx
+++ b/versions/8.0.1/extending/rules.mdx
@@ -449,8 +449,7 @@ def _example_library_impl(ctx):
 
 If `DefaultInfo` is not returned by a rule implementation or the `files`
 parameter is not specified, `DefaultInfo.files` defaults to all
-*predeclared outputs* (generally, those created by [output
-attributes](#output_attributes)).
+*predeclared outputs* (generally, those created by [output attributes](#output_attributes)).
 
 Rules that perform actions should provide default outputs, even if those outputs
 are not expected to be directly used. Actions that are not in the graph of the
diff --git a/versions/8.0.1/extending/toolchains.mdx b/versions/8.0.1/extending/toolchains.mdx
index 36fa1b9e..22c11e93 100644
--- a/versions/8.0.1/extending/toolchains.mdx
+++ b/versions/8.0.1/extending/toolchains.mdx
@@ -523,8 +523,7 @@ The set of available toolchains, in priority order, is created from
   4. Toolchains registered in the "WORKSPACE suffix"; this is only used by
      certain native rules bundled with the Bazel installation.
 
-**NOTE:** [Pseudo-targets like `:all`, `:*`, and
-`/...`](/versions/8.0.1/run/build#specifying-build-targets) are ordered by Bazel's package
+**NOTE:** [Pseudo-targets like `:all`, `:*`, and `/...`](/versions/8.0.1/run/build#specifying-build-targets) are ordered by Bazel's package
 loading mechanism, which uses a lexicographic ordering.
 
 The resolution steps are as follows.
diff --git a/versions/8.0.1/external/advanced.mdx b/versions/8.0.1/external/advanced.mdx
index b835ba5c..1410cd66 100644
--- a/versions/8.0.1/external/advanced.mdx
+++ b/versions/8.0.1/external/advanced.mdx
@@ -4,10 +4,8 @@ title: 'Advanced topics on external dependencies'
 
 ## Shadowing dependencies in WORKSPACE
 
-Note: This section applies to the [WORKSPACE
-system](/versions/8.0.1/external/overview#workspace-system) only. For
-[Bzlmod](/versions/8.0.1/external/overview#bzlmod), use a [multiple-version
-override](/versions/8.0.1/external/module#multiple-version_override).
+Note: This section applies to the [WORKSPACE system](/versions/8.0.1/external/overview#workspace-system) only. For
+[Bzlmod](/versions/8.0.1/external/overview#bzlmod), use a [multiple-version override](/versions/8.0.1/external/module#multiple-version_override).
 
 Whenever possible, have a single version policy in your project, which is
 required for dependencies that you compile against and end up in your final
@@ -128,29 +126,24 @@ preferring IPv4 if enabled. In some situations, for example when the IPv4
 network cannot resolve/reach external addresses, this can cause `Network
 unreachable` exceptions and build failures. In these cases, you can override
 Bazel's behavior to prefer IPv6 by using the
-[`java.net.preferIPv6Addresses=true` system
-property](https://docs.oracle.com/javase/8/docs/api/java/net/doc-files/net-properties.html).
+[`java.net.preferIPv6Addresses=true` system property](https://docs.oracle.com/javase/8/docs/api/java/net/doc-files/net-properties.html).
 Specifically:
 
-*   Use `--host_jvm_args=-Djava.net.preferIPv6Addresses=true` [startup
-    option](/versions/8.0.1/docs/user-manual#startup-options), for example by adding the
+*   Use `--host_jvm_args=-Djava.net.preferIPv6Addresses=true` [startup option](/versions/8.0.1/docs/user-manual#startup-options), for example by adding the
     following line in your [`.bazelrc` file](/versions/8.0.1/run/bazelrc):
 
     `startup --host_jvm_args=-Djava.net.preferIPv6Addresses=true`
 
 *   When running Java build targets that need to connect to the internet (such
     as for integration tests), use the
-    `--jvmopt=-Djava.net.preferIPv6Addresses=true` [tool
-    flag](/versions/8.0.1/docs/user-manual#jvmopt). For example, include in your [`.bazelrc`
-    file](/versions/8.0.1/run/bazelrc):
+    `--jvmopt=-Djava.net.preferIPv6Addresses=true` [tool flag](/versions/8.0.1/docs/user-manual#jvmopt). For example, include in your [`.bazelrc` file](/versions/8.0.1/run/bazelrc):
 
     `build --jvmopt=-Djava.net.preferIPv6Addresses`
 
 *   If you are using [`rules_jvm_external`](https://github.com/bazelbuild/rules_jvm_external)
     for dependency version resolution, also add
     `-Djava.net.preferIPv6Addresses=true` to the `COURSIER_OPTS` environment
-    variable to [provide JVM options for
-    Coursier](https://github.com/bazelbuild/rules_jvm_external#provide-jvm-options-for-coursier-with-coursier_opts).
+    variable to [provide JVM options for Coursier](https://github.com/bazelbuild/rules_jvm_external#provide-jvm-options-for-coursier-with-coursier_opts).
 
 ## Offline builds
 
@@ -167,15 +160,12 @@ fetch a file with [`ctx.download`](/versions/8.0.1/rules/lib/builtins/repository
 providing a hash sum of the file needed, Bazel looks for a file matching the
 basename of the first URL, and uses the local copy if the hash matches.
 
-Bazel itself uses this technique to bootstrap offline from the [distribution
-artifact](https://github.com/bazelbuild/bazel-website/blob/master/designs/_posts/2016-10-11-distribution-artifact.md).
-It does so by [collecting all the needed external
-dependencies](https://github.com/bazelbuild/bazel/blob/5cfa0303d6ac3b5bd031ff60272ce80a704af8c2/WORKSPACE#L116)
+Bazel itself uses this technique to bootstrap offline from the [distribution artifact](https://github.com/bazelbuild/bazel-website/blob/master/designs/_posts/2016-10-11-distribution-artifact.md).
+It does so by [collecting all the needed external dependencies](https://github.com/bazelbuild/bazel/blob/5cfa0303d6ac3b5bd031ff60272ce80a704af8c2/WORKSPACE#L116)
 in an internal
 [`distdir_tar`](https://github.com/bazelbuild/bazel/blob/5cfa0303d6ac3b5bd031ff60272ce80a704af8c2/distdir.bzl#L44).
 
 Bazel allows execution of arbitrary commands in repository rules without knowing
 if they call out to the network, and so cannot enforce fully offline builds. To
 test if a build works correctly offline, manually block off the network (as
-Bazel does in its [bootstrap
-test](https://cs.opensource.google/bazel/bazel/+/master:src/test/shell/bazel/BUILD;l=1073;drc=88c426e73cc0eb0a41c0d7995e36acd94e7c9a48)).
\ No newline at end of file
+Bazel does in its [bootstrap test](https://cs.opensource.google/bazel/bazel/+/master:src/test/shell/bazel/BUILD;l=1073;drc=88c426e73cc0eb0a41c0d7995e36acd94e7c9a48)).
\ No newline at end of file
diff --git a/versions/8.0.1/external/migration.mdx b/versions/8.0.1/external/migration.mdx
index 0ecd64cc..f639978b 100644
--- a/versions/8.0.1/external/migration.mdx
+++ b/versions/8.0.1/external/migration.mdx
@@ -2,8 +2,7 @@
 title: 'Bzlmod Migration Guide'
 ---
 
-Due to the [shortcomings of
-WORKSPACE](/versions/8.0.1/external/overview#workspace-shortcomings), Bzlmod is going to
+Due to the [shortcomings of WORKSPACE](/versions/8.0.1/external/overview#workspace-shortcomings), Bzlmod is going to
 replace the legacy WORKSPACE system. The WORKSPACE file will be disabled by
 default in Bazel 8 (late 2024) and will be removed in Bazel 9 (late 2025).
 This guide helps you migrate your project to Bzlmod and drop WORKSPACE for
@@ -117,9 +116,7 @@ Bazel module when it also adopts Bzlmod.
 
 *   **Bzlmod**
 
-    With Bzlmod, as long as the your dependency is available in [Bazel Central
-    Registry](https://registry.bazel.build) or your custom [Bazel
-    registry](/versions/8.0.1/external/registry), you can simply depend on it with a
+    With Bzlmod, as long as the your dependency is available in [Bazel Central Registry](https://registry.bazel.build) or your custom [Bazel registry](/versions/8.0.1/external/registry), you can simply depend on it with a
     [`bazel_dep`](/versions/8.0.1/rules/lib/globals/module#bazel_dep) directive.
 
     ```python
@@ -150,8 +147,7 @@ repository.
 
 If your dependency is not a Bazel project or not yet available in any Bazel
 registry, you can introduce it using
-[`use_repo_rule`](/versions/8.0.1/external/module#use_repo_rule) or [module
-extensions](/versions/8.0.1/external/extension).
+[`use_repo_rule`](/versions/8.0.1/external/module#use_repo_rule) or [module extensions](/versions/8.0.1/external/extension).
 
 *   **WORKSPACE**
 
@@ -604,8 +600,7 @@ macros.
 Fortunately, the flag
 [`--experimental_repository_resolved_file`][resolved_file_flag]
 can help. This flag essentially generates a "lock file" of all fetched external
-dependencies in your last Bazel command. You can find more details in this [blog
-post](https://blog.bazel.build/2018/07/09/bazel-sync-and-resolved-file.html).
+dependencies in your last Bazel command. You can find more details in this [blog post](https://blog.bazel.build/2018/07/09/bazel-sync-and-resolved-file.html).
 
 [resolved_file_flag]: /reference/command-line-reference#flag--experimental_repository_resolved_file
 
@@ -646,11 +641,9 @@ You may also know `bazel query` can be used for inspecting repository rules with
 bazel query --output=build //external:
 ```
 
-While it is more convenient and much faster, [bazel query can lie about
-external dependency version](https://github.com/bazelbuild/bazel/issues/12947),
+While it is more convenient and much faster, [bazel query can lie about external dependency version](https://github.com/bazelbuild/bazel/issues/12947),
 so be careful using it! Querying and inspecting external
-dependencies with Bzlmod is going to achieved by a [new
-subcommand](https://github.com/bazelbuild/bazel/issues/15365).
+dependencies with Bzlmod is going to achieved by a [new subcommand](https://github.com/bazelbuild/bazel/issues/15365).
 
 #### Built-in default dependencies {#builtin-default-deps}
 
@@ -697,8 +690,7 @@ Using the WORKSPACE.bzlmod file can make the migration easier because:
 #### Repository visibility {#repository-visibility}
 
 Bzlmod is able to control which other repositories are visible from a given
-repository, check [repository names and strict
-deps](/versions/8.0.1/external/module#repository_names_and_strict_deps) for more details.
+repository, check [repository names and strict deps](/versions/8.0.1/external/module#repository_names_and_strict_deps) for more details.
 
 Here is a summary of repository visibilities from different types of
 repositories when also taking WORKSPACE into consideration.
@@ -711,8 +703,7 @@ repositories when also taking WORKSPACE into consideration.
 | WORKSPACE Repos | All visible | Not visible | Not visible | All visible |
 
 Note: For the root module, if a repository `@foo` is defined in WORKSPACE and
-`@foo` is also used as an [apparent repository
-name](/versions/8.0.1/external/overview#apparent-repo-name) in MODULE.bazel, then `@foo`
+`@foo` is also used as an [apparent repository name](/versions/8.0.1/external/overview#apparent-repo-name) in MODULE.bazel, then `@foo`
 refers to the one introduced in MODULE.bazel.
 
 Note: For a module extension generated repository `@bar`, if `@foo` is used as
@@ -787,9 +778,7 @@ the project. Take note of a few things when creating the source archive:
     GitHub isn't going to guarantee the checksum of source archives generated on
     demand. In short, URLs in the form of
     `https://github.com///releases/download/...` is considered stable
-    while `https://github.com///archive/...` is not. Check [GitHub
-    Archive Checksum
-    Outage](https://blog.bazel.build/2023/02/15/github-archive-checksum.html)
+    while `https://github.com///archive/...` is not. Check [GitHub Archive Checksum Outage](https://blog.bazel.build/2023/02/15/github-archive-checksum.html)
     for more context.
 
 *   **Make sure the source tree follows the layout of the original repository.**
@@ -818,8 +807,7 @@ Pull Request.
 
 [bcr_contrib_guide]: https://github.com/bazelbuild/bazel-central-registry/tree/main/docs#contribute-a-bazel-module
 
-It is **highly recommended** to set up the [Publish to
-BCR](https://github.com/bazel-contrib/publish-to-bcr) GitHub App for your
+It is **highly recommended** to set up the [Publish to BCR](https://github.com/bazel-contrib/publish-to-bcr) GitHub App for your
 repository to automate the process of submitting your module to the BCR.
 
 ## Best practices {#best-practices}
diff --git a/versions/8.0.1/external/mod-command.mdx b/versions/8.0.1/external/mod-command.mdx
index e49acc52..f5ebb078 100644
--- a/versions/8.0.1/external/mod-command.mdx
+++ b/versions/8.0.1/external/mod-command.mdx
@@ -61,11 +61,9 @@ The available subcommands and their respective required arguments are:
 
 *   ``: All present versions of the module ``.
 
-*   `@`: The repo with the given [apparent
-    name](overview#apparent-repo-name) in the context of the `--base_module`.
+*   `@`: The repo with the given [apparent name](overview#apparent-repo-name) in the context of the `--base_module`.
 
-*   `@@`: The repo with the given [canonical
-    name](overview#canonical-repo-name).
+*   `@@`: The repo with the given [canonical name](overview#canonical-repo-name).
 
 In a context requiring specifying modules, ``s referring to repos that
 correspond to modules (as opposed to extension-generated repos) can also be
@@ -87,8 +85,7 @@ The following options only affect the subcommands that print graphs (`graph`,
     information about the version resolution of each module. If the module
     version changed during resolution, show either which version replaced it or
     what was the original version, the reason it was replaced, and which modules
-    requested the new version if the reason was [Minimal Version
-    Selection](module#version-selection).
+    requested the new version if the reason was [Minimal Version Selection](module#version-selection).
 
 *   `--include_unused` *default: "false"*: Include in the output graph the
     modules which were originally present in the dependency graph, but became
diff --git a/versions/8.0.1/external/module.mdx b/versions/8.0.1/external/module.mdx
index 51ed23dd..6ef3dded 100644
--- a/versions/8.0.1/external/module.mdx
+++ b/versions/8.0.1/external/module.mdx
@@ -122,8 +122,7 @@ serves multiple purposes:
     version, regardless of which versions of the dependency are requested in the
     dependency graph.
 *   With the `registry` attribute, you can force this dependency to come from a
-    specific registry, instead of following the normal [registry
-    selection](/versions/8.0.1/external/registry#selecting_registries) process.
+    specific registry, instead of following the normal [registry selection](/versions/8.0.1/external/registry#selecting_registries) process.
 *   With the `patch*` attributes, you can specify a set of patches to apply to
     the downloaded module.
 
@@ -176,13 +175,11 @@ With `bazel_dep`, you can define repos that represent other Bazel modules.
 Sometimes there is a need to define a repo that does _not_ represent a Bazel
 module; for example, one that contains a plain JSON file to be read as data.
 
-In this case, you could use the [`use_repo_rule`
-directive](/versions/8.0.1/rules/lib/globals/module#use_repo_rule) to directly define a repo
+In this case, you could use the [`use_repo_rule` directive](/versions/8.0.1/rules/lib/globals/module#use_repo_rule) to directly define a repo
 by invoking a repo rule. This repo will only be visible to the module it's
 defined in.
 
-Under the hood, this is implemented using the same mechanism as [module
-extensions](/versions/8.0.1/external/extension), which lets you define repos with more
+Under the hood, this is implemented using the same mechanism as [module extensions](/versions/8.0.1/external/extension), which lets you define repos with more
 flexibility.
 
 ## Repository names and strict deps
diff --git a/versions/8.0.1/external/overview.mdx b/versions/8.0.1/external/overview.mdx
index 8b1ed1b1..72dd86ad 100644
--- a/versions/8.0.1/external/overview.mdx
+++ b/versions/8.0.1/external/overview.mdx
@@ -128,8 +128,7 @@ for all build targets inside the repo.
 
 The syntax of a `REPO.bazel` file is similar to `BUILD` files, except that no
 `load` statements are supported, and only a single function, `repo()`, is
-available. `repo()` takes the same arguments as the [`package()`
-function](/versions/8.0.1/reference/be/functions#package) in `BUILD` files; whereas `package()`
+available. `repo()` takes the same arguments as the [`package()` function](/versions/8.0.1/reference/be/functions#package) in `BUILD` files; whereas `package()`
 specifies common attributes for all build targets inside the package, `repo()`
 analogously does so for all build targets inside the repo.
 
@@ -163,8 +162,7 @@ bazel_dep(name = "protobuf", version = "3.19.0")
 ```
 
 A module must only list its direct dependencies, which Bzlmod looks up in a
-[Bazel registry](/versions/8.0.1/external/registry) — by default, the [Bazel Central
-Registry](https://bcr.bazel.build/). The registry provides the
+[Bazel registry](/versions/8.0.1/external/registry) — by default, the [Bazel Central Registry](https://bcr.bazel.build/). The registry provides the
 dependencies' `MODULE.bazel` files, which allows Bazel to discover the entire
 transitive dependency graph before performing version resolution.
 
@@ -235,5 +233,4 @@ many pain points, including:
         `B` and `C`; `B` and `C` both depend on different versions of `D`).
 
 Due to the shortcomings of WORKSPACE, Bzlmod is going to replace the legacy
-WORKSPACE system in future Bazel releases. Please read the [Bzlmod migration
-guide](/versions/8.0.1/external/migration) on how to migrate to Bzlmod.
+WORKSPACE system in future Bazel releases. Please read the [Bzlmod migration guide](/versions/8.0.1/external/migration) on how to migrate to Bzlmod.
diff --git a/versions/8.0.1/external/registry.mdx b/versions/8.0.1/external/registry.mdx
index 44c8d937..77e07df3 100644
--- a/versions/8.0.1/external/registry.mdx
+++ b/versions/8.0.1/external/registry.mdx
@@ -42,8 +42,7 @@ An index registry must follow the format below:
             project
         *   `versions`: A list of all the versions of this module to be found in
             this registry
-        *   `yanked_versions`: A map of [*yanked*
-            versions](/versions/8.0.1/external/module#yanked_versions) of this module. The keys
+        *   `yanked_versions`: A map of [*yanked* versions](/versions/8.0.1/external/module#yanked_versions) of this module. The keys
             should be versions to yank and the values should be descriptions of
             why the version is yanked, ideally containing a link to more
             information
@@ -54,8 +53,7 @@ An index registry must follow the format below:
         *   The default type is "archive", representing an `http_archive` repo,
             with the following fields:
             *   `url`: The URL of the source archive
-            *   `integrity`: The [Subresource
-                Integrity](https://w3c.github.io/webappsec-subresource-integrity/#integrity-metadata-description)
+            *   `integrity`: The [Subresource Integrity](https://w3c.github.io/webappsec-subresource-integrity/#integrity-metadata-description)
                 checksum of the archive
             *   `strip_prefix`: A directory prefix to strip when extracting the
                 source archive
@@ -103,8 +101,7 @@ You can browse its contents using the web frontend at
 https://registry.bazel.build/.
 
 The Bazel community maintains the BCR, and contributors are welcome to submit
-pull requests. See the [BCR contribution
-guidelines](https://github.com/bazelbuild/bazel-central-registry/blob/main/docs/README.md).
+pull requests. See the [BCR contribution guidelines](https://github.com/bazelbuild/bazel-central-registry/blob/main/docs/README.md).
 
 In addition to following the format of a normal index registry, the BCR requires
 a `presubmit.yml` file for each module version
diff --git a/versions/8.0.1/external/vendor.mdx b/versions/8.0.1/external/vendor.mdx
index d011936a..8c9df7ce 100644
--- a/versions/8.0.1/external/vendor.mdx
+++ b/versions/8.0.1/external/vendor.mdx
@@ -23,9 +23,7 @@ absolute path.
 ## Vendor a specific external repository {#vendor-specific-repository}
 
 You can use the `vendor` command with the `--repo` flag to specify which repo
-to vendor, it accepts both [canonical repo
-name](/versions/8.0.1/external/overview#canonical-repo-name) and [apparent repo
-name](/versions/8.0.1/external/overview#apparent-repo-name).
+to vendor, it accepts both [canonical repo name](/versions/8.0.1/external/overview#canonical-repo-name) and [apparent repo name](/versions/8.0.1/external/overview#apparent-repo-name).
 
 For example, running:
 
diff --git a/versions/8.0.1/help.mdx b/versions/8.0.1/help.mdx
index f9e0dfda..459d6077 100644
--- a/versions/8.0.1/help.mdx
+++ b/versions/8.0.1/help.mdx
@@ -46,5 +46,4 @@ what level of support Bazel provides.
 
 ## File a bug {#file-bug}
 
-If you encounter a bug or want to request a feature, file a [GitHub
-Issue](https://github.com/bazelbuild/bazel/issues).
+If you encounter a bug or want to request a feature, file a [GitHub Issue](https://github.com/bazelbuild/bazel/issues).
diff --git a/versions/8.0.1/install/bazelisk.mdx b/versions/8.0.1/install/bazelisk.mdx
index c5afdcbd..abc502ee 100644
--- a/versions/8.0.1/install/bazelisk.mdx
+++ b/versions/8.0.1/install/bazelisk.mdx
@@ -16,8 +16,7 @@ For more details, see
 ## Updating Bazel
 
 Bazel has a [backward compatibility policy](/versions/8.0.1/release/backward-compatibility)
-(see [guidance for rolling out incompatible
-changes](/versions/8.0.1/contribute/breaking-changes) if you
+(see [guidance for rolling out incompatible changes](/versions/8.0.1/contribute/breaking-changes) if you
 are the author of one). That page summarizes best practices on how to test and
 migrate your project with upcoming incompatible changes and how to provide
 feedback to the incompatible change authors.
diff --git a/versions/8.0.1/install/compile-source.mdx b/versions/8.0.1/install/compile-source.mdx
index 842ce4ad..2135a70e 100644
--- a/versions/8.0.1/install/compile-source.mdx
+++ b/versions/8.0.1/install/compile-source.mdx
@@ -45,8 +45,7 @@ it by typing `bazel` in a terminal.
 
 **Reason**: To build Bazel from a GitHub source tree, you need a pre-existing
 Bazel binary. You can install one from a package manager or download one from
-GitHub. See [Installing Bazel](/versions/8.0.1/install). (Or you can [build from
-scratch (bootstrap)](#bootstrap-bazel).)
+GitHub. See [Installing Bazel](/versions/8.0.1/install). (Or you can [build from scratch (bootstrap)](#bootstrap-bazel).)
 
 **Troubleshooting**:
 
@@ -239,8 +238,7 @@ For instructions for Unix-like systems, see
     ```
 
 *   **The Visual C++ compiler.** Install the Visual C++ compiler either as part
-    of Visual Studio 2015 or newer, or by installing the latest [Build Tools
-    for Visual Studio 2017](https://aka.ms/BuildTools).
+    of Visual Studio 2015 or newer, or by installing the latest [Build Tools for Visual Studio 2017](https://aka.ms/BuildTools).
 
 *   **JDK.** Version 21 is required.
 
diff --git a/versions/8.0.1/install/ide.mdx b/versions/8.0.1/install/ide.mdx
index 561d0e02..c42d95e9 100644
--- a/versions/8.0.1/install/ide.mdx
+++ b/versions/8.0.1/install/ide.mdx
@@ -38,10 +38,8 @@ To install, go to the IDE's plugin browser and search for `Bazel`.
 To manually install older versions, download the zip files from JetBrains'
 Plugin Repository and install the zip file from the IDE's plugin browser:
 
-*  [Android Studio
-   plugin](https://plugins.jetbrains.com/plugin/9185-android-studio-with-bazel)
-*  [IntelliJ
-   plugin](https://plugins.jetbrains.com/plugin/8609-intellij-with-bazel)
+*  [Android Studio plugin](https://plugins.jetbrains.com/plugin/9185-android-studio-with-bazel)
+*  [IntelliJ plugin](https://plugins.jetbrains.com/plugin/8609-intellij-with-bazel)
 *  [CLion plugin](https://plugins.jetbrains.com/plugin/9554-clion-with-bazel)
 
 ### Xcode {#xcode}
@@ -61,8 +59,7 @@ Features:
 * Starlark debugger for `.bzl` files during a build (set breakpoints, step
   through code, inspect variables, and so on)
 
-Find [the plugin on the Visual Studio
-marketplace](https://marketplace.visualstudio.com/items?itemName=BazelBuild.vscode-bazel).
+Find [the plugin on the Visual Studio marketplace](https://marketplace.visualstudio.com/items?itemName=BazelBuild.vscode-bazel).
 The plugin is [open source](https://github.com/bazelbuild/vscode-bazel).
 
 See also: [Autocomplete for Source Code](#autocomplete-for-source-code)
@@ -82,8 +79,7 @@ See also: [Autocomplete for Source Code](#autocomplete-for-source-code)
 
 ### Emacs {#emacs}
 
-See [`bazelbuild/bazel-emacs-mode` on
-GitHub](https://github.com/bazelbuild/emacs-bazel-mode)
+See [`bazelbuild/bazel-emacs-mode` on GitHub](https://github.com/bazelbuild/emacs-bazel-mode)
 
 See also: [Autocomplete for Source Code](#autocomplete-for-source-code)
 
@@ -115,6 +111,5 @@ tool for building Bazel targets when source files change.
 
 ## Building your own IDE plugin {#build-own-plugin}
 
-Read the [**IDE support** blog
-post](https://blog.bazel.build/2016/06/10/ide-support.html) to learn more about
+Read the [**IDE support** blog post](https://blog.bazel.build/2016/06/10/ide-support.html) to learn more about
 the Bazel APIs to use when building an IDE plugin.
diff --git a/versions/8.0.1/install/windows.mdx b/versions/8.0.1/install/windows.mdx
index ea3e5a6d..873ecbfc 100644
--- a/versions/8.0.1/install/windows.mdx
+++ b/versions/8.0.1/install/windows.mdx
@@ -31,8 +31,7 @@ To check your Windows version:
 
 Alternatively you can:
 
-*   [Download the Bazel binary (`bazel-version-windows-x86_64.exe`) from
- GitHub](https://github.com/bazelbuild/bazel/releases).
+*   [Download the Bazel binary (`bazel-version-windows-x86_64.exe`) from GitHub](https://github.com/bazelbuild/bazel/releases).
 *   [Install Bazel from Chocolatey](#chocolately)
 *   [Install Bazel from Scoop](#scoop)
 *   [Build Bazel from source](/versions/8.0.1/install/compile-source)
@@ -208,8 +207,7 @@ If that doesn't help:
     its dependencies, such as the MSYS2 shell. This will not install Visual C++
     though.
 
-See [Chocolatey installation and package maintenance
-guide](/versions/8.0.1/contribute/windows-chocolatey-maintenance) for more
+See [Chocolatey installation and package maintenance guide](/versions/8.0.1/contribute/windows-chocolatey-maintenance) for more
 information about the Chocolatey package.
 
 ### Using Scoop {#scoop}
@@ -226,8 +224,7 @@ information about the Chocolatey package.
     scoop install bazel
     ```
 
-See [Scoop installation and package maintenance
-guide](/versions/8.0.1/contribute/windows-scoop-maintenance) for more
+See [Scoop installation and package maintenance guide](/versions/8.0.1/contribute/windows-scoop-maintenance) for more
 information about the Scoop package.
 
 ### Build from source {#build-from-source}
diff --git a/versions/8.0.1/migrate/maven.mdx b/versions/8.0.1/migrate/maven.mdx
index b4417dd3..6a9ee09c 100644
--- a/versions/8.0.1/migrate/maven.mdx
+++ b/versions/8.0.1/migrate/maven.mdx
@@ -19,8 +19,7 @@ directly run by Bazel since there's no Maven compatibility layer.
 ## Before you begin {#before-you-begin}
 
 *   [Install Bazel](/versions/8.0.1/install) if it's not yet installed.
-*   If you're new to Bazel, go through the tutorial [Introduction to Bazel:
-    Build Java](/versions/8.0.1/start/java) before you start migrating. The tutorial explains
+*   If you're new to Bazel, go through the tutorial [Introduction to Bazel: Build Java](/versions/8.0.1/start/java) before you start migrating. The tutorial explains
     Bazel's concepts, structure, and label syntax.
 
 ## Differences between Maven and Bazel {#dif-maven-bazel}
@@ -44,8 +43,7 @@ The steps below describe how to migrate your project to Bazel:
 3.  [Create more BUILD files](#3-build)
 4.  [Build using Bazel](#4-build)
 
-Examples below come from a migration of the [Guava
-project](https://github.com/google/guava) from Maven to Bazel. The
+Examples below come from a migration of the [Guava project](https://github.com/google/guava) from Maven to Bazel. The
 Guava project used is release `v31.1`. The examples using Guava do not walk
 through each step in the migration, but they do show the files and contents that
 are generated or added manually for the migration.
@@ -63,14 +61,12 @@ has no external dependencies, this file can be empty.
 If your project depends on files or packages that are not in one of the
 project's directories, specify these external dependencies in the MODULE.bazel
 file. You can use `rules_jvm_external` to manage dependencies from Maven. For
-instructions about using this ruleset, see [the
-README](https://github.com/bazelbuild/rules_jvm_external/#rules_jvm_external)
+instructions about using this ruleset, see [the README](https://github.com/bazelbuild/rules_jvm_external/#rules_jvm_external)
 .
 
 #### Guava project example: external dependencies {#guava-1}
 
-You can list the external dependencies of the [Guava
-project](https://github.com/google/guava) with the
+You can list the external dependencies of the [Guava project](https://github.com/google/guava) with the
 [`rules_jvm_external`](https://github.com/bazelbuild/rules_jvm_external)
 ruleset.
 
@@ -164,8 +160,7 @@ your build by adding more `BUILD` files with more granular targets.
             *   `resources`: Use globbing to list all resources in your project.
             *   `deps`: You need to determine which external dependencies your
                 project needs.
-        *   Take a look at the [example below of this top-level BUILD
-            file](#guava-2) from the migration of the Guava project.
+        *   Take a look at the [example below of this top-level BUILD file](#guava-2) from the migration of the Guava project.
 
 3.  Now that you have a `BUILD` file at the root of your project, build your
     project to ensure that it works. On the command line, from your workspace
diff --git a/versions/8.0.1/migrate/xcode.mdx b/versions/8.0.1/migrate/xcode.mdx
index 874a5f25..c3f3df17 100644
--- a/versions/8.0.1/migrate/xcode.mdx
+++ b/versions/8.0.1/migrate/xcode.mdx
@@ -32,8 +32,7 @@ Before you begin, do the following:
 
 1.  [Install Bazel](/versions/8.0.1/install) if you have not already done so.
 
-2.  If you're not familiar with Bazel and its concepts, complete the [iOS app
-    tutorial](/versions/8.0.1/start/ios-app)). You should understand the Bazel workspace,
+2.  If you're not familiar with Bazel and its concepts, complete the [iOS app tutorial](/versions/8.0.1/start/ios-app)). You should understand the Bazel workspace,
     including the `MODULE.bazel` and `BUILD` files, as well as the concepts of
     targets, build rules, and Bazel packages.
 
@@ -44,8 +43,7 @@ Before you begin, do the following:
 Unlike Xcode, Bazel requires you to explicitly declare all dependencies for
 every target in the `BUILD` file.
 
-For more information on external dependencies, see [Working with external
-dependencies](/versions/8.0.1/docs/external).
+For more information on external dependencies, see [Working with external dependencies](/versions/8.0.1/docs/external).
 
 ## Build or test an Xcode project with Bazel {#build-xcode-project}
 
@@ -84,8 +82,7 @@ Note: Place the project source code within the directory tree containing the
 
 To integrate SwiftPM dependencies into the Bazel workspace with
 [swift_bazel](https://github.com/cgrindel/swift_bazel), you must
-convert them into Bazel packages as described in the [following
-tutorial](https://chuckgrindel.com/swift-packages-in-bazel-using-swift_bazel/)
+convert them into Bazel packages as described in the [following tutorial](https://chuckgrindel.com/swift-packages-in-bazel-using-swift_bazel/)
 .
 
 Note: SwiftPM support is a manual process with many variables. SwiftPM
@@ -103,8 +100,7 @@ initial build of the project as follows:
 *   [Step 3b: (Optional) Add the test target(s)](#step-3b-optional-add-the-test-target-s)
 *   [Step 3c: Add the library target(s)](#step-3c-add-the-library-target-s)
 
-**Tip:** To learn more about packages and other Bazel concepts, see [Workspaces,
-packages, and targets](/versions/8.0.1/concepts/build-ref).
+**Tip:** To learn more about packages and other Bazel concepts, see [Workspaces, packages, and targets](/versions/8.0.1/concepts/build-ref).
 
 #### Step 3a: Add the application target {#add-app-target}
 
@@ -132,8 +128,7 @@ In the target, specify the following at the minimum:
 
 #### Step 3b: (Optional) Add the test target(s) {#add-test-target}
 
-Bazel's [Apple build
-rules](https://github.com/bazelbuild/rules_apple) support running
+Bazel's [Apple build rules](https://github.com/bazelbuild/rules_apple) support running
 unit and UI tests on all Apple platforms. Add test targets as follows:
 
 *   [`macos_unit_test`](https://github.com/bazelbuild/rules_apple/blob/master/doc/rules-macos.md#macos_unit_test)
@@ -181,8 +176,7 @@ all sources and/or headers of a certain type. Use it carefully as it might
 include files you do not want Bazel to build.
 
 You can browse existing examples for various types of applications directly in
-the [rules_apple examples
-directory](https://github.com/bazelbuild/rules_apple/tree/master/examples/). For
+the [rules_apple examples directory](https://github.com/bazelbuild/rules_apple/tree/master/examples/). For
 example:
 
 *   [macOS application targets](https://github.com/bazelbuild/rules_apple/tree/master/examples/macos)
@@ -191,8 +185,7 @@ example:
 
 *   [Multi platform applications (macOS, iOS, watchOS, tvOS)](https://github.com/bazelbuild/rules_apple/tree/master/examples/multi_platform)
 
-For more information on build rules, see [Apple Rules for
-Bazel](https://github.com/bazelbuild/rules_apple).
+For more information on build rules, see [Apple Rules for Bazel](https://github.com/bazelbuild/rules_apple).
 
 At this point, it is a good idea to test the build:
 
diff --git a/versions/8.0.1/query/cquery.mdx b/versions/8.0.1/query/cquery.mdx
index 71356dd4..494f4116 100644
--- a/versions/8.0.1/query/cquery.mdx
+++ b/versions/8.0.1/query/cquery.mdx
@@ -6,8 +6,7 @@ title: ' Configurable Query (cquery)'
 [`select()`](/versions/8.0.1/docs/configurable-attributes) and build options' effects on the build
 graph.
 
-It achieves this by running over the results of Bazel's [analysis
-phase](/versions/8.0.1/extending/concepts#evaluation-model),
+It achieves this by running over the results of Bazel's [analysis phase](/versions/8.0.1/extending/concepts#evaluation-model),
 which integrates these effects. `query`, by contrast, runs over the results of
 Bazel's loading phase, before options are evaluated.
 
@@ -137,8 +136,7 @@ $ bazel cquery //foo --universe_scope=//foo,//genrule_with_foo_as_tool
 If you want to precisely declare which instance to query over, use
 the [`config`](#config) function.
 
-See `query`'s [target pattern
-documentation](/versions/8.0.1/query/language#target-patterns) for more information on target patterns.
+See `query`'s [target pattern documentation](/versions/8.0.1/query/language#target-patterns) for more information on target patterns.
 
 ## Functions {#functions}
 
diff --git a/versions/8.0.1/query/language.mdx b/versions/8.0.1/query/language.mdx
index 0de68754..f45b6c88 100644
--- a/versions/8.0.1/query/language.mdx
+++ b/versions/8.0.1/query/language.mdx
@@ -1105,8 +1105,7 @@ is being used.
 
 ### On the ordering of results {#results-ordering}
 
-Although query expressions always follow the "[law of
-conservation of graph order](#graph-order)", _presenting_ the results may be done
+Although query expressions always follow the "[law of conservation of graph order](#graph-order)", _presenting_ the results may be done
 in either a dependency-ordered or unordered manner. This does **not**
 influence the targets in the result set or how the query is computed. It only
 affects how the results are printed to stdout. Moreover, nodes that are
@@ -1252,8 +1251,7 @@ and `maxrank` output formats print the labels of each
 target in the resulting graph, but instead of appearing in
 topological order, they appear in rank order, preceded by their
 rank number. These are unaffected by the result ordering
-`--[no]order_results` flag (see [notes on
-the ordering of results](#result-order)).
+`--[no]order_results` flag (see [notes on the ordering of results](#result-order)).
 
 There are two variants of this format: `minrank` ranks
 each node by the length of the shortest path from a root node to it.
diff --git a/versions/8.0.1/reference/be/functions.mdx b/versions/8.0.1/reference/be/functions.mdx
index b75d7656..3ae31e55 100644
--- a/versions/8.0.1/reference/be/functions.mdx
+++ b/versions/8.0.1/reference/be/functions.mdx
@@ -262,8 +262,7 @@ There are several important limitations and caveats:
    package called "Foo.java" (which is allowed, though Bazel warns about it),
    then the consumer of the `glob()` will use the "Foo.java" rule
    (its outputs) instead of the "Foo.java" file. See
-   [GitHub
-   issue #10395](https://github.com/bazelbuild/bazel/issues/10395#issuecomment-583714657) for more details.
+   [GitHub issue #10395](https://github.com/bazelbuild/bazel/issues/10395#issuecomment-583714657) for more details.
 3. Globs may match files in subdirectories. And subdirectory names
    may be wildcarded. However...
 4. Labels are not allowed to cross the package boundary and glob does
diff --git a/versions/8.0.1/reference/be/java.mdx b/versions/8.0.1/reference/be/java.mdx
index 99d9f962..01da4ce8 100644
--- a/versions/8.0.1/reference/be/java.mdx
+++ b/versions/8.0.1/reference/be/java.mdx
@@ -225,8 +225,7 @@ test code. The test runner's main method is invoked instead of the main class be
   [java\_binary](#java_binary) for more details.
 
 See the section on `java_binary()` arguments. This rule also
-supports all [attributes common
-to all test rules (\*\_test)](https://bazel.build/versions/8.0.1/reference/be/common-definitions#common-attributes-tests).
+supports all [attributes common to all test rules (\*\_test)](https://bazel.build/versions/8.0.1/reference/be/common-definitions#common-attributes-tests).
 
 #### Examples
 
diff --git a/versions/8.0.1/reference/be/make-variables.mdx b/versions/8.0.1/reference/be/make-variables.mdx
index 99155f9f..560ef0c5 100644
--- a/versions/8.0.1/reference/be/make-variables.mdx
+++ b/versions/8.0.1/reference/be/make-variables.mdx
@@ -19,8 +19,7 @@ targets, and *custom* variables, which are defined in dependency targets
 and only available to targets that depend on them.
 
 The reason for the term "Make" is historical: the syntax and semantics of
-these variables were originally intended to match [GNU
-Make](https://www.gnu.org/software/make/manual/html_node/Using-Variables.html).
+these variables were originally intended to match [GNU Make](https://www.gnu.org/software/make/manual/html_node/Using-Variables.html).
 
 ## Use
 
@@ -64,8 +63,7 @@ and look at the top output lines with capital letters.
 **Toolchain option variables**
 
 * `COMPILATION_MODE`:
-  `fastbuild`, `dbg`, or `opt`. ([more
-  details](https://bazel.build/versions/8.0.1/docs/user-manual#flag--compilation_mode))
+  `fastbuild`, `dbg`, or `opt`. ([more details](https://bazel.build/versions/8.0.1/docs/user-manual#flag--compilation_mode))
 
 **Path variables**
 
diff --git a/versions/8.0.1/reference/be/workspace.mdx b/versions/8.0.1/reference/be/workspace.mdx
index 36f47e32..8b2a736b 100644
--- a/versions/8.0.1/reference/be/workspace.mdx
+++ b/versions/8.0.1/reference/be/workspace.mdx
@@ -25,8 +25,7 @@ bind(name, actual, compatible_with, deprecation, distribs, features, licenses, r
 
 *Warning: use of `bind()` is not recommended. See "[Consider removing bind](https://github.com/bazelbuild/bazel/issues/1952)" for a long
 discussion of its issues and alternatives. In particular, consider the use of
-[`repo_mapping`
-repository attributes](https://bazel.build/versions/8.0.1/rules/repository_rules#attributes).*
+[`repo_mapping` repository attributes](https://bazel.build/versions/8.0.1/rules/repository_rules#attributes).*
 
 *Warning: `select()` cannot be used in `bind()`. See the [Configurable Attributes FAQ](/versions/8.0.1/docs/configurable-attributes#bind-select) for
 details.*
@@ -114,8 +113,7 @@ local_repository(name, path, repo_mapping)
 ```
 
 Allows targets from a local directory to be bound. This means that the current repository can
-use targets defined in this other directory. See the [bind
-section](/versions/8.0.1/reference/be/workspace#bind_examples) for more details.
+use targets defined in this other directory. See the [bind section](/versions/8.0.1/reference/be/workspace#bind_examples) for more details.
 
 #### Examples
 
diff --git a/versions/8.0.1/reference/glossary.mdx b/versions/8.0.1/reference/glossary.mdx
index 12d5dc1d..51e4a0ad 100644
--- a/versions/8.0.1/reference/glossary.mdx
+++ b/versions/8.0.1/reference/glossary.mdx
@@ -21,8 +21,7 @@ An in-memory graph of [actions](#action) and the [artifacts](#artifact) that
 these actions read and generate. The graph might include artifacts that exist as
 source files (for example, in the file system) as well as generated
 intermediate/final artifacts that are not mentioned in `BUILD` files. Produced
-during the [analysis phase](#analysis-phase) and used during the [execution
-phase](#execution-phase).
+during the [analysis phase](#analysis-phase) and used during the [execution phase](#execution-phase).
 
 ### Action graph query (aquery) {#action-graph-query}
 A [query](#query-concept) tool that can query over build [actions](#action).
@@ -37,8 +36,7 @@ invalidate individual actions deterministically.
 
 ### Analysis phase {#analysis-phase}
 The second phase of a build. Processes the [target graph](#target-graph)
-specified in [`BUILD` files](#build-file) to produce an in-memory [action
-graph](#action-graph) that determines the order of actions to run during the
+specified in [`BUILD` files](#build-file) to produce an in-memory [action graph](#action-graph) that determines the order of actions to run during the
 [execution phase](#execution-phase). This is the phase in which rule
 implementations are evaluated.
 
@@ -81,8 +79,7 @@ target's source files, dependencies, and custom compiler options. The particular
 attributes available for a given target depend on its rule type.
 
 ### .bazelrc {#bazelrc}
-Bazel’s configuration file used to change the default values for [startup
-flags](#startup-flags) and [command flags](#command-flags), and to define common
+Bazel’s configuration file used to change the default values for [startup flags](#startup-flags) and [command flags](#command-flags), and to define common
 groups of options that can then be set together on the Bazel command line using
 a `--config` flag. Bazel can combine settings from multiple bazelrc files
 (systemwide, per-workspace, per-user, or from a custom location), and a
@@ -108,8 +105,7 @@ directory.
 
 ### .bzl File {#bzl-file}
 A file that defines rules, [macros](#macro), and constants written in
-[Starlark](#starlark). These can then be imported into [`BUILD`
-files](#build-file) using the `load()` function.
+[Starlark](#starlark). These can then be imported into [`BUILD` files](#build-file) using the `load()` function.
 
 {/* TODO: ### Build event protocol */}
 
@@ -117,8 +113,7 @@ files](#build-file) using the `load()` function.
 
 ### Build graph {#build-graph}
 The dependency graph that Bazel constructs and traverses to perform a build.
-Includes nodes like [targets](#target), [configured
-targets](#configured-target), [actions](#action), and [artifacts](#artifact). A
+Includes nodes like [targets](#target), [configured targets](#configured-target), [actions](#action), and [artifacts](#artifact). A
 build is considered complete when all [artifacts](#artifact) on which a set of
 requested targets depend are verified as up-to-date.
 
@@ -158,8 +153,7 @@ graphs and restart the [analysis phase](#analysis-phase).
 ### Configuration {#configuration}
 Information outside of [rule](#rule) definitions that impacts how rules generate
 [actions](#action). Every build has at least one configuration specifying the
-target platform, action environment variables, and command-line [build
-flags](#command-flags). [Transitions](#transition) may create additional
+target platform, action environment variables, and command-line [build flags](#command-flags). [Transitions](#transition) may create additional
 configurations, such as for host tools or cross-compilation.
 
 **See also:** [Configurations](/versions/8.0.1/extending/rules#configurations)
@@ -174,8 +168,7 @@ configuration of `//:c` because changing `--javacopt` unnecessarily breaks C++
 build cacheability.
 
 ### Configured query (cquery) {#configured-query}
-A [query](#query-concept) tool that queries over [configured
-targets](#configured-target) (after the [analysis phase](#analysis-phase)
+A [query](#query-concept) tool that queries over [configured targets](#configured-target) (after the [analysis phase](#analysis-phase)
 completes). This means `select()` and [build flags](#command-flags) (such as
 `--platforms`) are accurately reflected in the results.
 
@@ -191,8 +184,7 @@ build, it has two configured targets: `` and ``.
 ### Correctness {#correctness}
 A build is correct when its output faithfully reflects the state of its
 transitive inputs. To achieve correct builds, Bazel strives to be
-[hermetic](#hermeticity), reproducible, and making [build
-analysis](#analysis-phase) and [action execution](#execution-phase)
+[hermetic](#hermeticity), reproducible, and making [build analysis](#analysis-phase) and [action execution](#execution-phase)
 deterministic.
 
 ### Dependency {#dependency}
@@ -234,8 +226,7 @@ compilation). A dynamic execution strategy can provide the best possible
 incremental and clean build times.
 
 ### Execution phase {#execution-phase}
-The third phase of a build. Executes the [actions](#action) in the [action
-graph](#action-graph) created during the [analysis phase](#analysis-phase).
+The third phase of a build. Executes the [actions](#action) in the [action graph](#action-graph) created during the [analysis phase](#analysis-phase).
 These actions invoke executables (compilers, scripts) to read and write
 [artifacts](#artifact). *Spawn strategies* control how these actions are
 executed: locally, remotely, dynamically, sandboxed, docker, and so on.
@@ -285,8 +276,7 @@ syntax may be omitted.
 The first phase of a build where Bazel executes [`BUILD` files](#build-file) to
 create [packages](#package). [Macros](#macro) and certain functions like
 `glob()` are evaluated in this phase. Interleaved with the second phase of the
-build, the [analysis phase](#analysis-phase), to build up a [target
-graph](#target-graph).
+build, the [analysis phase](#analysis-phase), to build up a [target graph](#target-graph).
 
 ### Legacy macro {#legacy-macro}
 A flavor of [macro](#macro) which is declared as an ordinary
@@ -336,8 +326,7 @@ Module metadata is hosted in Bazel registries.
 
 ### Module Extension {#module-extension}
 A piece of logic that can be run to generate [repos](#repository) by reading
-inputs from across the [module](#module) dependency graph and invoking [repo
-rules](#repository-rule). Module extensions have capabilities similar to repo
+inputs from across the [module](#module) dependency graph and invoking [repo rules](#repository-rule). Module extensions have capabilities similar to repo
 rules, allowing them to access the internet, perform file I/O, and so on.
 
 **See also:** [Module extensions](/versions/8.0.1/external/extension)
@@ -350,8 +339,7 @@ example, `native.cc_library` or `native.java_library`). User-defined rules
 
 ### Output base {#output-base}
 A [workspace](#workspace)-specific directory to store Bazel output files. Used
-to separate outputs from the *workspace*'s source tree (the [main
-repo](#repository)). Located in the [output user root](#output-user-root).
+to separate outputs from the *workspace*'s source tree (the [main repo](#repository)). Located in the [output user root](#output-user-root).
 
 ### Output groups {#output-groups}
 A group of files that is expected to be built when Bazel finishes building a
@@ -406,8 +394,7 @@ query variants: [query](#query-command), [cquery](#configured-query), and
 [aquery](#action-graph-query).
 
 ### query (command) {#query-command}
-A [query](#query-concept) tool that operates over the build's post-[loading
-phase](#loading-phase) [target graph](#target-graph). This is relatively fast,
+A [query](#query-concept) tool that operates over the build's post-[loading phase](#loading-phase) [target graph](#target-graph). This is relatively fast,
 but can't analyze the effects of `select()`, [build flags](#command-flags),
 [artifacts](#artifact), or build [actions](#action).
 
@@ -425,8 +412,7 @@ repo; multiple such files can coexist in a directory.
 The *main repo* is the repo in which the current Bazel command is being run.
 
 *External repos* are defined by specifying [modules](#module) in `MODULE.bazel`
-files, or invoking [repo rules](#repository-rule) in [module
-extensions](#module-extension). They can be fetched on demand to a predetermined
+files, or invoking [repo rules](#repository-rule) in [module extensions](#module-extension). They can be fetched on demand to a predetermined
 "magical" location on disk.
 
 Each repo has a unique, constant *canonical* name, and potentially different
@@ -437,8 +423,7 @@ Each repo has a unique, constant *canonical* name, and potentially different
 ### Repository cache {#repo-cache}
 A shared content-addressable cache of files downloaded by Bazel for builds,
 shareable across [workspaces](#workspace). Enables offline builds after the
-initial download. Commonly used to cache files downloaded through [repository
-rules](#repository-rule) like `http_archive` and repository rule APIs like
+initial download. Commonly used to cache files downloaded through [repository rules](#repository-rule) like `http_archive` and repository rule APIs like
 `repository_ctx.download`. Files are cached only if their SHA-256 checksums are
 specified for the download.
 
@@ -472,8 +457,7 @@ Rules are instantiated to produce rule targets in the
 [loading phase](#loading-phase). In the [analysis phase](#analysis-phase) rule
 targets communicate information to their downstream dependencies in the form of
 [providers](#provider), and register [actions](#action) describing how to
-generate their output artifacts. These actions are run in the [execution
-phase](#execution-phase).
+generate their output artifacts. These actions are run in the [execution phase](#execution-phase).
 
 Note: Historically the term "rule" has been used to refer to a rule target.
 This usage was inherited from tools like Make, but causes confusion and should
@@ -517,8 +501,7 @@ support the stamp attribute.
 ### Starlark {#starlark}
 The extension language for writing [rules](/versions/8.0.1/extending/rules) and [macros](#macro). A
 restricted subset of Python (syntactically and grammatically) aimed for the
-purpose of configuration, and for better performance. Uses the [`.bzl`
-file](#bzl-file) extension. [`BUILD` files](#build-file) use an even more
+purpose of configuration, and for better performance. Uses the [`.bzl` file](#bzl-file) extension. [`BUILD` files](#build-file) use an even more
 restricted version of Starlark (such as no `def` function definitions), formerly
 known as Skylark.
 
@@ -549,8 +532,7 @@ An object that is defined in a [`BUILD` file](#build-file) and identified by a
 [label](#label). Targets represent the buildable units of a workspace from
 the perspective of the end user.
 
-A target that is declared by instantiating a [rule](#rule) is called a [rule
-target](#rule-target). Depending on the rule, these may be runnable (like
+A target that is declared by instantiating a [rule](#rule) is called a [rule target](#rule-target). Depending on the rule, these may be runnable (like
 `cc_binary`) or testable (like `cc_test`). Rule targets typically depend on
 other targets via their [attributes](#attribute) (such as `deps`); these
 dependencies form the basis of the [target graph](#target-graph).
@@ -561,14 +543,11 @@ within a `BUILD` file. As a special case, the `BUILD` file of any package is
 always considered a source file target in that package.
 
 Targets are discovered during the [loading phase](#loading-phase). During the
-[analysis phase](#analysis-phase), targets are associated with [build
-configurations](#configuration) to form [configured
-targets](#configured-target).
+[analysis phase](#analysis-phase), targets are associated with [build configurations](#configuration) to form [configured targets](#configured-target).
 
 ### Target graph {#target-graph}
 An in-memory graph of [targets](#target) and their dependencies. Produced during
-the [loading phase](#loading-phase) and used as an input to the [analysis
-phase](#analysis-phase).
+the [loading phase](#loading-phase) and used as an input to the [analysis phase](#analysis-phase).
 
 ### Target pattern {#target-pattern}
 A way to specify a group of [targets](#target) on the command line. Commonly
@@ -581,8 +560,7 @@ packages recursively from the root of the [workspace](#workspace).
 Rule [targets](#target) instantiated from test rules, and therefore contains a
 test executable. A return code of zero from the completion of the executable
 indicates test success. The exact contract between Bazel and tests (such as test
-environment variables, test result collection methods) is specified in the [Test
-Encyclopedia](/versions/8.0.1/reference/test-encyclopedia).
+environment variables, test result collection methods) is specified in the [Test Encyclopedia](/versions/8.0.1/reference/test-encyclopedia).
 
 ### Toolchain {#toolchain}
 A set of tools to build outputs for a language. Typically, a toolchain includes
@@ -596,8 +574,7 @@ A build [target](#target) is top-level if it’s requested on the Bazel command
 line. For example, if `//:foo` depends on `//:bar`, and `bazel build //:foo` is
 called, then for this build, `//:foo` is top-level, and `//:bar` isn’t
 top-level, although both targets will need to be built. An important difference
-between top-level and non-top-level targets is that [command
-flags](#command-flags) set on the Bazel command line (or via
+between top-level and non-top-level targets is that [command flags](#command-flags) set on the Bazel command line (or via
 [.bazelrc](#bazelrc)) will set the [configuration](#configuration) for top-level
 targets, but might be modified by a [transition](#transition) for non-top-level
 targets.
@@ -628,8 +605,7 @@ or `.bzl` file may load a given `.bzl` file. Without context, usually
 **See also:** [Visibility documentation](/versions/8.0.1/concepts/visibility)
 
 ### Workspace {#workspace}
-The environment shared by all Bazel commands run from the same [main
-repository](#repository).
+The environment shared by all Bazel commands run from the same [main repository](#repository).
 
 Note that historically the concepts of "repository" and "workspace" have been
 conflated; the term "workspace" has often been used to refer to the main
diff --git a/versions/8.0.1/release/backward-compatibility.mdx b/versions/8.0.1/release/backward-compatibility.mdx
index 56e33225..e78cdb85 100644
--- a/versions/8.0.1/release/backward-compatibility.mdx
+++ b/versions/8.0.1/release/backward-compatibility.mdx
@@ -6,11 +6,9 @@ This page provides information about how to handle backward compatibility,
 including migrating from one release to another and how to communicate
 incompatible changes.
 
-Bazel is evolving. Minor versions released as part of an [LTS major
-version](/versions/8.0.1/release#bazel-versioning) are fully backward-compatible. New major LTS
+Bazel is evolving. Minor versions released as part of an [LTS major version](/versions/8.0.1/release#bazel-versioning) are fully backward-compatible. New major LTS
 releases may contain incompatible changes that require some migration effort.
-For more information about Bazel's release model, please check out the [Release
-Model](/versions/8.0.1/release) page.
+For more information about Bazel's release model, please check out the [Release Model](/versions/8.0.1/release) page.
 
 ## Summary {#summary}
 
@@ -59,8 +57,7 @@ available.
 ## Communicating incompatible changes {#communicating-incompatible-changes}
 
 The primary source of information about incompatible changes are GitHub issues
-marked with an ["incompatible-change"
-label](https://github.com/bazelbuild/bazel/issues?q=label%3Aincompatible-change).
+marked with an ["incompatible-change" label](https://github.com/bazelbuild/bazel/issues?q=label%3Aincompatible-change).
 
 For every incompatible change, the issue specifies the following:
 
diff --git a/versions/8.0.1/release/index.mdx b/versions/8.0.1/release/index.mdx
index 9d1f03ca..c2fc734a 100644
--- a/versions/8.0.1/release/index.mdx
+++ b/versions/8.0.1/release/index.mdx
@@ -2,8 +2,7 @@
 title: 'Release Model'
 ---
 
-As announced in [the original blog
-post](https://blog.bazel.build/2020/11/10/long-term-support-release.html), Bazel
+As announced in [the original blog post](https://blog.bazel.build/2020/11/10/long-term-support-release.html), Bazel
 4.0 and higher versions provides support for two release tracks: rolling
 releases and long term support (LTS) releases. This page covers the latest
 information about Bazel's release model.
@@ -18,8 +17,7 @@ information about Bazel's release model.
 | Bazel 5 | Maintenance | [5.4.1](https://github.com/bazelbuild/bazel/releases/tag/5.4.1) | Jan 2025 |
 | Bazel 4 | Deprecated | [4.2.4](https://github.com/bazelbuild/bazel/releases/tag/4.2.4) | Jan 2024 |
 
-All Bazel LTS releases can be found on the [release
-page](https://github.com/bazelbuild/bazel/releases) on GitHub.
+All Bazel LTS releases can be found on the [release page](https://github.com/bazelbuild/bazel/releases) on GitHub.
 
 Note: Bazel version older than Bazel 5 are no longer supported, Bazel users are
 recommended to upgrade to the latest LTS release or use rolling releases if you
@@ -27,8 +25,7 @@ want to keep up with the latest changes at HEAD.
 
 ## Release versioning {#bazel-versioning}
 
-Bazel uses a _major.minor.patch_ [Semantic
-Versioning](https://semver.org/) scheme.
+Bazel uses a _major.minor.patch_ [Semantic Versioning](https://semver.org/) scheme.
 
 *   A _major release_ contains features that are not backward compatible with
     the previous release. Each major Bazel version is an LTS release.
@@ -71,8 +68,7 @@ Bazel regularly publish releases for two release tracks.
     release.
 *   Rolling releases can ship incompatible changes. Incompatible flags are
     recommended for major breaking changes, rolling out incompatible changes
-    should follow our [backward compatibility
-    policy](/versions/8.0.1/release/backward-compatibility).
+    should follow our [backward compatibility policy](/versions/8.0.1/release/backward-compatibility).
 
 ### LTS releases {#lts-releases}
 
@@ -88,8 +84,7 @@ Bazel regularly publish releases for two release tracks.
 *   A Bazel LTS release enters the Deprecated stage after being in ​​the
     Maintenance stage for 2 years.
 
-For planned releases, please check our [release
-issues](https://github.com/bazelbuild/bazel/issues?q=is%3Aopen+is%3Aissue+label%3Arelease)
+For planned releases, please check our [release issues](https://github.com/bazelbuild/bazel/issues?q=is%3Aopen+is%3Aissue+label%3Arelease)
 on Github.
 
 ## Release procedure & policies {#release-procedure-policies}
@@ -152,8 +147,7 @@ For LTS releases, the procedure and policies below are followed:
 1.  Identify release blockers and fix issues found on the release branch.
     *   The release branch is tested with the same test suite in
         [postsubmit](https://buildkite.com/bazel/bazel-bazel) and
-        [downstream test pipeline]
-        (https://buildkite.com/bazel/bazel-at-head-plus-downstream)
+        [downstream test pipeline](https://buildkite.com/bazel/bazel-at-head-plus-downstream)
         on Bazel CI. The Bazel team monitors testing results of the release
         branch and fixes any regressions found.
 1.  Create a new release candidate from the release branch when all known
@@ -209,5 +203,4 @@ feature.
 ## Rule compatibility {#rule-compatibility}
 
 If you are a rule authors and want to maintain compatibility with different
-Bazel versions, please check out the [Rule
-Compatibility](/versions/8.0.1/release/rule-compatibility) page.
+Bazel versions, please check out the [Rule Compatibility](/versions/8.0.1/release/rule-compatibility) page.
diff --git a/versions/8.0.1/release/rule-compatibility.mdx b/versions/8.0.1/release/rule-compatibility.mdx
index 8f6f4697..1661988a 100644
--- a/versions/8.0.1/release/rule-compatibility.mdx
+++ b/versions/8.0.1/release/rule-compatibility.mdx
@@ -53,18 +53,15 @@ Bazel LTS release.
 As Bazel rules authors, you can ensure a manageable migration process for users
 by following these best practices:
 
-1.  The rule should follow [Semantic
-    Versioning](https://semver.org/): minor versions of the same
+1.  The rule should follow [Semantic Versioning](https://semver.org/): minor versions of the same
     major version are backward compatible.
 1.  The rule at HEAD should be compatible with the latest Bazel LTS release.
 1.  The rule at HEAD should be compatible with Bazel at HEAD. To achieve this,
     you can
     *   Set up your own CI testing with Bazel at HEAD
-    *   Add your project to [Bazel downstream
-        testing](https://github.com/bazelbuild/continuous-integration/blob/master/docs/downstream-testing.md);
+    *   Add your project to [Bazel downstream testing](https://github.com/bazelbuild/continuous-integration/blob/master/docs/downstream-testing.md);
         the Bazel team files issues to your project if breaking changes in Bazel
-        affect your project, and you must follow our [downstream project
-        policies](https://github.com/bazelbuild/continuous-integration/blob/master/docs/downstream-testing.md#downstream-project-policies)
+        affect your project, and you must follow our [downstream project policies](https://github.com/bazelbuild/continuous-integration/blob/master/docs/downstream-testing.md#downstream-project-policies)
         to address issues timely.
 1.  The latest major version of the rule must be compatible with the latest
     Bazel LTS release.
diff --git a/versions/8.0.1/remote/bep-glossary.mdx b/versions/8.0.1/remote/bep-glossary.mdx
index cc43f478..fa9081a7 100644
--- a/versions/8.0.1/remote/bep-glossary.mdx
+++ b/versions/8.0.1/remote/bep-glossary.mdx
@@ -410,5 +410,4 @@ workspace, such as the execution root.
 
 ## WorkspaceStatus {#workspacestatus}
 
-A single `WorkspaceStatus` event contains the result of the [workspace status
-command](/versions/8.0.1/docs/user-manual#workspace-status).
+A single `WorkspaceStatus` event contains the result of the [workspace status command](/versions/8.0.1/docs/user-manual#workspace-status).
diff --git a/versions/8.0.1/remote/bep.mdx b/versions/8.0.1/remote/bep.mdx
index 4026dc45..f2f9b3ae 100644
--- a/versions/8.0.1/remote/bep.mdx
+++ b/versions/8.0.1/remote/bep.mdx
@@ -2,14 +2,12 @@
 title: 'Build Event Protocol'
 ---
 
-The [Build Event
-Protocol](https://github.com/bazelbuild/bazel/blob/master/src/main/java/com/google/devtools/build/lib/buildeventstream/proto/build_event_stream.proto)
+The [Build Event Protocol](https://github.com/bazelbuild/bazel/blob/master/src/main/java/com/google/devtools/build/lib/buildeventstream/proto/build_event_stream.proto)
 (BEP) allows third-party programs to gain insight into a Bazel invocation. For
 example, you could use the BEP to gather information for an IDE
 plugin or a dashboard that displays build results.
 
-The protocol is a set of [protocol
-buffer](https://developers.google.com/protocol-buffers/) messages with some
+The protocol is a set of [protocol buffer](https://developers.google.com/protocol-buffers/) messages with some
 semantics defined on top of it. It includes information about build and test
 results, build progress, the build configuration and much more. The BEP is
 intended to be consumed programmatically and makes parsing Bazel’s
@@ -20,16 +18,13 @@ build event is a protocol buffer message consisting of a build event identifier,
 a set of child event identifiers, and a payload.
 
 *  __Build Event Identifier:__ Depending on the kind of build event, it might be
-an [opaque
-string](https://github.com/bazelbuild/bazel/blob/7.1.0/src/main/java/com/google/devtools/build/lib/buildeventstream/proto/build_event_stream.proto#L131-L140)
-or [structured
-information](https://github.com/bazelbuild/bazel/blob/7.1.0/src/main/java/com/google/devtools/build/lib/buildeventstream/proto/build_event_stream.proto#L194-L205)
+an [opaque string](https://github.com/bazelbuild/bazel/blob/7.1.0/src/main/java/com/google/devtools/build/lib/buildeventstream/proto/build_event_stream.proto#L131-L140)
+or [structured information](https://github.com/bazelbuild/bazel/blob/7.1.0/src/main/java/com/google/devtools/build/lib/buildeventstream/proto/build_event_stream.proto#L194-L205)
 revealing more about the build event. A build event identifier is unique within
 a build.
 
 *  __Children:__ A build event may announce other build events, by including
-their build event identifiers in its [children
-field](https://github.com/bazelbuild/bazel/blob/7.1.0/src/main/java/com/google/devtools/build/lib/buildeventstream/proto/build_event_stream.proto#L1276).
+their build event identifiers in its [children field](https://github.com/bazelbuild/bazel/blob/7.1.0/src/main/java/com/google/devtools/build/lib/buildeventstream/proto/build_event_stream.proto#L1276).
 For example, the `PatternExpanded` build event announces the targets it expands
 to as children. The protocol guarantees that all events, except for the first
 event, are announced by a previous event.
@@ -91,8 +86,7 @@ human-readable formats, such as text and JSON:
 
 ## Build Event Service {#build-event-service}
 
-The [Build Event
-Service](https://github.com/googleapis/googleapis/blob/master/google/devtools/build/v1/publish_build_event.proto)
+The [Build Event Service](https://github.com/googleapis/googleapis/blob/master/google/devtools/build/v1/publish_build_event.proto)
 Protocol is a generic [gRPC](https://www.grpc.io) service for publishing build events. The Build Event
 Service protocol is independent of the BEP and treats BEP events as opaque bytes.
 Bazel ships with a gRPC client implementation of the Build Event Service protocol that
@@ -136,8 +130,7 @@ For a description of each of these flags, see the
 The BEP typically contains many references to log files (test.log, test.xml,
 etc. ) stored on the machine where Bazel is running. A remote BES server
 typically can't access these files as they are on different machines. A way to
-work around this issue is to use Bazel with [remote
-caching](/versions/8.0.1/remote/caching).
+work around this issue is to use Bazel with [remote caching](/versions/8.0.1/remote/caching).
 Bazel will upload all output files to the remote cache (including files
 referenced in the BEP) and the BES server can then fetch the referenced files
 from the cache.
diff --git a/versions/8.0.1/remote/cache-local.mdx b/versions/8.0.1/remote/cache-local.mdx
index 97780758..f5843de0 100644
--- a/versions/8.0.1/remote/cache-local.mdx
+++ b/versions/8.0.1/remote/cache-local.mdx
@@ -18,8 +18,7 @@ execution. However, local execution presents some additional challenges.
 ## Checking your cache hit rate {#cache-hits}
 
 Successful remote cache hits will show up in the status line, similar to
-[Cache Hits rate with Remote
-Execution](/versions/8.0.1/remote/cache-remote#check-cache-hits).
+[Cache Hits rate with Remote Execution](/versions/8.0.1/remote/cache-remote#check-cache-hits).
 
 In the standard output of your Bazel run, you will see something like the
 following:
@@ -66,8 +65,7 @@ the steps in this section.
    message you see does not give you enough information, try adding
    `--verbose_failures`.
 
-2. Follow the steps from [Troubleshooting cache hits for remote
-   execution](/versions/8.0.1/remote/cache-remote#troubleshooting_cache_hits) to
+2. Follow the steps from [Troubleshooting cache hits for remote execution](/versions/8.0.1/remote/cache-remote#troubleshooting_cache_hits) to
    ensure that your cache-writing Bazel invocations are able to get cache hits
    on the same machine and across machines.
 
@@ -81,7 +79,6 @@ the steps in this section.
    b. Ensure your cache-reading Bazel invocations build the same targets as the
       cache-writing Bazel invocations.
 
-   c. Follow the same steps as to [ensure caching across
-      machines](/versions/8.0.1/remote/cache-remote#caching-across-machines),
+   c. Follow the same steps as to [ensure caching across machines](/versions/8.0.1/remote/cache-remote#caching-across-machines),
       to ensure caching from your cache-writing Bazel invocation to your
       cache-reading Bazel invocation.
diff --git a/versions/8.0.1/remote/caching.mdx b/versions/8.0.1/remote/caching.mdx
index 5785ff88..8eb76ddf 100644
--- a/versions/8.0.1/remote/caching.mdx
+++ b/versions/8.0.1/remote/caching.mdx
@@ -308,8 +308,7 @@ or for the age of individual cache entries. Bazel will automatically garbage
 collect the disk cache while idling between builds; the idle timer can be set
 with `--experimental_disk_cache_gc_idle_delay` (defaulting to 5 minutes).
 
-As an alternative to automatic garbage collection, we also provide a [tool](
-https://github.com/bazelbuild/bazel/tree/master/src/tools/diskcache) to run a
+As an alternative to automatic garbage collection, we also provide a [tool](https://github.com/bazelbuild/bazel/tree/master/src/tools/diskcache) to run a
 garbage collection on demand.
 
 ## Known issues {#known-issues}
diff --git a/versions/8.0.1/remote/dynamic.mdx b/versions/8.0.1/remote/dynamic.mdx
index 20a1ed50..7c3b6124 100644
--- a/versions/8.0.1/remote/dynamic.mdx
+++ b/versions/8.0.1/remote/dynamic.mdx
@@ -12,8 +12,7 @@ alike.
 This page describes how to enable, tune, and debug dynamic execution. If you
 have both local and remote execution set up and are trying to adjust Bazel
 settings for better performance, this page is for you. If you don't already have
-remote execution set up, go to the Bazel [Remote Execution
-Overview](/versions/8.0.1/remote/rbe) first.
+remote execution set up, go to the Bazel [Remote Execution Overview](/versions/8.0.1/remote/rbe) first.
 
 ## Enabling dynamic execution? {#enabling-dynamic-execution}
 
@@ -44,14 +43,12 @@ are likely. The default value is 1000ms, but should be tuned to being just a bit
 longer than cache hits usually take. The actual time depends both on the remote
 system and on how long a round-trip takes. Usually, the value will be the same
 for all users of a given remote system, unless some of them are far enough away
-to add roundtrip latency. You can use the [Bazel profiling
-features](/versions/8.0.1/rules/performance#performance-profiling) to look at how long typical
+to add roundtrip latency. You can use the [Bazel profiling features](/versions/8.0.1/rules/performance#performance-profiling) to look at how long typical
 cache hits take.
 
 Dynamic execution can be used with local sandboxed strategy as well as with
 [persistent workers](/versions/8.0.1/remote/persistent). Persistent workers will automatically
-run with sandboxing when used with dynamic execution, and cannot use [multiplex
-workers](/versions/8.0.1/remote/multiplex). On Darwin and Windows systems, the sandboxed
+run with sandboxing when used with dynamic execution, and cannot use [multiplex workers](/versions/8.0.1/remote/multiplex). On Darwin and Windows systems, the sandboxed
 strategy can be slow; you can pass `--reuse_sandbox_directories` to reduce
 overhead of creating sandboxes on these systems.
 
@@ -67,8 +64,7 @@ entire action fails. This is an intentional choice to prevent differences
 between local and remote execution from going unnoticed.
 
 For more background on how dynamic execution and its locking works, see Julio
-Merino's excellent [blog
-posts](https://jmmv.dev/series/bazel-dynamic-execution/)
+Merino's excellent [blog posts](https://jmmv.dev/series/bazel-dynamic-execution/)
 
 ## When should I use dynamic execution? {#when-to-use}
 
diff --git a/versions/8.0.1/remote/persistent.mdx b/versions/8.0.1/remote/persistent.mdx
index aa160ffc..f442f6ea 100644
--- a/versions/8.0.1/remote/persistent.mdx
+++ b/versions/8.0.1/remote/persistent.mdx
@@ -257,7 +257,6 @@ For more information on persistent workers, see:
 *   [Original persistent workers blog post](https://blog.bazel.build/2015/12/10/java-workers.html)
 *   [Haskell implementation description](https://www.tweag.io/blog/2019-09-25-bazel-ghc-persistent-worker-internship/)
 *   [Blog post by Mike Morearty](https://medium.com/@mmorearty/how-to-create-a-persistent-worker-for-bazel-7738bba2cabb)
-*   [Front End Development with Bazel: Angular/TypeScript and Persistent Workers
-    w/ Asana](https://www.youtube.com/watch?v=0pgERydGyqo)
+*   [Front End Development with Bazel: Angular/TypeScript and Persistent Workers w/ Asana](https://www.youtube.com/watch?v=0pgERydGyqo)
 *   [Bazel strategies explained](https://jmmv.dev/2019/12/bazel-strategies.html)
 *   [Informative worker strategy discussion on the bazel-discuss mailing list](https://groups.google.com/forum/#!msg/bazel-discuss/oAEnuhYOPm8/ol7hf4KWJgAJ)
diff --git a/versions/8.0.1/remote/rules.mdx b/versions/8.0.1/remote/rules.mdx
index 487edffa..b51b074c 100644
--- a/versions/8.0.1/remote/rules.mdx
+++ b/versions/8.0.1/remote/rules.mdx
@@ -54,8 +54,7 @@ variables that may not be set to equivalent values (or at all) in the remote
 execution environment.
 
 Toolchain rules currently exist for Bazel build and test rules for
-[Scala](https://github.com/bazelbuild/rules_scala/blob/master/scala/scala_toolch
-ain.bzl),
+[Scala](https://github.com/bazelbuild/rules_scala/blob/master/scala/scala_toolch ain.bzl),
 [Rust](https://github.com/bazelbuild/rules_rust/blob/main/rust/toolchain.bzl),
 and [Go](https://github.com/bazelbuild/rules_go/blob/master/go/toolchains.rst),
 and new toolchain rules are under way for other languages and tools such as
diff --git a/versions/8.0.1/remote/workspace.mdx b/versions/8.0.1/remote/workspace.mdx
index bde18bfc..a9d39143 100644
--- a/versions/8.0.1/remote/workspace.mdx
+++ b/versions/8.0.1/remote/workspace.mdx
@@ -11,8 +11,7 @@ on the host machine. If your workspace rules access information about the
 host machine for use during execution, your build is likely to break due to
 incompatibilities between the environments.
 
-As part of [adapting Bazel rules for remote
-execution](/versions/8.0.1/remote/rules), you need to find such workspace rules
+As part of [adapting Bazel rules for remote execution](/versions/8.0.1/remote/rules), you need to find such workspace rules
 and fix them. This page describes how to find potentially problematic workspace
 rules using the workspace log.
 
diff --git a/versions/8.0.1/rules/language.mdx b/versions/8.0.1/rules/language.mdx
index 80ad775e..5f619b14 100644
--- a/versions/8.0.1/rules/language.mdx
+++ b/versions/8.0.1/rules/language.mdx
@@ -93,10 +93,8 @@ values returned by rules are immutable.
 `BUILD` files register targets via making calls to rules. `.bzl` files provide
 definitions for constants, rules, macros, and functions.
 
-[Native functions](/versions/8.0.1/reference/be/functions) and [native rules](
-/reference/be/overview#language-specific-native-rules) are global symbols in
-`BUILD` files. `bzl` files need to load them using the [`native` module](
-/rules/lib/toplevel/native).
+[Native functions](/versions/8.0.1/reference/be/functions) and [native rules](/reference/be/overview#language-specific-native-rules) are global symbols in
+`BUILD` files. `bzl` files need to load them using the [`native` module](/rules/lib/toplevel/native).
 
 There are two syntactic restrictions in `BUILD` files: 1) declaring functions is
 illegal, and 2) `*args` and `**kwargs` arguments are not allowed.
diff --git a/versions/8.0.1/rules/legacy-macro-tutorial.mdx b/versions/8.0.1/rules/legacy-macro-tutorial.mdx
index 307a3092..a6dacb1a 100644
--- a/versions/8.0.1/rules/legacy-macro-tutorial.mdx
+++ b/versions/8.0.1/rules/legacy-macro-tutorial.mdx
@@ -3,9 +3,7 @@ title: 'Creating a Legacy Macro'
 ---
 
 IMPORTANT: This tutorial is for [*legacy macros*](/versions/8.0.1/extending/legacy-macros). If
-you only need to support Bazel 8 or newer, we recommend using [symbolic
-macros](/versions/8.0.1/extending/macros) instead; take a look at [Creating a Symbolic
-Macro](../macro-tutorial).
+you only need to support Bazel 8 or newer, we recommend using [symbolic macros](/versions/8.0.1/extending/macros) instead; take a look at [Creating a Symbolic Macro](../macro-tutorial).
 
 Imagine that you need to run a tool as part of your build. For example, you
 may want to generate or preprocess a source file, or compress a binary. In this
diff --git a/versions/8.0.1/rules/verbs-tutorial.mdx b/versions/8.0.1/rules/verbs-tutorial.mdx
index 61c48e6f..477806f7 100644
--- a/versions/8.0.1/rules/verbs-tutorial.mdx
+++ b/versions/8.0.1/rules/verbs-tutorial.mdx
@@ -49,8 +49,7 @@ This pattern can also be seen in the Angular project. The
 produces two targets. The first is a standard `nodejs_test` target which compares
 some generated output against a "golden" file (that is, a file containing the
 expected output). This can be built and run with a normal `bazel
-test` invocation. In `angular-cli`, you can run [one such
-target](https://github.com/angular/angular-cli/blob/e1269cb520871ee29b1a4eec6e6c0e4a94f0b5fc/etc/api/BUILD)
+test` invocation. In `angular-cli`, you can run [one such target](https://github.com/angular/angular-cli/blob/e1269cb520871ee29b1a4eec6e6c0e4a94f0b5fc/etc/api/BUILD)
 with `bazel test //etc/api:angular_devkit_core_api`.
 
 Over time, this golden file may need to be updated for legitimate reasons.
diff --git a/versions/8.0.1/run/build.mdx b/versions/8.0.1/run/build.mdx
index 1560fdfd..b55157b1 100644
--- a/versions/8.0.1/run/build.mdx
+++ b/versions/8.0.1/run/build.mdx
@@ -633,8 +633,7 @@ Note: Hermeticity means that the action only uses its declared input
 files and no other files in the filesystem, and it only produces its declared
 output files. See [Hermeticity](/versions/8.0.1/basics/hermeticity) for more details.
 
-On some platforms such as [Google Kubernetes
-Engine](https://cloud.google.com/kubernetes-engine/) cluster nodes or Debian,
+On some platforms such as [Google Kubernetes Engine](https://cloud.google.com/kubernetes-engine/) cluster nodes or Debian,
 user namespaces are deactivated by default due to security
 concerns. This can be checked by looking at the file
 `/proc/sys/kernel/unprivileged_userns_clone`: if it exists and contains a 0,
diff --git a/versions/8.0.1/start/android-app.mdx b/versions/8.0.1/start/android-app.mdx
index 28af56ff..287dfe04 100644
--- a/versions/8.0.1/start/android-app.mdx
+++ b/versions/8.0.1/start/android-app.mdx
@@ -36,8 +36,7 @@ In this tutorial you learn how to:
 Before you begin the tutorial, install the following software:
 
 * **Bazel.** To install, follow the [installation instructions](/versions/8.0.1/install).
-* **Android Studio.** To install, follow the steps to [download Android
-  Studio](https://developer.android.com/sdk/index.html).
+* **Android Studio.** To install, follow the steps to [download Android Studio](https://developer.android.com/sdk/index.html).
   Execute the setup wizard to download the SDK and configure your environment.
 * (Optional) **Git.** Use `git` to download the Android app project.
 
@@ -52,8 +51,7 @@ This app has a single button that prints a greeting when clicked:
 
 **Figure 1.** Android app button greeting.
 
-Clone the repository with `git` (or [download the ZIP file
-directly](https://github.com/bazelbuild/examples/archive/master.zip)):
+Clone the repository with `git` (or [download the ZIP file directly](https://github.com/bazelbuild/examples/archive/master.zip)):
 
 ```posix-terminal
 git clone https://github.com/bazelbuild/examples
@@ -103,8 +101,7 @@ A [workspace](/versions/8.0.1/concepts/build-ref#workspace) is a directory that
 source files for one or more software projects, and has a `MODULE.bazel` file at
 its root.
 
-The `MODULE.bazel` file may be empty or may contain references to [external
-dependencies](/versions/8.0.1/external/overview) required to build your project.
+The `MODULE.bazel` file may be empty or may contain references to [external dependencies](/versions/8.0.1/external/overview) required to build your project.
 
 First, run the following command to create an empty `MODULE.bazel` file:
 
@@ -147,8 +144,7 @@ environment variable, and automatically detect the highest API level and the
 latest version of build tools installed within that location.
 
 You can set the `ANDROID_HOME` variable to the location of the Android SDK. Find
-the path to the installed SDK using Android Studio's [SDK
-Manager](https://developer.android.com/studio/intro/update#sdk-manager).
+the path to the installed SDK using Android Studio's [SDK Manager](https://developer.android.com/studio/intro/update#sdk-manager).
 Assuming the SDK is installed to default locations, you can use the following
 commands to set the `ANDROID_HOME` variable:
 
@@ -170,16 +166,14 @@ them permanent, run the following commands:
 | Windows (PowerShell)     | `[System.Environment]::SetEnvironmentVariable('ANDROID_HOME', "$env:LOCALAPPDATA\Android\Sdk", [System.EnvironmentVariableTarget]::User)` |
 
 **Optional:** If you want to compile native code into your Android app, you
-also need to download the [Android
-NDK](https://developer.android.com/ndk/downloads/index.html)
+also need to download the [Android NDK](https://developer.android.com/ndk/downloads/index.html)
 and use `rules_android_ndk` by adding the following line to your `MODULE.bazel` file:
 
 ```python
 bazel_dep(name = "rules_android_ndk", version = "0.1.2")
 ```
 
-For more information, read [Using the Android Native Development Kit with
-Bazel](/versions/8.0.1/docs/android-ndk).
+For more information, read [Using the Android Native Development Kit with Bazel](/versions/8.0.1/docs/android-ndk).
 
 It's not necessary to set the API levels to the same value for the SDK and NDK.
 [This page](https://developer.android.com/ndk/guides/stable_apis.html)
@@ -221,8 +215,7 @@ files or other dependencies. Bazel provides two build rules,
 build an Android app.
 
 For this tutorial, you'll first use the
-`android_library` rule to tell Bazel to build an [Android library
-module](http://developer.android.com/tools/projects/index.html#LibraryProjects)
+`android_library` rule to tell Bazel to build an [Android library module](http://developer.android.com/tools/projects/index.html#LibraryProjects)
 from the app source code and resource files. You'll then use the
 `android_binary` rule to tell Bazel how to build the Android application package.
 
@@ -337,11 +330,9 @@ file:
 ### Run the app
 
 You can now deploy the app to a connected Android device or emulator from the
-command line using the [`bazel
-mobile-install`](/versions/8.0.1/docs/user-manual#mobile-install) command. This command uses
+command line using the [`bazel mobile-install`](/versions/8.0.1/docs/user-manual#mobile-install) command. This command uses
 the Android Debug Bridge (`adb`) to communicate with the device. You must set up
-your device to use `adb` following the instructions in [Android Debug
-Bridge](http://developer.android.com/tools/help/adb.html) before deployment. You
+your device to use `adb` following the instructions in [Android Debug Bridge](http://developer.android.com/tools/help/adb.html) before deployment. You
 can also choose to install the app on the Android emulator included in Android
 Studio. Make sure the emulator is running before executing the command below.
 
diff --git a/versions/8.0.1/start/cpp.mdx b/versions/8.0.1/start/cpp.mdx
index 0ab301dc..7f569edb 100644
--- a/versions/8.0.1/start/cpp.mdx
+++ b/versions/8.0.1/start/cpp.mdx
@@ -19,8 +19,7 @@ Estimated completion time: 30 minutes.
 ### Prerequisites {#prerequisites}
 
 Start by [installing Bazel](https://bazel.build/versions/8.0.1/install), if you haven't
-already. This tutorial uses Git for source control, so for best results [install
-Git](https://git-scm.com/book/en/v2/Getting-Started-Installing-Git) as well.
+already. This tutorial uses Git for source control, so for best results [install Git](https://git-scm.com/book/en/v2/Getting-Started-Installing-Git) as well.
 
 Next, retrieve the sample project from Bazel's GitHub repository by running the
 following in your command-line tool of choice:
@@ -63,9 +62,7 @@ examples
 ```
 
 There are three sets of files, each set representing a stage in this tutorial.
-In the first stage, you will build a single [target]
-(https://bazel.build/reference/glossary#target) residing in a single [package]
-(https://bazel.build/reference/glossary#package). In the second stage, you will
+In the first stage, you will build a single [target](https://bazel.build/reference/glossary#target) residing in a single [package](https://bazel.build/reference/glossary#package). In the second stage, you will
 build both a binary and a library from a single package. In the third and final
 stage, you will build a project with multiple packages and build it with
 multiple targets.
@@ -86,8 +83,7 @@ It also contains these significant files:
 *   The `MODULE.bazel` file, which identifies the directory and its contents as
     a Bazel workspace and lives at the root of the project's directory
     structure. It's also where you specify your external dependencies.
-*   One or more [`BUILD`
-    files](https://bazel.build/reference/glossary#build-file), which tell Bazel
+*   One or more [`BUILD` files](https://bazel.build/reference/glossary#build-file), which tell Bazel
     how to build different parts of the project. A directory within the
     workspace that contains a `BUILD` file is a
     [package](https://bazel.build/versions/8.0.1/reference/glossary#package). (More on packages
@@ -182,9 +178,7 @@ This results in a printed "`Hello world`" message.
 
 Here's the dependency graph of Stage 1:
 
-![Dependency graph for hello-world displays a single target with a single source
-file.](/versions/8.0.1/docs/images/cpp-tutorial-stage1.png "Dependency graph for hello-world
-displays a single target with a single source file.")
+![Dependency graph for hello-world displays a single target with a single source file.](/versions/8.0.1/docs/images/cpp-tutorial-stage1.png "Dependency graph for hello-world displays a single target with a single source file.")
 
 ### Summary: stage 1 {#summary-stage-1}
 
@@ -231,8 +225,7 @@ cc_binary(
 ```
 
 With this `BUILD` file, Bazel first builds the `hello-greet` library (using
-Bazel's built-in [`cc_library`
-rule](https://bazel.build/reference/be/c-cpp#cc_library)), then the
+Bazel's built-in [`cc_library` rule](https://bazel.build/reference/be/c-cpp#cc_library)), then the
 `hello-world` binary. The `deps` attribute in the `hello-world` target tells
 Bazel that the `hello-greet` library is required to build the `hello-world`
 binary.
@@ -272,10 +265,7 @@ recompiles that file.
 Looking at the dependency graph, you can see that `hello-world` depends on an
 extra input named `hello-greet`:
 
-![Dependency graph for `hello-world` displays dependency changes after
-modification to the file.](/versions/8.0.1/docs/images/cpp-tutorial-stage2.png "Dependency
-graph for `hello-world` displays dependency changes after modification to the
-file.")
+![Dependency graph for `hello-world` displays dependency changes after modification to the file.](/versions/8.0.1/docs/images/cpp-tutorial-stage2.png "Dependency graph for `hello-world` displays dependency changes after modification to the file.")
 
 ### Summary: stage 2 {#summary-stage-2}
 
@@ -343,11 +333,7 @@ in the `lib` package (hence the target label `//lib:hello-time`) - Bazel knows
 this through the `deps` attribute. You can see this reflected in the dependency
 graph:
 
-![Dependency graph for `hello-world` displays how the target in the main package
-depends on the target in the `lib`
-package.](/versions/8.0.1/docs/images/cpp-tutorial-stage3.png "Dependency graph for
-`hello-world` displays how the target in the main package depends on the target
-in the `lib` package.")
+![Dependency graph for `hello-world` displays how the target in the main package depends on the target in the `lib` package.](/versions/8.0.1/docs/images/cpp-tutorial-stage3.png "Dependency graph for `hello-world` displays how the target in the main package depends on the target in the `lib` package.")
 
 For the build to succeed, you make the `//lib:hello-time` target in `lib/BUILD`
 explicitly visible to targets in `main/BUILD` using the visibility attribute.
@@ -395,15 +381,11 @@ Bazel journey.
 You've now completed your first basic build with Bazel, but this is just the
 start. Here are some more resources to continue learning with Bazel:
 
-*   To keep focusing on C++, read about common [C++ build use
-    cases](https://bazel.build/tutorials/cpp-use-cases).
+*   To keep focusing on C++, read about common [C++ build use cases](https://bazel.build/tutorials/cpp-use-cases).
 *   To get started with building other applications with Bazel, see the
-    tutorials for [Java](https://bazel.build/versions/8.0.1/start/java), [Android
-    application](https://bazel.build/start/android-app), or [iOS
-    application](https://bazel.build/start/ios-app).
+    tutorials for [Java](https://bazel.build/versions/8.0.1/start/java), [Android application](https://bazel.build/start/android-app), or [iOS application](https://bazel.build/start/ios-app).
 *   To learn more about working with local and remote repositories, read about
     [external dependencies](https://bazel.build/versions/8.0.1/docs/external).
-*   To learn more about Bazel's other rules, see this [reference
-    guide](https://bazel.build/rules).
+*   To learn more about Bazel's other rules, see this [reference guide](https://bazel.build/rules).
 
 Happy building!
\ No newline at end of file
diff --git a/versions/8.0.1/start/java.mdx b/versions/8.0.1/start/java.mdx
index f7fb9b1e..f0ed5476 100644
--- a/versions/8.0.1/start/java.mdx
+++ b/versions/8.0.1/start/java.mdx
@@ -241,8 +241,7 @@ recompiles that file.
 Looking at the dependency graph, you can see that `ProjectRunner` depends on the
 same inputs as it did before, but the structure of the build is different:
 
-![Dependency graph of the target 'ProjectRunner' after adding a dependency](
-/docs/images/tutorial_java_02.svg)
+![Dependency graph of the target 'ProjectRunner' after adding a dependency](/docs/images/tutorial_java_02.svg)
 
 You've now built the project with two targets. The `ProjectRunner` target builds
 one source files and depends on one other target (`:greeter`), which builds
diff --git a/versions/8.0.1/tutorials/ccp-toolchain-config.mdx b/versions/8.0.1/tutorials/ccp-toolchain-config.mdx
index af41a10e..add6effd 100644
--- a/versions/8.0.1/tutorials/ccp-toolchain-config.mdx
+++ b/versions/8.0.1/tutorials/ccp-toolchain-config.mdx
@@ -29,8 +29,7 @@ uses `clang version 16`, which you can install on your system.
 
 Set up your build environment as follows:
 
-1.  If you have not already done so, [download and install Bazel
-    7.0.2](https://bazel.build/install) or later.
+1.  If you have not already done so, [download and install Bazel 7.0.2](https://bazel.build/install) or later.
 
 2.  Add an empty `MODULE.bazel` file at the root folder.
 
@@ -450,8 +449,7 @@ The key takeaways are:
 
 -   You need to specify a matching `platforms` flag in the command line for
     Bazel to resolve to the toolchain for the same constraint values on the
-    platform. The documentation holds more [information about language specific
-    configuration flags](/versions/8.0.1/concepts/platforms).
+    platform. The documentation holds more [information about language specific configuration flags](/versions/8.0.1/concepts/platforms).
 -   You have to let the toolchain know where the tools live. In this tutorial
     there is a simplified version where you access the tools from the system. If
     you are interested in a more self-contained approach, you can read about
@@ -464,5 +462,4 @@ The key takeaways are:
 
 ## Further reading {#further-reading}
 
-For more details, see [C++ toolchain
-configuration](/versions/8.0.1/docs/cc-toolchain-config-reference)
\ No newline at end of file
+For more details, see [C++ toolchain configuration](/versions/8.0.1/docs/cc-toolchain-config-reference)
\ No newline at end of file
diff --git a/versions/8.1.1/about/roadmap.mdx b/versions/8.1.1/about/roadmap.mdx
index d450c534..4f3d81ff 100644
--- a/versions/8.1.1/about/roadmap.mdx
+++ b/versions/8.1.1/about/roadmap.mdx
@@ -13,8 +13,7 @@ projects.
 
 ## Bazel 8.0 Release
 
-We plan to bring Bazel 8.0 [long term support
-(LTS)](https://bazel.build/release/versioning) to you in late 2024.
+We plan to bring Bazel 8.0 [long term support (LTS)](https://bazel.build/release/versioning) to you in late 2024.
 The following features are planned to be implemented.
 
 ### Bzlmod: external dependency management system
@@ -29,8 +28,7 @@ support will be removed. Starting with Bazel 7.1, you can set
 `--noenable_workspace` to opt into the new behavior.
 
 Bazel 8.0 will contain a number of enhancements to
-[Bazel's external dependency management]
-(https://docs.google.com/document/d/1moQfNcEIttsk6vYanNKIy3ZuK53hQUFq1b1r0rmsYVg/edit#heading=h.lgyp7ubwxmjc)
+[Bazel's external dependency management](https://docs.google.com/document/d/1moQfNcEIttsk6vYanNKIy3ZuK53hQUFq1b1r0rmsYVg/edit#heading=h.lgyp7ubwxmjc)
 functionality, including:
 
 *   The new flag `--enable_workspace` can be set to `false` to completely
diff --git a/versions/8.1.1/basics/dependencies.mdx b/versions/8.1.1/basics/dependencies.mdx
index f8732fd3..58b13cd7 100644
--- a/versions/8.1.1/basics/dependencies.mdx
+++ b/versions/8.1.1/basics/dependencies.mdx
@@ -65,8 +65,7 @@ targets, we’ve made some strides in mitigating the downside by investing in
 tooling to automatically manage `BUILD` files to avoid burdening developers.
 
 Some of these tools, such as `buildifier` and `buildozer`, are available with
-Bazel in the [`buildtools`
-directory](https://github.com/bazelbuild/buildtools).
+Bazel in the [`buildtools` directory](https://github.com/bazelbuild/buildtools).
 
 ## Minimizing Module Visibility
 
@@ -106,8 +105,7 @@ transitive dependencies (Figure 1). Suppose target A depends on target B, which
 depends on a common library target C. Should target A be able to use classes
 defined in target C?
 
-[![Transitive
-dependencies](/versions/8.1.1/images/transitive-dependencies.png)](/versions/8.1.1/images/transitive-dependencies.png)
+[![Transitive dependencies](/versions/8.1.1/images/transitive-dependencies.png)](/versions/8.1.1/images/transitive-dependencies.png)
 
 **Figure 1**. Transitive dependencies
 
@@ -141,9 +139,7 @@ dependencies and adding them to a `BUILD` files without any developer
 intervention. But even without such tools, we’ve found the trade-off to be well
 worth it as the codebase scales: explicitly adding a dependency to `BUILD` file
 is a one-time cost, but dealing with implicit transitive dependencies can cause
-ongoing problems as long as the build target exists. Bazel [enforces strict
-transitive
-dependencies](https://blog.bazel.build/2017/06/28/sjd-unused_deps.html)
+ongoing problems as long as the build target exists. Bazel [enforces strict transitive dependencies](https://blog.bazel.build/2017/06/28/sjd-unused_deps.html)
 on Java code by default.
 
 ### External dependencies
@@ -192,8 +188,7 @@ so in theory there’s no reason that different versions of the same external
 dependency couldn’t both be declared in the build system under different names.
 That way, each target could choose which version of the dependency it wanted to
 use. This causes a lot of problems in practice, so Google enforces a strict
-[One-Version
-Rule](https://opensource.google/docs/thirdparty/oneversion/) for
+[One-Version Rule](https://opensource.google/docs/thirdparty/oneversion/) for
 all third-party dependencies in our codebase.
 
 The biggest problem with allowing multiple versions is the diamond dependency
@@ -232,8 +227,7 @@ Bazel did not use to automatically download transitive dependencies. It used to
 employ a `WORKSPACE` file that required all transitive dependencies to be
 listed, which led to a lot of pain when managing external dependencies. Bazel
 has since added support for automatic transitive external dependency management
-in the form of the `MODULE.bazel` file. See [external dependency
-overview](/versions/8.1.1/external/overview) for more details.
+in the form of the `MODULE.bazel` file. See [external dependency overview](/versions/8.1.1/external/overview) for more details.
 
 Yet again, the choice here is one between convenience and scalability. Small
 projects might prefer not having to worry about managing transitive dependencies
diff --git a/versions/8.1.1/community/roadmaps-configurability.mdx b/versions/8.1.1/community/roadmaps-configurability.mdx
index 3741bee7..cf91ea2f 100644
--- a/versions/8.1.1/community/roadmaps-configurability.mdx
+++ b/versions/8.1.1/community/roadmaps-configurability.mdx
@@ -26,8 +26,7 @@ title: 'Bazel Configurability 2021 Roadmap'
 * Builds scale well, particularly w.r.t graph size and action caching.
 
 We also support
-[`cquery`](https://bazel.build/versions/8.1.1/query/cquery), [`Starlark
-configuration`](https://bazel.build/extending/config),
+[`cquery`](https://bazel.build/versions/8.1.1/query/cquery), [`Starlark configuration`](https://bazel.build/extending/config),
 and
 [`select()`](https://bazel.build/versions/8.1.1/docs/configurable-attributes).
 
@@ -41,15 +40,13 @@ interest of accurate expectations.
 ### Platforms
 
 

-Q3 2021**Android rules use the new [platforms
-API](https://bazel.build/concepts/platforms)**
+Q3 2021**Android rules use the new [platforms API](https://bazel.build/concepts/platforms)**
 IN PROGRESS ([#11749](https://github.com/bazelbuild/bazel/issues/11749))
 
 * This is our main priority for the beginning of 2021.
 
 

-Q3 2021**Builds support [multiple execution
-platforms](https://docs.google.com/document/d/1U9HzdDmtRnm244CaRM6JV-q2408mbNODAMewcGjnnbM/)**
+Q3 2021**Builds support [multiple execution platforms](https://docs.google.com/document/d/1U9HzdDmtRnm244CaRM6JV-q2408mbNODAMewcGjnnbM/)**
 IN PROGRESS ([#11748](https://github.com/bazelbuild/bazel/issues/11748))
 
 

diff --git a/versions/8.1.1/community/sig.mdx b/versions/8.1.1/community/sig.mdx
index 2d2f6177..af2b7696 100644
--- a/versions/8.1.1/community/sig.mdx
+++ b/versions/8.1.1/community/sig.mdx
@@ -3,8 +3,7 @@ title: 'Bazel Special Interest Groups'
 ---
 
 Bazel hosts Special Interest Groups (SIGs) to focus collaboration on particular
-areas and to support communication and coordination between [Bazel owners,
-maintainers, and contributors](/versions/8.1.1/contribute/policy). This policy
+areas and to support communication and coordination between [Bazel owners, maintainers, and contributors](/versions/8.1.1/contribute/policy). This policy
 applies to [`bazelbuild`](http://github.com/bazelbuild).
 
 SIGs do their work in public. The ideal scope for a SIG covers a well-defined
diff --git a/versions/8.1.1/community/users.mdx b/versions/8.1.1/community/users.mdx
index 09f92077..1058cb32 100644
--- a/versions/8.1.1/community/users.mdx
+++ b/versions/8.1.1/community/users.mdx
@@ -304,11 +304,9 @@ safety systems_.
 Pigweed is an open-source solution for sustained, robust, and rapid embedded
 product development for large teams. Pigweed has shipped in millions of
 devices, including Google's suite of Pixel devices, Nest thermostats,
-[satellites](https://www.spinlaunch.com/), and [autonomous aerial
-drones](https://www.flyzipline.com/).
+[satellites](https://www.spinlaunch.com/), and [autonomous aerial drones](https://www.flyzipline.com/).
 
-Pigweed [uses Bazel as its primary build
-system](https://pigweed.dev/seed/0111-build-systems.html). The [Bazel for
+Pigweed [uses Bazel as its primary build system](https://pigweed.dev/seed/0111-build-systems.html). The [Bazel for
 Embedded][pw-bazel-great] blog post discusses why we think it's a great build
 system for embedded projects!
 
diff --git a/versions/8.1.1/concepts/build-files.mdx b/versions/8.1.1/concepts/build-files.mdx
index 06216bf4..6e745390 100644
--- a/versions/8.1.1/concepts/build-files.mdx
+++ b/versions/8.1.1/concepts/build-files.mdx
@@ -132,10 +132,3 @@ for anyone to create new rules.
     programming language. Libraries can depend on other libraries,
     and binaries and tests can depend on libraries, with the expected
     separate-compilation behavior.
-
-
-  
-    
-    
-  
-
LabelsDependencies

diff --git a/versions/8.1.1/concepts/build-ref.mdx b/versions/8.1.1/concepts/build-ref.mdx
index 5dce01e8..a439f196 100644
--- a/versions/8.1.1/concepts/build-ref.mdx
+++ b/versions/8.1.1/concepts/build-ref.mdx
@@ -17,8 +17,7 @@ its root; such a boundary marker file could be `MODULE.bazel`, `REPO.bazel`, or
 in legacy contexts, `WORKSPACE` or `WORKSPACE.bazel`.
 
 The repo in which the current Bazel command is being run is called the _main
-repo_. Other, (external) repos are defined by _repo rules_; see [external
-dependencies overview](/versions/8.1.1/external/overview) for more information.
+repo_. Other, (external) repos are defined by _repo rules_; see [external dependencies overview](/versions/8.1.1/external/overview) for more information.
 
 ## Workspace {#workspace}
 
@@ -95,9 +94,4 @@ have three properties: the list of packages they contain, their name, and other
 package groups they include. The only allowed ways to refer to them are from the
 `visibility` attribute of rules or from the `default_visibility` attribute of
 the `package` function; they do not generate or consume files. For more
-information, refer to the [`package_group`
-documentation](/versions/8.1.1/reference/be/functions#package_group).
-
-
-  Labels
-
\ No newline at end of file
+information, refer to the [`package_group` documentation](/versions/8.1.1/reference/be/functions#package_group).
diff --git a/versions/8.1.1/concepts/dependencies.mdx b/versions/8.1.1/concepts/dependencies.mdx
index dcf79caa..ec900637 100644
--- a/versions/8.1.1/concepts/dependencies.mdx
+++ b/versions/8.1.1/concepts/dependencies.mdx
@@ -337,10 +337,3 @@ filegroup(
 ```
 
 You can then reference the label `my_data` as the data dependency in your test.
-
-
-  
-    
-    
-  
-
BUILD filesVisibility

diff --git a/versions/8.1.1/concepts/labels.mdx b/versions/8.1.1/concepts/labels.mdx
index 8dd577c6..fdb18ced 100644
--- a/versions/8.1.1/concepts/labels.mdx
+++ b/versions/8.1.1/concepts/labels.mdx
@@ -10,8 +10,7 @@ form looks like:
 ```
 
 The first part of the label is the repository name, `@@myrepo`. The double-`@`
-syntax signifies that this is a [*canonical* repo
-name](/versions/8.1.1/external/overview#canonical-repo-name), which is unique within
+syntax signifies that this is a [*canonical* repo name](/versions/8.1.1/external/overview#canonical-repo-name), which is unique within
 the workspace. Labels with canonical repo names unambiguously identify a target
 no matter which context they appear in.
 
@@ -239,10 +238,3 @@ the build.
 This directed acyclic graph over targets is called the _target graph_ or
 _build dependency graph_, and is the domain over which the
 [Bazel Query tool](/versions/8.1.1/query/guide) operates.
-
-
-  
-    
-    
-  
-
TargetsBUILD files

diff --git a/versions/8.1.1/concepts/platforms.mdx b/versions/8.1.1/concepts/platforms.mdx
index 2f5df03b..de76dc02 100644
--- a/versions/8.1.1/concepts/platforms.mdx
+++ b/versions/8.1.1/concepts/platforms.mdx
@@ -77,8 +77,7 @@ To test your Android project with platforms, see
 for support.
 
 You can still use platform APIs with Apple builds (for example, when building
-with a mixture of Apple rules and pure C++) with [platform
-mappings](#platform-mappings).
+with a mixture of Apple rules and pure C++) with [platform mappings](#platform-mappings).
 
 ### Other languages {#other-languages}
 
@@ -241,8 +240,7 @@ sets `--cpu`, `--crossstool_top`, or other legacy flags, rules that read
 
 When migrating your project to platforms, you must either convert changes like
 `return { "//command_line_option:cpu": "arm" }` to `return {
-"//command_line_option:platforms": "//:my_arm_platform" }` or use [platform
-mappings](#platform-mappings) to support both styles during migration.
+"//command_line_option:platforms": "//:my_arm_platform" }` or use [platform mappings](#platform-mappings) to support both styles during migration.
 window.
 
 ## Migrating your rule set {#migrating-your-rule-set}
@@ -361,10 +359,8 @@ attributes declare a language's tools (like `compiler =
 this information to rules that need to build with these tools.
 
 Toolchains declare the `constraint_value`s of machines they can
-[target][target_compatible_with Attribute]
-(`target_compatible_with = ["@platforms//os:linux"]`) and machines their tools can
-[run on][exec_compatible_with Attribute]
-(`exec_compatible_with = ["@platforms//os:mac"]`).
+[target][target_compatible_with Attribute](`target_compatible_with = ["@platforms//os:linux"]`) and machines their tools can
+[run on][exec_compatible_with Attribute](`exec_compatible_with = ["@platforms//os:mac"]`).
 
 When building `$ bazel build //:myproject --platforms=//:myplatform`, Bazel
 automatically selects a toolchain that can run on the build machine and
diff --git a/versions/8.1.1/configure/attributes.mdx b/versions/8.1.1/configure/attributes.mdx
index efb5e4a7..a174754b 100644
--- a/versions/8.1.1/configure/attributes.mdx
+++ b/versions/8.1.1/configure/attributes.mdx
@@ -2,8 +2,7 @@
 title: 'Configurable Build Attributes'
 ---
 
-**_Configurable attributes_**, commonly known as [`select()`](
-/reference/be/functions#select), is a Bazel feature that lets users toggle the values
+**_Configurable attributes_**, commonly known as [`select()`](/reference/be/functions#select), is a Bazel feature that lets users toggle the values
 of build rule attributes at the command line.
 
 This can be used, for example, for a multiplatform library that automatically
@@ -407,8 +406,7 @@ sh_library(
 )
 ```
 
-If you need a `select` to match when multiple conditions match, consider [AND
-chaining](#and-chaining).
+If you need a `select` to match when multiple conditions match, consider [AND chaining](#and-chaining).
 
 ## OR chaining {#or-chaining}
 
diff --git a/versions/8.1.1/configure/integrate-cpp.mdx b/versions/8.1.1/configure/integrate-cpp.mdx
index 750595c2..e657d9c5 100644
--- a/versions/8.1.1/configure/integrate-cpp.mdx
+++ b/versions/8.1.1/configure/integrate-cpp.mdx
@@ -33,8 +33,7 @@ This is because when writing our own actions, they must behave
 consistently with the C++ toolchain - for example, passing C++ command line
 flags to a tool that invokes the C++ compiler behind the scenes.
 
-C++ rules use a special way of constructing command lines based on [feature
-configuration](/versions/8.1.1/docs/cc-toolchain-config-reference). To construct a command line,
+C++ rules use a special way of constructing command lines based on [feature configuration](/versions/8.1.1/docs/cc-toolchain-config-reference). To construct a command line,
 you need the following:
 
 * `features` and `action_configs` - these come from the `CcToolchainConfigInfo`
diff --git a/versions/8.1.1/configure/windows.mdx b/versions/8.1.1/configure/windows.mdx
index e5b752c9..9e2abbda 100644
--- a/versions/8.1.1/configure/windows.mdx
+++ b/versions/8.1.1/configure/windows.mdx
@@ -166,8 +166,7 @@ To build C++ targets with MSVC, you need:
         set BAZEL_VC=C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC
         ```
 
-*   The [Windows
-    SDK](https://developer.microsoft.com/en-us/windows/downloads/windows-10-sdk).
+*   The [Windows SDK](https://developer.microsoft.com/en-us/windows/downloads/windows-10-sdk).
 
     The Windows SDK contains header files and libraries you need when building
     Windows applications, including Bazel itself. By default, the latest Windows SDK installed will
@@ -186,8 +185,7 @@ To build C++ targets with MSVC, you need:
 
 If everything is set up, you can build a C++ target now!
 
-Try building a target from one of our [sample
-projects](https://github.com/bazelbuild/bazel/tree/master/examples):
+Try building a target from one of our [sample projects](https://github.com/bazelbuild/bazel/tree/master/examples):
 
 
 
 
-To build and use Dynamically Linked Libraries (DLL files), see [this
-example](https://github.com/bazelbuild/bazel/tree/master/examples/windows/dll).
+To build and use Dynamically Linked Libraries (DLL files), see [this example](https://github.com/bazelbuild/bazel/tree/master/examples/windows/dll).
 
 **Command Line Length Limit**: To prevent the
 [Windows command line length limit issue](https://github.com/bazelbuild/bazel/issues/5163),
@@ -292,8 +289,7 @@ On Windows, Bazel builds two output files for `java_binary` rules:
 *   a `.jar` file
 *   a `.exe` file that can set up the environment for the JVM and run the binary
 
-Try building a target from one of our [sample
-projects](https://github.com/bazelbuild/bazel/tree/master/examples):
+Try building a target from one of our [sample projects](https://github.com/bazelbuild/bazel/tree/master/examples):
 
 
   
   
 
 If you are interested in details about how Bazel builds Python targets on
-Windows, check out this [design
-doc](https://github.com/bazelbuild/bazel-website/blob/master/designs/_posts/2016-09-05-build-python-on-windows.md).
+Windows, check out this [design doc](https://github.com/bazelbuild/bazel-website/blob/master/designs/_posts/2016-09-05-build-python-on-windows.md).
diff --git a/versions/8.1.1/contribute/codebase.mdx b/versions/8.1.1/contribute/codebase.mdx
index 4ad7007f..6fbd3522 100644
--- a/versions/8.1.1/contribute/codebase.mdx
+++ b/versions/8.1.1/contribute/codebase.mdx
@@ -227,8 +227,7 @@ repository", the others are called "external repositories".
 A repository is marked by a repo boundary file (`MODULE.bazel`, `REPO.bazel`, or
 in legacy contexts, `WORKSPACE` or `WORKSPACE.bazel`) in its root directory. The
 main repo is the source tree where you're invoking Bazel from. External repos
-are defined in various ways; see [external dependencies
-overview](/versions/8.1.1/external/overview) for more information.
+are defined in various ways; see [external dependencies overview](/versions/8.1.1/external/overview) for more information.
 
 Code of external repositories is symlinked or downloaded under
 `$OUTPUT_BASE/external`.
diff --git a/versions/8.1.1/contribute/design-documents.mdx b/versions/8.1.1/contribute/design-documents.mdx
index b28cef5f..98321897 100644
--- a/versions/8.1.1/contribute/design-documents.mdx
+++ b/versions/8.1.1/contribute/design-documents.mdx
@@ -137,8 +137,7 @@ A lead reviewer should be a domain expert who is:
 *   Objective and capable of providing constructive feedback
 *   Available for the entire review period to lead the process
 
-Consider checking the contacts for various [team
-labels](/versions/8.1.1/contribute/maintainers-guide#team-labels).
+Consider checking the contacts for various [team labels](/versions/8.1.1/contribute/maintainers-guide#team-labels).
 
 ## Markdown vs Google Docs {#markdown-versus-gdocs}
 
@@ -168,12 +167,10 @@ Markdown for posterity.
 
 ### Using Google Docs {#gdocs}
 
-For consistency, use the [Bazel design doc template](
-https://docs.google.com/document/d/1cE5zrjrR40RXNg64XtRFewSv6FrLV6slGkkqxBumS1w/edit).
+For consistency, use the [Bazel design doc template](https://docs.google.com/document/d/1cE5zrjrR40RXNg64XtRFewSv6FrLV6slGkkqxBumS1w/edit).
 It includes the necessary header and creates visual
 consistency with other Bazel related documents. To do that, click on **File** >
-**Make a copy** or click this link to [make a copy of the design doc
-template](https://docs.google.com/document/d/1cE5zrjrR40RXNg64XtRFewSv6FrLV6slGkkqxBumS1w/copy).
+**Make a copy** or click this link to [make a copy of the design doc template](https://docs.google.com/document/d/1cE5zrjrR40RXNg64XtRFewSv6FrLV6slGkkqxBumS1w/copy).
 
 To make your document readable to the world, click on
 **Share** > **Advanced** > **Change…**, and
diff --git a/versions/8.1.1/contribute/index.mdx b/versions/8.1.1/contribute/index.mdx
index f8c284ef..3bc09a11 100644
--- a/versions/8.1.1/contribute/index.mdx
+++ b/versions/8.1.1/contribute/index.mdx
@@ -10,8 +10,7 @@ As you use Bazel, you may find things that can be improved.
 You can help by [reporting issues](http://github.com/bazelbuild/bazel/issues)
 when:
 
-   - Bazel crashes or you encounter a bug that can [only be resolved using `bazel
-     clean`](/versions/8.1.1/run/build#correct-incremental-rebuilds).
+   - Bazel crashes or you encounter a bug that can [only be resolved using `bazel clean`](/versions/8.1.1/run/build#correct-incremental-rebuilds).
    - The documentation is incomplete or unclear. You can also report issues
      from the page you are viewing by using the "Create issue"
      link at the top right corner of the page.
@@ -21,11 +20,9 @@ when:
 
 You can engage with the Bazel community by:
 
-   - Answering questions [on Stack Overflow](
-     https://stackoverflow.com/questions/tagged/bazel).
+   - Answering questions [on Stack Overflow](https://stackoverflow.com/questions/tagged/bazel).
    - Helping other users [on Slack](https://slack.bazel.build).
-   - Improving documentation or [contributing examples](
-     https://github.com/bazelbuild/examples).
+   - Improving documentation or [contributing examples](https://github.com/bazelbuild/examples).
    - Sharing your experience or your tips, for example, on a blog or social media.
 
 ## Contribute code {#contribute-code}
@@ -40,8 +37,7 @@ You can contribute to the Bazel ecosystem by:
    - Contributing to Bazel-related tools, for example, migration tools.
    - Improving Bazel integration with other IDEs and tools.
 
-Before making a change, [create a GitHub
-issue](http://github.com/bazelbuild/bazel/issues)
+Before making a change, [create a GitHub issue](http://github.com/bazelbuild/bazel/issues)
 or email [bazel-discuss@](mailto:bazel-discuss@googlegroups.com).
 
 The most helpful contributions fix bugs or add features (as opposed
diff --git a/versions/8.1.1/contribute/maintainers-guide.mdx b/versions/8.1.1/contribute/maintainers-guide.mdx
index 185df6db..065b7b7d 100644
--- a/versions/8.1.1/contribute/maintainers-guide.mdx
+++ b/versions/8.1.1/contribute/maintainers-guide.mdx
@@ -4,8 +4,7 @@ title: 'Guide for Bazel Maintainers'
 
 This is a guide for the maintainers of the Bazel open source project.
 
-If you are looking to contribute to Bazel, please read [Contributing to
-Bazel](/versions/8.1.1/contribute) instead.
+If you are looking to contribute to Bazel, please read [Contributing to Bazel](/versions/8.1.1/contribute) instead.
 
 The objectives of this page are to:
 
@@ -37,8 +36,7 @@ repository.
 
 1. A user creates an issue by choosing one of the
 [issue templates](https://github.com/bazelbuild/bazel/issues/new/choose)
-   and it enters the pool of [unreviewed open
-   issues](https://github.com/bazelbuild/bazel/issues?utf8=%E2%9C%93&q=is%3Aissue+is%3Aopen+-label%3Auntriaged+-label%3Ap2+-label%3Ap1+-label%3Ap3+-label%3Ap4+-label%3Ateam-Starlark+-label%3Ateam-Rules-CPP+-label%3Ateam-Rules-Java+-label%3Ateam-XProduct+-label%3Ateam-Android+-label%3Ateam-Apple+-label%3Ateam-Configurability++-label%3Ateam-Performance+-label%3Ateam-Rules-Server+-label%3Ateam-Core+-label%3Ateam-Rules-Python+-label%3Ateam-Remote-Exec+-label%3Ateam-Local-Exec+-label%3Ateam-Bazel).
+   and it enters the pool of [unreviewed open issues](https://github.com/bazelbuild/bazel/issues?utf8=%E2%9C%93&q=is%3Aissue+is%3Aopen+-label%3Auntriaged+-label%3Ap2+-label%3Ap1+-label%3Ap3+-label%3Ap4+-label%3Ateam-Starlark+-label%3Ateam-Rules-CPP+-label%3Ateam-Rules-Java+-label%3Ateam-XProduct+-label%3Ateam-Android+-label%3Ateam-Apple+-label%3Ateam-Configurability++-label%3Ateam-Performance+-label%3Ateam-Rules-Server+-label%3Ateam-Core+-label%3Ateam-Rules-Python+-label%3Ateam-Remote-Exec+-label%3Ateam-Local-Exec+-label%3Ateam-Bazel).
 1. A member on the Developer Experience (DevEx) subteam rotation reviews the
    issue.
    1. If the issue is **not a bug** or a **feature request**, the DevEx member
@@ -58,21 +56,18 @@ repository.
 1. After reviewing the issue, the DevEx member decides if the issue requires
    immediate attention. If it does, they will assign the **P0**
    [priority](#priority) label and an owner from the list of team leads.
-1. The DevEx member assigns the `untriaged` label and exactly one [team
-   label](#team-labels) for routing.
+1. The DevEx member assigns the `untriaged` label and exactly one [team label](#team-labels) for routing.
 1. The DevEx member also assigns exactly one `type:` label, such as `type: bug`
    or `type: feature request`, according to the type of the issue.
 1. For platform-specific issues, the DevEx member assigns one `platform:` label,
    such as `platform:apple` for Mac-specific issues.
 1. If the issue is low priority and can be worked on by a new community
    contributor, the DevEx member assigns the `good first issue` label.
-At this stage, the issue enters the pool of [untriaged open
-issues](https://github.com/bazelbuild/bazel/issues?q=is%3Aissue+is%3Aopen+label%3Auntriaged).
+At this stage, the issue enters the pool of [untriaged open issues](https://github.com/bazelbuild/bazel/issues?q=is%3Aissue+is%3Aopen+label%3Auntriaged).
 
 Each Bazel subteam will triage all issues under labels they own, preferably on a
 weekly basis. The subteam will review and evaluate the issue and provide a
-resolution, if possible. If you are an owner of a team label, see [this section
-](#label-own) for more information.
+resolution, if possible. If you are an owner of a team label, see [this section](#label-own) for more information.
 
 When an issue is resolved, it can be closed.
 
@@ -111,8 +106,7 @@ preferably on a weekly basis.
      issue is either P0 or P1 we assume that is actively worked on.
 1. Remove the `untriaged` label.
 
-Note that you need to be in the [bazelbuild
-organization](https://github.com/bazelbuild) to be able to add or remove labels.
+Note that you need to be in the [bazelbuild organization](https://github.com/bazelbuild) to be able to add or remove labels.
 
 ### Pull Requests {#pull-requests}
 
@@ -138,8 +132,7 @@ issues.
   unusable, or a downed service that severely impacts development of the Bazel
   project. This includes regressions introduced in a new release that blocks a
   significant number of users, or an incompatible breaking change that was not
-  compliant to the [Breaking
-  Change](https://docs.google.com/document/d/1q5GGRxKrF_mnwtaPKI487P8OdDRh2nN7jX6U-FXnHL0/edit?pli=1#heading=h.ceof6vpkb3ik)
+  compliant to the [Breaking Change](https://docs.google.com/document/d/1q5GGRxKrF_mnwtaPKI487P8OdDRh2nN7jX6U-FXnHL0/edit?pli=1#heading=h.ceof6vpkb3ik)
   policy. No practical workaround exists.
 * [**P1**](https://github.com/bazelbuild/bazel/labels/P1) - Critical defect or
   feature which should be addressed in the next release, or a serious issue that
diff --git a/versions/8.1.1/contribute/naming.mdx b/versions/8.1.1/contribute/naming.mdx
index 05f58bdd..17cb32b7 100644
--- a/versions/8.1.1/contribute/naming.mdx
+++ b/versions/8.1.1/contribute/naming.mdx
@@ -4,8 +4,7 @@ title: 'Naming a Bazel related project'
 
 First, thank you for contributing to the Bazel ecosystem! Please reach out to
 the Bazel community on the
-[bazel-discuss mailing list](https://groups.google.com/forum/#!forum/bazel-discuss
-) to share your project and its suggested name.
+[bazel-discuss mailing list](https://groups.google.com/forum/#!forum/bazel-discuss) to share your project and its suggested name.
 
 If you are building a Bazel related tool or sharing your Skylark rules,
 we recommend following these guidelines for the name of your project:
diff --git a/versions/8.1.1/contribute/patch-acceptance.mdx b/versions/8.1.1/contribute/patch-acceptance.mdx
index c0d30b9e..70e89081 100644
--- a/versions/8.1.1/contribute/patch-acceptance.mdx
+++ b/versions/8.1.1/contribute/patch-acceptance.mdx
@@ -11,29 +11,24 @@ code base.
    need a corresponding issue for tracking.
 1. If you're proposing significant changes, write a
    [design document](/versions/8.1.1/contribute/design-documents).
-1. Ensure you've signed a [Contributor License
-   Agreement](https://cla.developers.google.com).
+1. Ensure you've signed a [Contributor License Agreement](https://cla.developers.google.com).
 1. Prepare a git commit that implements the feature. Don't forget to add tests
    and update the documentation. If your change has user-visible effects, please
    [add release notes](/versions/8.1.1/contribute/release-notes). If it is an incompatible change,
    read the [guide for rolling out breaking changes](/versions/8.1.1/contribute/breaking-changes).
 1. Create a pull request on
    [GitHub](https://github.com/bazelbuild/bazel/pulls). If you're new to GitHub,
-   read [about pull
-   requests](https://help.github.com/articles/about-pull-requests/). Note that
+   read [about pull requests](https://help.github.com/articles/about-pull-requests/). Note that
    we restrict permissions to create branches on the main Bazel repository, so
-   you will need to push your commit to [your own fork of the
-   repository](https://help.github.com/articles/working-with-forks/).
+   you will need to push your commit to [your own fork of the repository](https://help.github.com/articles/working-with-forks/).
 1. A Bazel maintainer should assign you a reviewer within two business days
    (excluding holidays in the USA and Germany). If you aren't assigned a
    reviewer in that time, you can request one by emailing
-   [bazel-discuss@googlegroups.com]
-   (mailto:bazel-discuss@googlegroups.com).
+   [bazel-discuss@googlegroups.com](mailto:bazel-discuss@googlegroups.com).
 1. Work with the reviewer to complete a code review. For each change, create a
    new commit and push it to make changes to your pull request. If the review
    takes too long (for instance, if the reviewer is unresponsive), send an email to
-   [bazel-discuss@googlegroups.com]
-   (mailto:bazel-discuss@googlegroups.com).
+   [bazel-discuss@googlegroups.com](mailto:bazel-discuss@googlegroups.com).
 1. After your review is complete, a Bazel maintainer applies your patch to
    Google's internal version control system.
 
diff --git a/versions/8.1.1/contribute/release-notes.mdx b/versions/8.1.1/contribute/release-notes.mdx
index 023722d5..05588efa 100644
--- a/versions/8.1.1/contribute/release-notes.mdx
+++ b/versions/8.1.1/contribute/release-notes.mdx
@@ -16,8 +16,7 @@ the release announcement.
 * If the change adds / removes / changes Bazel in a user-visible way, then it
   may be advantageous to mention it.
 
-If the change is significant, follow the [design document
-policy](/versions/8.1.1/contribute/design-documents) first.
+If the change is significant, follow the [design document policy](/versions/8.1.1/contribute/design-documents) first.
 
 ## Guidelines {#guidelines}
 
@@ -60,10 +59,8 @@ change is about.
 
 ## Process {#process}
 
-As part of the [release
-process](https://github.com/bazelbuild/continuous-integration/blob/master/docs/release-playbook.md),
-we collect the `RELNOTES` tags of every commit. We copy everything in a [Google
-Doc](https://docs.google.com/document/d/1wDvulLlj4NAlPZamdlEVFORks3YXJonCjyuQMUQEmB0/edit)
+As part of the [release process](https://github.com/bazelbuild/continuous-integration/blob/master/docs/release-playbook.md),
+we collect the `RELNOTES` tags of every commit. We copy everything in a [Google Doc](https://docs.google.com/document/d/1wDvulLlj4NAlPZamdlEVFORks3YXJonCjyuQMUQEmB0/edit)
 where we review, edit, and organize the notes.
 
 The release manager sends an email to the
@@ -71,6 +68,4 @@ The release manager sends an email to the
 Bazel contributors are invited to contribute to the document and make sure
 their changes are correctly reflected in the announcement.
 
-Later, the announcement will be submitted to the [Bazel
-blog](https://blog.bazel.build/), using the [bazel-blog
-repository](https://github.com/bazelbuild/bazel-blog/tree/master/_posts).
+Later, the announcement will be submitted to the [Bazel blog](https://blog.bazel.build/), using the [bazel-blog repository](https://github.com/bazelbuild/bazel-blog/tree/master/_posts).
diff --git a/versions/8.1.1/contribute/statemachine-guide.mdx b/versions/8.1.1/contribute/statemachine-guide.mdx
index cb9ece5c..86b15b74 100644
--- a/versions/8.1.1/contribute/statemachine-guide.mdx
+++ b/versions/8.1.1/contribute/statemachine-guide.mdx
@@ -172,8 +172,7 @@ instead, batches[^4] as many lookups as possible before doing so. The value
 might not be immediately available, for example, requiring a Skyframe restart,
 so the caller specifies what to do with the resulting value using a callback.
 
-The `StateMachine` processor ([`Driver`s and bridging to
-SkyFrame](#drivers-and-bridging)) guarantees that the value is available before
+The `StateMachine` processor ([`Driver`s and bridging to SkyFrame](#drivers-and-bridging)) guarantees that the value is available before
 the next state begins. An example follows.
 
 ```
@@ -284,8 +283,7 @@ and solutions to certain control flow problems.
 ### Sequential states
 
 This is the most common and straightforward control flow pattern. An example of
-this is shown in [Stateful computations inside
-`SkyKeyComputeState`](#stateful-computations).
+this is shown in [Stateful computations inside `SkyKeyComputeState`](#stateful-computations).
 
 ### Branching
 
@@ -545,8 +543,7 @@ section describes the propagation of data values.
 
 ### Implementing `Tasks.lookUp` callbacks
 
-There’s an example of implementing a `Tasks.lookUp` callback in [SkyValue
-lookups](#skyvalue-lookups). This section provides rationale and suggests
+There’s an example of implementing a `Tasks.lookUp` callback in [SkyValue lookups](#skyvalue-lookups). This section provides rationale and suggests
 approaches for handling multiple SkyValues.
 
 #### `Tasks.lookUp` callbacks {#tasks-lookup-callbacks}
@@ -710,8 +707,7 @@ class BarProducer implements StateMachine {
 Tip: It would be tempting to use the more concise signature void `accept(Bar
 value)` rather than the stuttery `void acceptBarValue(Bar value)` above.
 However, `Consumer` is a common overload of `void accept(Bar value)`,
-so doing this often leads to violations of the [Overloads: never
-split](https://google.github.io/styleguide/javaguide.html#s3.4.2-ordering-class-contents)
+so doing this often leads to violations of the [Overloads: never split](https://google.github.io/styleguide/javaguide.html#s3.4.2-ordering-class-contents)
 style-guide rule.
 
 Tip: Using a custom `ResultSink` type instead of a generic one from
@@ -774,14 +770,11 @@ pattern after accepting output from either a subtask or SkyValue lookup.
 Note that the implementation of `acceptBarError` eagerly forwards the result to
 the `Caller.ResultSink`, as required by [Error bubbling](#error-bubbling).
 
-Alternatives for top-level `StateMachine`s are described in [`Driver`s and
-bridging to SkyFunctions](#drivers-and-bridging).
+Alternatives for top-level `StateMachine`s are described in [`Driver`s and bridging to SkyFunctions](#drivers-and-bridging).
 
 ### Error handling {#error-handling}
 
-There's a couple of examples of error handling already in [`Tasks.lookUp`
-callbacks](#tasks-lookup-callbacks) and [Propagating values between
-`StateMachines`](#propagating-values). Exceptions, other than
+There's a couple of examples of error handling already in [`Tasks.lookUp` callbacks](#tasks-lookup-callbacks) and [Propagating values between `StateMachines`](#propagating-values). Exceptions, other than
 `InterruptedException` are not thrown, but instead passed around through
 callbacks as values. Such callbacks often have exclusive-or semantics, with
 exactly one of a value or error being passed.
@@ -1184,8 +1177,7 @@ states. Where it is possible, local stack `step` variables are young generation
 variables and efficiently GC'd.
 
 For `StateMachine` variables, breaking things down into subtasks and following
-the recommended pattern for [Propagating values between
-`StateMachine`s](#propagating-values) is also helpful. Observe that when
+the recommended pattern for [Propagating values between `StateMachine`s](#propagating-values) is also helpful. Observe that when
 following the pattern, only child `StateMachine`s have references to parent
 `StateMachine`s and not vice versa. This means that as children complete and
 update the parents using result callbacks, the children naturally fall out of
@@ -1207,8 +1199,7 @@ potentially reflecting local behavior.
 
 ### Concurrency tree diagram {#concurrency-tree-diagram}
 
-The following is an alternative view of the diagram in [Structured
-concurrency](#structured-concurrency) that better depicts the tree structure.
+The following is an alternative view of the diagram in [Structured concurrency](#structured-concurrency) that better depicts the tree structure.
 The blocks form a small tree.
 
 ![Structured Concurrency 3D](/versions/8.1.1/contribute/images/structured-concurrency-3d.svg)
diff --git a/versions/8.1.1/docs/android-instrumentation-test.mdx b/versions/8.1.1/docs/android-instrumentation-test.mdx
index 69b85830..01ea958b 100644
--- a/versions/8.1.1/docs/android-instrumentation-test.mdx
+++ b/versions/8.1.1/docs/android-instrumentation-test.mdx
@@ -2,8 +2,7 @@
 title: 'Android Instrumentation Tests'
 ---
 
-_If you're new to Bazel, start with the [Building Android with
-Bazel](/versions/8.1.1/start/android-app ) tutorial._
+_If you're new to Bazel, start with the [Building Android with Bazel](/versions/8.1.1/start/android-app) tutorial._
 
 ![Running Android instrumentation tests in parallel](/versions/8.1.1/docs/images/android_test.gif "Android instrumentation test")
 
@@ -18,9 +17,7 @@ emulators in a sandbox, ensuring that tests always run from a clean state. Each
 test gets an isolated emulator instance, allowing tests to run in parallel
 without passing states between them.
 
-For more information on Android instrumentation tests, check out the [Android
-developer
-documentation](https://developer.android.com/training/testing/unit-testing/instrumented-unit-tests.html).
+For more information on Android instrumentation tests, check out the [Android developer documentation](https://developer.android.com/training/testing/unit-testing/instrumented-unit-tests.html).
 
 Please file issues in the [GitHub issue tracker](https://github.com/bazelbuild/bazel/issues).
 
@@ -58,8 +55,7 @@ This results in output similar to the following:
 release 4.1.0
 ```
 
-- **KVM**. Bazel requires emulators to have [hardware
-  acceleration](https://developer.android.com/studio/run/emulator-acceleration.html#accel-check)
+- **KVM**. Bazel requires emulators to have [hardware acceleration](https://developer.android.com/studio/run/emulator-acceleration.html#accel-check)
   with KVM on Linux. You can follow these
   [installation instructions](https://help.ubuntu.com/community/KVM/Installation)
   for Ubuntu.
@@ -173,11 +169,9 @@ The main attributes of the rule `android_instrumentation_test` are:
 
 - `target_device`: An `android_device` target. This target describes the
   specifications of the Android emulator which Bazel uses to create, launch and
-  run the tests. See the [section on choosing an Android
-  device](#android-device-target) for more information.
+  run the tests. See the [section on choosing an Android device](#android-device-target) for more information.
 
-The test app's `AndroidManifest.xml` must include [an ``
-tag](https://developer.android.com/studio/test/#configure_instrumentation_manifest_settings).
+The test app's `AndroidManifest.xml` must include [an `` tag](https://developer.android.com/studio/test/#configure_instrumentation_manifest_settings).
 This tag must specify the attributes for the **package of the target app** and
 the **fully qualified class name of the instrumentation test runner**,
 `androidx.test.runner.AndroidJUnitRunner`.
@@ -214,8 +208,7 @@ repositories:
 - `@androidsdk`: The Android SDK. Download this through Android Studio.
 
 - `@android_test_support`: Hosts the test runner, emulator launcher, and
-  `android_device` targets. You can find the [latest release
-  here](https://github.com/android/android-test/releases).
+  `android_device` targets. You can find the [latest release here](https://github.com/android/android-test/releases).
 
 Enable these dependencies by adding the following lines to your `WORKSPACE`
 file:
@@ -240,8 +233,7 @@ android_test_repositories()
 
 ## Maven dependencies {#maven-dependencies}
 
-For managing dependencies on Maven artifacts from repositories, such as [Google
-Maven](https://maven.google.com) or [Maven Central](https://central.maven.org),
+For managing dependencies on Maven artifacts from repositories, such as [Google Maven](https://maven.google.com) or [Maven Central](https://central.maven.org),
 you should use a Maven resolver, such as
 [`rules_jvm_external`](https://github.com/bazelbuild/rules_jvm_external).
 
@@ -370,8 +362,7 @@ the device/emulator listed in `adb devices`.
 
 ## Sample projects {#sample-projects}
 
-If you are looking for canonical project samples, see the [Android testing
-samples](https://github.com/googlesamples/android-testing#experimental-bazel-support)
+If you are looking for canonical project samples, see the [Android testing samples](https://github.com/googlesamples/android-testing#experimental-bazel-support)
 for projects using Espresso and UIAutomator.
 
 ## Espresso setup {#espresso-setup}
@@ -560,8 +551,7 @@ API_LEVELS = [
 
 ## Known issues {#known-issues}
 
-- [Forked adb server processes are not terminated after
-  tests](https://github.com/bazelbuild/bazel/issues/4853)
+- [Forked adb server processes are not terminated after tests](https://github.com/bazelbuild/bazel/issues/4853)
 - While APK building works on all platforms (Linux, macOS, Windows), testing
   only works on Linux.
 - Even with `--config=local_adb`, users still need to specify
diff --git a/versions/8.1.1/docs/android-ndk.mdx b/versions/8.1.1/docs/android-ndk.mdx
index 34e253e4..286e336a 100644
--- a/versions/8.1.1/docs/android-ndk.mdx
+++ b/versions/8.1.1/docs/android-ndk.mdx
@@ -2,8 +2,7 @@
 title: 'Using the Android Native Development Kit with Bazel'
 ---
 
-_If you're new to Bazel, please start with the [Building Android with
-Bazel](/versions/8.1.1/start/android-app ) tutorial._
+_If you're new to Bazel, please start with the [Building Android with Bazel](/versions/8.1.1/start/android-app) tutorial._
 
 ## Overview {#overview}
 
@@ -31,8 +30,7 @@ android_ndk_repository(
 )
 ```
 
-For more information about the `android_ndk_repository` rule, see the [Build
-Encyclopedia entry](/versions/8.1.1/reference/be/android#android_ndk_repository).
+For more information about the `android_ndk_repository` rule, see the [Build Encyclopedia entry](/versions/8.1.1/reference/be/android#android_ndk_repository).
 
 If you're using a recent version of the Android NDK (r22 and beyond), use the
 Starlark implementation of `android_ndk_repository`.
@@ -101,13 +99,11 @@ META-INF/MANIFEST.MF
 
 Bazel compiles all of the cc_libraries into a single shared object (`.so`) file,
 targeted for the `armeabi-v7a` ABI by default. To change this or build for
-multiple ABIs at the same time, see the section on [configuring the target
-ABI](#configuring-target-abi).
+multiple ABIs at the same time, see the section on [configuring the target ABI](#configuring-target-abi).
 
 ## Example setup {#example-setup}
 
-This example is available in the [Bazel examples
-repository](https://github.com/bazelbuild/examples/tree/master/android/ndk).
+This example is available in the [Bazel examples repository](https://github.com/bazelbuild/examples/tree/master/android/ndk).
 
 In the `BUILD.bazel` file, three targets are defined with the `android_binary`,
 `android_library`, and `cc_library` rules.
diff --git a/versions/8.1.1/docs/configurable-attributes.mdx b/versions/8.1.1/docs/configurable-attributes.mdx
index 2e98a39d..f1efd703 100644
--- a/versions/8.1.1/docs/configurable-attributes.mdx
+++ b/versions/8.1.1/docs/configurable-attributes.mdx
@@ -2,8 +2,7 @@
 title: 'Configurable Build Attributes'
 ---
 
-**_Configurable attributes_**, commonly known as [`select()`](
-/reference/be/functions#select), is a Bazel feature that lets users toggle the values
+**_Configurable attributes_**, commonly known as [`select()`](/reference/be/functions#select), is a Bazel feature that lets users toggle the values
 of build rule attributes at the command line.
 
 This can be used, for example, for a multiplatform library that automatically
@@ -407,8 +406,7 @@ sh_library(
 )
 ```
 
-If you need a `select` to match when multiple conditions match, consider [AND
-chaining](#and-chaining).
+If you need a `select` to match when multiple conditions match, consider [AND chaining](#and-chaining).
 
 ## OR chaining {#or-chaining}
 
diff --git a/versions/8.1.1/docs/user-manual.mdx b/versions/8.1.1/docs/user-manual.mdx
index 661c0ec1..66a36537 100644
--- a/versions/8.1.1/docs/user-manual.mdx
+++ b/versions/8.1.1/docs/user-manual.mdx
@@ -1144,10 +1144,7 @@ This option causes Bazel's execution phase to print the full command line
 for each command prior to executing it.
 
 
-  >>>>> # //examples/cpp:hello-world [action 'Linking examples/cpp/hello-world']
-  (cd /home/johndoe/.cache/bazel/_bazel_johndoe/4c084335afceb392cfbe7c31afee3a9f/bazel && \
-    exec env - \
-    /usr/bin/gcc -o bazel-out/local-fastbuild/bin/examples/cpp/hello-world -B/usr/bin/ -Wl,-z,relro,-z,now -no-canonical-prefixes -pass-exit-codes -Wl,-S -Wl,@bazel-out/local_linux-fastbuild/bin/examples/cpp/hello-world-2.params)
+  >>>>> # //examples/cpp:hello-world [action 'Linking examples/cpp/hello-world'](cd /home/johndoe/.cache/bazel/_bazel_johndoe/4c084335afceb392cfbe7c31afee3a9f/bazel && \ exec env - \ /usr/bin/gcc -o bazel-out/local-fastbuild/bin/examples/cpp/hello-world -B/usr/bin/ -Wl,-z,relro,-z,now -no-canonical-prefixes -pass-exit-codes -Wl,-S -Wl,@bazel-out/local_linux-fastbuild/bin/examples/cpp/hello-world-2.params)
 

 
 Where possible, commands are printed in a Bourne shell compatible syntax,
diff --git a/versions/8.1.1/extending/auto-exec-groups.mdx b/versions/8.1.1/extending/auto-exec-groups.mdx
index 9c3d0d33..d7cef622 100644
--- a/versions/8.1.1/extending/auto-exec-groups.mdx
+++ b/versions/8.1.1/extending/auto-exec-groups.mdx
@@ -27,9 +27,7 @@ doesn't detect that ([the error](#first-error-message) is raised), you can set
 
 If you need to use multiple toolchains on a single execution platform (an action
 uses executable or tools from two or more toolchains), you need to manually
-define [exec_groups][exec_groups] (check
-[When should I use a custom exec_group?][multiple_toolchains_exec_groups]
-section).
+define [exec_groups][exec_groups](check [When should I use a custom exec_group?][multiple_toolchains_exec_groups] section).
 
 ## History {#history}
 
@@ -42,8 +40,7 @@ my_rule = rule(
 )
 ```
 
-Rule `my_rule` registers two toolchain types. This means that the [Toolchain
-Resolution](https://bazel.build/extending/toolchains#toolchain-resolution) used
+Rule `my_rule` registers two toolchain types. This means that the [Toolchain Resolution](https://bazel.build/extending/toolchains#toolchain-resolution) used
 to find an execution platform which supports both toolchain types. The selected
 execution platform was used for each registered action inside the rule, unless
 specified differently with [exec_groups][exec_groups].
diff --git a/versions/8.1.1/extending/concepts.mdx b/versions/8.1.1/extending/concepts.mdx
index 37ea889f..15299879 100644
--- a/versions/8.1.1/extending/concepts.mdx
+++ b/versions/8.1.1/extending/concepts.mdx
@@ -20,16 +20,14 @@ Before learning the more advanced concepts, first:
 ## Macros and rules {#macros-and-rules}
 
 A macro is a function that instantiates rules. Macros come in two flavors:
-[symbolic macros](/versions/8.1.1/extending/macros) (new in Bazel 8) and [legacy
-macros](/versions/8.1.1/extending/legacy-macros). The two flavors of macros are defined
+[symbolic macros](/versions/8.1.1/extending/macros) (new in Bazel 8) and [legacy macros](/versions/8.1.1/extending/legacy-macros). The two flavors of macros are defined
 differently, but behave almost the same from the point of view of a user. A
 macro is useful when a `BUILD` file is getting too repetitive or too complex, as
 it lets you reuse some code. The function is evaluated as soon as the `BUILD`
 file is read. After the evaluation of the `BUILD` file, Bazel has little
 information about macros. If your macro generates a `genrule`, Bazel will
 behave *almost* as if you declared that `genrule` in the `BUILD` file. (The one
-exception is that targets declared in a symbolic macro have [special visibility
-semantics](/versions/8.1.1/extending/macros#visibility): a symbolic macro can hide its internal
+exception is that targets declared in a symbolic macro have [special visibility semantics](/versions/8.1.1/extending/macros#visibility): a symbolic macro can hide its internal
 targets from the rest of the package.)
 
 A [rule](/versions/8.1.1/extending/rules) is more powerful than a macro. It can access Bazel
@@ -76,8 +74,7 @@ they will not be executed.
 ## Creating extensions
 
 * [Create your first macro](/versions/8.1.1/rules/macro-tutorial) in order to reuse some code.
-  Then [learn more about macros](/versions/8.1.1/extending/macros) and [using them to create
-  "custom verbs"](/versions/8.1.1/rules/verbs-tutorial).
+  Then [learn more about macros](/versions/8.1.1/extending/macros) and [using them to create "custom verbs"](/versions/8.1.1/rules/verbs-tutorial).
 
 * [Follow the rules tutorial](/versions/8.1.1/rules/rules-tutorial) to get started with rules.
   Next, you can read more about the [rules concepts](/versions/8.1.1/extending/rules).
@@ -92,8 +89,7 @@ them within reach:
 ## Going further
 
 In addition to [macros](/versions/8.1.1/extending/macros) and [rules](/versions/8.1.1/extending/rules), you
-may want to write [aspects](/versions/8.1.1/extending/aspects) and [repository
-rules](/versions/8.1.1/extending/repo).
+may want to write [aspects](/versions/8.1.1/extending/aspects) and [repository rules](/versions/8.1.1/extending/repo).
 
 * Use [Buildifier](https://github.com/bazelbuild/buildtools)
   consistently to format and lint your code.
diff --git a/versions/8.1.1/extending/depsets.mdx b/versions/8.1.1/extending/depsets.mdx
index 816c9418..ed933e91 100644
--- a/versions/8.1.1/extending/depsets.mdx
+++ b/versions/8.1.1/extending/depsets.mdx
@@ -111,8 +111,7 @@ need to ensure that if `B` depends on `A`, then `A.o` comes before `B.o` on the
 linker’s command line. Other tools might have the opposite requirement.
 
 Three traversal orders are supported: `postorder`, `preorder`, and
-`topological`. The first two work exactly like [tree
-traversals](https://en.wikipedia.org/wiki/Tree_traversal#Depth-first_search)
+`topological`. The first two work exactly like [tree traversals](https://en.wikipedia.org/wiki/Tree_traversal#Depth-first_search)
 except that they operate on DAGs and skip already visited nodes. The third order
 works as a topological sort from root to leaves, essentially the same as
 preorder except that shared children are listed only after all of their parents.
diff --git a/versions/8.1.1/extending/exec-groups.mdx b/versions/8.1.1/extending/exec-groups.mdx
index 2733b6a2..ec2fbe10 100644
--- a/versions/8.1.1/extending/exec-groups.mdx
+++ b/versions/8.1.1/extending/exec-groups.mdx
@@ -63,8 +63,7 @@ test rules.
 
 In the rule implementation, you can declare that actions should be run on the
 execution platform of an execution group. You can do this by using the `exec_group`
-param of action generating methods, specifically [`ctx.actions.run`]
-(/rules/lib/builtins/actions#run) and
+param of action generating methods, specifically [`ctx.actions.run`](/rules/lib/builtins/actions#run) and
 [`ctx.actions.run_shell`](/versions/8.1.1/rules/lib/builtins/actions#run_shell).
 
 ```python
diff --git a/versions/8.1.1/extending/macros.mdx b/versions/8.1.1/extending/macros.mdx
index 3b620b9a..5d433c5d 100644
--- a/versions/8.1.1/extending/macros.mdx
+++ b/versions/8.1.1/extending/macros.mdx
@@ -31,8 +31,7 @@ two required parameters: `attrs` and `implementation`.
 
 ### Attributes {#attributes}
 
-`attrs` accepts a dictionary of attribute name to [attribute
-types](https://bazel.build/rules/lib/toplevel/attr#members), which represents
+`attrs` accepts a dictionary of attribute name to [attribute types](https://bazel.build/rules/lib/toplevel/attr#members), which represents
 the arguments to the macro. Two common attributes – `name` and `visibility` –
 are implicitly added to all macros and are not included in the dictionary passed
 to `attrs`.
@@ -66,9 +65,7 @@ To support this pattern, a macro can *inherit attributes* from a rule or another
 macro by passing the [rule](https://bazel.build/versions/8.1.1/rules/lib/builtins/rule) or
 [macro symbol](https://bazel.build/versions/8.1.1/rules/lib/builtins/macro) to `macro()`'s
 `inherit_attrs` argument. (You can also use the special string `"common"`
-instead of a rule or macro symbol to inherit the [common attributes defined for
-all Starlark build
-rules](https://bazel.build/reference/be/common-definitions#common-attributes).)
+instead of a rule or macro symbol to inherit the [common attributes defined for all Starlark build rules](https://bazel.build/reference/be/common-definitions#common-attributes).)
 Only public attributes get inherited, and the attributes in the macro's own
 `attrs` dictionary override inherited attributes with the same name. You can
 also *remove* inherited attributes by using `None` as a value in the `attrs`
diff --git a/versions/8.1.1/extending/platforms.mdx b/versions/8.1.1/extending/platforms.mdx
index bad03150..a77ff544 100644
--- a/versions/8.1.1/extending/platforms.mdx
+++ b/versions/8.1.1/extending/platforms.mdx
@@ -245,8 +245,7 @@ cc_library(
 
 You can use the
 [`IncompatiblePlatformProvider`](/versions/8.1.1/rules/lib/providers/IncompatiblePlatformProvider)
-in `bazel cquery`'s [Starlark output
-format](/versions/8.1.1/query/cquery#output-format-definition) to distinguish
+in `bazel cquery`'s [Starlark output format](/versions/8.1.1/query/cquery#output-format-definition) to distinguish
 incompatible targets from compatible ones.
 
 This can be used to filter out incompatible targets. The example below will
@@ -266,5 +265,4 @@ $ bazel cquery //... --output=starlark --starlark:file=example.cquery
 
 ### Known Issues
 
-Incompatible targets [ignore visibility
-restrictions](https://github.com/bazelbuild/bazel/issues/16044).
+Incompatible targets [ignore visibility restrictions](https://github.com/bazelbuild/bazel/issues/16044).
diff --git a/versions/8.1.1/extending/repo.mdx b/versions/8.1.1/extending/repo.mdx
index 2963e0bb..2688c0cf 100644
--- a/versions/8.1.1/extending/repo.mdx
+++ b/versions/8.1.1/extending/repo.mdx
@@ -74,8 +74,7 @@ specified.
 
 The input parameter `repository_ctx` can be used to access attribute values, and
 non-hermetic functions (finding a binary, executing a binary, creating a file in
-the repository or downloading a file from the Internet). See [the API
-docs](/versions/8.1.1/rules/lib/builtins/repository_ctx) for more context. Example:
+the repository or downloading a file from the Internet). See [the API docs](/versions/8.1.1/rules/lib/builtins/repository_ctx) for more context. Example:
 
 ```python
 def _impl(repository_ctx):
@@ -144,8 +143,7 @@ definition has the `configure` attribute set, use `bazel fetch --force
 
 ## Examples
 
--   [C++ auto-configured
-    toolchain](https://cs.opensource.google/bazel/bazel/+/master:tools/cpp/cc_configure.bzl;drc=644b7d41748e09eff9e47cbab2be2263bb71f29a;l=176):
+-   [C++ auto-configured toolchain](https://cs.opensource.google/bazel/bazel/+/master:tools/cpp/cc_configure.bzl;drc=644b7d41748e09eff9e47cbab2be2263bb71f29a;l=176):
     it uses a repo rule to automatically create the C++ configuration files for
     Bazel by looking for the local C++ compiler, the environment and the flags
     the C++ compiler supports.
diff --git a/versions/8.1.1/extending/rules.mdx b/versions/8.1.1/extending/rules.mdx
index 9138e5bb..dc1b702b 100644
--- a/versions/8.1.1/extending/rules.mdx
+++ b/versions/8.1.1/extending/rules.mdx
@@ -449,8 +449,7 @@ def _example_library_impl(ctx):
 
 If `DefaultInfo` is not returned by a rule implementation or the `files`
 parameter is not specified, `DefaultInfo.files` defaults to all
-*predeclared outputs* (generally, those created by [output
-attributes](#output_attributes)).
+*predeclared outputs* (generally, those created by [output attributes](#output_attributes)).
 
 Rules that perform actions should provide default outputs, even if those outputs
 are not expected to be directly used. Actions that are not in the graph of the
diff --git a/versions/8.1.1/extending/toolchains.mdx b/versions/8.1.1/extending/toolchains.mdx
index 31744967..f36fddea 100644
--- a/versions/8.1.1/extending/toolchains.mdx
+++ b/versions/8.1.1/extending/toolchains.mdx
@@ -523,8 +523,7 @@ The set of available toolchains, in priority order, is created from
   4. Toolchains registered in the "WORKSPACE suffix"; this is only used by
      certain native rules bundled with the Bazel installation.
 
-**NOTE:** [Pseudo-targets like `:all`, `:*`, and
-`/...`](/versions/8.1.1/run/build#specifying-build-targets) are ordered by Bazel's package
+**NOTE:** [Pseudo-targets like `:all`, `:*`, and `/...`](/versions/8.1.1/run/build#specifying-build-targets) are ordered by Bazel's package
 loading mechanism, which uses a lexicographic ordering.
 
 The resolution steps are as follows.
diff --git a/versions/8.1.1/external/advanced.mdx b/versions/8.1.1/external/advanced.mdx
index e247b382..bb120a5a 100644
--- a/versions/8.1.1/external/advanced.mdx
+++ b/versions/8.1.1/external/advanced.mdx
@@ -4,10 +4,8 @@ title: 'Advanced topics on external dependencies'
 
 ## Shadowing dependencies in WORKSPACE
 
-Note: This section applies to the [WORKSPACE
-system](/versions/8.1.1/external/overview#workspace-system) only. For
-[Bzlmod](/versions/8.1.1/external/overview#bzlmod), use a [multiple-version
-override](/versions/8.1.1/external/module#multiple-version_override).
+Note: This section applies to the [WORKSPACE system](/versions/8.1.1/external/overview#workspace-system) only. For
+[Bzlmod](/versions/8.1.1/external/overview#bzlmod), use a [multiple-version override](/versions/8.1.1/external/module#multiple-version_override).
 
 Whenever possible, have a single version policy in your project, which is
 required for dependencies that you compile against and end up in your final
@@ -128,29 +126,24 @@ preferring IPv4 if enabled. In some situations, for example when the IPv4
 network cannot resolve/reach external addresses, this can cause `Network
 unreachable` exceptions and build failures. In these cases, you can override
 Bazel's behavior to prefer IPv6 by using the
-[`java.net.preferIPv6Addresses=true` system
-property](https://docs.oracle.com/javase/8/docs/api/java/net/doc-files/net-properties.html).
+[`java.net.preferIPv6Addresses=true` system property](https://docs.oracle.com/javase/8/docs/api/java/net/doc-files/net-properties.html).
 Specifically:
 
-*   Use `--host_jvm_args=-Djava.net.preferIPv6Addresses=true` [startup
-    option](/versions/8.1.1/docs/user-manual#startup-options), for example by adding the
+*   Use `--host_jvm_args=-Djava.net.preferIPv6Addresses=true` [startup option](/versions/8.1.1/docs/user-manual#startup-options), for example by adding the
     following line in your [`.bazelrc` file](/versions/8.1.1/run/bazelrc):
 
     `startup --host_jvm_args=-Djava.net.preferIPv6Addresses=true`
 
 *   When running Java build targets that need to connect to the internet (such
     as for integration tests), use the
-    `--jvmopt=-Djava.net.preferIPv6Addresses=true` [tool
-    flag](/versions/8.1.1/docs/user-manual#jvmopt). For example, include in your [`.bazelrc`
-    file](/versions/8.1.1/run/bazelrc):
+    `--jvmopt=-Djava.net.preferIPv6Addresses=true` [tool flag](/versions/8.1.1/docs/user-manual#jvmopt). For example, include in your [`.bazelrc` file](/versions/8.1.1/run/bazelrc):
 
     `build --jvmopt=-Djava.net.preferIPv6Addresses`
 
 *   If you are using [`rules_jvm_external`](https://github.com/bazelbuild/rules_jvm_external)
     for dependency version resolution, also add
     `-Djava.net.preferIPv6Addresses=true` to the `COURSIER_OPTS` environment
-    variable to [provide JVM options for
-    Coursier](https://github.com/bazelbuild/rules_jvm_external#provide-jvm-options-for-coursier-with-coursier_opts).
+    variable to [provide JVM options for Coursier](https://github.com/bazelbuild/rules_jvm_external#provide-jvm-options-for-coursier-with-coursier_opts).
 
 ## Offline builds
 
@@ -167,15 +160,12 @@ fetch a file with [`ctx.download`](/versions/8.1.1/rules/lib/builtins/repository
 providing a hash sum of the file needed, Bazel looks for a file matching the
 basename of the first URL, and uses the local copy if the hash matches.
 
-Bazel itself uses this technique to bootstrap offline from the [distribution
-artifact](https://github.com/bazelbuild/bazel-website/blob/master/designs/_posts/2016-10-11-distribution-artifact.md).
-It does so by [collecting all the needed external
-dependencies](https://github.com/bazelbuild/bazel/blob/5cfa0303d6ac3b5bd031ff60272ce80a704af8c2/WORKSPACE#L116)
+Bazel itself uses this technique to bootstrap offline from the [distribution artifact](https://github.com/bazelbuild/bazel-website/blob/master/designs/_posts/2016-10-11-distribution-artifact.md).
+It does so by [collecting all the needed external dependencies](https://github.com/bazelbuild/bazel/blob/5cfa0303d6ac3b5bd031ff60272ce80a704af8c2/WORKSPACE#L116)
 in an internal
 [`distdir_tar`](https://github.com/bazelbuild/bazel/blob/5cfa0303d6ac3b5bd031ff60272ce80a704af8c2/distdir.bzl#L44).
 
 Bazel allows execution of arbitrary commands in repository rules without knowing
 if they call out to the network, and so cannot enforce fully offline builds. To
 test if a build works correctly offline, manually block off the network (as
-Bazel does in its [bootstrap
-test](https://cs.opensource.google/bazel/bazel/+/master:src/test/shell/bazel/BUILD;l=1073;drc=88c426e73cc0eb0a41c0d7995e36acd94e7c9a48)).
\ No newline at end of file
+Bazel does in its [bootstrap test](https://cs.opensource.google/bazel/bazel/+/master:src/test/shell/bazel/BUILD;l=1073;drc=88c426e73cc0eb0a41c0d7995e36acd94e7c9a48)).
\ No newline at end of file
diff --git a/versions/8.1.1/external/migration.mdx b/versions/8.1.1/external/migration.mdx
index 0474207f..c18cf5d9 100644
--- a/versions/8.1.1/external/migration.mdx
+++ b/versions/8.1.1/external/migration.mdx
@@ -2,8 +2,7 @@
 title: 'Bzlmod Migration Guide'
 ---
 
-Due to the [shortcomings of
-WORKSPACE](/versions/8.1.1/external/overview#workspace-shortcomings), Bzlmod is going to
+Due to the [shortcomings of WORKSPACE](/versions/8.1.1/external/overview#workspace-shortcomings), Bzlmod is going to
 replace the legacy WORKSPACE system. The WORKSPACE file will be disabled by
 default in Bazel 8 (late 2024) and will be removed in Bazel 9 (late 2025).
 This guide helps you migrate your project to Bzlmod and drop WORKSPACE for
@@ -117,9 +116,7 @@ Bazel module when it also adopts Bzlmod.
 
 *   **Bzlmod**
 
-    With Bzlmod, as long as the your dependency is available in [Bazel Central
-    Registry](https://registry.bazel.build) or your custom [Bazel
-    registry](/versions/8.1.1/external/registry), you can simply depend on it with a
+    With Bzlmod, as long as the your dependency is available in [Bazel Central Registry](https://registry.bazel.build) or your custom [Bazel registry](/versions/8.1.1/external/registry), you can simply depend on it with a
     [`bazel_dep`](/versions/8.1.1/rules/lib/globals/module#bazel_dep) directive.
 
     ```python
@@ -150,8 +147,7 @@ repository.
 
 If your dependency is not a Bazel project or not yet available in any Bazel
 registry, you can introduce it using
-[`use_repo_rule`](/versions/8.1.1/external/module#use_repo_rule) or [module
-extensions](/versions/8.1.1/external/extension).
+[`use_repo_rule`](/versions/8.1.1/external/module#use_repo_rule) or [module extensions](/versions/8.1.1/external/extension).
 
 *   **WORKSPACE**
 
@@ -604,8 +600,7 @@ macros.
 Fortunately, the flag
 [`--experimental_repository_resolved_file`][resolved_file_flag]
 can help. This flag essentially generates a "lock file" of all fetched external
-dependencies in your last Bazel command. You can find more details in this [blog
-post](https://blog.bazel.build/2018/07/09/bazel-sync-and-resolved-file.html).
+dependencies in your last Bazel command. You can find more details in this [blog post](https://blog.bazel.build/2018/07/09/bazel-sync-and-resolved-file.html).
 
 [resolved_file_flag]: /reference/command-line-reference#flag--experimental_repository_resolved_file
 
@@ -646,11 +641,9 @@ You may also know `bazel query` can be used for inspecting repository rules with
 bazel query --output=build //external:
 ```
 
-While it is more convenient and much faster, [bazel query can lie about
-external dependency version](https://github.com/bazelbuild/bazel/issues/12947),
+While it is more convenient and much faster, [bazel query can lie about external dependency version](https://github.com/bazelbuild/bazel/issues/12947),
 so be careful using it! Querying and inspecting external
-dependencies with Bzlmod is going to achieved by a [new
-subcommand](https://github.com/bazelbuild/bazel/issues/15365).
+dependencies with Bzlmod is going to achieved by a [new subcommand](https://github.com/bazelbuild/bazel/issues/15365).
 
 #### Built-in default dependencies {#builtin-default-deps}
 
@@ -697,8 +690,7 @@ Using the WORKSPACE.bzlmod file can make the migration easier because:
 #### Repository visibility {#repository-visibility}
 
 Bzlmod is able to control which other repositories are visible from a given
-repository, check [repository names and strict
-deps](/versions/8.1.1/external/module#repository_names_and_strict_deps) for more details.
+repository, check [repository names and strict deps](/versions/8.1.1/external/module#repository_names_and_strict_deps) for more details.
 
 Here is a summary of repository visibilities from different types of
 repositories when also taking WORKSPACE into consideration.
@@ -711,8 +703,7 @@ repositories when also taking WORKSPACE into consideration.
 | WORKSPACE Repos | All visible | Not visible | Not visible | All visible |
 
 Note: For the root module, if a repository `@foo` is defined in WORKSPACE and
-`@foo` is also used as an [apparent repository
-name](/versions/8.1.1/external/overview#apparent-repo-name) in MODULE.bazel, then `@foo`
+`@foo` is also used as an [apparent repository name](/versions/8.1.1/external/overview#apparent-repo-name) in MODULE.bazel, then `@foo`
 refers to the one introduced in MODULE.bazel.
 
 Note: For a module extension generated repository `@bar`, if `@foo` is used as
@@ -787,9 +778,7 @@ the project. Take note of a few things when creating the source archive:
     GitHub isn't going to guarantee the checksum of source archives generated on
     demand. In short, URLs in the form of
     `https://github.com///releases/download/...` is considered stable
-    while `https://github.com///archive/...` is not. Check [GitHub
-    Archive Checksum
-    Outage](https://blog.bazel.build/2023/02/15/github-archive-checksum.html)
+    while `https://github.com///archive/...` is not. Check [GitHub Archive Checksum Outage](https://blog.bazel.build/2023/02/15/github-archive-checksum.html)
     for more context.
 
 *   **Make sure the source tree follows the layout of the original repository.**
@@ -818,8 +807,7 @@ Pull Request.
 
 [bcr_contrib_guide]: https://github.com/bazelbuild/bazel-central-registry/tree/main/docs#contribute-a-bazel-module
 
-It is **highly recommended** to set up the [Publish to
-BCR](https://github.com/bazel-contrib/publish-to-bcr) GitHub App for your
+It is **highly recommended** to set up the [Publish to BCR](https://github.com/bazel-contrib/publish-to-bcr) GitHub App for your
 repository to automate the process of submitting your module to the BCR.
 
 ## Best practices {#best-practices}
diff --git a/versions/8.1.1/external/mod-command.mdx b/versions/8.1.1/external/mod-command.mdx
index e49acc52..f5ebb078 100644
--- a/versions/8.1.1/external/mod-command.mdx
+++ b/versions/8.1.1/external/mod-command.mdx
@@ -61,11 +61,9 @@ The available subcommands and their respective required arguments are:
 
 *   ``: All present versions of the module ``.
 
-*   `@`: The repo with the given [apparent
-    name](overview#apparent-repo-name) in the context of the `--base_module`.
+*   `@`: The repo with the given [apparent name](overview#apparent-repo-name) in the context of the `--base_module`.
 
-*   `@@`: The repo with the given [canonical
-    name](overview#canonical-repo-name).
+*   `@@`: The repo with the given [canonical name](overview#canonical-repo-name).
 
 In a context requiring specifying modules, ``s referring to repos that
 correspond to modules (as opposed to extension-generated repos) can also be
@@ -87,8 +85,7 @@ The following options only affect the subcommands that print graphs (`graph`,
     information about the version resolution of each module. If the module
     version changed during resolution, show either which version replaced it or
     what was the original version, the reason it was replaced, and which modules
-    requested the new version if the reason was [Minimal Version
-    Selection](module#version-selection).
+    requested the new version if the reason was [Minimal Version Selection](module#version-selection).
 
 *   `--include_unused` *default: "false"*: Include in the output graph the
     modules which were originally present in the dependency graph, but became
diff --git a/versions/8.1.1/external/module.mdx b/versions/8.1.1/external/module.mdx
index 2728ea94..0628b7e3 100644
--- a/versions/8.1.1/external/module.mdx
+++ b/versions/8.1.1/external/module.mdx
@@ -122,8 +122,7 @@ serves multiple purposes:
     version, regardless of which versions of the dependency are requested in the
     dependency graph.
 *   With the `registry` attribute, you can force this dependency to come from a
-    specific registry, instead of following the normal [registry
-    selection](/versions/8.1.1/external/registry#selecting_registries) process.
+    specific registry, instead of following the normal [registry selection](/versions/8.1.1/external/registry#selecting_registries) process.
 *   With the `patch*` attributes, you can specify a set of patches to apply to
     the downloaded module.
 
@@ -176,13 +175,11 @@ With `bazel_dep`, you can define repos that represent other Bazel modules.
 Sometimes there is a need to define a repo that does _not_ represent a Bazel
 module; for example, one that contains a plain JSON file to be read as data.
 
-In this case, you could use the [`use_repo_rule`
-directive](/versions/8.1.1/rules/lib/globals/module#use_repo_rule) to directly define a repo
+In this case, you could use the [`use_repo_rule` directive](/versions/8.1.1/rules/lib/globals/module#use_repo_rule) to directly define a repo
 by invoking a repo rule. This repo will only be visible to the module it's
 defined in.
 
-Under the hood, this is implemented using the same mechanism as [module
-extensions](/versions/8.1.1/external/extension), which lets you define repos with more
+Under the hood, this is implemented using the same mechanism as [module extensions](/versions/8.1.1/external/extension), which lets you define repos with more
 flexibility.
 
 ## Repository names and strict deps
diff --git a/versions/8.1.1/external/overview.mdx b/versions/8.1.1/external/overview.mdx
index f8fbab98..42cf1296 100644
--- a/versions/8.1.1/external/overview.mdx
+++ b/versions/8.1.1/external/overview.mdx
@@ -128,8 +128,7 @@ for all build targets inside the repo.
 
 The syntax of a `REPO.bazel` file is similar to `BUILD` files, except that no
 `load` statements are supported, and only a single function, `repo()`, is
-available. `repo()` takes the same arguments as the [`package()`
-function](/versions/8.1.1/reference/be/functions#package) in `BUILD` files; whereas `package()`
+available. `repo()` takes the same arguments as the [`package()` function](/versions/8.1.1/reference/be/functions#package) in `BUILD` files; whereas `package()`
 specifies common attributes for all build targets inside the package, `repo()`
 analogously does so for all build targets inside the repo.
 
@@ -163,8 +162,7 @@ bazel_dep(name = "protobuf", version = "3.19.0")
 ```
 
 A module must only list its direct dependencies, which Bzlmod looks up in a
-[Bazel registry](/versions/8.1.1/external/registry) — by default, the [Bazel Central
-Registry](https://bcr.bazel.build/). The registry provides the
+[Bazel registry](/versions/8.1.1/external/registry) — by default, the [Bazel Central Registry](https://bcr.bazel.build/). The registry provides the
 dependencies' `MODULE.bazel` files, which allows Bazel to discover the entire
 transitive dependency graph before performing version resolution.
 
@@ -235,5 +233,4 @@ many pain points, including:
         `B` and `C`; `B` and `C` both depend on different versions of `D`).
 
 Due to the shortcomings of WORKSPACE, Bzlmod is going to replace the legacy
-WORKSPACE system in future Bazel releases. Please read the [Bzlmod migration
-guide](/versions/8.1.1/external/migration) on how to migrate to Bzlmod.
+WORKSPACE system in future Bazel releases. Please read the [Bzlmod migration guide](/versions/8.1.1/external/migration) on how to migrate to Bzlmod.
diff --git a/versions/8.1.1/external/registry.mdx b/versions/8.1.1/external/registry.mdx
index ea868c4c..e9ee12ee 100644
--- a/versions/8.1.1/external/registry.mdx
+++ b/versions/8.1.1/external/registry.mdx
@@ -42,8 +42,7 @@ An index registry must follow the format below:
             project
         *   `versions`: A list of all the versions of this module to be found in
             this registry
-        *   `yanked_versions`: A map of [*yanked*
-            versions](/versions/8.1.1/external/module#yanked_versions) of this module. The keys
+        *   `yanked_versions`: A map of [*yanked* versions](/versions/8.1.1/external/module#yanked_versions) of this module. The keys
             should be versions to yank and the values should be descriptions of
             why the version is yanked, ideally containing a link to more
             information
@@ -54,8 +53,7 @@ An index registry must follow the format below:
         *   The default type is "archive", representing an `http_archive` repo,
             with the following fields:
             *   `url`: The URL of the source archive
-            *   `integrity`: The [Subresource
-                Integrity](https://w3c.github.io/webappsec-subresource-integrity/#integrity-metadata-description)
+            *   `integrity`: The [Subresource Integrity](https://w3c.github.io/webappsec-subresource-integrity/#integrity-metadata-description)
                 checksum of the archive
             *   `strip_prefix`: A directory prefix to strip when extracting the
                 source archive
@@ -103,8 +101,7 @@ You can browse its contents using the web frontend at
 https://registry.bazel.build/.
 
 The Bazel community maintains the BCR, and contributors are welcome to submit
-pull requests. See the [BCR contribution
-guidelines](https://github.com/bazelbuild/bazel-central-registry/blob/main/docs/README.md).
+pull requests. See the [BCR contribution guidelines](https://github.com/bazelbuild/bazel-central-registry/blob/main/docs/README.md).
 
 In addition to following the format of a normal index registry, the BCR requires
 a `presubmit.yml` file for each module version
diff --git a/versions/8.1.1/external/vendor.mdx b/versions/8.1.1/external/vendor.mdx
index fe7fc846..8ee7ff04 100644
--- a/versions/8.1.1/external/vendor.mdx
+++ b/versions/8.1.1/external/vendor.mdx
@@ -23,9 +23,7 @@ absolute path.
 ## Vendor a specific external repository {#vendor-specific-repository}
 
 You can use the `vendor` command with the `--repo` flag to specify which repo
-to vendor, it accepts both [canonical repo
-name](/versions/8.1.1/external/overview#canonical-repo-name) and [apparent repo
-name](/versions/8.1.1/external/overview#apparent-repo-name).
+to vendor, it accepts both [canonical repo name](/versions/8.1.1/external/overview#canonical-repo-name) and [apparent repo name](/versions/8.1.1/external/overview#apparent-repo-name).
 
 For example, running:
 
diff --git a/versions/8.1.1/help.mdx b/versions/8.1.1/help.mdx
index 42da6b73..53762c83 100644
--- a/versions/8.1.1/help.mdx
+++ b/versions/8.1.1/help.mdx
@@ -46,5 +46,4 @@ what level of support Bazel provides.
 
 ## File a bug {#file-bug}
 
-If you encounter a bug or want to request a feature, file a [GitHub
-Issue](https://github.com/bazelbuild/bazel/issues).
+If you encounter a bug or want to request a feature, file a [GitHub Issue](https://github.com/bazelbuild/bazel/issues).
diff --git a/versions/8.1.1/install/bazelisk.mdx b/versions/8.1.1/install/bazelisk.mdx
index 241ecf2a..00f5d8fd 100644
--- a/versions/8.1.1/install/bazelisk.mdx
+++ b/versions/8.1.1/install/bazelisk.mdx
@@ -16,8 +16,7 @@ For more details, see
 ## Updating Bazel
 
 Bazel has a [backward compatibility policy](/versions/8.1.1/release/backward-compatibility)
-(see [guidance for rolling out incompatible
-changes](/versions/8.1.1/contribute/breaking-changes) if you
+(see [guidance for rolling out incompatible changes](/versions/8.1.1/contribute/breaking-changes) if you
 are the author of one). That page summarizes best practices on how to test and
 migrate your project with upcoming incompatible changes and how to provide
 feedback to the incompatible change authors.
diff --git a/versions/8.1.1/install/compile-source.mdx b/versions/8.1.1/install/compile-source.mdx
index 03edd11c..d339a270 100644
--- a/versions/8.1.1/install/compile-source.mdx
+++ b/versions/8.1.1/install/compile-source.mdx
@@ -45,8 +45,7 @@ it by typing `bazel` in a terminal.
 
 **Reason**: To build Bazel from a GitHub source tree, you need a pre-existing
 Bazel binary. You can install one from a package manager or download one from
-GitHub. See [Installing Bazel](/versions/8.1.1/install). (Or you can [build from
-scratch (bootstrap)](#bootstrap-bazel).)
+GitHub. See [Installing Bazel](/versions/8.1.1/install). (Or you can [build from scratch (bootstrap)](#bootstrap-bazel).)
 
 **Troubleshooting**:
 
@@ -239,8 +238,7 @@ For instructions for Unix-like systems, see
     ```
 
 *   **The Visual C++ compiler.** Install the Visual C++ compiler either as part
-    of Visual Studio 2015 or newer, or by installing the latest [Build Tools
-    for Visual Studio 2017](https://aka.ms/BuildTools).
+    of Visual Studio 2015 or newer, or by installing the latest [Build Tools for Visual Studio 2017](https://aka.ms/BuildTools).
 
 *   **JDK.** Version 21 is required.
 
diff --git a/versions/8.1.1/install/ide.mdx b/versions/8.1.1/install/ide.mdx
index 561d0e02..c42d95e9 100644
--- a/versions/8.1.1/install/ide.mdx
+++ b/versions/8.1.1/install/ide.mdx
@@ -38,10 +38,8 @@ To install, go to the IDE's plugin browser and search for `Bazel`.
 To manually install older versions, download the zip files from JetBrains'
 Plugin Repository and install the zip file from the IDE's plugin browser:
 
-*  [Android Studio
-   plugin](https://plugins.jetbrains.com/plugin/9185-android-studio-with-bazel)
-*  [IntelliJ
-   plugin](https://plugins.jetbrains.com/plugin/8609-intellij-with-bazel)
+*  [Android Studio plugin](https://plugins.jetbrains.com/plugin/9185-android-studio-with-bazel)
+*  [IntelliJ plugin](https://plugins.jetbrains.com/plugin/8609-intellij-with-bazel)
 *  [CLion plugin](https://plugins.jetbrains.com/plugin/9554-clion-with-bazel)
 
 ### Xcode {#xcode}
@@ -61,8 +59,7 @@ Features:
 * Starlark debugger for `.bzl` files during a build (set breakpoints, step
   through code, inspect variables, and so on)
 
-Find [the plugin on the Visual Studio
-marketplace](https://marketplace.visualstudio.com/items?itemName=BazelBuild.vscode-bazel).
+Find [the plugin on the Visual Studio marketplace](https://marketplace.visualstudio.com/items?itemName=BazelBuild.vscode-bazel).
 The plugin is [open source](https://github.com/bazelbuild/vscode-bazel).
 
 See also: [Autocomplete for Source Code](#autocomplete-for-source-code)
@@ -82,8 +79,7 @@ See also: [Autocomplete for Source Code](#autocomplete-for-source-code)
 
 ### Emacs {#emacs}
 
-See [`bazelbuild/bazel-emacs-mode` on
-GitHub](https://github.com/bazelbuild/emacs-bazel-mode)
+See [`bazelbuild/bazel-emacs-mode` on GitHub](https://github.com/bazelbuild/emacs-bazel-mode)
 
 See also: [Autocomplete for Source Code](#autocomplete-for-source-code)
 
@@ -115,6 +111,5 @@ tool for building Bazel targets when source files change.
 
 ## Building your own IDE plugin {#build-own-plugin}
 
-Read the [**IDE support** blog
-post](https://blog.bazel.build/2016/06/10/ide-support.html) to learn more about
+Read the [**IDE support** blog post](https://blog.bazel.build/2016/06/10/ide-support.html) to learn more about
 the Bazel APIs to use when building an IDE plugin.
diff --git a/versions/8.1.1/install/windows.mdx b/versions/8.1.1/install/windows.mdx
index d5d56dd6..00e45c80 100644
--- a/versions/8.1.1/install/windows.mdx
+++ b/versions/8.1.1/install/windows.mdx
@@ -31,8 +31,7 @@ To check your Windows version:
 
 Alternatively you can:
 
-*   [Download the Bazel binary (`bazel-version-windows-x86_64.exe`) from
- GitHub](https://github.com/bazelbuild/bazel/releases).
+*   [Download the Bazel binary (`bazel-version-windows-x86_64.exe`) from GitHub](https://github.com/bazelbuild/bazel/releases).
 *   [Install Bazel from Chocolatey](#chocolately)
 *   [Install Bazel from Scoop](#scoop)
 *   [Build Bazel from source](/versions/8.1.1/install/compile-source)
@@ -208,8 +207,7 @@ If that doesn't help:
     its dependencies, such as the MSYS2 shell. This will not install Visual C++
     though.
 
-See [Chocolatey installation and package maintenance
-guide](/versions/8.1.1/contribute/windows-chocolatey-maintenance) for more
+See [Chocolatey installation and package maintenance guide](/versions/8.1.1/contribute/windows-chocolatey-maintenance) for more
 information about the Chocolatey package.
 
 ### Using Scoop {#scoop}
@@ -226,8 +224,7 @@ information about the Chocolatey package.
     scoop install bazel
     ```
 
-See [Scoop installation and package maintenance
-guide](/versions/8.1.1/contribute/windows-scoop-maintenance) for more
+See [Scoop installation and package maintenance guide](/versions/8.1.1/contribute/windows-scoop-maintenance) for more
 information about the Scoop package.
 
 ### Build from source {#build-from-source}
diff --git a/versions/8.1.1/migrate/maven.mdx b/versions/8.1.1/migrate/maven.mdx
index c86694e2..6b2bff8e 100644
--- a/versions/8.1.1/migrate/maven.mdx
+++ b/versions/8.1.1/migrate/maven.mdx
@@ -19,8 +19,7 @@ directly run by Bazel since there's no Maven compatibility layer.
 ## Before you begin {#before-you-begin}
 
 *   [Install Bazel](/versions/8.1.1/install) if it's not yet installed.
-*   If you're new to Bazel, go through the tutorial [Introduction to Bazel:
-    Build Java](/versions/8.1.1/start/java) before you start migrating. The tutorial explains
+*   If you're new to Bazel, go through the tutorial [Introduction to Bazel: Build Java](/versions/8.1.1/start/java) before you start migrating. The tutorial explains
     Bazel's concepts, structure, and label syntax.
 
 ## Differences between Maven and Bazel {#dif-maven-bazel}
@@ -44,8 +43,7 @@ The steps below describe how to migrate your project to Bazel:
 3.  [Create more BUILD files](#3-build)
 4.  [Build using Bazel](#4-build)
 
-Examples below come from a migration of the [Guava
-project](https://github.com/google/guava) from Maven to Bazel. The
+Examples below come from a migration of the [Guava project](https://github.com/google/guava) from Maven to Bazel. The
 Guava project used is release `v31.1`. The examples using Guava do not walk
 through each step in the migration, but they do show the files and contents that
 are generated or added manually for the migration.
@@ -63,14 +61,12 @@ has no external dependencies, this file can be empty.
 If your project depends on files or packages that are not in one of the
 project's directories, specify these external dependencies in the MODULE.bazel
 file. You can use `rules_jvm_external` to manage dependencies from Maven. For
-instructions about using this ruleset, see [the
-README](https://github.com/bazelbuild/rules_jvm_external/#rules_jvm_external)
+instructions about using this ruleset, see [the README](https://github.com/bazelbuild/rules_jvm_external/#rules_jvm_external)
 .
 
 #### Guava project example: external dependencies {#guava-1}
 
-You can list the external dependencies of the [Guava
-project](https://github.com/google/guava) with the
+You can list the external dependencies of the [Guava project](https://github.com/google/guava) with the
 [`rules_jvm_external`](https://github.com/bazelbuild/rules_jvm_external)
 ruleset.
 
@@ -164,8 +160,7 @@ your build by adding more `BUILD` files with more granular targets.
             *   `resources`: Use globbing to list all resources in your project.
             *   `deps`: You need to determine which external dependencies your
                 project needs.
-        *   Take a look at the [example below of this top-level BUILD
-            file](#guava-2) from the migration of the Guava project.
+        *   Take a look at the [example below of this top-level BUILD file](#guava-2) from the migration of the Guava project.
 
 3.  Now that you have a `BUILD` file at the root of your project, build your
     project to ensure that it works. On the command line, from your workspace
diff --git a/versions/8.1.1/migrate/xcode.mdx b/versions/8.1.1/migrate/xcode.mdx
index 6e5e2c5c..061798d1 100644
--- a/versions/8.1.1/migrate/xcode.mdx
+++ b/versions/8.1.1/migrate/xcode.mdx
@@ -32,8 +32,7 @@ Before you begin, do the following:
 
 1.  [Install Bazel](/versions/8.1.1/install) if you have not already done so.
 
-2.  If you're not familiar with Bazel and its concepts, complete the [iOS app
-    tutorial](/versions/8.1.1/start/ios-app)). You should understand the Bazel workspace,
+2.  If you're not familiar with Bazel and its concepts, complete the [iOS app tutorial](/versions/8.1.1/start/ios-app)). You should understand the Bazel workspace,
     including the `MODULE.bazel` and `BUILD` files, as well as the concepts of
     targets, build rules, and Bazel packages.
 
@@ -44,8 +43,7 @@ Before you begin, do the following:
 Unlike Xcode, Bazel requires you to explicitly declare all dependencies for
 every target in the `BUILD` file.
 
-For more information on external dependencies, see [Working with external
-dependencies](/versions/8.1.1/docs/external).
+For more information on external dependencies, see [Working with external dependencies](/versions/8.1.1/docs/external).
 
 ## Build or test an Xcode project with Bazel {#build-xcode-project}
 
@@ -84,8 +82,7 @@ Note: Place the project source code within the directory tree containing the
 
 To integrate SwiftPM dependencies into the Bazel workspace with
 [swift_bazel](https://github.com/cgrindel/swift_bazel), you must
-convert them into Bazel packages as described in the [following
-tutorial](https://chuckgrindel.com/swift-packages-in-bazel-using-swift_bazel/)
+convert them into Bazel packages as described in the [following tutorial](https://chuckgrindel.com/swift-packages-in-bazel-using-swift_bazel/)
 .
 
 Note: SwiftPM support is a manual process with many variables. SwiftPM
@@ -103,8 +100,7 @@ initial build of the project as follows:
 *   [Step 3b: (Optional) Add the test target(s)](#step-3b-optional-add-the-test-target-s)
 *   [Step 3c: Add the library target(s)](#step-3c-add-the-library-target-s)
 
-**Tip:** To learn more about packages and other Bazel concepts, see [Workspaces,
-packages, and targets](/versions/8.1.1/concepts/build-ref).
+**Tip:** To learn more about packages and other Bazel concepts, see [Workspaces, packages, and targets](/versions/8.1.1/concepts/build-ref).
 
 #### Step 3a: Add the application target {#add-app-target}
 
@@ -132,8 +128,7 @@ In the target, specify the following at the minimum:
 
 #### Step 3b: (Optional) Add the test target(s) {#add-test-target}
 
-Bazel's [Apple build
-rules](https://github.com/bazelbuild/rules_apple) support running
+Bazel's [Apple build rules](https://github.com/bazelbuild/rules_apple) support running
 unit and UI tests on all Apple platforms. Add test targets as follows:
 
 *   [`macos_unit_test`](https://github.com/bazelbuild/rules_apple/blob/master/doc/rules-macos.md#macos_unit_test)
@@ -181,8 +176,7 @@ all sources and/or headers of a certain type. Use it carefully as it might
 include files you do not want Bazel to build.
 
 You can browse existing examples for various types of applications directly in
-the [rules_apple examples
-directory](https://github.com/bazelbuild/rules_apple/tree/master/examples/). For
+the [rules_apple examples directory](https://github.com/bazelbuild/rules_apple/tree/master/examples/). For
 example:
 
 *   [macOS application targets](https://github.com/bazelbuild/rules_apple/tree/master/examples/macos)
@@ -191,8 +185,7 @@ example:
 
 *   [Multi platform applications (macOS, iOS, watchOS, tvOS)](https://github.com/bazelbuild/rules_apple/tree/master/examples/multi_platform)
 
-For more information on build rules, see [Apple Rules for
-Bazel](https://github.com/bazelbuild/rules_apple).
+For more information on build rules, see [Apple Rules for Bazel](https://github.com/bazelbuild/rules_apple).
 
 At this point, it is a good idea to test the build:
 
diff --git a/versions/8.1.1/query/cquery.mdx b/versions/8.1.1/query/cquery.mdx
index 616d9772..079ffd95 100644
--- a/versions/8.1.1/query/cquery.mdx
+++ b/versions/8.1.1/query/cquery.mdx
@@ -6,8 +6,7 @@ title: ' Configurable Query (cquery)'
 [`select()`](/versions/8.1.1/docs/configurable-attributes) and build options' effects on the build
 graph.
 
-It achieves this by running over the results of Bazel's [analysis
-phase](/versions/8.1.1/extending/concepts#evaluation-model),
+It achieves this by running over the results of Bazel's [analysis phase](/versions/8.1.1/extending/concepts#evaluation-model),
 which integrates these effects. `query`, by contrast, runs over the results of
 Bazel's loading phase, before options are evaluated.
 
@@ -137,8 +136,7 @@ $ bazel cquery //foo --universe_scope=//foo,//genrule_with_foo_as_tool
 If you want to precisely declare which instance to query over, use
 the [`config`](#config) function.
 
-See `query`'s [target pattern
-documentation](/versions/8.1.1/query/language#target-patterns) for more information on target patterns.
+See `query`'s [target pattern documentation](/versions/8.1.1/query/language#target-patterns) for more information on target patterns.
 
 ## Functions {#functions}
 
diff --git a/versions/8.1.1/query/language.mdx b/versions/8.1.1/query/language.mdx
index 1caa0e8a..10ae32eb 100644
--- a/versions/8.1.1/query/language.mdx
+++ b/versions/8.1.1/query/language.mdx
@@ -1105,8 +1105,7 @@ is being used.
 
 ### On the ordering of results {#results-ordering}
 
-Although query expressions always follow the "[law of
-conservation of graph order](#graph-order)", _presenting_ the results may be done
+Although query expressions always follow the "[law of conservation of graph order](#graph-order)", _presenting_ the results may be done
 in either a dependency-ordered or unordered manner. This does **not**
 influence the targets in the result set or how the query is computed. It only
 affects how the results are printed to stdout. Moreover, nodes that are
@@ -1252,8 +1251,7 @@ and `maxrank` output formats print the labels of each
 target in the resulting graph, but instead of appearing in
 topological order, they appear in rank order, preceded by their
 rank number. These are unaffected by the result ordering
-`--[no]order_results` flag (see [notes on
-the ordering of results](#result-order)).
+`--[no]order_results` flag (see [notes on the ordering of results](#result-order)).
 
 There are two variants of this format: `minrank` ranks
 each node by the length of the shortest path from a root node to it.
diff --git a/versions/8.1.1/reference/be/functions.mdx b/versions/8.1.1/reference/be/functions.mdx
index 0ecf43a4..cf3b553a 100644
--- a/versions/8.1.1/reference/be/functions.mdx
+++ b/versions/8.1.1/reference/be/functions.mdx
@@ -262,8 +262,7 @@ There are several important limitations and caveats:
    package called "Foo.java" (which is allowed, though Bazel warns about it),
    then the consumer of the `glob()` will use the "Foo.java" rule
    (its outputs) instead of the "Foo.java" file. See
-   [GitHub
-   issue #10395](https://github.com/bazelbuild/bazel/issues/10395#issuecomment-583714657) for more details.
+   [GitHub issue #10395](https://github.com/bazelbuild/bazel/issues/10395#issuecomment-583714657) for more details.
 3. Globs may match files in subdirectories. And subdirectory names
    may be wildcarded. However...
 4. Labels are not allowed to cross the package boundary and glob does
diff --git a/versions/8.1.1/reference/be/java.mdx b/versions/8.1.1/reference/be/java.mdx
index 2c678657..313de2b2 100644
--- a/versions/8.1.1/reference/be/java.mdx
+++ b/versions/8.1.1/reference/be/java.mdx
@@ -225,8 +225,7 @@ test code. The test runner's main method is invoked instead of the main class be
   [java\_binary](#java_binary) for more details.
 
 See the section on `java_binary()` arguments. This rule also
-supports all [attributes common
-to all test rules (\*\_test)](https://bazel.build/versions/8.1.1/reference/be/common-definitions#common-attributes-tests).
+supports all [attributes common to all test rules (\*\_test)](https://bazel.build/versions/8.1.1/reference/be/common-definitions#common-attributes-tests).
 
 #### Examples
 
diff --git a/versions/8.1.1/reference/be/make-variables.mdx b/versions/8.1.1/reference/be/make-variables.mdx
index a1af9f2d..40582924 100644
--- a/versions/8.1.1/reference/be/make-variables.mdx
+++ b/versions/8.1.1/reference/be/make-variables.mdx
@@ -19,8 +19,7 @@ targets, and *custom* variables, which are defined in dependency targets
 and only available to targets that depend on them.
 
 The reason for the term "Make" is historical: the syntax and semantics of
-these variables were originally intended to match [GNU
-Make](https://www.gnu.org/software/make/manual/html_node/Using-Variables.html).
+these variables were originally intended to match [GNU Make](https://www.gnu.org/software/make/manual/html_node/Using-Variables.html).
 
 ## Use
 
@@ -64,8 +63,7 @@ and look at the top output lines with capital letters.
 **Toolchain option variables**
 
 * `COMPILATION_MODE`:
-  `fastbuild`, `dbg`, or `opt`. ([more
-  details](https://bazel.build/versions/8.1.1/docs/user-manual#flag--compilation_mode))
+  `fastbuild`, `dbg`, or `opt`. ([more details](https://bazel.build/versions/8.1.1/docs/user-manual#flag--compilation_mode))
 
 **Path variables**
 
diff --git a/versions/8.1.1/reference/be/workspace.mdx b/versions/8.1.1/reference/be/workspace.mdx
index 79332940..5fe10537 100644
--- a/versions/8.1.1/reference/be/workspace.mdx
+++ b/versions/8.1.1/reference/be/workspace.mdx
@@ -25,8 +25,7 @@ bind(name, actual, compatible_with, deprecation, distribs, features, licenses, r
 
 *Warning: use of `bind()` is not recommended. See "[Consider removing bind](https://github.com/bazelbuild/bazel/issues/1952)" for a long
 discussion of its issues and alternatives. In particular, consider the use of
-[`repo_mapping`
-repository attributes](https://bazel.build/versions/8.1.1/rules/repository_rules#attributes).*
+[`repo_mapping` repository attributes](https://bazel.build/versions/8.1.1/rules/repository_rules#attributes).*
 
 *Warning: `select()` cannot be used in `bind()`. See the [Configurable Attributes FAQ](/versions/8.1.1/docs/configurable-attributes#bind-select) for
 details.*
@@ -114,8 +113,7 @@ local_repository(name, path, repo_mapping)
 ```
 
 Allows targets from a local directory to be bound. This means that the current repository can
-use targets defined in this other directory. See the [bind
-section](/versions/8.1.1/reference/be/workspace#bind_examples) for more details.
+use targets defined in this other directory. See the [bind section](/versions/8.1.1/reference/be/workspace#bind_examples) for more details.
 
 #### Examples
 
diff --git a/versions/8.1.1/reference/glossary.mdx b/versions/8.1.1/reference/glossary.mdx
index 691585dc..c21764ae 100644
--- a/versions/8.1.1/reference/glossary.mdx
+++ b/versions/8.1.1/reference/glossary.mdx
@@ -21,8 +21,7 @@ An in-memory graph of [actions](#action) and the [artifacts](#artifact) that
 these actions read and generate. The graph might include artifacts that exist as
 source files (for example, in the file system) as well as generated
 intermediate/final artifacts that are not mentioned in `BUILD` files. Produced
-during the [analysis phase](#analysis-phase) and used during the [execution
-phase](#execution-phase).
+during the [analysis phase](#analysis-phase) and used during the [execution phase](#execution-phase).
 
 ### Action graph query (aquery) {#action-graph-query}
 A [query](#query-concept) tool that can query over build [actions](#action).
@@ -37,8 +36,7 @@ invalidate individual actions deterministically.
 
 ### Analysis phase {#analysis-phase}
 The second phase of a build. Processes the [target graph](#target-graph)
-specified in [`BUILD` files](#build-file) to produce an in-memory [action
-graph](#action-graph) that determines the order of actions to run during the
+specified in [`BUILD` files](#build-file) to produce an in-memory [action graph](#action-graph) that determines the order of actions to run during the
 [execution phase](#execution-phase). This is the phase in which rule
 implementations are evaluated.
 
@@ -81,8 +79,7 @@ target's source files, dependencies, and custom compiler options. The particular
 attributes available for a given target depend on its rule type.
 
 ### .bazelrc {#bazelrc}
-Bazel’s configuration file used to change the default values for [startup
-flags](#startup-flags) and [command flags](#command-flags), and to define common
+Bazel’s configuration file used to change the default values for [startup flags](#startup-flags) and [command flags](#command-flags), and to define common
 groups of options that can then be set together on the Bazel command line using
 a `--config` flag. Bazel can combine settings from multiple bazelrc files
 (systemwide, per-workspace, per-user, or from a custom location), and a
@@ -108,8 +105,7 @@ directory.
 
 ### .bzl File {#bzl-file}
 A file that defines rules, [macros](#macro), and constants written in
-[Starlark](#starlark). These can then be imported into [`BUILD`
-files](#build-file) using the `load()` function.
+[Starlark](#starlark). These can then be imported into [`BUILD` files](#build-file) using the `load()` function.
 
 {/* TODO: ### Build event protocol */}
 
@@ -117,8 +113,7 @@ files](#build-file) using the `load()` function.
 
 ### Build graph {#build-graph}
 The dependency graph that Bazel constructs and traverses to perform a build.
-Includes nodes like [targets](#target), [configured
-targets](#configured-target), [actions](#action), and [artifacts](#artifact). A
+Includes nodes like [targets](#target), [configured targets](#configured-target), [actions](#action), and [artifacts](#artifact). A
 build is considered complete when all [artifacts](#artifact) on which a set of
 requested targets depend are verified as up-to-date.
 
@@ -158,8 +153,7 @@ graphs and restart the [analysis phase](#analysis-phase).
 ### Configuration {#configuration}
 Information outside of [rule](#rule) definitions that impacts how rules generate
 [actions](#action). Every build has at least one configuration specifying the
-target platform, action environment variables, and command-line [build
-flags](#command-flags). [Transitions](#transition) may create additional
+target platform, action environment variables, and command-line [build flags](#command-flags). [Transitions](#transition) may create additional
 configurations, such as for host tools or cross-compilation.
 
 **See also:** [Configurations](/versions/8.1.1/extending/rules#configurations)
@@ -174,8 +168,7 @@ configuration of `//:c` because changing `--javacopt` unnecessarily breaks C++
 build cacheability.
 
 ### Configured query (cquery) {#configured-query}
-A [query](#query-concept) tool that queries over [configured
-targets](#configured-target) (after the [analysis phase](#analysis-phase)
+A [query](#query-concept) tool that queries over [configured targets](#configured-target) (after the [analysis phase](#analysis-phase)
 completes). This means `select()` and [build flags](#command-flags) (such as
 `--platforms`) are accurately reflected in the results.
 
@@ -191,8 +184,7 @@ build, it has two configured targets: `` and ``.
 ### Correctness {#correctness}
 A build is correct when its output faithfully reflects the state of its
 transitive inputs. To achieve correct builds, Bazel strives to be
-[hermetic](#hermeticity), reproducible, and making [build
-analysis](#analysis-phase) and [action execution](#execution-phase)
+[hermetic](#hermeticity), reproducible, and making [build analysis](#analysis-phase) and [action execution](#execution-phase)
 deterministic.
 
 ### Dependency {#dependency}
@@ -234,8 +226,7 @@ compilation). A dynamic execution strategy can provide the best possible
 incremental and clean build times.
 
 ### Execution phase {#execution-phase}
-The third phase of a build. Executes the [actions](#action) in the [action
-graph](#action-graph) created during the [analysis phase](#analysis-phase).
+The third phase of a build. Executes the [actions](#action) in the [action graph](#action-graph) created during the [analysis phase](#analysis-phase).
 These actions invoke executables (compilers, scripts) to read and write
 [artifacts](#artifact). *Spawn strategies* control how these actions are
 executed: locally, remotely, dynamically, sandboxed, docker, and so on.
@@ -285,8 +276,7 @@ syntax may be omitted.
 The first phase of a build where Bazel executes [`BUILD` files](#build-file) to
 create [packages](#package). [Macros](#macro) and certain functions like
 `glob()` are evaluated in this phase. Interleaved with the second phase of the
-build, the [analysis phase](#analysis-phase), to build up a [target
-graph](#target-graph).
+build, the [analysis phase](#analysis-phase), to build up a [target graph](#target-graph).
 
 ### Legacy macro {#legacy-macro}
 A flavor of [macro](#macro) which is declared as an ordinary
@@ -336,8 +326,7 @@ Module metadata is hosted in Bazel registries.
 
 ### Module Extension {#module-extension}
 A piece of logic that can be run to generate [repos](#repository) by reading
-inputs from across the [module](#module) dependency graph and invoking [repo
-rules](#repository-rule). Module extensions have capabilities similar to repo
+inputs from across the [module](#module) dependency graph and invoking [repo rules](#repository-rule). Module extensions have capabilities similar to repo
 rules, allowing them to access the internet, perform file I/O, and so on.
 
 **See also:** [Module extensions](/versions/8.1.1/external/extension)
@@ -350,8 +339,7 @@ example, `native.cc_library` or `native.java_library`). User-defined rules
 
 ### Output base {#output-base}
 A [workspace](#workspace)-specific directory to store Bazel output files. Used
-to separate outputs from the *workspace*'s source tree (the [main
-repo](#repository)). Located in the [output user root](#output-user-root).
+to separate outputs from the *workspace*'s source tree (the [main repo](#repository)). Located in the [output user root](#output-user-root).
 
 ### Output groups {#output-groups}
 A group of files that is expected to be built when Bazel finishes building a
@@ -406,8 +394,7 @@ query variants: [query](#query-command), [cquery](#configured-query), and
 [aquery](#action-graph-query).
 
 ### query (command) {#query-command}
-A [query](#query-concept) tool that operates over the build's post-[loading
-phase](#loading-phase) [target graph](#target-graph). This is relatively fast,
+A [query](#query-concept) tool that operates over the build's post-[loading phase](#loading-phase) [target graph](#target-graph). This is relatively fast,
 but can't analyze the effects of `select()`, [build flags](#command-flags),
 [artifacts](#artifact), or build [actions](#action).
 
@@ -425,8 +412,7 @@ repo; multiple such files can coexist in a directory.
 The *main repo* is the repo in which the current Bazel command is being run.
 
 *External repos* are defined by specifying [modules](#module) in `MODULE.bazel`
-files, or invoking [repo rules](#repository-rule) in [module
-extensions](#module-extension). They can be fetched on demand to a predetermined
+files, or invoking [repo rules](#repository-rule) in [module extensions](#module-extension). They can be fetched on demand to a predetermined
 "magical" location on disk.
 
 Each repo has a unique, constant *canonical* name, and potentially different
@@ -437,8 +423,7 @@ Each repo has a unique, constant *canonical* name, and potentially different
 ### Repository cache {#repo-cache}
 A shared content-addressable cache of files downloaded by Bazel for builds,
 shareable across [workspaces](#workspace). Enables offline builds after the
-initial download. Commonly used to cache files downloaded through [repository
-rules](#repository-rule) like `http_archive` and repository rule APIs like
+initial download. Commonly used to cache files downloaded through [repository rules](#repository-rule) like `http_archive` and repository rule APIs like
 `repository_ctx.download`. Files are cached only if their SHA-256 checksums are
 specified for the download.
 
@@ -472,8 +457,7 @@ Rules are instantiated to produce rule targets in the
 [loading phase](#loading-phase). In the [analysis phase](#analysis-phase) rule
 targets communicate information to their downstream dependencies in the form of
 [providers](#provider), and register [actions](#action) describing how to
-generate their output artifacts. These actions are run in the [execution
-phase](#execution-phase).
+generate their output artifacts. These actions are run in the [execution phase](#execution-phase).
 
 Note: Historically the term "rule" has been used to refer to a rule target.
 This usage was inherited from tools like Make, but causes confusion and should
@@ -517,8 +501,7 @@ support the stamp attribute.
 ### Starlark {#starlark}
 The extension language for writing [rules](/versions/8.1.1/extending/rules) and [macros](#macro). A
 restricted subset of Python (syntactically and grammatically) aimed for the
-purpose of configuration, and for better performance. Uses the [`.bzl`
-file](#bzl-file) extension. [`BUILD` files](#build-file) use an even more
+purpose of configuration, and for better performance. Uses the [`.bzl` file](#bzl-file) extension. [`BUILD` files](#build-file) use an even more
 restricted version of Starlark (such as no `def` function definitions), formerly
 known as Skylark.
 
@@ -549,8 +532,7 @@ An object that is defined in a [`BUILD` file](#build-file) and identified by a
 [label](#label). Targets represent the buildable units of a workspace from
 the perspective of the end user.
 
-A target that is declared by instantiating a [rule](#rule) is called a [rule
-target](#rule-target). Depending on the rule, these may be runnable (like
+A target that is declared by instantiating a [rule](#rule) is called a [rule target](#rule-target). Depending on the rule, these may be runnable (like
 `cc_binary`) or testable (like `cc_test`). Rule targets typically depend on
 other targets via their [attributes](#attribute) (such as `deps`); these
 dependencies form the basis of the [target graph](#target-graph).
@@ -561,14 +543,11 @@ within a `BUILD` file. As a special case, the `BUILD` file of any package is
 always considered a source file target in that package.
 
 Targets are discovered during the [loading phase](#loading-phase). During the
-[analysis phase](#analysis-phase), targets are associated with [build
-configurations](#configuration) to form [configured
-targets](#configured-target).
+[analysis phase](#analysis-phase), targets are associated with [build configurations](#configuration) to form [configured targets](#configured-target).
 
 ### Target graph {#target-graph}
 An in-memory graph of [targets](#target) and their dependencies. Produced during
-the [loading phase](#loading-phase) and used as an input to the [analysis
-phase](#analysis-phase).
+the [loading phase](#loading-phase) and used as an input to the [analysis phase](#analysis-phase).
 
 ### Target pattern {#target-pattern}
 A way to specify a group of [targets](#target) on the command line. Commonly
@@ -581,8 +560,7 @@ packages recursively from the root of the [workspace](#workspace).
 Rule [targets](#target) instantiated from test rules, and therefore contains a
 test executable. A return code of zero from the completion of the executable
 indicates test success. The exact contract between Bazel and tests (such as test
-environment variables, test result collection methods) is specified in the [Test
-Encyclopedia](/versions/8.1.1/reference/test-encyclopedia).
+environment variables, test result collection methods) is specified in the [Test Encyclopedia](/versions/8.1.1/reference/test-encyclopedia).
 
 ### Toolchain {#toolchain}
 A set of tools to build outputs for a language. Typically, a toolchain includes
@@ -596,8 +574,7 @@ A build [target](#target) is top-level if it’s requested on the Bazel command
 line. For example, if `//:foo` depends on `//:bar`, and `bazel build //:foo` is
 called, then for this build, `//:foo` is top-level, and `//:bar` isn’t
 top-level, although both targets will need to be built. An important difference
-between top-level and non-top-level targets is that [command
-flags](#command-flags) set on the Bazel command line (or via
+between top-level and non-top-level targets is that [command flags](#command-flags) set on the Bazel command line (or via
 [.bazelrc](#bazelrc)) will set the [configuration](#configuration) for top-level
 targets, but might be modified by a [transition](#transition) for non-top-level
 targets.
@@ -628,8 +605,7 @@ or `.bzl` file may load a given `.bzl` file. Without context, usually
 **See also:** [Visibility documentation](/versions/8.1.1/concepts/visibility)
 
 ### Workspace {#workspace}
-The environment shared by all Bazel commands run from the same [main
-repository](#repository).
+The environment shared by all Bazel commands run from the same [main repository](#repository).
 
 Note that historically the concepts of "repository" and "workspace" have been
 conflated; the term "workspace" has often been used to refer to the main
diff --git a/versions/8.1.1/release/backward-compatibility.mdx b/versions/8.1.1/release/backward-compatibility.mdx
index 1dfb6403..9c6d4576 100644
--- a/versions/8.1.1/release/backward-compatibility.mdx
+++ b/versions/8.1.1/release/backward-compatibility.mdx
@@ -6,11 +6,9 @@ This page provides information about how to handle backward compatibility,
 including migrating from one release to another and how to communicate
 incompatible changes.
 
-Bazel is evolving. Minor versions released as part of an [LTS major
-version](/versions/8.1.1/release#bazel-versioning) are fully backward-compatible. New major LTS
+Bazel is evolving. Minor versions released as part of an [LTS major version](/versions/8.1.1/release#bazel-versioning) are fully backward-compatible. New major LTS
 releases may contain incompatible changes that require some migration effort.
-For more information about Bazel's release model, please check out the [Release
-Model](/versions/8.1.1/release) page.
+For more information about Bazel's release model, please check out the [Release Model](/versions/8.1.1/release) page.
 
 ## Summary {#summary}
 
@@ -59,8 +57,7 @@ available.
 ## Communicating incompatible changes {#communicating-incompatible-changes}
 
 The primary source of information about incompatible changes are GitHub issues
-marked with an ["incompatible-change"
-label](https://github.com/bazelbuild/bazel/issues?q=label%3Aincompatible-change).
+marked with an ["incompatible-change" label](https://github.com/bazelbuild/bazel/issues?q=label%3Aincompatible-change).
 
 For every incompatible change, the issue specifies the following:
 
diff --git a/versions/8.1.1/release/index.mdx b/versions/8.1.1/release/index.mdx
index f4d996e0..cd948d48 100644
--- a/versions/8.1.1/release/index.mdx
+++ b/versions/8.1.1/release/index.mdx
@@ -2,8 +2,7 @@
 title: 'Release Model'
 ---
 
-As announced in [the original blog
-post](https://blog.bazel.build/2020/11/10/long-term-support-release.html), Bazel
+As announced in [the original blog post](https://blog.bazel.build/2020/11/10/long-term-support-release.html), Bazel
 4.0 and higher versions provides support for two release tracks: rolling
 releases and long term support (LTS) releases. This page covers the latest
 information about Bazel's release model.
@@ -19,8 +18,7 @@ information about Bazel's release model.
 | Bazel 5 | Maintenance | [5.4.1](https://github.com/bazelbuild/bazel/releases/tag/5.4.1) | Jan 2025 |
 | Bazel 4 | Deprecated | [4.2.4](https://github.com/bazelbuild/bazel/releases/tag/4.2.4) | Jan 2024 |
 
-All Bazel LTS releases can be found on the [release
-page](https://github.com/bazelbuild/bazel/releases) on GitHub.
+All Bazel LTS releases can be found on the [release page](https://github.com/bazelbuild/bazel/releases) on GitHub.
 
 Note: Bazel version older than Bazel 5 are no longer supported, Bazel users are
 recommended to upgrade to the latest LTS release or use rolling releases if you
@@ -28,8 +26,7 @@ want to keep up with the latest changes at HEAD.
 
 ## Release versioning {#bazel-versioning}
 
-Bazel uses a _major.minor.patch_ [Semantic
-Versioning](https://semver.org/) scheme.
+Bazel uses a _major.minor.patch_ [Semantic Versioning](https://semver.org/) scheme.
 
 *   A _major release_ contains features that are not backward compatible with
     the previous release. Each major Bazel version is an LTS release.
@@ -72,8 +69,7 @@ Bazel regularly publish releases for two release tracks.
     release.
 *   Rolling releases can ship incompatible changes. Incompatible flags are
     recommended for major breaking changes, rolling out incompatible changes
-    should follow our [backward compatibility
-    policy](/versions/8.1.1/release/backward-compatibility).
+    should follow our [backward compatibility policy](/versions/8.1.1/release/backward-compatibility).
 
 ### LTS releases {#lts-releases}
 
@@ -89,8 +85,7 @@ Bazel regularly publish releases for two release tracks.
 *   A Bazel LTS release enters the Deprecated stage after being in ​​the
     Maintenance stage for 2 years.
 
-For planned releases, please check our [release
-issues](https://github.com/bazelbuild/bazel/issues?q=is%3Aopen+is%3Aissue+label%3Arelease)
+For planned releases, please check our [release issues](https://github.com/bazelbuild/bazel/issues?q=is%3Aopen+is%3Aissue+label%3Arelease)
 on Github.
 
 ## Release procedure & policies {#release-procedure-policies}
@@ -153,8 +148,7 @@ For LTS releases, the procedure and policies below are followed:
 1.  Identify release blockers and fix issues found on the release branch.
     *   The release branch is tested with the same test suite in
         [postsubmit](https://buildkite.com/bazel/bazel-bazel) and
-        [downstream test pipeline]
-        (https://buildkite.com/bazel/bazel-at-head-plus-downstream)
+        [downstream test pipeline](https://buildkite.com/bazel/bazel-at-head-plus-downstream)
         on Bazel CI. The Bazel team monitors testing results of the release
         branch and fixes any regressions found.
 1.  Create a new release candidate from the release branch when all known
@@ -210,5 +204,4 @@ feature.
 ## Rule compatibility {#rule-compatibility}
 
 If you are a rule authors and want to maintain compatibility with different
-Bazel versions, please check out the [Rule
-Compatibility](/versions/8.1.1/release/rule-compatibility) page.
+Bazel versions, please check out the [Rule Compatibility](/versions/8.1.1/release/rule-compatibility) page.
diff --git a/versions/8.1.1/release/rule-compatibility.mdx b/versions/8.1.1/release/rule-compatibility.mdx
index 8d3b0bdc..5317d4a4 100644
--- a/versions/8.1.1/release/rule-compatibility.mdx
+++ b/versions/8.1.1/release/rule-compatibility.mdx
@@ -53,18 +53,15 @@ Bazel LTS release.
 As Bazel rules authors, you can ensure a manageable migration process for users
 by following these best practices:
 
-1.  The rule should follow [Semantic
-    Versioning](https://semver.org/): minor versions of the same
+1.  The rule should follow [Semantic Versioning](https://semver.org/): minor versions of the same
     major version are backward compatible.
 1.  The rule at HEAD should be compatible with the latest Bazel LTS release.
 1.  The rule at HEAD should be compatible with Bazel at HEAD. To achieve this,
     you can
     *   Set up your own CI testing with Bazel at HEAD
-    *   Add your project to [Bazel downstream
-        testing](https://github.com/bazelbuild/continuous-integration/blob/master/docs/downstream-testing.md);
+    *   Add your project to [Bazel downstream testing](https://github.com/bazelbuild/continuous-integration/blob/master/docs/downstream-testing.md);
         the Bazel team files issues to your project if breaking changes in Bazel
-        affect your project, and you must follow our [downstream project
-        policies](https://github.com/bazelbuild/continuous-integration/blob/master/docs/downstream-testing.md#downstream-project-policies)
+        affect your project, and you must follow our [downstream project policies](https://github.com/bazelbuild/continuous-integration/blob/master/docs/downstream-testing.md#downstream-project-policies)
         to address issues timely.
 1.  The latest major version of the rule must be compatible with the latest
     Bazel LTS release.
diff --git a/versions/8.1.1/remote/bep-glossary.mdx b/versions/8.1.1/remote/bep-glossary.mdx
index f13ee4cb..98692d82 100644
--- a/versions/8.1.1/remote/bep-glossary.mdx
+++ b/versions/8.1.1/remote/bep-glossary.mdx
@@ -410,5 +410,4 @@ workspace, such as the execution root.
 
 ## WorkspaceStatus {#workspacestatus}
 
-A single `WorkspaceStatus` event contains the result of the [workspace status
-command](/versions/8.1.1/docs/user-manual#workspace-status).
+A single `WorkspaceStatus` event contains the result of the [workspace status command](/versions/8.1.1/docs/user-manual#workspace-status).
diff --git a/versions/8.1.1/remote/bep.mdx b/versions/8.1.1/remote/bep.mdx
index fbce7e69..d01fa66f 100644
--- a/versions/8.1.1/remote/bep.mdx
+++ b/versions/8.1.1/remote/bep.mdx
@@ -2,14 +2,12 @@
 title: 'Build Event Protocol'
 ---
 
-The [Build Event
-Protocol](https://github.com/bazelbuild/bazel/blob/master/src/main/java/com/google/devtools/build/lib/buildeventstream/proto/build_event_stream.proto)
+The [Build Event Protocol](https://github.com/bazelbuild/bazel/blob/master/src/main/java/com/google/devtools/build/lib/buildeventstream/proto/build_event_stream.proto)
 (BEP) allows third-party programs to gain insight into a Bazel invocation. For
 example, you could use the BEP to gather information for an IDE
 plugin or a dashboard that displays build results.
 
-The protocol is a set of [protocol
-buffer](https://developers.google.com/protocol-buffers/) messages with some
+The protocol is a set of [protocol buffer](https://developers.google.com/protocol-buffers/) messages with some
 semantics defined on top of it. It includes information about build and test
 results, build progress, the build configuration and much more. The BEP is
 intended to be consumed programmatically and makes parsing Bazel’s
@@ -20,16 +18,13 @@ build event is a protocol buffer message consisting of a build event identifier,
 a set of child event identifiers, and a payload.
 
 *  __Build Event Identifier:__ Depending on the kind of build event, it might be
-an [opaque
-string](https://github.com/bazelbuild/bazel/blob/7.1.0/src/main/java/com/google/devtools/build/lib/buildeventstream/proto/build_event_stream.proto#L131-L140)
-or [structured
-information](https://github.com/bazelbuild/bazel/blob/7.1.0/src/main/java/com/google/devtools/build/lib/buildeventstream/proto/build_event_stream.proto#L194-L205)
+an [opaque string](https://github.com/bazelbuild/bazel/blob/7.1.0/src/main/java/com/google/devtools/build/lib/buildeventstream/proto/build_event_stream.proto#L131-L140)
+or [structured information](https://github.com/bazelbuild/bazel/blob/7.1.0/src/main/java/com/google/devtools/build/lib/buildeventstream/proto/build_event_stream.proto#L194-L205)
 revealing more about the build event. A build event identifier is unique within
 a build.
 
 *  __Children:__ A build event may announce other build events, by including
-their build event identifiers in its [children
-field](https://github.com/bazelbuild/bazel/blob/7.1.0/src/main/java/com/google/devtools/build/lib/buildeventstream/proto/build_event_stream.proto#L1276).
+their build event identifiers in its [children field](https://github.com/bazelbuild/bazel/blob/7.1.0/src/main/java/com/google/devtools/build/lib/buildeventstream/proto/build_event_stream.proto#L1276).
 For example, the `PatternExpanded` build event announces the targets it expands
 to as children. The protocol guarantees that all events, except for the first
 event, are announced by a previous event.
@@ -91,8 +86,7 @@ human-readable formats, such as text and JSON:
 
 ## Build Event Service {#build-event-service}
 
-The [Build Event
-Service](https://github.com/googleapis/googleapis/blob/master/google/devtools/build/v1/publish_build_event.proto)
+The [Build Event Service](https://github.com/googleapis/googleapis/blob/master/google/devtools/build/v1/publish_build_event.proto)
 Protocol is a generic [gRPC](https://www.grpc.io) service for publishing build events. The Build Event
 Service protocol is independent of the BEP and treats BEP events as opaque bytes.
 Bazel ships with a gRPC client implementation of the Build Event Service protocol that
@@ -136,8 +130,7 @@ For a description of each of these flags, see the
 The BEP typically contains many references to log files (test.log, test.xml,
 etc. ) stored on the machine where Bazel is running. A remote BES server
 typically can't access these files as they are on different machines. A way to
-work around this issue is to use Bazel with [remote
-caching](/versions/8.1.1/remote/caching).
+work around this issue is to use Bazel with [remote caching](/versions/8.1.1/remote/caching).
 Bazel will upload all output files to the remote cache (including files
 referenced in the BEP) and the BES server can then fetch the referenced files
 from the cache.
diff --git a/versions/8.1.1/remote/cache-local.mdx b/versions/8.1.1/remote/cache-local.mdx
index be730ca2..a691a41c 100644
--- a/versions/8.1.1/remote/cache-local.mdx
+++ b/versions/8.1.1/remote/cache-local.mdx
@@ -18,8 +18,7 @@ execution. However, local execution presents some additional challenges.
 ## Checking your cache hit rate {#cache-hits}
 
 Successful remote cache hits will show up in the status line, similar to
-[Cache Hits rate with Remote
-Execution](/versions/8.1.1/remote/cache-remote#check-cache-hits).
+[Cache Hits rate with Remote Execution](/versions/8.1.1/remote/cache-remote#check-cache-hits).
 
 In the standard output of your Bazel run, you will see something like the
 following:
@@ -66,8 +65,7 @@ the steps in this section.
    message you see does not give you enough information, try adding
    `--verbose_failures`.
 
-2. Follow the steps from [Troubleshooting cache hits for remote
-   execution](/versions/8.1.1/remote/cache-remote#troubleshooting_cache_hits) to
+2. Follow the steps from [Troubleshooting cache hits for remote execution](/versions/8.1.1/remote/cache-remote#troubleshooting_cache_hits) to
    ensure that your cache-writing Bazel invocations are able to get cache hits
    on the same machine and across machines.
 
@@ -81,7 +79,6 @@ the steps in this section.
    b. Ensure your cache-reading Bazel invocations build the same targets as the
       cache-writing Bazel invocations.
 
-   c. Follow the same steps as to [ensure caching across
-      machines](/versions/8.1.1/remote/cache-remote#caching-across-machines),
+   c. Follow the same steps as to [ensure caching across machines](/versions/8.1.1/remote/cache-remote#caching-across-machines),
       to ensure caching from your cache-writing Bazel invocation to your
       cache-reading Bazel invocation.
diff --git a/versions/8.1.1/remote/caching.mdx b/versions/8.1.1/remote/caching.mdx
index 7a7b4f2e..6d2b48a3 100644
--- a/versions/8.1.1/remote/caching.mdx
+++ b/versions/8.1.1/remote/caching.mdx
@@ -308,8 +308,7 @@ or for the age of individual cache entries. Bazel will automatically garbage
 collect the disk cache while idling between builds; the idle timer can be set
 with `--experimental_disk_cache_gc_idle_delay` (defaulting to 5 minutes).
 
-As an alternative to automatic garbage collection, we also provide a [tool](
-https://github.com/bazelbuild/bazel/tree/master/src/tools/diskcache) to run a
+As an alternative to automatic garbage collection, we also provide a [tool](https://github.com/bazelbuild/bazel/tree/master/src/tools/diskcache) to run a
 garbage collection on demand.
 
 ## Known issues {#known-issues}
diff --git a/versions/8.1.1/remote/dynamic.mdx b/versions/8.1.1/remote/dynamic.mdx
index 379e43c4..eba1342c 100644
--- a/versions/8.1.1/remote/dynamic.mdx
+++ b/versions/8.1.1/remote/dynamic.mdx
@@ -12,8 +12,7 @@ alike.
 This page describes how to enable, tune, and debug dynamic execution. If you
 have both local and remote execution set up and are trying to adjust Bazel
 settings for better performance, this page is for you. If you don't already have
-remote execution set up, go to the Bazel [Remote Execution
-Overview](/versions/8.1.1/remote/rbe) first.
+remote execution set up, go to the Bazel [Remote Execution Overview](/versions/8.1.1/remote/rbe) first.
 
 ## Enabling dynamic execution? {#enabling-dynamic-execution}
 
@@ -44,14 +43,12 @@ are likely. The default value is 1000ms, but should be tuned to being just a bit
 longer than cache hits usually take. The actual time depends both on the remote
 system and on how long a round-trip takes. Usually, the value will be the same
 for all users of a given remote system, unless some of them are far enough away
-to add roundtrip latency. You can use the [Bazel profiling
-features](/versions/8.1.1/rules/performance#performance-profiling) to look at how long typical
+to add roundtrip latency. You can use the [Bazel profiling features](/versions/8.1.1/rules/performance#performance-profiling) to look at how long typical
 cache hits take.
 
 Dynamic execution can be used with local sandboxed strategy as well as with
 [persistent workers](/versions/8.1.1/remote/persistent). Persistent workers will automatically
-run with sandboxing when used with dynamic execution, and cannot use [multiplex
-workers](/versions/8.1.1/remote/multiplex). On Darwin and Windows systems, the sandboxed
+run with sandboxing when used with dynamic execution, and cannot use [multiplex workers](/versions/8.1.1/remote/multiplex). On Darwin and Windows systems, the sandboxed
 strategy can be slow; you can pass `--reuse_sandbox_directories` to reduce
 overhead of creating sandboxes on these systems.
 
@@ -67,8 +64,7 @@ entire action fails. This is an intentional choice to prevent differences
 between local and remote execution from going unnoticed.
 
 For more background on how dynamic execution and its locking works, see Julio
-Merino's excellent [blog
-posts](https://jmmv.dev/series/bazel-dynamic-execution/)
+Merino's excellent [blog posts](https://jmmv.dev/series/bazel-dynamic-execution/)
 
 ## When should I use dynamic execution? {#when-to-use}
 
diff --git a/versions/8.1.1/remote/persistent.mdx b/versions/8.1.1/remote/persistent.mdx
index 9492be55..62c25e08 100644
--- a/versions/8.1.1/remote/persistent.mdx
+++ b/versions/8.1.1/remote/persistent.mdx
@@ -257,7 +257,6 @@ For more information on persistent workers, see:
 *   [Original persistent workers blog post](https://blog.bazel.build/2015/12/10/java-workers.html)
 *   [Haskell implementation description](https://www.tweag.io/blog/2019-09-25-bazel-ghc-persistent-worker-internship/)
 *   [Blog post by Mike Morearty](https://medium.com/@mmorearty/how-to-create-a-persistent-worker-for-bazel-7738bba2cabb)
-*   [Front End Development with Bazel: Angular/TypeScript and Persistent Workers
-    w/ Asana](https://www.youtube.com/watch?v=0pgERydGyqo)
+*   [Front End Development with Bazel: Angular/TypeScript and Persistent Workers w/ Asana](https://www.youtube.com/watch?v=0pgERydGyqo)
 *   [Bazel strategies explained](https://jmmv.dev/2019/12/bazel-strategies.html)
 *   [Informative worker strategy discussion on the bazel-discuss mailing list](https://groups.google.com/forum/#!msg/bazel-discuss/oAEnuhYOPm8/ol7hf4KWJgAJ)
diff --git a/versions/8.1.1/remote/rules.mdx b/versions/8.1.1/remote/rules.mdx
index b1c5ba0e..806800a3 100644
--- a/versions/8.1.1/remote/rules.mdx
+++ b/versions/8.1.1/remote/rules.mdx
@@ -54,8 +54,7 @@ variables that may not be set to equivalent values (or at all) in the remote
 execution environment.
 
 Toolchain rules currently exist for Bazel build and test rules for
-[Scala](https://github.com/bazelbuild/rules_scala/blob/master/scala/scala_toolch
-ain.bzl),
+[Scala](https://github.com/bazelbuild/rules_scala/blob/master/scala/scala_toolch ain.bzl),
 [Rust](https://github.com/bazelbuild/rules_rust/blob/main/rust/toolchain.bzl),
 and [Go](https://github.com/bazelbuild/rules_go/blob/master/go/toolchains.rst),
 and new toolchain rules are under way for other languages and tools such as
diff --git a/versions/8.1.1/remote/workspace.mdx b/versions/8.1.1/remote/workspace.mdx
index 679db269..c7ca3999 100644
--- a/versions/8.1.1/remote/workspace.mdx
+++ b/versions/8.1.1/remote/workspace.mdx
@@ -11,8 +11,7 @@ on the host machine. If your workspace rules access information about the
 host machine for use during execution, your build is likely to break due to
 incompatibilities between the environments.
 
-As part of [adapting Bazel rules for remote
-execution](/versions/8.1.1/remote/rules), you need to find such workspace rules
+As part of [adapting Bazel rules for remote execution](/versions/8.1.1/remote/rules), you need to find such workspace rules
 and fix them. This page describes how to find potentially problematic workspace
 rules using the workspace log.
 
diff --git a/versions/8.1.1/rules/language.mdx b/versions/8.1.1/rules/language.mdx
index a931b451..ddb8535e 100644
--- a/versions/8.1.1/rules/language.mdx
+++ b/versions/8.1.1/rules/language.mdx
@@ -93,10 +93,8 @@ values returned by rules are immutable.
 `BUILD` files register targets via making calls to rules. `.bzl` files provide
 definitions for constants, rules, macros, and functions.
 
-[Native functions](/versions/8.1.1/reference/be/functions) and [native rules](
-/reference/be/overview#language-specific-native-rules) are global symbols in
-`BUILD` files. `bzl` files need to load them using the [`native` module](
-/rules/lib/toplevel/native).
+[Native functions](/versions/8.1.1/reference/be/functions) and [native rules](/reference/be/overview#language-specific-native-rules) are global symbols in
+`BUILD` files. `bzl` files need to load them using the [`native` module](/rules/lib/toplevel/native).
 
 There are two syntactic restrictions in `BUILD` files: 1) declaring functions is
 illegal, and 2) `*args` and `**kwargs` arguments are not allowed.
diff --git a/versions/8.1.1/rules/legacy-macro-tutorial.mdx b/versions/8.1.1/rules/legacy-macro-tutorial.mdx
index 140d3a12..0f5181ef 100644
--- a/versions/8.1.1/rules/legacy-macro-tutorial.mdx
+++ b/versions/8.1.1/rules/legacy-macro-tutorial.mdx
@@ -3,9 +3,7 @@ title: 'Creating a Legacy Macro'
 ---
 
 IMPORTANT: This tutorial is for [*legacy macros*](/versions/8.1.1/extending/legacy-macros). If
-you only need to support Bazel 8 or newer, we recommend using [symbolic
-macros](/versions/8.1.1/extending/macros) instead; take a look at [Creating a Symbolic
-Macro](../macro-tutorial).
+you only need to support Bazel 8 or newer, we recommend using [symbolic macros](/versions/8.1.1/extending/macros) instead; take a look at [Creating a Symbolic Macro](../macro-tutorial).
 
 Imagine that you need to run a tool as part of your build. For example, you
 may want to generate or preprocess a source file, or compress a binary. In this
diff --git a/versions/8.1.1/rules/verbs-tutorial.mdx b/versions/8.1.1/rules/verbs-tutorial.mdx
index 8ef4d284..1efbee8c 100644
--- a/versions/8.1.1/rules/verbs-tutorial.mdx
+++ b/versions/8.1.1/rules/verbs-tutorial.mdx
@@ -49,8 +49,7 @@ This pattern can also be seen in the Angular project. The
 produces two targets. The first is a standard `nodejs_test` target which compares
 some generated output against a "golden" file (that is, a file containing the
 expected output). This can be built and run with a normal `bazel
-test` invocation. In `angular-cli`, you can run [one such
-target](https://github.com/angular/angular-cli/blob/e1269cb520871ee29b1a4eec6e6c0e4a94f0b5fc/etc/api/BUILD)
+test` invocation. In `angular-cli`, you can run [one such target](https://github.com/angular/angular-cli/blob/e1269cb520871ee29b1a4eec6e6c0e4a94f0b5fc/etc/api/BUILD)
 with `bazel test //etc/api:angular_devkit_core_api`.
 
 Over time, this golden file may need to be updated for legitimate reasons.
diff --git a/versions/8.1.1/run/build.mdx b/versions/8.1.1/run/build.mdx
index 2b06f1aa..ba447022 100644
--- a/versions/8.1.1/run/build.mdx
+++ b/versions/8.1.1/run/build.mdx
@@ -626,8 +626,7 @@ Note: Hermeticity means that the action only uses its declared input
 files and no other files in the filesystem, and it only produces its declared
 output files. See [Hermeticity](/versions/8.1.1/basics/hermeticity) for more details.
 
-On some platforms such as [Google Kubernetes
-Engine](https://cloud.google.com/kubernetes-engine/) cluster nodes or Debian,
+On some platforms such as [Google Kubernetes Engine](https://cloud.google.com/kubernetes-engine/) cluster nodes or Debian,
 user namespaces are deactivated by default due to security
 concerns. This can be checked by looking at the file
 `/proc/sys/kernel/unprivileged_userns_clone`: if it exists and contains a 0,
diff --git a/versions/8.1.1/start/android-app.mdx b/versions/8.1.1/start/android-app.mdx
index 9dec18c9..b8dc8ae8 100644
--- a/versions/8.1.1/start/android-app.mdx
+++ b/versions/8.1.1/start/android-app.mdx
@@ -36,8 +36,7 @@ In this tutorial you learn how to:
 Before you begin the tutorial, install the following software:
 
 * **Bazel.** To install, follow the [installation instructions](/versions/8.1.1/install).
-* **Android Studio.** To install, follow the steps to [download Android
-  Studio](https://developer.android.com/sdk/index.html).
+* **Android Studio.** To install, follow the steps to [download Android Studio](https://developer.android.com/sdk/index.html).
   Execute the setup wizard to download the SDK and configure your environment.
 * (Optional) **Git.** Use `git` to download the Android app project.
 
@@ -52,8 +51,7 @@ This app has a single button that prints a greeting when clicked:
 
 **Figure 1.** Android app button greeting.
 
-Clone the repository with `git` (or [download the ZIP file
-directly](https://github.com/bazelbuild/examples/archive/master.zip)):
+Clone the repository with `git` (or [download the ZIP file directly](https://github.com/bazelbuild/examples/archive/master.zip)):
 
 ```posix-terminal
 git clone https://github.com/bazelbuild/examples
@@ -103,8 +101,7 @@ A [workspace](/versions/8.1.1/concepts/build-ref#workspace) is a directory that
 source files for one or more software projects, and has a `MODULE.bazel` file at
 its root.
 
-The `MODULE.bazel` file may be empty or may contain references to [external
-dependencies](/versions/8.1.1/external/overview) required to build your project.
+The `MODULE.bazel` file may be empty or may contain references to [external dependencies](/versions/8.1.1/external/overview) required to build your project.
 
 First, run the following command to create an empty `MODULE.bazel` file:
 
@@ -147,8 +144,7 @@ environment variable, and automatically detect the highest API level and the
 latest version of build tools installed within that location.
 
 You can set the `ANDROID_HOME` variable to the location of the Android SDK. Find
-the path to the installed SDK using Android Studio's [SDK
-Manager](https://developer.android.com/studio/intro/update#sdk-manager).
+the path to the installed SDK using Android Studio's [SDK Manager](https://developer.android.com/studio/intro/update#sdk-manager).
 Assuming the SDK is installed to default locations, you can use the following
 commands to set the `ANDROID_HOME` variable:
 
@@ -170,16 +166,14 @@ them permanent, run the following commands:
 | Windows (PowerShell)     | `[System.Environment]::SetEnvironmentVariable('ANDROID_HOME', "$env:LOCALAPPDATA\Android\Sdk", [System.EnvironmentVariableTarget]::User)` |
 
 **Optional:** If you want to compile native code into your Android app, you
-also need to download the [Android
-NDK](https://developer.android.com/ndk/downloads/index.html)
+also need to download the [Android NDK](https://developer.android.com/ndk/downloads/index.html)
 and use `rules_android_ndk` by adding the following line to your `MODULE.bazel` file:
 
 ```python
 bazel_dep(name = "rules_android_ndk", version = "0.1.2")
 ```
 
-For more information, read [Using the Android Native Development Kit with
-Bazel](/versions/8.1.1/docs/android-ndk).
+For more information, read [Using the Android Native Development Kit with Bazel](/versions/8.1.1/docs/android-ndk).
 
 It's not necessary to set the API levels to the same value for the SDK and NDK.
 [This page](https://developer.android.com/ndk/guides/stable_apis.html)
@@ -221,8 +215,7 @@ files or other dependencies. Bazel provides two build rules,
 build an Android app.
 
 For this tutorial, you'll first use the
-`android_library` rule to tell Bazel to build an [Android library
-module](http://developer.android.com/tools/projects/index.html#LibraryProjects)
+`android_library` rule to tell Bazel to build an [Android library module](http://developer.android.com/tools/projects/index.html#LibraryProjects)
 from the app source code and resource files. You'll then use the
 `android_binary` rule to tell Bazel how to build the Android application package.
 
@@ -337,11 +330,9 @@ file:
 ### Run the app
 
 You can now deploy the app to a connected Android device or emulator from the
-command line using the [`bazel
-mobile-install`](/versions/8.1.1/docs/user-manual#mobile-install) command. This command uses
+command line using the [`bazel mobile-install`](/versions/8.1.1/docs/user-manual#mobile-install) command. This command uses
 the Android Debug Bridge (`adb`) to communicate with the device. You must set up
-your device to use `adb` following the instructions in [Android Debug
-Bridge](http://developer.android.com/tools/help/adb.html) before deployment. You
+your device to use `adb` following the instructions in [Android Debug Bridge](http://developer.android.com/tools/help/adb.html) before deployment. You
 can also choose to install the app on the Android emulator included in Android
 Studio. Make sure the emulator is running before executing the command below.
 
diff --git a/versions/8.1.1/start/cpp.mdx b/versions/8.1.1/start/cpp.mdx
index 5fefdd35..400fd077 100644
--- a/versions/8.1.1/start/cpp.mdx
+++ b/versions/8.1.1/start/cpp.mdx
@@ -19,8 +19,7 @@ Estimated completion time: 30 minutes.
 ### Prerequisites {#prerequisites}
 
 Start by [installing Bazel](https://bazel.build/versions/8.1.1/install), if you haven't
-already. This tutorial uses Git for source control, so for best results [install
-Git](https://git-scm.com/book/en/v2/Getting-Started-Installing-Git) as well.
+already. This tutorial uses Git for source control, so for best results [install Git](https://git-scm.com/book/en/v2/Getting-Started-Installing-Git) as well.
 
 Next, retrieve the sample project from Bazel's GitHub repository by running the
 following in your command-line tool of choice:
@@ -63,9 +62,7 @@ examples
 ```
 
 There are three sets of files, each set representing a stage in this tutorial.
-In the first stage, you will build a single [target]
-(https://bazel.build/reference/glossary#target) residing in a single [package]
-(https://bazel.build/reference/glossary#package). In the second stage, you will
+In the first stage, you will build a single [target](https://bazel.build/reference/glossary#target) residing in a single [package](https://bazel.build/reference/glossary#package). In the second stage, you will
 build both a binary and a library from a single package. In the third and final
 stage, you will build a project with multiple packages and build it with
 multiple targets.
@@ -86,8 +83,7 @@ It also contains these significant files:
 *   The `MODULE.bazel` file, which identifies the directory and its contents as
     a Bazel workspace and lives at the root of the project's directory
     structure. It's also where you specify your external dependencies.
-*   One or more [`BUILD`
-    files](https://bazel.build/reference/glossary#build-file), which tell Bazel
+*   One or more [`BUILD` files](https://bazel.build/reference/glossary#build-file), which tell Bazel
     how to build different parts of the project. A directory within the
     workspace that contains a `BUILD` file is a
     [package](https://bazel.build/versions/8.1.1/reference/glossary#package). (More on packages
@@ -182,9 +178,7 @@ This results in a printed "`Hello world`" message.
 
 Here's the dependency graph of Stage 1:
 
-![Dependency graph for hello-world displays a single target with a single source
-file.](/versions/8.1.1/docs/images/cpp-tutorial-stage1.png "Dependency graph for hello-world
-displays a single target with a single source file.")
+![Dependency graph for hello-world displays a single target with a single source file.](/versions/8.1.1/docs/images/cpp-tutorial-stage1.png "Dependency graph for hello-world displays a single target with a single source file.")
 
 ### Summary: stage 1 {#summary-stage-1}
 
@@ -231,8 +225,7 @@ cc_binary(
 ```
 
 With this `BUILD` file, Bazel first builds the `hello-greet` library (using
-Bazel's built-in [`cc_library`
-rule](https://bazel.build/reference/be/c-cpp#cc_library)), then the
+Bazel's built-in [`cc_library` rule](https://bazel.build/reference/be/c-cpp#cc_library)), then the
 `hello-world` binary. The `deps` attribute in the `hello-world` target tells
 Bazel that the `hello-greet` library is required to build the `hello-world`
 binary.
@@ -272,10 +265,7 @@ recompiles that file.
 Looking at the dependency graph, you can see that `hello-world` depends on an
 extra input named `hello-greet`:
 
-![Dependency graph for `hello-world` displays dependency changes after
-modification to the file.](/versions/8.1.1/docs/images/cpp-tutorial-stage2.png "Dependency
-graph for `hello-world` displays dependency changes after modification to the
-file.")
+![Dependency graph for `hello-world` displays dependency changes after modification to the file.](/versions/8.1.1/docs/images/cpp-tutorial-stage2.png "Dependency graph for `hello-world` displays dependency changes after modification to the file.")
 
 ### Summary: stage 2 {#summary-stage-2}
 
@@ -343,11 +333,7 @@ in the `lib` package (hence the target label `//lib:hello-time`) - Bazel knows
 this through the `deps` attribute. You can see this reflected in the dependency
 graph:
 
-![Dependency graph for `hello-world` displays how the target in the main package
-depends on the target in the `lib`
-package.](/versions/8.1.1/docs/images/cpp-tutorial-stage3.png "Dependency graph for
-`hello-world` displays how the target in the main package depends on the target
-in the `lib` package.")
+![Dependency graph for `hello-world` displays how the target in the main package depends on the target in the `lib` package.](/versions/8.1.1/docs/images/cpp-tutorial-stage3.png "Dependency graph for `hello-world` displays how the target in the main package depends on the target in the `lib` package.")
 
 For the build to succeed, you make the `//lib:hello-time` target in `lib/BUILD`
 explicitly visible to targets in `main/BUILD` using the visibility attribute.
@@ -395,15 +381,11 @@ Bazel journey.
 You've now completed your first basic build with Bazel, but this is just the
 start. Here are some more resources to continue learning with Bazel:
 
-*   To keep focusing on C++, read about common [C++ build use
-    cases](https://bazel.build/tutorials/cpp-use-cases).
+*   To keep focusing on C++, read about common [C++ build use cases](https://bazel.build/tutorials/cpp-use-cases).
 *   To get started with building other applications with Bazel, see the
-    tutorials for [Java](https://bazel.build/versions/8.1.1/start/java), [Android
-    application](https://bazel.build/start/android-app), or [iOS
-    application](https://bazel.build/start/ios-app).
+    tutorials for [Java](https://bazel.build/versions/8.1.1/start/java), [Android application](https://bazel.build/start/android-app), or [iOS application](https://bazel.build/start/ios-app).
 *   To learn more about working with local and remote repositories, read about
     [external dependencies](https://bazel.build/versions/8.1.1/docs/external).
-*   To learn more about Bazel's other rules, see this [reference
-    guide](https://bazel.build/rules).
+*   To learn more about Bazel's other rules, see this [reference guide](https://bazel.build/rules).
 
 Happy building!
\ No newline at end of file
diff --git a/versions/8.1.1/start/java.mdx b/versions/8.1.1/start/java.mdx
index 7571a904..47cdcbad 100644
--- a/versions/8.1.1/start/java.mdx
+++ b/versions/8.1.1/start/java.mdx
@@ -241,8 +241,7 @@ recompiles that file.
 Looking at the dependency graph, you can see that `ProjectRunner` depends on the
 same inputs as it did before, but the structure of the build is different:
 
-![Dependency graph of the target 'ProjectRunner' after adding a dependency](
-/docs/images/tutorial_java_02.svg)
+![Dependency graph of the target 'ProjectRunner' after adding a dependency](/docs/images/tutorial_java_02.svg)
 
 You've now built the project with two targets. The `ProjectRunner` target builds
 one source files and depends on one other target (`:greeter`), which builds
diff --git a/versions/8.1.1/tutorials/ccp-toolchain-config.mdx b/versions/8.1.1/tutorials/ccp-toolchain-config.mdx
index e194c28e..cf16a9e9 100644
--- a/versions/8.1.1/tutorials/ccp-toolchain-config.mdx
+++ b/versions/8.1.1/tutorials/ccp-toolchain-config.mdx
@@ -29,8 +29,7 @@ uses `clang version 16`, which you can install on your system.
 
 Set up your build environment as follows:
 
-1.  If you have not already done so, [download and install Bazel
-    7.0.2](https://bazel.build/install) or later.
+1.  If you have not already done so, [download and install Bazel 7.0.2](https://bazel.build/install) or later.
 
 2.  Add an empty `MODULE.bazel` file at the root folder.
 
@@ -450,8 +449,7 @@ The key takeaways are:
 
 -   You need to specify a matching `platforms` flag in the command line for
     Bazel to resolve to the toolchain for the same constraint values on the
-    platform. The documentation holds more [information about language specific
-    configuration flags](/versions/8.1.1/concepts/platforms).
+    platform. The documentation holds more [information about language specific configuration flags](/versions/8.1.1/concepts/platforms).
 -   You have to let the toolchain know where the tools live. In this tutorial
     there is a simplified version where you access the tools from the system. If
     you are interested in a more self-contained approach, you can read about
@@ -464,5 +462,4 @@ The key takeaways are:
 
 ## Further reading {#further-reading}
 
-For more details, see [C++ toolchain
-configuration](/versions/8.1.1/docs/cc-toolchain-config-reference)
\ No newline at end of file
+For more details, see [C++ toolchain configuration](/versions/8.1.1/docs/cc-toolchain-config-reference)
\ No newline at end of file
diff --git a/versions/8.2.1/about/roadmap.mdx b/versions/8.2.1/about/roadmap.mdx
index e9ddad48..37fb5192 100644
--- a/versions/8.2.1/about/roadmap.mdx
+++ b/versions/8.2.1/about/roadmap.mdx
@@ -13,8 +13,7 @@ projects.
 
 ## Bazel 8.0 Release
 
-We plan to bring Bazel 8.0 [long term support
-(LTS)](https://bazel.build/release/versioning) to you in late 2024.
+We plan to bring Bazel 8.0 [long term support (LTS)](https://bazel.build/release/versioning) to you in late 2024.
 The following features are planned to be implemented.
 
 ### Bzlmod: external dependency management system
@@ -29,8 +28,7 @@ support will be removed. Starting with Bazel 7.1, you can set
 `--noenable_workspace` to opt into the new behavior.
 
 Bazel 8.0 will contain a number of enhancements to
-[Bazel's external dependency management]
-(https://docs.google.com/document/d/1moQfNcEIttsk6vYanNKIy3ZuK53hQUFq1b1r0rmsYVg/edit#heading=h.lgyp7ubwxmjc)
+[Bazel's external dependency management](https://docs.google.com/document/d/1moQfNcEIttsk6vYanNKIy3ZuK53hQUFq1b1r0rmsYVg/edit#heading=h.lgyp7ubwxmjc)
 functionality, including:
 
 *   The new flag `--enable_workspace` can be set to `false` to completely
diff --git a/versions/8.2.1/basics/dependencies.mdx b/versions/8.2.1/basics/dependencies.mdx
index 81851301..9fc1ff43 100644
--- a/versions/8.2.1/basics/dependencies.mdx
+++ b/versions/8.2.1/basics/dependencies.mdx
@@ -65,8 +65,7 @@ targets, we’ve made some strides in mitigating the downside by investing in
 tooling to automatically manage `BUILD` files to avoid burdening developers.
 
 Some of these tools, such as `buildifier` and `buildozer`, are available with
-Bazel in the [`buildtools`
-directory](https://github.com/bazelbuild/buildtools).
+Bazel in the [`buildtools` directory](https://github.com/bazelbuild/buildtools).
 
 ## Minimizing Module Visibility
 
@@ -106,8 +105,7 @@ transitive dependencies (Figure 1). Suppose target A depends on target B, which
 depends on a common library target C. Should target A be able to use classes
 defined in target C?
 
-[![Transitive
-dependencies](/versions/8.2.1/images/transitive-dependencies.png)](/versions/8.2.1/images/transitive-dependencies.png)
+[![Transitive dependencies](/versions/8.2.1/images/transitive-dependencies.png)](/versions/8.2.1/images/transitive-dependencies.png)
 
 **Figure 1**. Transitive dependencies
 
@@ -141,9 +139,7 @@ dependencies and adding them to a `BUILD` files without any developer
 intervention. But even without such tools, we’ve found the trade-off to be well
 worth it as the codebase scales: explicitly adding a dependency to `BUILD` file
 is a one-time cost, but dealing with implicit transitive dependencies can cause
-ongoing problems as long as the build target exists. Bazel [enforces strict
-transitive
-dependencies](https://blog.bazel.build/2017/06/28/sjd-unused_deps.html)
+ongoing problems as long as the build target exists. Bazel [enforces strict transitive dependencies](https://blog.bazel.build/2017/06/28/sjd-unused_deps.html)
 on Java code by default.
 
 ### External dependencies
@@ -192,8 +188,7 @@ so in theory there’s no reason that different versions of the same external
 dependency couldn’t both be declared in the build system under different names.
 That way, each target could choose which version of the dependency it wanted to
 use. This causes a lot of problems in practice, so Google enforces a strict
-[One-Version
-Rule](https://opensource.google/docs/thirdparty/oneversion/) for
+[One-Version Rule](https://opensource.google/docs/thirdparty/oneversion/) for
 all third-party dependencies in our codebase.
 
 The biggest problem with allowing multiple versions is the diamond dependency
@@ -232,8 +227,7 @@ Bazel did not use to automatically download transitive dependencies. It used to
 employ a `WORKSPACE` file that required all transitive dependencies to be
 listed, which led to a lot of pain when managing external dependencies. Bazel
 has since added support for automatic transitive external dependency management
-in the form of the `MODULE.bazel` file. See [external dependency
-overview](/versions/8.2.1/external/overview) for more details.
+in the form of the `MODULE.bazel` file. See [external dependency overview](/versions/8.2.1/external/overview) for more details.
 
 Yet again, the choice here is one between convenience and scalability. Small
 projects might prefer not having to worry about managing transitive dependencies
diff --git a/versions/8.2.1/community/roadmaps-configurability.mdx b/versions/8.2.1/community/roadmaps-configurability.mdx
index c1f7eda2..4d1ae46d 100644
--- a/versions/8.2.1/community/roadmaps-configurability.mdx
+++ b/versions/8.2.1/community/roadmaps-configurability.mdx
@@ -26,8 +26,7 @@ title: 'Bazel Configurability 2021 Roadmap'
 * Builds scale well, particularly w.r.t graph size and action caching.
 
 We also support
-[`cquery`](https://bazel.build/versions/8.2.1/query/cquery), [`Starlark
-configuration`](https://bazel.build/extending/config),
+[`cquery`](https://bazel.build/versions/8.2.1/query/cquery), [`Starlark configuration`](https://bazel.build/extending/config),
 and
 [`select()`](https://bazel.build/versions/8.2.1/docs/configurable-attributes).
 
@@ -41,15 +40,13 @@ interest of accurate expectations.
 ### Platforms
 
 

-Q3 2021**Android rules use the new [platforms
-API](https://bazel.build/concepts/platforms)**
+Q3 2021**Android rules use the new [platforms API](https://bazel.build/concepts/platforms)**
 IN PROGRESS ([#11749](https://github.com/bazelbuild/bazel/issues/11749))
 
 * This is our main priority for the beginning of 2021.
 
 

-Q3 2021**Builds support [multiple execution
-platforms](https://docs.google.com/document/d/1U9HzdDmtRnm244CaRM6JV-q2408mbNODAMewcGjnnbM/)**
+Q3 2021**Builds support [multiple execution platforms](https://docs.google.com/document/d/1U9HzdDmtRnm244CaRM6JV-q2408mbNODAMewcGjnnbM/)**
 IN PROGRESS ([#11748](https://github.com/bazelbuild/bazel/issues/11748))
 
 

diff --git a/versions/8.2.1/community/sig.mdx b/versions/8.2.1/community/sig.mdx
index 2cbf4dac..4224ff27 100644
--- a/versions/8.2.1/community/sig.mdx
+++ b/versions/8.2.1/community/sig.mdx
@@ -3,8 +3,7 @@ title: 'Bazel Special Interest Groups'
 ---
 
 Bazel hosts Special Interest Groups (SIGs) to focus collaboration on particular
-areas and to support communication and coordination between [Bazel owners,
-maintainers, and contributors](/versions/8.2.1/contribute/policy). This policy
+areas and to support communication and coordination between [Bazel owners, maintainers, and contributors](/versions/8.2.1/contribute/policy). This policy
 applies to [`bazelbuild`](http://github.com/bazelbuild).
 
 SIGs do their work in public. The ideal scope for a SIG covers a well-defined
diff --git a/versions/8.2.1/community/users.mdx b/versions/8.2.1/community/users.mdx
index 3333968e..561de990 100644
--- a/versions/8.2.1/community/users.mdx
+++ b/versions/8.2.1/community/users.mdx
@@ -304,11 +304,9 @@ safety systems_.
 Pigweed is an open-source solution for sustained, robust, and rapid embedded
 product development for large teams. Pigweed has shipped in millions of
 devices, including Google's suite of Pixel devices, Nest thermostats,
-[satellites](https://www.spinlaunch.com/), and [autonomous aerial
-drones](https://www.flyzipline.com/).
+[satellites](https://www.spinlaunch.com/), and [autonomous aerial drones](https://www.flyzipline.com/).
 
-Pigweed [uses Bazel as its primary build
-system](https://pigweed.dev/seed/0111-build-systems.html). The [Bazel for
+Pigweed [uses Bazel as its primary build system](https://pigweed.dev/seed/0111-build-systems.html). The [Bazel for
 Embedded][pw-bazel-great] blog post discusses why we think it's a great build
 system for embedded projects!
 
diff --git a/versions/8.2.1/concepts/build-files.mdx b/versions/8.2.1/concepts/build-files.mdx
index b315f07b..3fbbba98 100644
--- a/versions/8.2.1/concepts/build-files.mdx
+++ b/versions/8.2.1/concepts/build-files.mdx
@@ -132,20 +132,3 @@ for anyone to create new rules.
     programming language. Libraries can depend on other libraries,
     and binaries and tests can depend on libraries, with the expected
     separate-compilation behavior.
-
-
-  
-    
-    
-  
-

-      
-        Labels
-      
-    
-      
-        Dependencies
-      
-    

diff --git a/versions/8.2.1/concepts/build-ref.mdx b/versions/8.2.1/concepts/build-ref.mdx
index 9d2783cf..6ba3b306 100644
--- a/versions/8.2.1/concepts/build-ref.mdx
+++ b/versions/8.2.1/concepts/build-ref.mdx
@@ -17,8 +17,7 @@ its root; such a boundary marker file could be `MODULE.bazel`, `REPO.bazel`, or
 in legacy contexts, `WORKSPACE` or `WORKSPACE.bazel`.
 
 The repo in which the current Bazel command is being run is called the _main
-repo_. Other, (external) repos are defined by _repo rules_; see [external
-dependencies overview](/versions/8.2.1/external/overview) for more information.
+repo_. Other, (external) repos are defined by _repo rules_; see [external dependencies overview](/versions/8.2.1/external/overview) for more information.
 
 ## Workspace {#workspace}
 
@@ -95,9 +94,4 @@ have three properties: the list of packages they contain, their name, and other
 package groups they include. The only allowed ways to refer to them are from the
 `visibility` attribute of rules or from the `default_visibility` attribute of
 the `package` function; they do not generate or consume files. For more
-information, refer to the [`package_group`
-documentation](/versions/8.2.1/reference/be/functions#package_group).
-
-
-  Labels
-
\ No newline at end of file
+information, refer to the [`package_group` documentation](/versions/8.2.1/reference/be/functions#package_group).
diff --git a/versions/8.2.1/concepts/dependencies.mdx b/versions/8.2.1/concepts/dependencies.mdx
index 9e326a7a..c74b28b1 100644
--- a/versions/8.2.1/concepts/dependencies.mdx
+++ b/versions/8.2.1/concepts/dependencies.mdx
@@ -352,21 +352,3 @@ filegroup(
 ```
 
 You can then reference the label `my_data` as the data dependency in your test.
-
-
-  
-    
-    
-  
-

-      
-        BUILD files
-      
-    
-      
-        Visibility
-      
-    

-
diff --git a/versions/8.2.1/concepts/labels.mdx b/versions/8.2.1/concepts/labels.mdx
index cc5e4da0..14daada5 100644
--- a/versions/8.2.1/concepts/labels.mdx
+++ b/versions/8.2.1/concepts/labels.mdx
@@ -10,8 +10,7 @@ form looks like:
 ```
 
 The first part of the label is the repository name, `@@myrepo`. The double-`@`
-syntax signifies that this is a [*canonical* repo
-name](/versions/8.2.1/external/overview#canonical-repo-name), which is unique within
+syntax signifies that this is a [*canonical* repo name](/versions/8.2.1/external/overview#canonical-repo-name), which is unique within
 the workspace. Labels with canonical repo names unambiguously identify a target
 no matter which context they appear in.
 
@@ -243,20 +242,3 @@ the build.
 This directed acyclic graph over targets is called the _target graph_ or
 _build dependency graph_, and is the domain over which the
 [Bazel Query tool](/versions/8.2.1/query/guide) operates.
-
-
-  
-    
-    
-  
-

-      
-        Targets
-      
-    
-      
-        BUILD files
-      
-    

diff --git a/versions/8.2.1/concepts/platforms.mdx b/versions/8.2.1/concepts/platforms.mdx
index a69fa60b..10dff937 100644
--- a/versions/8.2.1/concepts/platforms.mdx
+++ b/versions/8.2.1/concepts/platforms.mdx
@@ -77,8 +77,7 @@ To test your Android project with platforms, see
 for support.
 
 You can still use platform APIs with Apple builds (for example, when building
-with a mixture of Apple rules and pure C++) with [platform
-mappings](#platform-mappings).
+with a mixture of Apple rules and pure C++) with [platform mappings](#platform-mappings).
 
 ### Other languages {#other-languages}
 
@@ -241,8 +240,7 @@ sets `--cpu`, `--crossstool_top`, or other legacy flags, rules that read
 
 When migrating your project to platforms, you must either convert changes like
 `return { "//command_line_option:cpu": "arm" }` to `return {
-"//command_line_option:platforms": "//:my_arm_platform" }` or use [platform
-mappings](#platform-mappings) to support both styles during migration.
+"//command_line_option:platforms": "//:my_arm_platform" }` or use [platform mappings](#platform-mappings) to support both styles during migration.
 window.
 
 ## Migrating your rule set {#migrating-your-rule-set}
@@ -361,10 +359,8 @@ attributes declare a language's tools (like `compiler =
 this information to rules that need to build with these tools.
 
 Toolchains declare the `constraint_value`s of machines they can
-[target][target_compatible_with Attribute]
-(`target_compatible_with = ["@platforms//os:linux"]`) and machines their tools can
-[run on][exec_compatible_with Attribute]
-(`exec_compatible_with = ["@platforms//os:mac"]`).
+[target][target_compatible_with Attribute](`target_compatible_with = ["@platforms//os:linux"]`) and machines their tools can
+[run on][exec_compatible_with Attribute](`exec_compatible_with = ["@platforms//os:mac"]`).
 
 When building `$ bazel build //:myproject --platforms=//:myplatform`, Bazel
 automatically selects a toolchain that can run on the build machine and
diff --git a/versions/8.2.1/configure/attributes.mdx b/versions/8.2.1/configure/attributes.mdx
index a291aeb2..51cb3540 100644
--- a/versions/8.2.1/configure/attributes.mdx
+++ b/versions/8.2.1/configure/attributes.mdx
@@ -2,8 +2,7 @@
 title: 'Configurable Build Attributes'
 ---
 
-**_Configurable attributes_**, commonly known as [`select()`](
-/reference/be/functions#select), is a Bazel feature that lets users toggle the values
+**_Configurable attributes_**, commonly known as [`select()`](/reference/be/functions#select), is a Bazel feature that lets users toggle the values
 of build rule attributes at the command line.
 
 This can be used, for example, for a multiplatform library that automatically
@@ -407,8 +406,7 @@ sh_library(
 )
 ```
 
-If you need a `select` to match when multiple conditions match, consider [AND
-chaining](#and-chaining).
+If you need a `select` to match when multiple conditions match, consider [AND chaining](#and-chaining).
 
 ## OR chaining {#or-chaining}
 
diff --git a/versions/8.2.1/configure/integrate-cpp.mdx b/versions/8.2.1/configure/integrate-cpp.mdx
index f2ece735..f71d7d24 100644
--- a/versions/8.2.1/configure/integrate-cpp.mdx
+++ b/versions/8.2.1/configure/integrate-cpp.mdx
@@ -33,8 +33,7 @@ This is because when writing our own actions, they must behave
 consistently with the C++ toolchain - for example, passing C++ command line
 flags to a tool that invokes the C++ compiler behind the scenes.
 
-C++ rules use a special way of constructing command lines based on [feature
-configuration](/versions/8.2.1/docs/cc-toolchain-config-reference). To construct a command line,
+C++ rules use a special way of constructing command lines based on [feature configuration](/versions/8.2.1/docs/cc-toolchain-config-reference). To construct a command line,
 you need the following:
 
 * `features` and `action_configs` - these come from the `CcToolchainConfigInfo`
diff --git a/versions/8.2.1/configure/windows.mdx b/versions/8.2.1/configure/windows.mdx
index c3261084..0557ba1f 100644
--- a/versions/8.2.1/configure/windows.mdx
+++ b/versions/8.2.1/configure/windows.mdx
@@ -166,8 +166,7 @@ To build C++ targets with MSVC, you need:
         set BAZEL_VC=C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC
         ```
 
-*   The [Windows
-    SDK](https://developer.microsoft.com/en-us/windows/downloads/windows-10-sdk).
+*   The [Windows SDK](https://developer.microsoft.com/en-us/windows/downloads/windows-10-sdk).
 
     The Windows SDK contains header files and libraries you need when building
     Windows applications, including Bazel itself. By default, the latest Windows SDK installed will
@@ -186,8 +185,7 @@ To build C++ targets with MSVC, you need:
 
 If everything is set up, you can build a C++ target now!
 
-Try building a target from one of our [sample
-projects](https://github.com/bazelbuild/bazel/tree/master/examples):
+Try building a target from one of our [sample projects](https://github.com/bazelbuild/bazel/tree/master/examples):
 
 ```posix-terminal
 C:\projects\bazel> bazel build //examples/cpp:hello-world
@@ -209,8 +207,7 @@ For example, to build targets for ARM architecture, run:
 C:\projects\bazel> bazel build //examples/cpp:hello-world --cpu=x64_arm_windows
 ```
 
-To build and use Dynamically Linked Libraries (DLL files), see [this
-example](https://github.com/bazelbuild/bazel/tree/master/examples/windows/dll).
+To build and use Dynamically Linked Libraries (DLL files), see [this example](https://github.com/bazelbuild/bazel/tree/master/examples/windows/dll).
 
 **Command Line Length Limit**: To prevent the
 [Windows command line length limit issue](https://github.com/bazelbuild/bazel/issues/5163),
@@ -289,8 +286,7 @@ On Windows, Bazel builds two output files for `java_binary` rules:
 *   a `.jar` file
 *   a `.exe` file that can set up the environment for the JVM and run the binary
 
-Try building a target from one of our [sample
-projects](https://github.com/bazelbuild/bazel/tree/master/examples):
+Try building a target from one of our [sample projects](https://github.com/bazelbuild/bazel/tree/master/examples):
 
 ```posix-terminal
 C:\projects\bazel> bazel build //examples/java-native/src/main/java/com/example/myproject:hello-world
@@ -312,8 +308,7 @@ On Windows, Bazel builds two output files for `py_binary` rules:
 You can either run the executable file (it has a `.exe` extension) or you can run
 Python with the self-extracting zip file as the argument.
 
-Try building a target from one of our [sample
-projects](https://github.com/bazelbuild/bazel/tree/master/examples):
+Try building a target from one of our [sample projects](https://github.com/bazelbuild/bazel/tree/master/examples):
 
 ```posix-terminal
 C:\projects\bazel> bazel build //examples/py_native:bin
@@ -322,5 +317,4 @@ C:\projects\bazel> python bazel-bin\examples\py_native\bin.zip
 ```
 
 If you are interested in details about how Bazel builds Python targets on
-Windows, check out this [design
-doc](https://github.com/bazelbuild/bazel-website/blob/master/designs/_posts/2016-09-05-build-python-on-windows.md).
+Windows, check out this [design doc](https://github.com/bazelbuild/bazel-website/blob/master/designs/_posts/2016-09-05-build-python-on-windows.md).
diff --git a/versions/8.2.1/contribute/codebase.mdx b/versions/8.2.1/contribute/codebase.mdx
index 3138dcf7..7a4770f1 100644
--- a/versions/8.2.1/contribute/codebase.mdx
+++ b/versions/8.2.1/contribute/codebase.mdx
@@ -227,8 +227,7 @@ repository", the others are called "external repositories".
 A repository is marked by a repo boundary file (`MODULE.bazel`, `REPO.bazel`, or
 in legacy contexts, `WORKSPACE` or `WORKSPACE.bazel`) in its root directory. The
 main repo is the source tree where you're invoking Bazel from. External repos
-are defined in various ways; see [external dependencies
-overview](/versions/8.2.1/external/overview) for more information.
+are defined in various ways; see [external dependencies overview](/versions/8.2.1/external/overview) for more information.
 
 Code of external repositories is symlinked or downloaded under
 `$OUTPUT_BASE/external`.
diff --git a/versions/8.2.1/contribute/design-documents.mdx b/versions/8.2.1/contribute/design-documents.mdx
index 994983f5..10d7f62d 100644
--- a/versions/8.2.1/contribute/design-documents.mdx
+++ b/versions/8.2.1/contribute/design-documents.mdx
@@ -137,8 +137,7 @@ A lead reviewer should be a domain expert who is:
 *   Objective and capable of providing constructive feedback
 *   Available for the entire review period to lead the process
 
-Consider checking the contacts for various [team
-labels](/versions/8.2.1/contribute/maintainers-guide#team-labels).
+Consider checking the contacts for various [team labels](/versions/8.2.1/contribute/maintainers-guide#team-labels).
 
 ## Markdown vs Google Docs {#markdown-versus-gdocs}
 
@@ -168,12 +167,10 @@ Markdown for posterity.
 
 ### Using Google Docs {#gdocs}
 
-For consistency, use the [Bazel design doc template](
-https://docs.google.com/document/d/1cE5zrjrR40RXNg64XtRFewSv6FrLV6slGkkqxBumS1w/edit).
+For consistency, use the [Bazel design doc template](https://docs.google.com/document/d/1cE5zrjrR40RXNg64XtRFewSv6FrLV6slGkkqxBumS1w/edit).
 It includes the necessary header and creates visual
 consistency with other Bazel related documents. To do that, click on **File** >
-**Make a copy** or click this link to [make a copy of the design doc
-template](https://docs.google.com/document/d/1cE5zrjrR40RXNg64XtRFewSv6FrLV6slGkkqxBumS1w/copy).
+**Make a copy** or click this link to [make a copy of the design doc template](https://docs.google.com/document/d/1cE5zrjrR40RXNg64XtRFewSv6FrLV6slGkkqxBumS1w/copy).
 
 To make your document readable to the world, click on
 **Share** > **Advanced** > **Change…**, and
diff --git a/versions/8.2.1/contribute/index.mdx b/versions/8.2.1/contribute/index.mdx
index f1b70520..e1f8ca6f 100644
--- a/versions/8.2.1/contribute/index.mdx
+++ b/versions/8.2.1/contribute/index.mdx
@@ -10,8 +10,7 @@ As you use Bazel, you may find things that can be improved.
 You can help by [reporting issues](http://github.com/bazelbuild/bazel/issues)
 when:
 
-   - Bazel crashes or you encounter a bug that can [only be resolved using `bazel
-     clean`](/versions/8.2.1/run/build#correct-incremental-rebuilds).
+   - Bazel crashes or you encounter a bug that can [only be resolved using `bazel clean`](/versions/8.2.1/run/build#correct-incremental-rebuilds).
    - The documentation is incomplete or unclear. You can also report issues
      from the page you are viewing by using the "Create issue"
      link at the top right corner of the page.
@@ -21,11 +20,9 @@ when:
 
 You can engage with the Bazel community by:
 
-   - Answering questions [on Stack Overflow](
-     https://stackoverflow.com/questions/tagged/bazel).
+   - Answering questions [on Stack Overflow](https://stackoverflow.com/questions/tagged/bazel).
    - Helping other users [on Slack](https://slack.bazel.build).
-   - Improving documentation or [contributing examples](
-     https://github.com/bazelbuild/examples).
+   - Improving documentation or [contributing examples](https://github.com/bazelbuild/examples).
    - Sharing your experience or your tips, for example, on a blog or social media.
 
 ## Contribute code {#contribute-code}
@@ -40,8 +37,7 @@ You can contribute to the Bazel ecosystem by:
    - Contributing to Bazel-related tools, for example, migration tools.
    - Improving Bazel integration with other IDEs and tools.
 
-Before making a change, [create a GitHub
-issue](http://github.com/bazelbuild/bazel/issues)
+Before making a change, [create a GitHub issue](http://github.com/bazelbuild/bazel/issues)
 or email [bazel-discuss@](mailto:bazel-discuss@googlegroups.com).
 
 The most helpful contributions fix bugs or add features (as opposed
diff --git a/versions/8.2.1/contribute/maintainers-guide.mdx b/versions/8.2.1/contribute/maintainers-guide.mdx
index 73598706..fd5d5a29 100644
--- a/versions/8.2.1/contribute/maintainers-guide.mdx
+++ b/versions/8.2.1/contribute/maintainers-guide.mdx
@@ -4,8 +4,7 @@ title: 'Guide for Bazel Maintainers'
 
 This is a guide for the maintainers of the Bazel open source project.
 
-If you are looking to contribute to Bazel, please read [Contributing to
-Bazel](/versions/8.2.1/contribute) instead.
+If you are looking to contribute to Bazel, please read [Contributing to Bazel](/versions/8.2.1/contribute) instead.
 
 The objectives of this page are to:
 
@@ -37,8 +36,7 @@ repository.
 
 1. A user creates an issue by choosing one of the
 [issue templates](https://github.com/bazelbuild/bazel/issues/new/choose)
-   and it enters the pool of [unreviewed open
-   issues](https://github.com/bazelbuild/bazel/issues?utf8=%E2%9C%93&q=is%3Aissue+is%3Aopen+-label%3Auntriaged+-label%3Ap2+-label%3Ap1+-label%3Ap3+-label%3Ap4+-label%3Ateam-Starlark+-label%3Ateam-Rules-CPP+-label%3Ateam-Rules-Java+-label%3Ateam-XProduct+-label%3Ateam-Android+-label%3Ateam-Apple+-label%3Ateam-Configurability++-label%3Ateam-Performance+-label%3Ateam-Rules-Server+-label%3Ateam-Core+-label%3Ateam-Rules-Python+-label%3Ateam-Remote-Exec+-label%3Ateam-Local-Exec+-label%3Ateam-Bazel).
+   and it enters the pool of [unreviewed open issues](https://github.com/bazelbuild/bazel/issues?utf8=%E2%9C%93&q=is%3Aissue+is%3Aopen+-label%3Auntriaged+-label%3Ap2+-label%3Ap1+-label%3Ap3+-label%3Ap4+-label%3Ateam-Starlark+-label%3Ateam-Rules-CPP+-label%3Ateam-Rules-Java+-label%3Ateam-XProduct+-label%3Ateam-Android+-label%3Ateam-Apple+-label%3Ateam-Configurability++-label%3Ateam-Performance+-label%3Ateam-Rules-Server+-label%3Ateam-Core+-label%3Ateam-Rules-Python+-label%3Ateam-Remote-Exec+-label%3Ateam-Local-Exec+-label%3Ateam-Bazel).
 1. A member on the Developer Experience (DevEx) subteam rotation reviews the
    issue.
    1. If the issue is **not a bug** or a **feature request**, the DevEx member
@@ -58,21 +56,18 @@ repository.
 1. After reviewing the issue, the DevEx member decides if the issue requires
    immediate attention. If it does, they will assign the **P0**
    [priority](#priority) label and an owner from the list of team leads.
-1. The DevEx member assigns the `untriaged` label and exactly one [team
-   label](#team-labels) for routing.
+1. The DevEx member assigns the `untriaged` label and exactly one [team label](#team-labels) for routing.
 1. The DevEx member also assigns exactly one `type:` label, such as `type: bug`
    or `type: feature request`, according to the type of the issue.
 1. For platform-specific issues, the DevEx member assigns one `platform:` label,
    such as `platform:apple` for Mac-specific issues.
 1. If the issue is low priority and can be worked on by a new community
    contributor, the DevEx member assigns the `good first issue` label.
-At this stage, the issue enters the pool of [untriaged open
-issues](https://github.com/bazelbuild/bazel/issues?q=is%3Aissue+is%3Aopen+label%3Auntriaged).
+At this stage, the issue enters the pool of [untriaged open issues](https://github.com/bazelbuild/bazel/issues?q=is%3Aissue+is%3Aopen+label%3Auntriaged).
 
 Each Bazel subteam will triage all issues under labels they own, preferably on a
 weekly basis. The subteam will review and evaluate the issue and provide a
-resolution, if possible. If you are an owner of a team label, see [this section
-](#label-own) for more information.
+resolution, if possible. If you are an owner of a team label, see [this section](#label-own) for more information.
 
 When an issue is resolved, it can be closed.
 
@@ -111,8 +106,7 @@ preferably on a weekly basis.
      issue is either P0 or P1 we assume that is actively worked on.
 1. Remove the `untriaged` label.
 
-Note that you need to be in the [bazelbuild
-organization](https://github.com/bazelbuild) to be able to add or remove labels.
+Note that you need to be in the [bazelbuild organization](https://github.com/bazelbuild) to be able to add or remove labels.
 
 ### Pull Requests {#pull-requests}
 
@@ -138,8 +132,7 @@ issues.
   unusable, or a downed service that severely impacts development of the Bazel
   project. This includes regressions introduced in a new release that blocks a
   significant number of users, or an incompatible breaking change that was not
-  compliant to the [Breaking
-  Change](https://docs.google.com/document/d/1q5GGRxKrF_mnwtaPKI487P8OdDRh2nN7jX6U-FXnHL0/edit?pli=1#heading=h.ceof6vpkb3ik)
+  compliant to the [Breaking Change](https://docs.google.com/document/d/1q5GGRxKrF_mnwtaPKI487P8OdDRh2nN7jX6U-FXnHL0/edit?pli=1#heading=h.ceof6vpkb3ik)
   policy. No practical workaround exists.
 * [**P1**](https://github.com/bazelbuild/bazel/labels/P1) - Critical defect or
   feature which should be addressed in the next release, or a serious issue that
diff --git a/versions/8.2.1/contribute/naming.mdx b/versions/8.2.1/contribute/naming.mdx
index c8cf6f37..318895d8 100644
--- a/versions/8.2.1/contribute/naming.mdx
+++ b/versions/8.2.1/contribute/naming.mdx
@@ -4,8 +4,7 @@ title: 'Naming a Bazel related project'
 
 First, thank you for contributing to the Bazel ecosystem! Please reach out to
 the Bazel community on the
-[bazel-discuss mailing list](https://groups.google.com/forum/#!forum/bazel-discuss
-) to share your project and its suggested name.
+[bazel-discuss mailing list](https://groups.google.com/forum/#!forum/bazel-discuss) to share your project and its suggested name.
 
 If you are building a Bazel related tool or sharing your Skylark rules,
 we recommend following these guidelines for the name of your project:
diff --git a/versions/8.2.1/contribute/patch-acceptance.mdx b/versions/8.2.1/contribute/patch-acceptance.mdx
index 8e23f591..66e842ca 100644
--- a/versions/8.2.1/contribute/patch-acceptance.mdx
+++ b/versions/8.2.1/contribute/patch-acceptance.mdx
@@ -11,29 +11,24 @@ code base.
    need a corresponding issue for tracking.
 1. If you're proposing significant changes, write a
    [design document](/versions/8.2.1/contribute/design-documents).
-1. Ensure you've signed a [Contributor License
-   Agreement](https://cla.developers.google.com).
+1. Ensure you've signed a [Contributor License Agreement](https://cla.developers.google.com).
 1. Prepare a git commit that implements the feature. Don't forget to add tests
    and update the documentation. If your change has user-visible effects, please
    [add release notes](/versions/8.2.1/contribute/release-notes). If it is an incompatible change,
    read the [guide for rolling out breaking changes](/versions/8.2.1/contribute/breaking-changes).
 1. Create a pull request on
    [GitHub](https://github.com/bazelbuild/bazel/pulls). If you're new to GitHub,
-   read [about pull
-   requests](https://help.github.com/articles/about-pull-requests/). Note that
+   read [about pull requests](https://help.github.com/articles/about-pull-requests/). Note that
    we restrict permissions to create branches on the main Bazel repository, so
-   you will need to push your commit to [your own fork of the
-   repository](https://help.github.com/articles/working-with-forks/).
+   you will need to push your commit to [your own fork of the repository](https://help.github.com/articles/working-with-forks/).
 1. A Bazel maintainer should assign you a reviewer within two business days
    (excluding holidays in the USA and Germany). If you aren't assigned a
    reviewer in that time, you can request one by emailing
-   [bazel-discuss@googlegroups.com]
-   (mailto:bazel-discuss@googlegroups.com).
+   [bazel-discuss@googlegroups.com](mailto:bazel-discuss@googlegroups.com).
 1. Work with the reviewer to complete a code review. For each change, create a
    new commit and push it to make changes to your pull request. If the review
    takes too long (for instance, if the reviewer is unresponsive), send an email to
-   [bazel-discuss@googlegroups.com]
-   (mailto:bazel-discuss@googlegroups.com).
+   [bazel-discuss@googlegroups.com](mailto:bazel-discuss@googlegroups.com).
 1. After your review is complete, a Bazel maintainer applies your patch to
    Google's internal version control system.
 
diff --git a/versions/8.2.1/contribute/release-notes.mdx b/versions/8.2.1/contribute/release-notes.mdx
index 8113a865..0ff55367 100644
--- a/versions/8.2.1/contribute/release-notes.mdx
+++ b/versions/8.2.1/contribute/release-notes.mdx
@@ -16,8 +16,7 @@ the release announcement.
 * If the change adds / removes / changes Bazel in a user-visible way, then it
   may be advantageous to mention it.
 
-If the change is significant, follow the [design document
-policy](/versions/8.2.1/contribute/design-documents) first.
+If the change is significant, follow the [design document policy](/versions/8.2.1/contribute/design-documents) first.
 
 ## Guidelines {#guidelines}
 
@@ -60,10 +59,8 @@ change is about.
 
 ## Process {#process}
 
-As part of the [release
-process](https://github.com/bazelbuild/continuous-integration/blob/master/docs/release-playbook.md),
-we collect the `RELNOTES` tags of every commit. We copy everything in a [Google
-Doc](https://docs.google.com/document/d/1wDvulLlj4NAlPZamdlEVFORks3YXJonCjyuQMUQEmB0/edit)
+As part of the [release process](https://github.com/bazelbuild/continuous-integration/blob/master/docs/release-playbook.md),
+we collect the `RELNOTES` tags of every commit. We copy everything in a [Google Doc](https://docs.google.com/document/d/1wDvulLlj4NAlPZamdlEVFORks3YXJonCjyuQMUQEmB0/edit)
 where we review, edit, and organize the notes.
 
 The release manager sends an email to the
@@ -71,6 +68,4 @@ The release manager sends an email to the
 Bazel contributors are invited to contribute to the document and make sure
 their changes are correctly reflected in the announcement.
 
-Later, the announcement will be submitted to the [Bazel
-blog](https://blog.bazel.build/), using the [bazel-blog
-repository](https://github.com/bazelbuild/bazel-blog/tree/master/_posts).
+Later, the announcement will be submitted to the [Bazel blog](https://blog.bazel.build/), using the [bazel-blog repository](https://github.com/bazelbuild/bazel-blog/tree/master/_posts).
diff --git a/versions/8.2.1/contribute/statemachine-guide.mdx b/versions/8.2.1/contribute/statemachine-guide.mdx
index 4c952499..65670a14 100644
--- a/versions/8.2.1/contribute/statemachine-guide.mdx
+++ b/versions/8.2.1/contribute/statemachine-guide.mdx
@@ -172,8 +172,7 @@ instead, batches[^4] as many lookups as possible before doing so. The value
 might not be immediately available, for example, requiring a Skyframe restart,
 so the caller specifies what to do with the resulting value using a callback.
 
-The `StateMachine` processor ([`Driver`s and bridging to
-SkyFrame](#drivers-and-bridging)) guarantees that the value is available before
+The `StateMachine` processor ([`Driver`s and bridging to SkyFrame](#drivers-and-bridging)) guarantees that the value is available before
 the next state begins. An example follows.
 
 ```
@@ -284,8 +283,7 @@ and solutions to certain control flow problems.
 ### Sequential states
 
 This is the most common and straightforward control flow pattern. An example of
-this is shown in [Stateful computations inside
-`SkyKeyComputeState`](#stateful-computations).
+this is shown in [Stateful computations inside `SkyKeyComputeState`](#stateful-computations).
 
 ### Branching
 
@@ -545,8 +543,7 @@ section describes the propagation of data values.
 
 ### Implementing `Tasks.lookUp` callbacks
 
-There’s an example of implementing a `Tasks.lookUp` callback in [SkyValue
-lookups](#skyvalue-lookups). This section provides rationale and suggests
+There’s an example of implementing a `Tasks.lookUp` callback in [SkyValue lookups](#skyvalue-lookups). This section provides rationale and suggests
 approaches for handling multiple SkyValues.
 
 #### `Tasks.lookUp` callbacks {#tasks-lookup-callbacks}
@@ -710,8 +707,7 @@ class BarProducer implements StateMachine {
 Tip: It would be tempting to use the more concise signature void `accept(Bar
 value)` rather than the stuttery `void acceptBarValue(Bar value)` above.
 However, `Consumer` is a common overload of `void accept(Bar value)`,
-so doing this often leads to violations of the [Overloads: never
-split](https://google.github.io/styleguide/javaguide.html#s3.4.2-ordering-class-contents)
+so doing this often leads to violations of the [Overloads: never split](https://google.github.io/styleguide/javaguide.html#s3.4.2-ordering-class-contents)
 style-guide rule.
 
 Tip: Using a custom `ResultSink` type instead of a generic one from
@@ -774,14 +770,11 @@ pattern after accepting output from either a subtask or SkyValue lookup.
 Note that the implementation of `acceptBarError` eagerly forwards the result to
 the `Caller.ResultSink`, as required by [Error bubbling](#error-bubbling).
 
-Alternatives for top-level `StateMachine`s are described in [`Driver`s and
-bridging to SkyFunctions](#drivers-and-bridging).
+Alternatives for top-level `StateMachine`s are described in [`Driver`s and bridging to SkyFunctions](#drivers-and-bridging).
 
 ### Error handling {#error-handling}
 
-There's a couple of examples of error handling already in [`Tasks.lookUp`
-callbacks](#tasks-lookup-callbacks) and [Propagating values between
-`StateMachines`](#propagating-values). Exceptions, other than
+There's a couple of examples of error handling already in [`Tasks.lookUp` callbacks](#tasks-lookup-callbacks) and [Propagating values between `StateMachines`](#propagating-values). Exceptions, other than
 `InterruptedException` are not thrown, but instead passed around through
 callbacks as values. Such callbacks often have exclusive-or semantics, with
 exactly one of a value or error being passed.
@@ -1184,8 +1177,7 @@ states. Where it is possible, local stack `step` variables are young generation
 variables and efficiently GC'd.
 
 For `StateMachine` variables, breaking things down into subtasks and following
-the recommended pattern for [Propagating values between
-`StateMachine`s](#propagating-values) is also helpful. Observe that when
+the recommended pattern for [Propagating values between `StateMachine`s](#propagating-values) is also helpful. Observe that when
 following the pattern, only child `StateMachine`s have references to parent
 `StateMachine`s and not vice versa. This means that as children complete and
 update the parents using result callbacks, the children naturally fall out of
@@ -1207,8 +1199,7 @@ potentially reflecting local behavior.
 
 ### Concurrency tree diagram {#concurrency-tree-diagram}
 
-The following is an alternative view of the diagram in [Structured
-concurrency](#structured-concurrency) that better depicts the tree structure.
+The following is an alternative view of the diagram in [Structured concurrency](#structured-concurrency) that better depicts the tree structure.
 The blocks form a small tree.
 
 ![Structured Concurrency 3D](/versions/8.2.1/contribute/images/structured-concurrency-3d.svg)
diff --git a/versions/8.2.1/docs/android-instrumentation-test.mdx b/versions/8.2.1/docs/android-instrumentation-test.mdx
index 4d68e04e..68d3f7ea 100644
--- a/versions/8.2.1/docs/android-instrumentation-test.mdx
+++ b/versions/8.2.1/docs/android-instrumentation-test.mdx
@@ -2,8 +2,7 @@
 title: 'Android Instrumentation Tests'
 ---
 
-_If you're new to Bazel, start with the [Building Android with
-Bazel](/versions/8.2.1/start/android-app ) tutorial._
+_If you're new to Bazel, start with the [Building Android with Bazel](/versions/8.2.1/start/android-app) tutorial._
 
 ![Running Android instrumentation tests in parallel](/versions/8.2.1/docs/images/android_test.gif "Android instrumentation test")
 
@@ -18,9 +17,7 @@ emulators in a sandbox, ensuring that tests always run from a clean state. Each
 test gets an isolated emulator instance, allowing tests to run in parallel
 without passing states between them.
 
-For more information on Android instrumentation tests, check out the [Android
-developer
-documentation](https://developer.android.com/training/testing/unit-testing/instrumented-unit-tests.html).
+For more information on Android instrumentation tests, check out the [Android developer documentation](https://developer.android.com/training/testing/unit-testing/instrumented-unit-tests.html).
 
 Please file issues in the [GitHub issue tracker](https://github.com/bazelbuild/bazel/issues).
 
@@ -58,8 +55,7 @@ This results in output similar to the following:
 release 4.1.0
 ```
 
-- **KVM**. Bazel requires emulators to have [hardware
-  acceleration](https://developer.android.com/studio/run/emulator-acceleration.html#accel-check)
+- **KVM**. Bazel requires emulators to have [hardware acceleration](https://developer.android.com/studio/run/emulator-acceleration.html#accel-check)
   with KVM on Linux. You can follow these
   [installation instructions](https://help.ubuntu.com/community/KVM/Installation)
   for Ubuntu.
@@ -173,11 +169,9 @@ The main attributes of the rule `android_instrumentation_test` are:
 
 - `target_device`: An `android_device` target. This target describes the
   specifications of the Android emulator which Bazel uses to create, launch and
-  run the tests. See the [section on choosing an Android
-  device](#android-device-target) for more information.
+  run the tests. See the [section on choosing an Android device](#android-device-target) for more information.
 
-The test app's `AndroidManifest.xml` must include [an ``
-tag](https://developer.android.com/studio/test/#configure_instrumentation_manifest_settings).
+The test app's `AndroidManifest.xml` must include [an `` tag](https://developer.android.com/studio/test/#configure_instrumentation_manifest_settings).
 This tag must specify the attributes for the **package of the target app** and
 the **fully qualified class name of the instrumentation test runner**,
 `androidx.test.runner.AndroidJUnitRunner`.
@@ -214,8 +208,7 @@ repositories:
 - `@androidsdk`: The Android SDK. Download this through Android Studio.
 
 - `@android_test_support`: Hosts the test runner, emulator launcher, and
-  `android_device` targets. You can find the [latest release
-  here](https://github.com/android/android-test/releases).
+  `android_device` targets. You can find the [latest release here](https://github.com/android/android-test/releases).
 
 Enable these dependencies by adding the following lines to your `WORKSPACE`
 file:
@@ -240,8 +233,7 @@ android_test_repositories()
 
 ## Maven dependencies {#maven-dependencies}
 
-For managing dependencies on Maven artifacts from repositories, such as [Google
-Maven](https://maven.google.com) or [Maven Central](https://central.maven.org),
+For managing dependencies on Maven artifacts from repositories, such as [Google Maven](https://maven.google.com) or [Maven Central](https://central.maven.org),
 you should use a Maven resolver, such as
 [`rules_jvm_external`](https://github.com/bazelbuild/rules_jvm_external).
 
@@ -370,8 +362,7 @@ the device/emulator listed in `adb devices`.
 
 ## Sample projects {#sample-projects}
 
-If you are looking for canonical project samples, see the [Android testing
-samples](https://github.com/googlesamples/android-testing#experimental-bazel-support)
+If you are looking for canonical project samples, see the [Android testing samples](https://github.com/googlesamples/android-testing#experimental-bazel-support)
 for projects using Espresso and UIAutomator.
 
 ## Espresso setup {#espresso-setup}
@@ -560,8 +551,7 @@ API_LEVELS = [
 
 ## Known issues {#known-issues}
 
-- [Forked adb server processes are not terminated after
-  tests](https://github.com/bazelbuild/bazel/issues/4853)
+- [Forked adb server processes are not terminated after tests](https://github.com/bazelbuild/bazel/issues/4853)
 - While APK building works on all platforms (Linux, macOS, Windows), testing
   only works on Linux.
 - Even with `--config=local_adb`, users still need to specify
diff --git a/versions/8.2.1/docs/android-ndk.mdx b/versions/8.2.1/docs/android-ndk.mdx
index f9c423a5..b71cc6a1 100644
--- a/versions/8.2.1/docs/android-ndk.mdx
+++ b/versions/8.2.1/docs/android-ndk.mdx
@@ -2,8 +2,7 @@
 title: 'Using the Android Native Development Kit with Bazel'
 ---
 
-_If you're new to Bazel, please start with the [Building Android with
-Bazel](/versions/8.2.1/start/android-app ) tutorial._
+_If you're new to Bazel, please start with the [Building Android with Bazel](/versions/8.2.1/start/android-app) tutorial._
 
 ## Overview {#overview}
 
@@ -31,8 +30,7 @@ android_ndk_repository(
 )
 ```
 
-For more information about the `android_ndk_repository` rule, see the [Build
-Encyclopedia entry](/versions/8.2.1/reference/be/android#android_ndk_repository).
+For more information about the `android_ndk_repository` rule, see the [Build Encyclopedia entry](/versions/8.2.1/reference/be/android#android_ndk_repository).
 
 If you're using a recent version of the Android NDK (r22 and beyond), use the
 Starlark implementation of `android_ndk_repository`.
@@ -101,13 +99,11 @@ META-INF/MANIFEST.MF
 
 Bazel compiles all of the cc_libraries into a single shared object (`.so`) file,
 targeted for the `armeabi-v7a` ABI by default. To change this or build for
-multiple ABIs at the same time, see the section on [configuring the target
-ABI](#configuring-target-abi).
+multiple ABIs at the same time, see the section on [configuring the target ABI](#configuring-target-abi).
 
 ## Example setup {#example-setup}
 
-This example is available in the [Bazel examples
-repository](https://github.com/bazelbuild/examples/tree/master/android/ndk).
+This example is available in the [Bazel examples repository](https://github.com/bazelbuild/examples/tree/master/android/ndk).
 
 In the `BUILD.bazel` file, three targets are defined with the `android_binary`,
 `android_library`, and `cc_library` rules.
diff --git a/versions/8.2.1/docs/configurable-attributes.mdx b/versions/8.2.1/docs/configurable-attributes.mdx
index 29953abb..f5ecf009 100644
--- a/versions/8.2.1/docs/configurable-attributes.mdx
+++ b/versions/8.2.1/docs/configurable-attributes.mdx
@@ -2,8 +2,7 @@
 title: 'Configurable Build Attributes'
 ---
 
-**_Configurable attributes_**, commonly known as [`select()`](
-/reference/be/functions#select), is a Bazel feature that lets users toggle the values
+**_Configurable attributes_**, commonly known as [`select()`](/reference/be/functions#select), is a Bazel feature that lets users toggle the values
 of build rule attributes at the command line.
 
 This can be used, for example, for a multiplatform library that automatically
@@ -407,8 +406,7 @@ sh_library(
 )
 ```
 
-If you need a `select` to match when multiple conditions match, consider [AND
-chaining](#and-chaining).
+If you need a `select` to match when multiple conditions match, consider [AND chaining](#and-chaining).
 
 ## OR chaining {#or-chaining}
 
diff --git a/versions/8.2.1/extending/auto-exec-groups.mdx b/versions/8.2.1/extending/auto-exec-groups.mdx
index 9c3d0d33..d7cef622 100644
--- a/versions/8.2.1/extending/auto-exec-groups.mdx
+++ b/versions/8.2.1/extending/auto-exec-groups.mdx
@@ -27,9 +27,7 @@ doesn't detect that ([the error](#first-error-message) is raised), you can set
 
 If you need to use multiple toolchains on a single execution platform (an action
 uses executable or tools from two or more toolchains), you need to manually
-define [exec_groups][exec_groups] (check
-[When should I use a custom exec_group?][multiple_toolchains_exec_groups]
-section).
+define [exec_groups][exec_groups](check [When should I use a custom exec_group?][multiple_toolchains_exec_groups] section).
 
 ## History {#history}
 
@@ -42,8 +40,7 @@ my_rule = rule(
 )
 ```
 
-Rule `my_rule` registers two toolchain types. This means that the [Toolchain
-Resolution](https://bazel.build/extending/toolchains#toolchain-resolution) used
+Rule `my_rule` registers two toolchain types. This means that the [Toolchain Resolution](https://bazel.build/extending/toolchains#toolchain-resolution) used
 to find an execution platform which supports both toolchain types. The selected
 execution platform was used for each registered action inside the rule, unless
 specified differently with [exec_groups][exec_groups].
diff --git a/versions/8.2.1/extending/concepts.mdx b/versions/8.2.1/extending/concepts.mdx
index 3eb8da4d..7579dc49 100644
--- a/versions/8.2.1/extending/concepts.mdx
+++ b/versions/8.2.1/extending/concepts.mdx
@@ -20,16 +20,14 @@ Before learning the more advanced concepts, first:
 ## Macros and rules {#macros-and-rules}
 
 A macro is a function that instantiates rules. Macros come in two flavors:
-[symbolic macros](/versions/8.2.1/extending/macros) (new in Bazel 8) and [legacy
-macros](/versions/8.2.1/extending/legacy-macros). The two flavors of macros are defined
+[symbolic macros](/versions/8.2.1/extending/macros) (new in Bazel 8) and [legacy macros](/versions/8.2.1/extending/legacy-macros). The two flavors of macros are defined
 differently, but behave almost the same from the point of view of a user. A
 macro is useful when a `BUILD` file is getting too repetitive or too complex, as
 it lets you reuse some code. The function is evaluated as soon as the `BUILD`
 file is read. After the evaluation of the `BUILD` file, Bazel has little
 information about macros. If your macro generates a `genrule`, Bazel will
 behave *almost* as if you declared that `genrule` in the `BUILD` file. (The one
-exception is that targets declared in a symbolic macro have [special visibility
-semantics](/versions/8.2.1/extending/macros#visibility): a symbolic macro can hide its internal
+exception is that targets declared in a symbolic macro have [special visibility semantics](/versions/8.2.1/extending/macros#visibility): a symbolic macro can hide its internal
 targets from the rest of the package.)
 
 A [rule](/versions/8.2.1/extending/rules) is more powerful than a macro. It can access Bazel
@@ -76,8 +74,7 @@ they will not be executed.
 ## Creating extensions
 
 * [Create your first macro](/versions/8.2.1/rules/macro-tutorial) in order to reuse some code.
-  Then [learn more about macros](/versions/8.2.1/extending/macros) and [using them to create
-  "custom verbs"](/versions/8.2.1/rules/verbs-tutorial).
+  Then [learn more about macros](/versions/8.2.1/extending/macros) and [using them to create "custom verbs"](/versions/8.2.1/rules/verbs-tutorial).
 
 * [Follow the rules tutorial](/versions/8.2.1/rules/rules-tutorial) to get started with rules.
   Next, you can read more about the [rules concepts](/versions/8.2.1/extending/rules).
@@ -92,8 +89,7 @@ them within reach:
 ## Going further
 
 In addition to [macros](/versions/8.2.1/extending/macros) and [rules](/versions/8.2.1/extending/rules), you
-may want to write [aspects](/versions/8.2.1/extending/aspects) and [repository
-rules](/versions/8.2.1/extending/repo).
+may want to write [aspects](/versions/8.2.1/extending/aspects) and [repository rules](/versions/8.2.1/extending/repo).
 
 * Use [Buildifier](https://github.com/bazelbuild/buildtools)
   consistently to format and lint your code.
diff --git a/versions/8.2.1/extending/depsets.mdx b/versions/8.2.1/extending/depsets.mdx
index 5fc3b106..8f95b876 100644
--- a/versions/8.2.1/extending/depsets.mdx
+++ b/versions/8.2.1/extending/depsets.mdx
@@ -111,8 +111,7 @@ need to ensure that if `B` depends on `A`, then `A.o` comes before `B.o` on the
 linker’s command line. Other tools might have the opposite requirement.
 
 Three traversal orders are supported: `postorder`, `preorder`, and
-`topological`. The first two work exactly like [tree
-traversals](https://en.wikipedia.org/wiki/Tree_traversal#Depth-first_search)
+`topological`. The first two work exactly like [tree traversals](https://en.wikipedia.org/wiki/Tree_traversal#Depth-first_search)
 except that they operate on DAGs and skip already visited nodes. The third order
 works as a topological sort from root to leaves, essentially the same as
 preorder except that shared children are listed only after all of their parents.
diff --git a/versions/8.2.1/extending/exec-groups.mdx b/versions/8.2.1/extending/exec-groups.mdx
index bfd6ec63..75695387 100644
--- a/versions/8.2.1/extending/exec-groups.mdx
+++ b/versions/8.2.1/extending/exec-groups.mdx
@@ -63,8 +63,7 @@ test rules.
 
 In the rule implementation, you can declare that actions should be run on the
 execution platform of an execution group. You can do this by using the `exec_group`
-param of action generating methods, specifically [`ctx.actions.run`]
-(/rules/lib/builtins/actions#run) and
+param of action generating methods, specifically [`ctx.actions.run`](/rules/lib/builtins/actions#run) and
 [`ctx.actions.run_shell`](/versions/8.2.1/rules/lib/builtins/actions#run_shell).
 
 ```python
diff --git a/versions/8.2.1/extending/macros.mdx b/versions/8.2.1/extending/macros.mdx
index 3a27bf62..c757c260 100644
--- a/versions/8.2.1/extending/macros.mdx
+++ b/versions/8.2.1/extending/macros.mdx
@@ -31,8 +31,7 @@ two required parameters: `attrs` and `implementation`.
 
 ### Attributes {#attributes}
 
-`attrs` accepts a dictionary of attribute name to [attribute
-types](https://bazel.build/rules/lib/toplevel/attr#members), which represents
+`attrs` accepts a dictionary of attribute name to [attribute types](https://bazel.build/rules/lib/toplevel/attr#members), which represents
 the arguments to the macro. Two common attributes – `name` and `visibility` –
 are implicitly added to all macros and are not included in the dictionary passed
 to `attrs`.
@@ -66,9 +65,7 @@ To support this pattern, a macro can *inherit attributes* from a rule or another
 macro by passing the [rule](https://bazel.build/versions/8.2.1/rules/lib/builtins/rule) or
 [macro symbol](https://bazel.build/versions/8.2.1/rules/lib/builtins/macro) to `macro()`'s
 `inherit_attrs` argument. (You can also use the special string `"common"`
-instead of a rule or macro symbol to inherit the [common attributes defined for
-all Starlark build
-rules](https://bazel.build/reference/be/common-definitions#common-attributes).)
+instead of a rule or macro symbol to inherit the [common attributes defined for all Starlark build rules](https://bazel.build/reference/be/common-definitions#common-attributes).)
 Only public attributes get inherited, and the attributes in the macro's own
 `attrs` dictionary override inherited attributes with the same name. You can
 also *remove* inherited attributes by using `None` as a value in the `attrs`
diff --git a/versions/8.2.1/extending/platforms.mdx b/versions/8.2.1/extending/platforms.mdx
index 48ec3fa2..1bbde38a 100644
--- a/versions/8.2.1/extending/platforms.mdx
+++ b/versions/8.2.1/extending/platforms.mdx
@@ -245,8 +245,7 @@ cc_library(
 
 You can use the
 [`IncompatiblePlatformProvider`](/versions/8.2.1/rules/lib/providers/IncompatiblePlatformProvider)
-in `bazel cquery`'s [Starlark output
-format](/versions/8.2.1/query/cquery#output-format-definition) to distinguish
+in `bazel cquery`'s [Starlark output format](/versions/8.2.1/query/cquery#output-format-definition) to distinguish
 incompatible targets from compatible ones.
 
 This can be used to filter out incompatible targets. The example below will
@@ -266,5 +265,4 @@ $ bazel cquery //... --output=starlark --starlark:file=example.cquery
 
 ### Known Issues
 
-Incompatible targets [ignore visibility
-restrictions](https://github.com/bazelbuild/bazel/issues/16044).
+Incompatible targets [ignore visibility restrictions](https://github.com/bazelbuild/bazel/issues/16044).
diff --git a/versions/8.2.1/extending/repo.mdx b/versions/8.2.1/extending/repo.mdx
index 7b207a88..d8dcf489 100644
--- a/versions/8.2.1/extending/repo.mdx
+++ b/versions/8.2.1/extending/repo.mdx
@@ -74,8 +74,7 @@ specified.
 
 The input parameter `repository_ctx` can be used to access attribute values, and
 non-hermetic functions (finding a binary, executing a binary, creating a file in
-the repository or downloading a file from the Internet). See [the API
-docs](/versions/8.2.1/rules/lib/builtins/repository_ctx) for more context. Example:
+the repository or downloading a file from the Internet). See [the API docs](/versions/8.2.1/rules/lib/builtins/repository_ctx) for more context. Example:
 
 ```python
 def _impl(repository_ctx):
@@ -144,8 +143,7 @@ definition has the `configure` attribute set, use `bazel fetch --force
 
 ## Examples
 
--   [C++ auto-configured
-    toolchain](https://cs.opensource.google/bazel/bazel/+/master:tools/cpp/cc_configure.bzl;drc=644b7d41748e09eff9e47cbab2be2263bb71f29a;l=176):
+-   [C++ auto-configured toolchain](https://cs.opensource.google/bazel/bazel/+/master:tools/cpp/cc_configure.bzl;drc=644b7d41748e09eff9e47cbab2be2263bb71f29a;l=176):
     it uses a repo rule to automatically create the C++ configuration files for
     Bazel by looking for the local C++ compiler, the environment and the flags
     the C++ compiler supports.
diff --git a/versions/8.2.1/extending/rules.mdx b/versions/8.2.1/extending/rules.mdx
index 83cc1755..227d14fa 100644
--- a/versions/8.2.1/extending/rules.mdx
+++ b/versions/8.2.1/extending/rules.mdx
@@ -449,8 +449,7 @@ def _example_library_impl(ctx):
 
 If `DefaultInfo` is not returned by a rule implementation or the `files`
 parameter is not specified, `DefaultInfo.files` defaults to all
-*predeclared outputs* (generally, those created by [output
-attributes](#output_attributes)).
+*predeclared outputs* (generally, those created by [output attributes](#output_attributes)).
 
 Rules that perform actions should provide default outputs, even if those outputs
 are not expected to be directly used. Actions that are not in the graph of the
diff --git a/versions/8.2.1/extending/toolchains.mdx b/versions/8.2.1/extending/toolchains.mdx
index c7debd52..6cfb3351 100644
--- a/versions/8.2.1/extending/toolchains.mdx
+++ b/versions/8.2.1/extending/toolchains.mdx
@@ -523,8 +523,7 @@ The set of available toolchains, in priority order, is created from
   4. Toolchains registered in the "WORKSPACE suffix"; this is only used by
      certain native rules bundled with the Bazel installation.
 
-**NOTE:** [Pseudo-targets like `:all`, `:*`, and
-`/...`](/versions/8.2.1/run/build#specifying-build-targets) are ordered by Bazel's package
+**NOTE:** [Pseudo-targets like `:all`, `:*`, and `/...`](/versions/8.2.1/run/build#specifying-build-targets) are ordered by Bazel's package
 loading mechanism, which uses a lexicographic ordering.
 
 The resolution steps are as follows.
diff --git a/versions/8.2.1/external/advanced.mdx b/versions/8.2.1/external/advanced.mdx
index 883162cb..56c9e472 100644
--- a/versions/8.2.1/external/advanced.mdx
+++ b/versions/8.2.1/external/advanced.mdx
@@ -4,10 +4,8 @@ title: 'Advanced topics on external dependencies'
 
 ## Shadowing dependencies in WORKSPACE
 
-Note: This section applies to the [WORKSPACE
-system](/versions/8.2.1/external/overview#workspace-system) only. For
-[Bzlmod](/versions/8.2.1/external/overview#bzlmod), use a [multiple-version
-override](/versions/8.2.1/external/module#multiple-version_override).
+Note: This section applies to the [WORKSPACE system](/versions/8.2.1/external/overview#workspace-system) only. For
+[Bzlmod](/versions/8.2.1/external/overview#bzlmod), use a [multiple-version override](/versions/8.2.1/external/module#multiple-version_override).
 
 Whenever possible, have a single version policy in your project, which is
 required for dependencies that you compile against and end up in your final
@@ -128,29 +126,24 @@ preferring IPv4 if enabled. In some situations, for example when the IPv4
 network cannot resolve/reach external addresses, this can cause `Network
 unreachable` exceptions and build failures. In these cases, you can override
 Bazel's behavior to prefer IPv6 by using the
-[`java.net.preferIPv6Addresses=true` system
-property](https://docs.oracle.com/javase/8/docs/api/java/net/doc-files/net-properties.html).
+[`java.net.preferIPv6Addresses=true` system property](https://docs.oracle.com/javase/8/docs/api/java/net/doc-files/net-properties.html).
 Specifically:
 
-*   Use `--host_jvm_args=-Djava.net.preferIPv6Addresses=true` [startup
-    option](/versions/8.2.1/docs/user-manual#startup-options), for example by adding the
+*   Use `--host_jvm_args=-Djava.net.preferIPv6Addresses=true` [startup option](/versions/8.2.1/docs/user-manual#startup-options), for example by adding the
     following line in your [`.bazelrc` file](/versions/8.2.1/run/bazelrc):
 
     `startup --host_jvm_args=-Djava.net.preferIPv6Addresses=true`
 
 *   When running Java build targets that need to connect to the internet (such
     as for integration tests), use the
-    `--jvmopt=-Djava.net.preferIPv6Addresses=true` [tool
-    flag](/versions/8.2.1/docs/user-manual#jvmopt). For example, include in your [`.bazelrc`
-    file](/versions/8.2.1/run/bazelrc):
+    `--jvmopt=-Djava.net.preferIPv6Addresses=true` [tool flag](/versions/8.2.1/docs/user-manual#jvmopt). For example, include in your [`.bazelrc` file](/versions/8.2.1/run/bazelrc):
 
     `build --jvmopt=-Djava.net.preferIPv6Addresses`
 
 *   If you are using [`rules_jvm_external`](https://github.com/bazelbuild/rules_jvm_external)
     for dependency version resolution, also add
     `-Djava.net.preferIPv6Addresses=true` to the `COURSIER_OPTS` environment
-    variable to [provide JVM options for
-    Coursier](https://github.com/bazelbuild/rules_jvm_external#provide-jvm-options-for-coursier-with-coursier_opts).
+    variable to [provide JVM options for Coursier](https://github.com/bazelbuild/rules_jvm_external#provide-jvm-options-for-coursier-with-coursier_opts).
 
 ## Offline builds
 
@@ -167,15 +160,12 @@ fetch a file with [`ctx.download`](/versions/8.2.1/rules/lib/builtins/repository
 providing a hash sum of the file needed, Bazel looks for a file matching the
 basename of the first URL, and uses the local copy if the hash matches.
 
-Bazel itself uses this technique to bootstrap offline from the [distribution
-artifact](https://github.com/bazelbuild/bazel-website/blob/master/designs/_posts/2016-10-11-distribution-artifact.md).
-It does so by [collecting all the needed external
-dependencies](https://github.com/bazelbuild/bazel/blob/5cfa0303d6ac3b5bd031ff60272ce80a704af8c2/WORKSPACE#L116)
+Bazel itself uses this technique to bootstrap offline from the [distribution artifact](https://github.com/bazelbuild/bazel-website/blob/master/designs/_posts/2016-10-11-distribution-artifact.md).
+It does so by [collecting all the needed external dependencies](https://github.com/bazelbuild/bazel/blob/5cfa0303d6ac3b5bd031ff60272ce80a704af8c2/WORKSPACE#L116)
 in an internal
 [`distdir_tar`](https://github.com/bazelbuild/bazel/blob/5cfa0303d6ac3b5bd031ff60272ce80a704af8c2/distdir.bzl#L44).
 
 Bazel allows execution of arbitrary commands in repository rules without knowing
 if they call out to the network, and so cannot enforce fully offline builds. To
 test if a build works correctly offline, manually block off the network (as
-Bazel does in its [bootstrap
-test](https://cs.opensource.google/bazel/bazel/+/master:src/test/shell/bazel/BUILD;l=1073;drc=88c426e73cc0eb0a41c0d7995e36acd94e7c9a48)).
\ No newline at end of file
+Bazel does in its [bootstrap test](https://cs.opensource.google/bazel/bazel/+/master:src/test/shell/bazel/BUILD;l=1073;drc=88c426e73cc0eb0a41c0d7995e36acd94e7c9a48)).
\ No newline at end of file
diff --git a/versions/8.2.1/external/migration.mdx b/versions/8.2.1/external/migration.mdx
index 2c779abb..78855bef 100644
--- a/versions/8.2.1/external/migration.mdx
+++ b/versions/8.2.1/external/migration.mdx
@@ -2,8 +2,7 @@
 title: 'Bzlmod Migration Guide'
 ---
 
-Due to the [shortcomings of
-WORKSPACE](/versions/8.2.1/external/overview#workspace-shortcomings), Bzlmod is going to
+Due to the [shortcomings of WORKSPACE](/versions/8.2.1/external/overview#workspace-shortcomings), Bzlmod is going to
 replace the legacy WORKSPACE system. The WORKSPACE file will be disabled by
 default in Bazel 8 (late 2024) and will be removed in Bazel 9 (late 2025).
 This guide helps you migrate your project to Bzlmod and drop WORKSPACE for
@@ -117,9 +116,7 @@ Bazel module when it also adopts Bzlmod.
 
 *   **Bzlmod**
 
-    With Bzlmod, as long as the your dependency is available in [Bazel Central
-    Registry](https://registry.bazel.build) or your custom [Bazel
-    registry](/versions/8.2.1/external/registry), you can simply depend on it with a
+    With Bzlmod, as long as the your dependency is available in [Bazel Central Registry](https://registry.bazel.build) or your custom [Bazel registry](/versions/8.2.1/external/registry), you can simply depend on it with a
     [`bazel_dep`](/versions/8.2.1/rules/lib/globals/module#bazel_dep) directive.
 
     ```python
@@ -150,8 +147,7 @@ repository.
 
 If your dependency is not a Bazel project or not yet available in any Bazel
 registry, you can introduce it using
-[`use_repo_rule`](/versions/8.2.1/external/module#use_repo_rule) or [module
-extensions](/versions/8.2.1/external/extension).
+[`use_repo_rule`](/versions/8.2.1/external/module#use_repo_rule) or [module extensions](/versions/8.2.1/external/extension).
 
 *   **WORKSPACE**
 
@@ -604,8 +600,7 @@ macros.
 Fortunately, the flag
 [`--experimental_repository_resolved_file`][resolved_file_flag]
 can help. This flag essentially generates a "lock file" of all fetched external
-dependencies in your last Bazel command. You can find more details in this [blog
-post](https://blog.bazel.build/2018/07/09/bazel-sync-and-resolved-file.html).
+dependencies in your last Bazel command. You can find more details in this [blog post](https://blog.bazel.build/2018/07/09/bazel-sync-and-resolved-file.html).
 
 [resolved_file_flag]: /reference/command-line-reference#flag--experimental_repository_resolved_file
 
@@ -646,11 +641,9 @@ You may also know `bazel query` can be used for inspecting repository rules with
 bazel query --output=build //external:
 ```
 
-While it is more convenient and much faster, [bazel query can lie about
-external dependency version](https://github.com/bazelbuild/bazel/issues/12947),
+While it is more convenient and much faster, [bazel query can lie about external dependency version](https://github.com/bazelbuild/bazel/issues/12947),
 so be careful using it! Querying and inspecting external
-dependencies with Bzlmod is going to achieved by a [new
-subcommand](https://github.com/bazelbuild/bazel/issues/15365).
+dependencies with Bzlmod is going to achieved by a [new subcommand](https://github.com/bazelbuild/bazel/issues/15365).
 
 #### Built-in default dependencies {#builtin-default-deps}
 
@@ -697,8 +690,7 @@ Using the WORKSPACE.bzlmod file can make the migration easier because:
 #### Repository visibility {#repository-visibility}
 
 Bzlmod is able to control which other repositories are visible from a given
-repository, check [repository names and strict
-deps](/versions/8.2.1/external/module#repository_names_and_strict_deps) for more details.
+repository, check [repository names and strict deps](/versions/8.2.1/external/module#repository_names_and_strict_deps) for more details.
 
 Here is a summary of repository visibilities from different types of
 repositories when also taking WORKSPACE into consideration.
@@ -711,8 +703,7 @@ repositories when also taking WORKSPACE into consideration.
 | WORKSPACE Repos | All visible | Not visible | Not visible | All visible |
 
 Note: For the root module, if a repository `@foo` is defined in WORKSPACE and
-`@foo` is also used as an [apparent repository
-name](/versions/8.2.1/external/overview#apparent-repo-name) in MODULE.bazel, then `@foo`
+`@foo` is also used as an [apparent repository name](/versions/8.2.1/external/overview#apparent-repo-name) in MODULE.bazel, then `@foo`
 refers to the one introduced in MODULE.bazel.
 
 Note: For a module extension generated repository `@bar`, if `@foo` is used as
@@ -787,9 +778,7 @@ the project. Take note of a few things when creating the source archive:
     GitHub isn't going to guarantee the checksum of source archives generated on
     demand. In short, URLs in the form of
     `https://github.com///releases/download/...` is considered stable
-    while `https://github.com///archive/...` is not. Check [GitHub
-    Archive Checksum
-    Outage](https://blog.bazel.build/2023/02/15/github-archive-checksum.html)
+    while `https://github.com///archive/...` is not. Check [GitHub Archive Checksum Outage](https://blog.bazel.build/2023/02/15/github-archive-checksum.html)
     for more context.
 
 *   **Make sure the source tree follows the layout of the original repository.**
@@ -818,8 +807,7 @@ Pull Request.
 
 [bcr_contrib_guide]: https://github.com/bazelbuild/bazel-central-registry/tree/main/docs#contribute-a-bazel-module
 
-It is **highly recommended** to set up the [Publish to
-BCR](https://github.com/bazel-contrib/publish-to-bcr) GitHub App for your
+It is **highly recommended** to set up the [Publish to BCR](https://github.com/bazel-contrib/publish-to-bcr) GitHub App for your
 repository to automate the process of submitting your module to the BCR.
 
 ## Best practices {#best-practices}
diff --git a/versions/8.2.1/external/mod-command.mdx b/versions/8.2.1/external/mod-command.mdx
index e49acc52..f5ebb078 100644
--- a/versions/8.2.1/external/mod-command.mdx
+++ b/versions/8.2.1/external/mod-command.mdx
@@ -61,11 +61,9 @@ The available subcommands and their respective required arguments are:
 
 *   ``: All present versions of the module ``.
 
-*   `@`: The repo with the given [apparent
-    name](overview#apparent-repo-name) in the context of the `--base_module`.
+*   `@`: The repo with the given [apparent name](overview#apparent-repo-name) in the context of the `--base_module`.
 
-*   `@@`: The repo with the given [canonical
-    name](overview#canonical-repo-name).
+*   `@@`: The repo with the given [canonical name](overview#canonical-repo-name).
 
 In a context requiring specifying modules, ``s referring to repos that
 correspond to modules (as opposed to extension-generated repos) can also be
@@ -87,8 +85,7 @@ The following options only affect the subcommands that print graphs (`graph`,
     information about the version resolution of each module. If the module
     version changed during resolution, show either which version replaced it or
     what was the original version, the reason it was replaced, and which modules
-    requested the new version if the reason was [Minimal Version
-    Selection](module#version-selection).
+    requested the new version if the reason was [Minimal Version Selection](module#version-selection).
 
 *   `--include_unused` *default: "false"*: Include in the output graph the
     modules which were originally present in the dependency graph, but became
diff --git a/versions/8.2.1/external/module.mdx b/versions/8.2.1/external/module.mdx
index 018ac455..b4d9906c 100644
--- a/versions/8.2.1/external/module.mdx
+++ b/versions/8.2.1/external/module.mdx
@@ -122,8 +122,7 @@ serves multiple purposes:
     version, regardless of which versions of the dependency are requested in the
     dependency graph.
 *   With the `registry` attribute, you can force this dependency to come from a
-    specific registry, instead of following the normal [registry
-    selection](/versions/8.2.1/external/registry#selecting_registries) process.
+    specific registry, instead of following the normal [registry selection](/versions/8.2.1/external/registry#selecting_registries) process.
 *   With the `patch*` attributes, you can specify a set of patches to apply to
     the downloaded module.
 
@@ -176,13 +175,11 @@ With `bazel_dep`, you can define repos that represent other Bazel modules.
 Sometimes there is a need to define a repo that does _not_ represent a Bazel
 module; for example, one that contains a plain JSON file to be read as data.
 
-In this case, you could use the [`use_repo_rule`
-directive](/versions/8.2.1/rules/lib/globals/module#use_repo_rule) to directly define a repo
+In this case, you could use the [`use_repo_rule` directive](/versions/8.2.1/rules/lib/globals/module#use_repo_rule) to directly define a repo
 by invoking a repo rule. This repo will only be visible to the module it's
 defined in.
 
-Under the hood, this is implemented using the same mechanism as [module
-extensions](/versions/8.2.1/external/extension), which lets you define repos with more
+Under the hood, this is implemented using the same mechanism as [module extensions](/versions/8.2.1/external/extension), which lets you define repos with more
 flexibility.
 
 ## Repository names and strict deps
diff --git a/versions/8.2.1/external/overview.mdx b/versions/8.2.1/external/overview.mdx
index b92fbd95..5e9b58a6 100644
--- a/versions/8.2.1/external/overview.mdx
+++ b/versions/8.2.1/external/overview.mdx
@@ -128,8 +128,7 @@ for all build targets inside the repo.
 
 The syntax of a `REPO.bazel` file is similar to `BUILD` files, except that no
 `load` statements are supported, and only a single function, `repo()`, is
-available. `repo()` takes the same arguments as the [`package()`
-function](/versions/8.2.1/reference/be/functions#package) in `BUILD` files; whereas `package()`
+available. `repo()` takes the same arguments as the [`package()` function](/versions/8.2.1/reference/be/functions#package) in `BUILD` files; whereas `package()`
 specifies common attributes for all build targets inside the package, `repo()`
 analogously does so for all build targets inside the repo.
 
@@ -163,8 +162,7 @@ bazel_dep(name = "protobuf", version = "3.19.0")
 ```
 
 A module must only list its direct dependencies, which Bzlmod looks up in a
-[Bazel registry](/versions/8.2.1/external/registry) — by default, the [Bazel Central
-Registry](https://bcr.bazel.build/). The registry provides the
+[Bazel registry](/versions/8.2.1/external/registry) — by default, the [Bazel Central Registry](https://bcr.bazel.build/). The registry provides the
 dependencies' `MODULE.bazel` files, which allows Bazel to discover the entire
 transitive dependency graph before performing version resolution.
 
@@ -235,5 +233,4 @@ many pain points, including:
         `B` and `C`; `B` and `C` both depend on different versions of `D`).
 
 Due to the shortcomings of WORKSPACE, Bzlmod is going to replace the legacy
-WORKSPACE system in future Bazel releases. Please read the [Bzlmod migration
-guide](/versions/8.2.1/external/migration) on how to migrate to Bzlmod.
+WORKSPACE system in future Bazel releases. Please read the [Bzlmod migration guide](/versions/8.2.1/external/migration) on how to migrate to Bzlmod.
diff --git a/versions/8.2.1/external/registry.mdx b/versions/8.2.1/external/registry.mdx
index 0fb17eaa..26a90821 100644
--- a/versions/8.2.1/external/registry.mdx
+++ b/versions/8.2.1/external/registry.mdx
@@ -42,8 +42,7 @@ An index registry must follow the format below:
             project
         *   `versions`: A list of all the versions of this module to be found in
             this registry
-        *   `yanked_versions`: A map of [*yanked*
-            versions](/versions/8.2.1/external/module#yanked_versions) of this module. The keys
+        *   `yanked_versions`: A map of [*yanked* versions](/versions/8.2.1/external/module#yanked_versions) of this module. The keys
             should be versions to yank and the values should be descriptions of
             why the version is yanked, ideally containing a link to more
             information
@@ -54,8 +53,7 @@ An index registry must follow the format below:
         *   The default type is "archive", representing an `http_archive` repo,
             with the following fields:
             *   `url`: The URL of the source archive
-            *   `integrity`: The [Subresource
-                Integrity](https://w3c.github.io/webappsec-subresource-integrity/#integrity-metadata-description)
+            *   `integrity`: The [Subresource Integrity](https://w3c.github.io/webappsec-subresource-integrity/#integrity-metadata-description)
                 checksum of the archive
             *   `strip_prefix`: A directory prefix to strip when extracting the
                 source archive
@@ -103,8 +101,7 @@ You can browse its contents using the web frontend at
 https://registry.bazel.build/.
 
 The Bazel community maintains the BCR, and contributors are welcome to submit
-pull requests. See the [BCR contribution
-guidelines](https://github.com/bazelbuild/bazel-central-registry/blob/main/docs/README.md).
+pull requests. See the [BCR contribution guidelines](https://github.com/bazelbuild/bazel-central-registry/blob/main/docs/README.md).
 
 In addition to following the format of a normal index registry, the BCR requires
 a `presubmit.yml` file for each module version
diff --git a/versions/8.2.1/external/vendor.mdx b/versions/8.2.1/external/vendor.mdx
index a8841098..f6fe5d62 100644
--- a/versions/8.2.1/external/vendor.mdx
+++ b/versions/8.2.1/external/vendor.mdx
@@ -23,9 +23,7 @@ absolute path.
 ## Vendor a specific external repository {#vendor-specific-repository}
 
 You can use the `vendor` command with the `--repo` flag to specify which repo
-to vendor, it accepts both [canonical repo
-name](/versions/8.2.1/external/overview#canonical-repo-name) and [apparent repo
-name](/versions/8.2.1/external/overview#apparent-repo-name).
+to vendor, it accepts both [canonical repo name](/versions/8.2.1/external/overview#canonical-repo-name) and [apparent repo name](/versions/8.2.1/external/overview#apparent-repo-name).
 
 For example, running:
 
diff --git a/versions/8.2.1/help.mdx b/versions/8.2.1/help.mdx
index 19357612..3ebe61af 100644
--- a/versions/8.2.1/help.mdx
+++ b/versions/8.2.1/help.mdx
@@ -46,5 +46,4 @@ what level of support Bazel provides.
 
 ## File a bug {#file-bug}
 
-If you encounter a bug or want to request a feature, file a [GitHub
-Issue](https://github.com/bazelbuild/bazel/issues).
+If you encounter a bug or want to request a feature, file a [GitHub Issue](https://github.com/bazelbuild/bazel/issues).
diff --git a/versions/8.2.1/install/bazelisk.mdx b/versions/8.2.1/install/bazelisk.mdx
index ecf32ae9..2fbcb775 100644
--- a/versions/8.2.1/install/bazelisk.mdx
+++ b/versions/8.2.1/install/bazelisk.mdx
@@ -16,8 +16,7 @@ For more details, see
 ## Updating Bazel
 
 Bazel has a [backward compatibility policy](/versions/8.2.1/release/backward-compatibility)
-(see [guidance for rolling out incompatible
-changes](/versions/8.2.1/contribute/breaking-changes) if you
+(see [guidance for rolling out incompatible changes](/versions/8.2.1/contribute/breaking-changes) if you
 are the author of one). That page summarizes best practices on how to test and
 migrate your project with upcoming incompatible changes and how to provide
 feedback to the incompatible change authors.
diff --git a/versions/8.2.1/install/compile-source.mdx b/versions/8.2.1/install/compile-source.mdx
index 2168fc33..b36af539 100644
--- a/versions/8.2.1/install/compile-source.mdx
+++ b/versions/8.2.1/install/compile-source.mdx
@@ -45,8 +45,7 @@ it by typing `bazel` in a terminal.
 
 **Reason**: To build Bazel from a GitHub source tree, you need a pre-existing
 Bazel binary. You can install one from a package manager or download one from
-GitHub. See [Installing Bazel](/versions/8.2.1/install). (Or you can [build from
-scratch (bootstrap)](#bootstrap-bazel).)
+GitHub. See [Installing Bazel](/versions/8.2.1/install). (Or you can [build from scratch (bootstrap)](#bootstrap-bazel).)
 
 **Troubleshooting**:
 
@@ -239,8 +238,7 @@ For instructions for Unix-like systems, see
     ```
 
 *   **The Visual C++ compiler.** Install the Visual C++ compiler either as part
-    of Visual Studio 2015 or newer, or by installing the latest [Build Tools
-    for Visual Studio 2017](https://aka.ms/BuildTools).
+    of Visual Studio 2015 or newer, or by installing the latest [Build Tools for Visual Studio 2017](https://aka.ms/BuildTools).
 
 *   **JDK.** Version 21 is required.
 
diff --git a/versions/8.2.1/install/ide.mdx b/versions/8.2.1/install/ide.mdx
index 561d0e02..c42d95e9 100644
--- a/versions/8.2.1/install/ide.mdx
+++ b/versions/8.2.1/install/ide.mdx
@@ -38,10 +38,8 @@ To install, go to the IDE's plugin browser and search for `Bazel`.
 To manually install older versions, download the zip files from JetBrains'
 Plugin Repository and install the zip file from the IDE's plugin browser:
 
-*  [Android Studio
-   plugin](https://plugins.jetbrains.com/plugin/9185-android-studio-with-bazel)
-*  [IntelliJ
-   plugin](https://plugins.jetbrains.com/plugin/8609-intellij-with-bazel)
+*  [Android Studio plugin](https://plugins.jetbrains.com/plugin/9185-android-studio-with-bazel)
+*  [IntelliJ plugin](https://plugins.jetbrains.com/plugin/8609-intellij-with-bazel)
 *  [CLion plugin](https://plugins.jetbrains.com/plugin/9554-clion-with-bazel)
 
 ### Xcode {#xcode}
@@ -61,8 +59,7 @@ Features:
 * Starlark debugger for `.bzl` files during a build (set breakpoints, step
   through code, inspect variables, and so on)
 
-Find [the plugin on the Visual Studio
-marketplace](https://marketplace.visualstudio.com/items?itemName=BazelBuild.vscode-bazel).
+Find [the plugin on the Visual Studio marketplace](https://marketplace.visualstudio.com/items?itemName=BazelBuild.vscode-bazel).
 The plugin is [open source](https://github.com/bazelbuild/vscode-bazel).
 
 See also: [Autocomplete for Source Code](#autocomplete-for-source-code)
@@ -82,8 +79,7 @@ See also: [Autocomplete for Source Code](#autocomplete-for-source-code)
 
 ### Emacs {#emacs}
 
-See [`bazelbuild/bazel-emacs-mode` on
-GitHub](https://github.com/bazelbuild/emacs-bazel-mode)
+See [`bazelbuild/bazel-emacs-mode` on GitHub](https://github.com/bazelbuild/emacs-bazel-mode)
 
 See also: [Autocomplete for Source Code](#autocomplete-for-source-code)
 
@@ -115,6 +111,5 @@ tool for building Bazel targets when source files change.
 
 ## Building your own IDE plugin {#build-own-plugin}
 
-Read the [**IDE support** blog
-post](https://blog.bazel.build/2016/06/10/ide-support.html) to learn more about
+Read the [**IDE support** blog post](https://blog.bazel.build/2016/06/10/ide-support.html) to learn more about
 the Bazel APIs to use when building an IDE plugin.
diff --git a/versions/8.2.1/install/windows.mdx b/versions/8.2.1/install/windows.mdx
index e1435f36..b75163a1 100644
--- a/versions/8.2.1/install/windows.mdx
+++ b/versions/8.2.1/install/windows.mdx
@@ -31,8 +31,7 @@ To check your Windows version:
 
 Alternatively you can:
 
-*   [Download the Bazel binary (`bazel-version-windows-x86_64.exe`) from
- GitHub](https://github.com/bazelbuild/bazel/releases).
+*   [Download the Bazel binary (`bazel-version-windows-x86_64.exe`) from GitHub](https://github.com/bazelbuild/bazel/releases).
 *   [Install Bazel from Chocolatey](#chocolately)
 *   [Install Bazel from Scoop](#scoop)
 *   [Build Bazel from source](/versions/8.2.1/install/compile-source)
@@ -208,8 +207,7 @@ If that doesn't help:
     its dependencies, such as the MSYS2 shell. This will not install Visual C++
     though.
 
-See [Chocolatey installation and package maintenance
-guide](/versions/8.2.1/contribute/windows-chocolatey-maintenance) for more
+See [Chocolatey installation and package maintenance guide](/versions/8.2.1/contribute/windows-chocolatey-maintenance) for more
 information about the Chocolatey package.
 
 ### Using Scoop {#scoop}
@@ -226,8 +224,7 @@ information about the Chocolatey package.
     scoop install bazel
     ```
 
-See [Scoop installation and package maintenance
-guide](/versions/8.2.1/contribute/windows-scoop-maintenance) for more
+See [Scoop installation and package maintenance guide](/versions/8.2.1/contribute/windows-scoop-maintenance) for more
 information about the Scoop package.
 
 ### Build from source {#build-from-source}
diff --git a/versions/8.2.1/migrate/maven.mdx b/versions/8.2.1/migrate/maven.mdx
index 3b91aec4..fc575c0c 100644
--- a/versions/8.2.1/migrate/maven.mdx
+++ b/versions/8.2.1/migrate/maven.mdx
@@ -19,8 +19,7 @@ directly run by Bazel since there's no Maven compatibility layer.
 ## Before you begin {#before-you-begin}
 
 *   [Install Bazel](/versions/8.2.1/install) if it's not yet installed.
-*   If you're new to Bazel, go through the tutorial [Introduction to Bazel:
-    Build Java](/versions/8.2.1/start/java) before you start migrating. The tutorial explains
+*   If you're new to Bazel, go through the tutorial [Introduction to Bazel: Build Java](/versions/8.2.1/start/java) before you start migrating. The tutorial explains
     Bazel's concepts, structure, and label syntax.
 
 ## Differences between Maven and Bazel {#dif-maven-bazel}
@@ -44,8 +43,7 @@ The steps below describe how to migrate your project to Bazel:
 3.  [Create more BUILD files](#3-build)
 4.  [Build using Bazel](#4-build)
 
-Examples below come from a migration of the [Guava
-project](https://github.com/google/guava) from Maven to Bazel. The
+Examples below come from a migration of the [Guava project](https://github.com/google/guava) from Maven to Bazel. The
 Guava project used is release `v31.1`. The examples using Guava do not walk
 through each step in the migration, but they do show the files and contents that
 are generated or added manually for the migration.
@@ -63,14 +61,12 @@ has no external dependencies, this file can be empty.
 If your project depends on files or packages that are not in one of the
 project's directories, specify these external dependencies in the MODULE.bazel
 file. You can use `rules_jvm_external` to manage dependencies from Maven. For
-instructions about using this ruleset, see [the
-README](https://github.com/bazelbuild/rules_jvm_external/#rules_jvm_external)
+instructions about using this ruleset, see [the README](https://github.com/bazelbuild/rules_jvm_external/#rules_jvm_external)
 .
 
 #### Guava project example: external dependencies {#guava-1}
 
-You can list the external dependencies of the [Guava
-project](https://github.com/google/guava) with the
+You can list the external dependencies of the [Guava project](https://github.com/google/guava) with the
 [`rules_jvm_external`](https://github.com/bazelbuild/rules_jvm_external)
 ruleset.
 
@@ -164,8 +160,7 @@ your build by adding more `BUILD` files with more granular targets.
             *   `resources`: Use globbing to list all resources in your project.
             *   `deps`: You need to determine which external dependencies your
                 project needs.
-        *   Take a look at the [example below of this top-level BUILD
-            file](#guava-2) from the migration of the Guava project.
+        *   Take a look at the [example below of this top-level BUILD file](#guava-2) from the migration of the Guava project.
 
 3.  Now that you have a `BUILD` file at the root of your project, build your
     project to ensure that it works. On the command line, from your workspace
diff --git a/versions/8.2.1/migrate/xcode.mdx b/versions/8.2.1/migrate/xcode.mdx
index 6e57a42a..ded70688 100644
--- a/versions/8.2.1/migrate/xcode.mdx
+++ b/versions/8.2.1/migrate/xcode.mdx
@@ -32,8 +32,7 @@ Before you begin, do the following:
 
 1.  [Install Bazel](/versions/8.2.1/install) if you have not already done so.
 
-2.  If you're not familiar with Bazel and its concepts, complete the [iOS app
-    tutorial](/versions/8.2.1/start/ios-app)). You should understand the Bazel workspace,
+2.  If you're not familiar with Bazel and its concepts, complete the [iOS app tutorial](/versions/8.2.1/start/ios-app)). You should understand the Bazel workspace,
     including the `MODULE.bazel` and `BUILD` files, as well as the concepts of
     targets, build rules, and Bazel packages.
 
@@ -44,8 +43,7 @@ Before you begin, do the following:
 Unlike Xcode, Bazel requires you to explicitly declare all dependencies for
 every target in the `BUILD` file.
 
-For more information on external dependencies, see [Working with external
-dependencies](/versions/8.2.1/docs/external).
+For more information on external dependencies, see [Working with external dependencies](/versions/8.2.1/docs/external).
 
 ## Build or test an Xcode project with Bazel {#build-xcode-project}
 
@@ -84,8 +82,7 @@ Note: Place the project source code within the directory tree containing the
 
 To integrate SwiftPM dependencies into the Bazel workspace with
 [swift_bazel](https://github.com/cgrindel/swift_bazel), you must
-convert them into Bazel packages as described in the [following
-tutorial](https://chuckgrindel.com/swift-packages-in-bazel-using-swift_bazel/)
+convert them into Bazel packages as described in the [following tutorial](https://chuckgrindel.com/swift-packages-in-bazel-using-swift_bazel/)
 .
 
 Note: SwiftPM support is a manual process with many variables. SwiftPM
@@ -103,8 +100,7 @@ initial build of the project as follows:
 *   [Step 3b: (Optional) Add the test target(s)](#step-3b-optional-add-the-test-target-s)
 *   [Step 3c: Add the library target(s)](#step-3c-add-the-library-target-s)
 
-**Tip:** To learn more about packages and other Bazel concepts, see [Workspaces,
-packages, and targets](/versions/8.2.1/concepts/build-ref).
+**Tip:** To learn more about packages and other Bazel concepts, see [Workspaces, packages, and targets](/versions/8.2.1/concepts/build-ref).
 
 #### Step 3a: Add the application target {#add-app-target}
 
@@ -132,8 +128,7 @@ In the target, specify the following at the minimum:
 
 #### Step 3b: (Optional) Add the test target(s) {#add-test-target}
 
-Bazel's [Apple build
-rules](https://github.com/bazelbuild/rules_apple) support running
+Bazel's [Apple build rules](https://github.com/bazelbuild/rules_apple) support running
 unit and UI tests on all Apple platforms. Add test targets as follows:
 
 *   [`macos_unit_test`](https://github.com/bazelbuild/rules_apple/blob/master/doc/rules-macos.md#macos_unit_test)
@@ -181,8 +176,7 @@ all sources and/or headers of a certain type. Use it carefully as it might
 include files you do not want Bazel to build.
 
 You can browse existing examples for various types of applications directly in
-the [rules_apple examples
-directory](https://github.com/bazelbuild/rules_apple/tree/master/examples/). For
+the [rules_apple examples directory](https://github.com/bazelbuild/rules_apple/tree/master/examples/). For
 example:
 
 *   [macOS application targets](https://github.com/bazelbuild/rules_apple/tree/master/examples/macos)
@@ -191,8 +185,7 @@ example:
 
 *   [Multi platform applications (macOS, iOS, watchOS, tvOS)](https://github.com/bazelbuild/rules_apple/tree/master/examples/multi_platform)
 
-For more information on build rules, see [Apple Rules for
-Bazel](https://github.com/bazelbuild/rules_apple).
+For more information on build rules, see [Apple Rules for Bazel](https://github.com/bazelbuild/rules_apple).
 
 At this point, it is a good idea to test the build:
 
diff --git a/versions/8.2.1/query/cquery.mdx b/versions/8.2.1/query/cquery.mdx
index 53d20ee5..45a4d38d 100644
--- a/versions/8.2.1/query/cquery.mdx
+++ b/versions/8.2.1/query/cquery.mdx
@@ -6,8 +6,7 @@ title: ' Configurable Query (cquery)'
 [`select()`](/versions/8.2.1/docs/configurable-attributes) and build options' effects on the build
 graph.
 
-It achieves this by running over the results of Bazel's [analysis
-phase](/versions/8.2.1/extending/concepts#evaluation-model),
+It achieves this by running over the results of Bazel's [analysis phase](/versions/8.2.1/extending/concepts#evaluation-model),
 which integrates these effects. `query`, by contrast, runs over the results of
 Bazel's loading phase, before options are evaluated.
 
@@ -137,8 +136,7 @@ $ bazel cquery //foo --universe_scope=//foo,//genrule_with_foo_as_tool
 If you want to precisely declare which instance to query over, use
 the [`config`](#config) function.
 
-See `query`'s [target pattern
-documentation](/versions/8.2.1/query/language#target-patterns) for more information on target patterns.
+See `query`'s [target pattern documentation](/versions/8.2.1/query/language#target-patterns) for more information on target patterns.
 
 ## Functions {#functions}
 
diff --git a/versions/8.2.1/query/language.mdx b/versions/8.2.1/query/language.mdx
index 11272fca..8a5964e7 100644
--- a/versions/8.2.1/query/language.mdx
+++ b/versions/8.2.1/query/language.mdx
@@ -1105,8 +1105,7 @@ is being used.
 
 ### On the ordering of results {#results-ordering}
 
-Although query expressions always follow the "[law of
-conservation of graph order](#graph-order)", _presenting_ the results may be done
+Although query expressions always follow the "[law of conservation of graph order](#graph-order)", _presenting_ the results may be done
 in either a dependency-ordered or unordered manner. This does **not**
 influence the targets in the result set or how the query is computed. It only
 affects how the results are printed to stdout. Moreover, nodes that are
@@ -1252,8 +1251,7 @@ and `maxrank` output formats print the labels of each
 target in the resulting graph, but instead of appearing in
 topological order, they appear in rank order, preceded by their
 rank number. These are unaffected by the result ordering
-`--[no]order_results` flag (see [notes on
-the ordering of results](#result-order)).
+`--[no]order_results` flag (see [notes on the ordering of results](#result-order)).
 
 There are two variants of this format: `minrank` ranks
 each node by the length of the shortest path from a root node to it.
diff --git a/versions/8.2.1/reference/be/functions.mdx b/versions/8.2.1/reference/be/functions.mdx
index 1a2931e7..382696d5 100644
--- a/versions/8.2.1/reference/be/functions.mdx
+++ b/versions/8.2.1/reference/be/functions.mdx
@@ -262,8 +262,7 @@ There are several important limitations and caveats:
    package called "Foo.java" (which is allowed, though Bazel warns about it),
    then the consumer of the `glob()` will use the "Foo.java" rule
    (its outputs) instead of the "Foo.java" file. See
-   [GitHub
-   issue #10395](https://github.com/bazelbuild/bazel/issues/10395#issuecomment-583714657) for more details.
+   [GitHub issue #10395](https://github.com/bazelbuild/bazel/issues/10395#issuecomment-583714657) for more details.
 3. Globs may match files in subdirectories. And subdirectory names
    may be wildcarded. However...
 4. Labels are not allowed to cross the package boundary and glob does
diff --git a/versions/8.2.1/reference/be/java.mdx b/versions/8.2.1/reference/be/java.mdx
index 013a1c18..c1df0436 100644
--- a/versions/8.2.1/reference/be/java.mdx
+++ b/versions/8.2.1/reference/be/java.mdx
@@ -225,8 +225,7 @@ test code. The test runner's main method is invoked instead of the main class be
   [java\_binary](#java_binary) for more details.
 
 See the section on `java_binary()` arguments. This rule also
-supports all [attributes common
-to all test rules (\*\_test)](https://bazel.build/versions/8.2.1/reference/be/common-definitions#common-attributes-tests).
+supports all [attributes common to all test rules (\*\_test)](https://bazel.build/versions/8.2.1/reference/be/common-definitions#common-attributes-tests).
 
 #### Examples
 
diff --git a/versions/8.2.1/reference/be/make-variables.mdx b/versions/8.2.1/reference/be/make-variables.mdx
index 55438eda..bcf3d20b 100644
--- a/versions/8.2.1/reference/be/make-variables.mdx
+++ b/versions/8.2.1/reference/be/make-variables.mdx
@@ -19,8 +19,7 @@ targets, and *custom* variables, which are defined in dependency targets
 and only available to targets that depend on them.
 
 The reason for the term "Make" is historical: the syntax and semantics of
-these variables were originally intended to match [GNU
-Make](https://www.gnu.org/software/make/manual/html_node/Using-Variables.html).
+these variables were originally intended to match [GNU Make](https://www.gnu.org/software/make/manual/html_node/Using-Variables.html).
 
 ## Use
 
@@ -64,8 +63,7 @@ and look at the top output lines with capital letters.
 **Toolchain option variables**
 
 * `COMPILATION_MODE`:
-  `fastbuild`, `dbg`, or `opt`. ([more
-  details](https://bazel.build/versions/8.2.1/docs/user-manual#flag--compilation_mode))
+  `fastbuild`, `dbg`, or `opt`. ([more details](https://bazel.build/versions/8.2.1/docs/user-manual#flag--compilation_mode))
 
 **Path variables**
 
diff --git a/versions/8.2.1/reference/be/workspace.mdx b/versions/8.2.1/reference/be/workspace.mdx
index 30de6592..135eee85 100644
--- a/versions/8.2.1/reference/be/workspace.mdx
+++ b/versions/8.2.1/reference/be/workspace.mdx
@@ -25,8 +25,7 @@ bind(name, actual, compatible_with, deprecation, distribs, features, licenses, r
 
 *Warning: use of `bind()` is not recommended. See "[Consider removing bind](https://github.com/bazelbuild/bazel/issues/1952)" for a long
 discussion of its issues and alternatives. In particular, consider the use of
-[`repo_mapping`
-repository attributes](https://bazel.build/versions/8.2.1/rules/repository_rules#attributes).*
+[`repo_mapping` repository attributes](https://bazel.build/versions/8.2.1/rules/repository_rules#attributes).*
 
 *Warning: `select()` cannot be used in `bind()`. See the [Configurable Attributes FAQ](/versions/8.2.1/docs/configurable-attributes#bind-select) for
 details.*
@@ -114,8 +113,7 @@ local_repository(name, path, repo_mapping)
 ```
 
 Allows targets from a local directory to be bound. This means that the current repository can
-use targets defined in this other directory. See the [bind
-section](/versions/8.2.1/reference/be/workspace#bind_examples) for more details.
+use targets defined in this other directory. See the [bind section](/versions/8.2.1/reference/be/workspace#bind_examples) for more details.
 
 #### Examples
 
diff --git a/versions/8.2.1/reference/glossary.mdx b/versions/8.2.1/reference/glossary.mdx
index 19606dd0..a4f490ec 100644
--- a/versions/8.2.1/reference/glossary.mdx
+++ b/versions/8.2.1/reference/glossary.mdx
@@ -21,8 +21,7 @@ An in-memory graph of [actions](#action) and the [artifacts](#artifact) that
 these actions read and generate. The graph might include artifacts that exist as
 source files (for example, in the file system) as well as generated
 intermediate/final artifacts that are not mentioned in `BUILD` files. Produced
-during the [analysis phase](#analysis-phase) and used during the [execution
-phase](#execution-phase).
+during the [analysis phase](#analysis-phase) and used during the [execution phase](#execution-phase).
 
 ### Action graph query (aquery) {#action-graph-query}
 A [query](#query-concept) tool that can query over build [actions](#action).
@@ -37,8 +36,7 @@ invalidate individual actions deterministically.
 
 ### Analysis phase {#analysis-phase}
 The second phase of a build. Processes the [target graph](#target-graph)
-specified in [`BUILD` files](#build-file) to produce an in-memory [action
-graph](#action-graph) that determines the order of actions to run during the
+specified in [`BUILD` files](#build-file) to produce an in-memory [action graph](#action-graph) that determines the order of actions to run during the
 [execution phase](#execution-phase). This is the phase in which rule
 implementations are evaluated.
 
@@ -81,8 +79,7 @@ target's source files, dependencies, and custom compiler options. The particular
 attributes available for a given target depend on its rule type.
 
 ### .bazelrc {#bazelrc}
-Bazel’s configuration file used to change the default values for [startup
-flags](#startup-flags) and [command flags](#command-flags), and to define common
+Bazel’s configuration file used to change the default values for [startup flags](#startup-flags) and [command flags](#command-flags), and to define common
 groups of options that can then be set together on the Bazel command line using
 a `--config` flag. Bazel can combine settings from multiple bazelrc files
 (systemwide, per-workspace, per-user, or from a custom location), and a
@@ -108,8 +105,7 @@ directory.
 
 ### .bzl File {#bzl-file}
 A file that defines rules, [macros](#macro), and constants written in
-[Starlark](#starlark). These can then be imported into [`BUILD`
-files](#build-file) using the `load()` function.
+[Starlark](#starlark). These can then be imported into [`BUILD` files](#build-file) using the `load()` function.
 
 {/* TODO: ### Build event protocol */}
 
@@ -117,8 +113,7 @@ files](#build-file) using the `load()` function.
 
 ### Build graph {#build-graph}
 The dependency graph that Bazel constructs and traverses to perform a build.
-Includes nodes like [targets](#target), [configured
-targets](#configured-target), [actions](#action), and [artifacts](#artifact). A
+Includes nodes like [targets](#target), [configured targets](#configured-target), [actions](#action), and [artifacts](#artifact). A
 build is considered complete when all [artifacts](#artifact) on which a set of
 requested targets depend are verified as up-to-date.
 
@@ -158,8 +153,7 @@ graphs and restart the [analysis phase](#analysis-phase).
 ### Configuration {#configuration}
 Information outside of [rule](#rule) definitions that impacts how rules generate
 [actions](#action). Every build has at least one configuration specifying the
-target platform, action environment variables, and command-line [build
-flags](#command-flags). [Transitions](#transition) may create additional
+target platform, action environment variables, and command-line [build flags](#command-flags). [Transitions](#transition) may create additional
 configurations, such as for host tools or cross-compilation.
 
 **See also:** [Configurations](/versions/8.2.1/extending/rules#configurations)
@@ -174,8 +168,7 @@ configuration of `//:c` because changing `--javacopt` unnecessarily breaks C++
 build cacheability.
 
 ### Configured query (cquery) {#configured-query}
-A [query](#query-concept) tool that queries over [configured
-targets](#configured-target) (after the [analysis phase](#analysis-phase)
+A [query](#query-concept) tool that queries over [configured targets](#configured-target) (after the [analysis phase](#analysis-phase)
 completes). This means `select()` and [build flags](#command-flags) (such as
 `--platforms`) are accurately reflected in the results.
 
@@ -191,8 +184,7 @@ build, it has two configured targets: `` and ``.
 ### Correctness {#correctness}
 A build is correct when its output faithfully reflects the state of its
 transitive inputs. To achieve correct builds, Bazel strives to be
-[hermetic](#hermeticity), reproducible, and making [build
-analysis](#analysis-phase) and [action execution](#execution-phase)
+[hermetic](#hermeticity), reproducible, and making [build analysis](#analysis-phase) and [action execution](#execution-phase)
 deterministic.
 
 ### Dependency {#dependency}
@@ -234,8 +226,7 @@ compilation). A dynamic execution strategy can provide the best possible
 incremental and clean build times.
 
 ### Execution phase {#execution-phase}
-The third phase of a build. Executes the [actions](#action) in the [action
-graph](#action-graph) created during the [analysis phase](#analysis-phase).
+The third phase of a build. Executes the [actions](#action) in the [action graph](#action-graph) created during the [analysis phase](#analysis-phase).
 These actions invoke executables (compilers, scripts) to read and write
 [artifacts](#artifact). *Spawn strategies* control how these actions are
 executed: locally, remotely, dynamically, sandboxed, docker, and so on.
@@ -285,8 +276,7 @@ syntax may be omitted.
 The first phase of a build where Bazel executes [`BUILD` files](#build-file) to
 create [packages](#package). [Macros](#macro) and certain functions like
 `glob()` are evaluated in this phase. Interleaved with the second phase of the
-build, the [analysis phase](#analysis-phase), to build up a [target
-graph](#target-graph).
+build, the [analysis phase](#analysis-phase), to build up a [target graph](#target-graph).
 
 ### Legacy macro {#legacy-macro}
 A flavor of [macro](#macro) which is declared as an ordinary
@@ -336,8 +326,7 @@ Module metadata is hosted in Bazel registries.
 
 ### Module Extension {#module-extension}
 A piece of logic that can be run to generate [repos](#repository) by reading
-inputs from across the [module](#module) dependency graph and invoking [repo
-rules](#repository-rule). Module extensions have capabilities similar to repo
+inputs from across the [module](#module) dependency graph and invoking [repo rules](#repository-rule). Module extensions have capabilities similar to repo
 rules, allowing them to access the internet, perform file I/O, and so on.
 
 **See also:** [Module extensions](/versions/8.2.1/external/extension)
@@ -350,8 +339,7 @@ example, `native.cc_library` or `native.java_library`). User-defined rules
 
 ### Output base {#output-base}
 A [workspace](#workspace)-specific directory to store Bazel output files. Used
-to separate outputs from the *workspace*'s source tree (the [main
-repo](#repository)). Located in the [output user root](#output-user-root).
+to separate outputs from the *workspace*'s source tree (the [main repo](#repository)). Located in the [output user root](#output-user-root).
 
 ### Output groups {#output-groups}
 A group of files that is expected to be built when Bazel finishes building a
@@ -406,8 +394,7 @@ query variants: [query](#query-command), [cquery](#configured-query), and
 [aquery](#action-graph-query).
 
 ### query (command) {#query-command}
-A [query](#query-concept) tool that operates over the build's post-[loading
-phase](#loading-phase) [target graph](#target-graph). This is relatively fast,
+A [query](#query-concept) tool that operates over the build's post-[loading phase](#loading-phase) [target graph](#target-graph). This is relatively fast,
 but can't analyze the effects of `select()`, [build flags](#command-flags),
 [artifacts](#artifact), or build [actions](#action).
 
@@ -425,8 +412,7 @@ repo; multiple such files can coexist in a directory.
 The *main repo* is the repo in which the current Bazel command is being run.
 
 *External repos* are defined by specifying [modules](#module) in `MODULE.bazel`
-files, or invoking [repo rules](#repository-rule) in [module
-extensions](#module-extension). They can be fetched on demand to a predetermined
+files, or invoking [repo rules](#repository-rule) in [module extensions](#module-extension). They can be fetched on demand to a predetermined
 "magical" location on disk.
 
 Each repo has a unique, constant *canonical* name, and potentially different
@@ -437,8 +423,7 @@ Each repo has a unique, constant *canonical* name, and potentially different
 ### Repository cache {#repo-cache}
 A shared content-addressable cache of files downloaded by Bazel for builds,
 shareable across [workspaces](#workspace). Enables offline builds after the
-initial download. Commonly used to cache files downloaded through [repository
-rules](#repository-rule) like `http_archive` and repository rule APIs like
+initial download. Commonly used to cache files downloaded through [repository rules](#repository-rule) like `http_archive` and repository rule APIs like
 `repository_ctx.download`. Files are cached only if their SHA-256 checksums are
 specified for the download.
 
@@ -472,8 +457,7 @@ Rules are instantiated to produce rule targets in the
 [loading phase](#loading-phase). In the [analysis phase](#analysis-phase) rule
 targets communicate information to their downstream dependencies in the form of
 [providers](#provider), and register [actions](#action) describing how to
-generate their output artifacts. These actions are run in the [execution
-phase](#execution-phase).
+generate their output artifacts. These actions are run in the [execution phase](#execution-phase).
 
 Note: Historically the term "rule" has been used to refer to a rule target.
 This usage was inherited from tools like Make, but causes confusion and should
@@ -517,8 +501,7 @@ support the stamp attribute.
 ### Starlark {#starlark}
 The extension language for writing [rules](/versions/8.2.1/extending/rules) and [macros](#macro). A
 restricted subset of Python (syntactically and grammatically) aimed for the
-purpose of configuration, and for better performance. Uses the [`.bzl`
-file](#bzl-file) extension. [`BUILD` files](#build-file) use an even more
+purpose of configuration, and for better performance. Uses the [`.bzl` file](#bzl-file) extension. [`BUILD` files](#build-file) use an even more
 restricted version of Starlark (such as no `def` function definitions), formerly
 known as Skylark.
 
@@ -549,8 +532,7 @@ An object that is defined in a [`BUILD` file](#build-file) and identified by a
 [label](#label). Targets represent the buildable units of a workspace from
 the perspective of the end user.
 
-A target that is declared by instantiating a [rule](#rule) is called a [rule
-target](#rule-target). Depending on the rule, these may be runnable (like
+A target that is declared by instantiating a [rule](#rule) is called a [rule target](#rule-target). Depending on the rule, these may be runnable (like
 `cc_binary`) or testable (like `cc_test`). Rule targets typically depend on
 other targets via their [attributes](#attribute) (such as `deps`); these
 dependencies form the basis of the [target graph](#target-graph).
@@ -561,14 +543,11 @@ within a `BUILD` file. As a special case, the `BUILD` file of any package is
 always considered a source file target in that package.
 
 Targets are discovered during the [loading phase](#loading-phase). During the
-[analysis phase](#analysis-phase), targets are associated with [build
-configurations](#configuration) to form [configured
-targets](#configured-target).
+[analysis phase](#analysis-phase), targets are associated with [build configurations](#configuration) to form [configured targets](#configured-target).
 
 ### Target graph {#target-graph}
 An in-memory graph of [targets](#target) and their dependencies. Produced during
-the [loading phase](#loading-phase) and used as an input to the [analysis
-phase](#analysis-phase).
+the [loading phase](#loading-phase) and used as an input to the [analysis phase](#analysis-phase).
 
 ### Target pattern {#target-pattern}
 A way to specify a group of [targets](#target) on the command line. Commonly
@@ -581,8 +560,7 @@ packages recursively from the root of the [workspace](#workspace).
 Rule [targets](#target) instantiated from test rules, and therefore contains a
 test executable. A return code of zero from the completion of the executable
 indicates test success. The exact contract between Bazel and tests (such as test
-environment variables, test result collection methods) is specified in the [Test
-Encyclopedia](/versions/8.2.1/reference/test-encyclopedia).
+environment variables, test result collection methods) is specified in the [Test Encyclopedia](/versions/8.2.1/reference/test-encyclopedia).
 
 ### Toolchain {#toolchain}
 A set of tools to build outputs for a language. Typically, a toolchain includes
@@ -596,8 +574,7 @@ A build [target](#target) is top-level if it’s requested on the Bazel command
 line. For example, if `//:foo` depends on `//:bar`, and `bazel build //:foo` is
 called, then for this build, `//:foo` is top-level, and `//:bar` isn’t
 top-level, although both targets will need to be built. An important difference
-between top-level and non-top-level targets is that [command
-flags](#command-flags) set on the Bazel command line (or via
+between top-level and non-top-level targets is that [command flags](#command-flags) set on the Bazel command line (or via
 [.bazelrc](#bazelrc)) will set the [configuration](#configuration) for top-level
 targets, but might be modified by a [transition](#transition) for non-top-level
 targets.
@@ -628,8 +605,7 @@ or `.bzl` file may load a given `.bzl` file. Without context, usually
 **See also:** [Visibility documentation](/versions/8.2.1/concepts/visibility)
 
 ### Workspace {#workspace}
-The environment shared by all Bazel commands run from the same [main
-repository](#repository).
+The environment shared by all Bazel commands run from the same [main repository](#repository).
 
 Note that historically the concepts of "repository" and "workspace" have been
 conflated; the term "workspace" has often been used to refer to the main
diff --git a/versions/8.2.1/release/backward-compatibility.mdx b/versions/8.2.1/release/backward-compatibility.mdx
index 6668690a..f3e8495a 100644
--- a/versions/8.2.1/release/backward-compatibility.mdx
+++ b/versions/8.2.1/release/backward-compatibility.mdx
@@ -6,11 +6,9 @@ This page provides information about how to handle backward compatibility,
 including migrating from one release to another and how to communicate
 incompatible changes.
 
-Bazel is evolving. Minor versions released as part of an [LTS major
-version](/versions/8.2.1/release#bazel-versioning) are fully backward-compatible. New major LTS
+Bazel is evolving. Minor versions released as part of an [LTS major version](/versions/8.2.1/release#bazel-versioning) are fully backward-compatible. New major LTS
 releases may contain incompatible changes that require some migration effort.
-For more information about Bazel's release model, please check out the [Release
-Model](/versions/8.2.1/release) page.
+For more information about Bazel's release model, please check out the [Release Model](/versions/8.2.1/release) page.
 
 ## Summary {#summary}
 
@@ -59,8 +57,7 @@ available.
 ## Communicating incompatible changes {#communicating-incompatible-changes}
 
 The primary source of information about incompatible changes are GitHub issues
-marked with an ["incompatible-change"
-label](https://github.com/bazelbuild/bazel/issues?q=label%3Aincompatible-change).
+marked with an ["incompatible-change" label](https://github.com/bazelbuild/bazel/issues?q=label%3Aincompatible-change).
 
 For every incompatible change, the issue specifies the following:
 
diff --git a/versions/8.2.1/release/index.mdx b/versions/8.2.1/release/index.mdx
index 152928b1..10264b87 100644
--- a/versions/8.2.1/release/index.mdx
+++ b/versions/8.2.1/release/index.mdx
@@ -2,8 +2,7 @@
 title: 'Release Model'
 ---
 
-As announced in [the original blog
-post](https://blog.bazel.build/2020/11/10/long-term-support-release.html), Bazel
+As announced in [the original blog post](https://blog.bazel.build/2020/11/10/long-term-support-release.html), Bazel
 4.0 and higher versions provides support for two release tracks: rolling
 releases and long term support (LTS) releases. This page covers the latest
 information about Bazel's release model.
@@ -19,8 +18,7 @@ information about Bazel's release model.
 | Bazel 5 | Maintenance | [5.4.1](https://github.com/bazelbuild/bazel/releases/tag/5.4.1) | Jan 2025 |
 | Bazel 4 | Deprecated | [4.2.4](https://github.com/bazelbuild/bazel/releases/tag/4.2.4) | Jan 2024 |
 
-All Bazel LTS releases can be found on the [release
-page](https://github.com/bazelbuild/bazel/releases) on GitHub.
+All Bazel LTS releases can be found on the [release page](https://github.com/bazelbuild/bazel/releases) on GitHub.
 
 Note: Bazel version older than Bazel 5 are no longer supported, Bazel users are
 recommended to upgrade to the latest LTS release or use rolling releases if you
@@ -28,8 +26,7 @@ want to keep up with the latest changes at HEAD.
 
 ## Release versioning {#bazel-versioning}
 
-Bazel uses a _major.minor.patch_ [Semantic
-Versioning](https://semver.org/) scheme.
+Bazel uses a _major.minor.patch_ [Semantic Versioning](https://semver.org/) scheme.
 
 *   A _major release_ contains features that are not backward compatible with
     the previous release. Each major Bazel version is an LTS release.
@@ -72,8 +69,7 @@ Bazel regularly publish releases for two release tracks.
     release.
 *   Rolling releases can ship incompatible changes. Incompatible flags are
     recommended for major breaking changes, rolling out incompatible changes
-    should follow our [backward compatibility
-    policy](/versions/8.2.1/release/backward-compatibility).
+    should follow our [backward compatibility policy](/versions/8.2.1/release/backward-compatibility).
 
 ### LTS releases {#lts-releases}
 
@@ -89,8 +85,7 @@ Bazel regularly publish releases for two release tracks.
 *   A Bazel LTS release enters the Deprecated stage after being in ​​the
     Maintenance stage for 2 years.
 
-For planned releases, please check our [release
-issues](https://github.com/bazelbuild/bazel/issues?q=is%3Aopen+is%3Aissue+label%3Arelease)
+For planned releases, please check our [release issues](https://github.com/bazelbuild/bazel/issues?q=is%3Aopen+is%3Aissue+label%3Arelease)
 on Github.
 
 ## Release procedure & policies {#release-procedure-policies}
@@ -153,8 +148,7 @@ For LTS releases, the procedure and policies below are followed:
 1.  Identify release blockers and fix issues found on the release branch.
     *   The release branch is tested with the same test suite in
         [postsubmit](https://buildkite.com/bazel/bazel-bazel) and
-        [downstream test pipeline]
-        (https://buildkite.com/bazel/bazel-at-head-plus-downstream)
+        [downstream test pipeline](https://buildkite.com/bazel/bazel-at-head-plus-downstream)
         on Bazel CI. The Bazel team monitors testing results of the release
         branch and fixes any regressions found.
 1.  Create a new release candidate from the release branch when all known
@@ -210,5 +204,4 @@ feature.
 ## Rule compatibility {#rule-compatibility}
 
 If you are a rule authors and want to maintain compatibility with different
-Bazel versions, please check out the [Rule
-Compatibility](/versions/8.2.1/release/rule-compatibility) page.
+Bazel versions, please check out the [Rule Compatibility](/versions/8.2.1/release/rule-compatibility) page.
diff --git a/versions/8.2.1/release/rule-compatibility.mdx b/versions/8.2.1/release/rule-compatibility.mdx
index b066e8f0..34d739dc 100644
--- a/versions/8.2.1/release/rule-compatibility.mdx
+++ b/versions/8.2.1/release/rule-compatibility.mdx
@@ -53,18 +53,15 @@ Bazel LTS release.
 As Bazel rules authors, you can ensure a manageable migration process for users
 by following these best practices:
 
-1.  The rule should follow [Semantic
-    Versioning](https://semver.org/): minor versions of the same
+1.  The rule should follow [Semantic Versioning](https://semver.org/): minor versions of the same
     major version are backward compatible.
 1.  The rule at HEAD should be compatible with the latest Bazel LTS release.
 1.  The rule at HEAD should be compatible with Bazel at HEAD. To achieve this,
     you can
     *   Set up your own CI testing with Bazel at HEAD
-    *   Add your project to [Bazel downstream
-        testing](https://github.com/bazelbuild/continuous-integration/blob/master/docs/downstream-testing.md);
+    *   Add your project to [Bazel downstream testing](https://github.com/bazelbuild/continuous-integration/blob/master/docs/downstream-testing.md);
         the Bazel team files issues to your project if breaking changes in Bazel
-        affect your project, and you must follow our [downstream project
-        policies](https://github.com/bazelbuild/continuous-integration/blob/master/docs/downstream-testing.md#downstream-project-policies)
+        affect your project, and you must follow our [downstream project policies](https://github.com/bazelbuild/continuous-integration/blob/master/docs/downstream-testing.md#downstream-project-policies)
         to address issues timely.
 1.  The latest major version of the rule must be compatible with the latest
     Bazel LTS release.
diff --git a/versions/8.2.1/remote/bep-glossary.mdx b/versions/8.2.1/remote/bep-glossary.mdx
index 58ea4ac6..2b631b99 100644
--- a/versions/8.2.1/remote/bep-glossary.mdx
+++ b/versions/8.2.1/remote/bep-glossary.mdx
@@ -410,5 +410,4 @@ workspace, such as the execution root.
 
 ## WorkspaceStatus {#workspacestatus}
 
-A single `WorkspaceStatus` event contains the result of the [workspace status
-command](/versions/8.2.1/docs/user-manual#workspace-status).
+A single `WorkspaceStatus` event contains the result of the [workspace status command](/versions/8.2.1/docs/user-manual#workspace-status).
diff --git a/versions/8.2.1/remote/bep.mdx b/versions/8.2.1/remote/bep.mdx
index a68eb3b8..98d2481d 100644
--- a/versions/8.2.1/remote/bep.mdx
+++ b/versions/8.2.1/remote/bep.mdx
@@ -2,14 +2,12 @@
 title: 'Build Event Protocol'
 ---
 
-The [Build Event
-Protocol](https://github.com/bazelbuild/bazel/blob/master/src/main/java/com/google/devtools/build/lib/buildeventstream/proto/build_event_stream.proto)
+The [Build Event Protocol](https://github.com/bazelbuild/bazel/blob/master/src/main/java/com/google/devtools/build/lib/buildeventstream/proto/build_event_stream.proto)
 (BEP) allows third-party programs to gain insight into a Bazel invocation. For
 example, you could use the BEP to gather information for an IDE
 plugin or a dashboard that displays build results.
 
-The protocol is a set of [protocol
-buffer](https://developers.google.com/protocol-buffers/) messages with some
+The protocol is a set of [protocol buffer](https://developers.google.com/protocol-buffers/) messages with some
 semantics defined on top of it. It includes information about build and test
 results, build progress, the build configuration and much more. The BEP is
 intended to be consumed programmatically and makes parsing Bazel’s
@@ -20,16 +18,13 @@ build event is a protocol buffer message consisting of a build event identifier,
 a set of child event identifiers, and a payload.
 
 *  __Build Event Identifier:__ Depending on the kind of build event, it might be
-an [opaque
-string](https://github.com/bazelbuild/bazel/blob/7.1.0/src/main/java/com/google/devtools/build/lib/buildeventstream/proto/build_event_stream.proto#L131-L140)
-or [structured
-information](https://github.com/bazelbuild/bazel/blob/7.1.0/src/main/java/com/google/devtools/build/lib/buildeventstream/proto/build_event_stream.proto#L194-L205)
+an [opaque string](https://github.com/bazelbuild/bazel/blob/7.1.0/src/main/java/com/google/devtools/build/lib/buildeventstream/proto/build_event_stream.proto#L131-L140)
+or [structured information](https://github.com/bazelbuild/bazel/blob/7.1.0/src/main/java/com/google/devtools/build/lib/buildeventstream/proto/build_event_stream.proto#L194-L205)
 revealing more about the build event. A build event identifier is unique within
 a build.
 
 *  __Children:__ A build event may announce other build events, by including
-their build event identifiers in its [children
-field](https://github.com/bazelbuild/bazel/blob/7.1.0/src/main/java/com/google/devtools/build/lib/buildeventstream/proto/build_event_stream.proto#L1276).
+their build event identifiers in its [children field](https://github.com/bazelbuild/bazel/blob/7.1.0/src/main/java/com/google/devtools/build/lib/buildeventstream/proto/build_event_stream.proto#L1276).
 For example, the `PatternExpanded` build event announces the targets it expands
 to as children. The protocol guarantees that all events, except for the first
 event, are announced by a previous event.
@@ -91,8 +86,7 @@ human-readable formats, such as text and JSON:
 
 ## Build Event Service {#build-event-service}
 
-The [Build Event
-Service](https://github.com/googleapis/googleapis/blob/master/google/devtools/build/v1/publish_build_event.proto)
+The [Build Event Service](https://github.com/googleapis/googleapis/blob/master/google/devtools/build/v1/publish_build_event.proto)
 Protocol is a generic [gRPC](https://www.grpc.io) service for publishing build events. The Build Event
 Service protocol is independent of the BEP and treats BEP events as opaque bytes.
 Bazel ships with a gRPC client implementation of the Build Event Service protocol that
@@ -136,8 +130,7 @@ For a description of each of these flags, see the
 The BEP typically contains many references to log files (test.log, test.xml,
 etc. ) stored on the machine where Bazel is running. A remote BES server
 typically can't access these files as they are on different machines. A way to
-work around this issue is to use Bazel with [remote
-caching](/versions/8.2.1/remote/caching).
+work around this issue is to use Bazel with [remote caching](/versions/8.2.1/remote/caching).
 Bazel will upload all output files to the remote cache (including files
 referenced in the BEP) and the BES server can then fetch the referenced files
 from the cache.
diff --git a/versions/8.2.1/remote/cache-local.mdx b/versions/8.2.1/remote/cache-local.mdx
index af49017c..87b8a0e8 100644
--- a/versions/8.2.1/remote/cache-local.mdx
+++ b/versions/8.2.1/remote/cache-local.mdx
@@ -18,8 +18,7 @@ execution. However, local execution presents some additional challenges.
 ## Checking your cache hit rate {#cache-hits}
 
 Successful remote cache hits will show up in the status line, similar to
-[Cache Hits rate with Remote
-Execution](/versions/8.2.1/remote/cache-remote#check-cache-hits).
+[Cache Hits rate with Remote Execution](/versions/8.2.1/remote/cache-remote#check-cache-hits).
 
 In the standard output of your Bazel run, you will see something like the
 following:
@@ -66,8 +65,7 @@ the steps in this section.
    message you see does not give you enough information, try adding
    `--verbose_failures`.
 
-2. Follow the steps from [Troubleshooting cache hits for remote
-   execution](/versions/8.2.1/remote/cache-remote#troubleshooting_cache_hits) to
+2. Follow the steps from [Troubleshooting cache hits for remote execution](/versions/8.2.1/remote/cache-remote#troubleshooting_cache_hits) to
    ensure that your cache-writing Bazel invocations are able to get cache hits
    on the same machine and across machines.
 
@@ -81,7 +79,6 @@ the steps in this section.
    b. Ensure your cache-reading Bazel invocations build the same targets as the
       cache-writing Bazel invocations.
 
-   c. Follow the same steps as to [ensure caching across
-      machines](/versions/8.2.1/remote/cache-remote#caching-across-machines),
+   c. Follow the same steps as to [ensure caching across machines](/versions/8.2.1/remote/cache-remote#caching-across-machines),
       to ensure caching from your cache-writing Bazel invocation to your
       cache-reading Bazel invocation.
diff --git a/versions/8.2.1/remote/caching.mdx b/versions/8.2.1/remote/caching.mdx
index 90802fb5..f2755734 100644
--- a/versions/8.2.1/remote/caching.mdx
+++ b/versions/8.2.1/remote/caching.mdx
@@ -308,8 +308,7 @@ or for the age of individual cache entries. Bazel will automatically garbage
 collect the disk cache while idling between builds; the idle timer can be set
 with `--experimental_disk_cache_gc_idle_delay` (defaulting to 5 minutes).
 
-As an alternative to automatic garbage collection, we also provide a [tool](
-https://github.com/bazelbuild/bazel/tree/master/src/tools/diskcache) to run a
+As an alternative to automatic garbage collection, we also provide a [tool](https://github.com/bazelbuild/bazel/tree/master/src/tools/diskcache) to run a
 garbage collection on demand.
 
 ## Known issues {#known-issues}
diff --git a/versions/8.2.1/remote/dynamic.mdx b/versions/8.2.1/remote/dynamic.mdx
index 3a173a6b..dcf1f811 100644
--- a/versions/8.2.1/remote/dynamic.mdx
+++ b/versions/8.2.1/remote/dynamic.mdx
@@ -12,8 +12,7 @@ alike.
 This page describes how to enable, tune, and debug dynamic execution. If you
 have both local and remote execution set up and are trying to adjust Bazel
 settings for better performance, this page is for you. If you don't already have
-remote execution set up, go to the Bazel [Remote Execution
-Overview](/versions/8.2.1/remote/rbe) first.
+remote execution set up, go to the Bazel [Remote Execution Overview](/versions/8.2.1/remote/rbe) first.
 
 ## Enabling dynamic execution? {#enabling-dynamic-execution}
 
@@ -44,14 +43,12 @@ are likely. The default value is 1000ms, but should be tuned to being just a bit
 longer than cache hits usually take. The actual time depends both on the remote
 system and on how long a round-trip takes. Usually, the value will be the same
 for all users of a given remote system, unless some of them are far enough away
-to add roundtrip latency. You can use the [Bazel profiling
-features](/versions/8.2.1/rules/performance#performance-profiling) to look at how long typical
+to add roundtrip latency. You can use the [Bazel profiling features](/versions/8.2.1/rules/performance#performance-profiling) to look at how long typical
 cache hits take.
 
 Dynamic execution can be used with local sandboxed strategy as well as with
 [persistent workers](/versions/8.2.1/remote/persistent). Persistent workers will automatically
-run with sandboxing when used with dynamic execution, and cannot use [multiplex
-workers](/versions/8.2.1/remote/multiplex). On Darwin and Windows systems, the sandboxed
+run with sandboxing when used with dynamic execution, and cannot use [multiplex workers](/versions/8.2.1/remote/multiplex). On Darwin and Windows systems, the sandboxed
 strategy can be slow; you can pass `--reuse_sandbox_directories` to reduce
 overhead of creating sandboxes on these systems.
 
@@ -67,8 +64,7 @@ entire action fails. This is an intentional choice to prevent differences
 between local and remote execution from going unnoticed.
 
 For more background on how dynamic execution and its locking works, see Julio
-Merino's excellent [blog
-posts](https://jmmv.dev/series/bazel-dynamic-execution/)
+Merino's excellent [blog posts](https://jmmv.dev/series/bazel-dynamic-execution/)
 
 ## When should I use dynamic execution? {#when-to-use}
 
diff --git a/versions/8.2.1/remote/persistent.mdx b/versions/8.2.1/remote/persistent.mdx
index 3f654535..ec5264a0 100644
--- a/versions/8.2.1/remote/persistent.mdx
+++ b/versions/8.2.1/remote/persistent.mdx
@@ -257,7 +257,6 @@ For more information on persistent workers, see:
 *   [Original persistent workers blog post](https://blog.bazel.build/2015/12/10/java-workers.html)
 *   [Haskell implementation description](https://www.tweag.io/blog/2019-09-25-bazel-ghc-persistent-worker-internship/)
 *   [Blog post by Mike Morearty](https://medium.com/@mmorearty/how-to-create-a-persistent-worker-for-bazel-7738bba2cabb)
-*   [Front End Development with Bazel: Angular/TypeScript and Persistent Workers
-    w/ Asana](https://www.youtube.com/watch?v=0pgERydGyqo)
+*   [Front End Development with Bazel: Angular/TypeScript and Persistent Workers w/ Asana](https://www.youtube.com/watch?v=0pgERydGyqo)
 *   [Bazel strategies explained](https://jmmv.dev/2019/12/bazel-strategies.html)
 *   [Informative worker strategy discussion on the bazel-discuss mailing list](https://groups.google.com/forum/#!msg/bazel-discuss/oAEnuhYOPm8/ol7hf4KWJgAJ)
diff --git a/versions/8.2.1/remote/rules.mdx b/versions/8.2.1/remote/rules.mdx
index f9e22e7b..503ea395 100644
--- a/versions/8.2.1/remote/rules.mdx
+++ b/versions/8.2.1/remote/rules.mdx
@@ -54,8 +54,7 @@ variables that may not be set to equivalent values (or at all) in the remote
 execution environment.
 
 Toolchain rules currently exist for Bazel build and test rules for
-[Scala](https://github.com/bazelbuild/rules_scala/blob/master/scala/scala_toolch
-ain.bzl),
+[Scala](https://github.com/bazelbuild/rules_scala/blob/master/scala/scala_toolch ain.bzl),
 [Rust](https://github.com/bazelbuild/rules_rust/blob/main/rust/toolchain.bzl),
 and [Go](https://github.com/bazelbuild/rules_go/blob/master/go/toolchains.rst),
 and new toolchain rules are under way for other languages and tools such as
diff --git a/versions/8.2.1/remote/workspace.mdx b/versions/8.2.1/remote/workspace.mdx
index c7eea2bf..ce39388c 100644
--- a/versions/8.2.1/remote/workspace.mdx
+++ b/versions/8.2.1/remote/workspace.mdx
@@ -11,8 +11,7 @@ on the host machine. If your workspace rules access information about the
 host machine for use during execution, your build is likely to break due to
 incompatibilities between the environments.
 
-As part of [adapting Bazel rules for remote
-execution](/versions/8.2.1/remote/rules), you need to find such workspace rules
+As part of [adapting Bazel rules for remote execution](/versions/8.2.1/remote/rules), you need to find such workspace rules
 and fix them. This page describes how to find potentially problematic workspace
 rules using the workspace log.
 
diff --git a/versions/8.2.1/rules/language.mdx b/versions/8.2.1/rules/language.mdx
index e0ca1ec2..f8f73547 100644
--- a/versions/8.2.1/rules/language.mdx
+++ b/versions/8.2.1/rules/language.mdx
@@ -93,10 +93,8 @@ values returned by rules are immutable.
 `BUILD` files register targets via making calls to rules. `.bzl` files provide
 definitions for constants, rules, macros, and functions.
 
-[Native functions](/versions/8.2.1/reference/be/functions) and [native rules](
-/reference/be/overview#language-specific-native-rules) are global symbols in
-`BUILD` files. `bzl` files need to load them using the [`native` module](
-/rules/lib/toplevel/native).
+[Native functions](/versions/8.2.1/reference/be/functions) and [native rules](/reference/be/overview#language-specific-native-rules) are global symbols in
+`BUILD` files. `bzl` files need to load them using the [`native` module](/rules/lib/toplevel/native).
 
 There are two syntactic restrictions in `BUILD` files: 1) declaring functions is
 illegal, and 2) `*args` and `**kwargs` arguments are not allowed.
diff --git a/versions/8.2.1/rules/legacy-macro-tutorial.mdx b/versions/8.2.1/rules/legacy-macro-tutorial.mdx
index c115eed0..d17e36b8 100644
--- a/versions/8.2.1/rules/legacy-macro-tutorial.mdx
+++ b/versions/8.2.1/rules/legacy-macro-tutorial.mdx
@@ -3,9 +3,7 @@ title: 'Creating a Legacy Macro'
 ---
 
 IMPORTANT: This tutorial is for [*legacy macros*](/versions/8.2.1/extending/legacy-macros). If
-you only need to support Bazel 8 or newer, we recommend using [symbolic
-macros](/versions/8.2.1/extending/macros) instead; take a look at [Creating a Symbolic
-Macro](../macro-tutorial).
+you only need to support Bazel 8 or newer, we recommend using [symbolic macros](/versions/8.2.1/extending/macros) instead; take a look at [Creating a Symbolic Macro](../macro-tutorial).
 
 Imagine that you need to run a tool as part of your build. For example, you
 may want to generate or preprocess a source file, or compress a binary. In this
diff --git a/versions/8.2.1/rules/verbs-tutorial.mdx b/versions/8.2.1/rules/verbs-tutorial.mdx
index 0d225d4d..192f9b22 100644
--- a/versions/8.2.1/rules/verbs-tutorial.mdx
+++ b/versions/8.2.1/rules/verbs-tutorial.mdx
@@ -49,8 +49,7 @@ This pattern can also be seen in the Angular project. The
 produces two targets. The first is a standard `nodejs_test` target which compares
 some generated output against a "golden" file (that is, a file containing the
 expected output). This can be built and run with a normal `bazel
-test` invocation. In `angular-cli`, you can run [one such
-target](https://github.com/angular/angular-cli/blob/e1269cb520871ee29b1a4eec6e6c0e4a94f0b5fc/etc/api/BUILD)
+test` invocation. In `angular-cli`, you can run [one such target](https://github.com/angular/angular-cli/blob/e1269cb520871ee29b1a4eec6e6c0e4a94f0b5fc/etc/api/BUILD)
 with `bazel test //etc/api:angular_devkit_core_api`.
 
 Over time, this golden file may need to be updated for legitimate reasons.
diff --git a/versions/8.2.1/run/build.mdx b/versions/8.2.1/run/build.mdx
index 5d16ff40..26ded2d3 100644
--- a/versions/8.2.1/run/build.mdx
+++ b/versions/8.2.1/run/build.mdx
@@ -633,8 +633,7 @@ Note: Hermeticity means that the action only uses its declared input
 files and no other files in the filesystem, and it only produces its declared
 output files. See [Hermeticity](/versions/8.2.1/basics/hermeticity) for more details.
 
-On some platforms such as [Google Kubernetes
-Engine](https://cloud.google.com/kubernetes-engine/) cluster nodes or Debian,
+On some platforms such as [Google Kubernetes Engine](https://cloud.google.com/kubernetes-engine/) cluster nodes or Debian,
 user namespaces are deactivated by default due to security
 concerns. This can be checked by looking at the file
 `/proc/sys/kernel/unprivileged_userns_clone`: if it exists and contains a 0,
diff --git a/versions/8.2.1/start/android-app.mdx b/versions/8.2.1/start/android-app.mdx
index 9066787e..56cefe70 100644
--- a/versions/8.2.1/start/android-app.mdx
+++ b/versions/8.2.1/start/android-app.mdx
@@ -36,8 +36,7 @@ In this tutorial you learn how to:
 Before you begin the tutorial, install the following software:
 
 * **Bazel.** To install, follow the [installation instructions](/versions/8.2.1/install).
-* **Android Studio.** To install, follow the steps to [download Android
-  Studio](https://developer.android.com/sdk/index.html).
+* **Android Studio.** To install, follow the steps to [download Android Studio](https://developer.android.com/sdk/index.html).
   Execute the setup wizard to download the SDK and configure your environment.
 * (Optional) **Git.** Use `git` to download the Android app project.
 
@@ -52,8 +51,7 @@ This app has a single button that prints a greeting when clicked:
 
 **Figure 1.** Android app button greeting.
 
-Clone the repository with `git` (or [download the ZIP file
-directly](https://github.com/bazelbuild/examples/archive/master.zip)):
+Clone the repository with `git` (or [download the ZIP file directly](https://github.com/bazelbuild/examples/archive/master.zip)):
 
 ```posix-terminal
 git clone https://github.com/bazelbuild/examples
@@ -103,8 +101,7 @@ A [workspace](/versions/8.2.1/concepts/build-ref#workspace) is a directory that
 source files for one or more software projects, and has a `MODULE.bazel` file at
 its root.
 
-The `MODULE.bazel` file may be empty or may contain references to [external
-dependencies](/versions/8.2.1/external/overview) required to build your project.
+The `MODULE.bazel` file may be empty or may contain references to [external dependencies](/versions/8.2.1/external/overview) required to build your project.
 
 First, run the following command to create an empty `MODULE.bazel` file:
 
@@ -147,8 +144,7 @@ environment variable, and automatically detect the highest API level and the
 latest version of build tools installed within that location.
 
 You can set the `ANDROID_HOME` variable to the location of the Android SDK. Find
-the path to the installed SDK using Android Studio's [SDK
-Manager](https://developer.android.com/studio/intro/update#sdk-manager).
+the path to the installed SDK using Android Studio's [SDK Manager](https://developer.android.com/studio/intro/update#sdk-manager).
 Assuming the SDK is installed to default locations, you can use the following
 commands to set the `ANDROID_HOME` variable:
 
@@ -170,16 +166,14 @@ them permanent, run the following commands:
 | Windows (PowerShell)     | `[System.Environment]::SetEnvironmentVariable('ANDROID_HOME', "$env:LOCALAPPDATA\Android\Sdk", [System.EnvironmentVariableTarget]::User)` |
 
 **Optional:** If you want to compile native code into your Android app, you
-also need to download the [Android
-NDK](https://developer.android.com/ndk/downloads/index.html)
+also need to download the [Android NDK](https://developer.android.com/ndk/downloads/index.html)
 and use `rules_android_ndk` by adding the following line to your `MODULE.bazel` file:
 
 ```python
 bazel_dep(name = "rules_android_ndk", version = "0.1.2")
 ```
 
-For more information, read [Using the Android Native Development Kit with
-Bazel](/versions/8.2.1/docs/android-ndk).
+For more information, read [Using the Android Native Development Kit with Bazel](/versions/8.2.1/docs/android-ndk).
 
 It's not necessary to set the API levels to the same value for the SDK and NDK.
 [This page](https://developer.android.com/ndk/guides/stable_apis.html)
@@ -221,8 +215,7 @@ files or other dependencies. Bazel provides two build rules,
 build an Android app.
 
 For this tutorial, you'll first use the
-`android_library` rule to tell Bazel to build an [Android library
-module](http://developer.android.com/tools/projects/index.html#LibraryProjects)
+`android_library` rule to tell Bazel to build an [Android library module](http://developer.android.com/tools/projects/index.html#LibraryProjects)
 from the app source code and resource files. You'll then use the
 `android_binary` rule to tell Bazel how to build the Android application package.
 
@@ -337,11 +330,9 @@ file:
 ### Run the app
 
 You can now deploy the app to a connected Android device or emulator from the
-command line using the [`bazel
-mobile-install`](/versions/8.2.1/docs/user-manual#mobile-install) command. This command uses
+command line using the [`bazel mobile-install`](/versions/8.2.1/docs/user-manual#mobile-install) command. This command uses
 the Android Debug Bridge (`adb`) to communicate with the device. You must set up
-your device to use `adb` following the instructions in [Android Debug
-Bridge](http://developer.android.com/tools/help/adb.html) before deployment. You
+your device to use `adb` following the instructions in [Android Debug Bridge](http://developer.android.com/tools/help/adb.html) before deployment. You
 can also choose to install the app on the Android emulator included in Android
 Studio. Make sure the emulator is running before executing the command below.
 
diff --git a/versions/8.2.1/start/cpp.mdx b/versions/8.2.1/start/cpp.mdx
index 646bd7db..6329e2da 100644
--- a/versions/8.2.1/start/cpp.mdx
+++ b/versions/8.2.1/start/cpp.mdx
@@ -19,8 +19,7 @@ Estimated completion time: 30 minutes.
 ### Prerequisites {#prerequisites}
 
 Start by [installing Bazel](https://bazel.build/versions/8.2.1/install), if you haven't
-already. This tutorial uses Git for source control, so for best results [install
-Git](https://git-scm.com/book/en/v2/Getting-Started-Installing-Git) as well.
+already. This tutorial uses Git for source control, so for best results [install Git](https://git-scm.com/book/en/v2/Getting-Started-Installing-Git) as well.
 
 Next, retrieve the sample project from Bazel's GitHub repository by running the
 following in your command-line tool of choice:
@@ -63,9 +62,7 @@ examples
 ```
 
 There are three sets of files, each set representing a stage in this tutorial.
-In the first stage, you will build a single [target]
-(https://bazel.build/reference/glossary#target) residing in a single [package]
-(https://bazel.build/reference/glossary#package). In the second stage, you will
+In the first stage, you will build a single [target](https://bazel.build/reference/glossary#target) residing in a single [package](https://bazel.build/reference/glossary#package). In the second stage, you will
 build both a binary and a library from a single package. In the third and final
 stage, you will build a project with multiple packages and build it with
 multiple targets.
@@ -86,8 +83,7 @@ It also contains these significant files:
 *   The `MODULE.bazel` file, which identifies the directory and its contents as
     a Bazel workspace and lives at the root of the project's directory
     structure. It's also where you specify your external dependencies.
-*   One or more [`BUILD`
-    files](https://bazel.build/reference/glossary#build-file), which tell Bazel
+*   One or more [`BUILD` files](https://bazel.build/reference/glossary#build-file), which tell Bazel
     how to build different parts of the project. A directory within the
     workspace that contains a `BUILD` file is a
     [package](https://bazel.build/versions/8.2.1/reference/glossary#package). (More on packages
@@ -182,9 +178,7 @@ This results in a printed "`Hello world`" message.
 
 Here's the dependency graph of Stage 1:
 
-![Dependency graph for hello-world displays a single target with a single source
-file.](/versions/8.2.1/docs/images/cpp-tutorial-stage1.png "Dependency graph for hello-world
-displays a single target with a single source file.")
+![Dependency graph for hello-world displays a single target with a single source file.](/versions/8.2.1/docs/images/cpp-tutorial-stage1.png "Dependency graph for hello-world displays a single target with a single source file.")
 
 ### Summary: stage 1 {#summary-stage-1}
 
@@ -231,8 +225,7 @@ cc_binary(
 ```
 
 With this `BUILD` file, Bazel first builds the `hello-greet` library (using
-Bazel's built-in [`cc_library`
-rule](https://bazel.build/reference/be/c-cpp#cc_library)), then the
+Bazel's built-in [`cc_library` rule](https://bazel.build/reference/be/c-cpp#cc_library)), then the
 `hello-world` binary. The `deps` attribute in the `hello-world` target tells
 Bazel that the `hello-greet` library is required to build the `hello-world`
 binary.
@@ -272,10 +265,7 @@ recompiles that file.
 Looking at the dependency graph, you can see that `hello-world` depends on an
 extra input named `hello-greet`:
 
-![Dependency graph for `hello-world` displays dependency changes after
-modification to the file.](/versions/8.2.1/docs/images/cpp-tutorial-stage2.png "Dependency
-graph for `hello-world` displays dependency changes after modification to the
-file.")
+![Dependency graph for `hello-world` displays dependency changes after modification to the file.](/versions/8.2.1/docs/images/cpp-tutorial-stage2.png "Dependency graph for `hello-world` displays dependency changes after modification to the file.")
 
 ### Summary: stage 2 {#summary-stage-2}
 
@@ -343,11 +333,7 @@ in the `lib` package (hence the target label `//lib:hello-time`) - Bazel knows
 this through the `deps` attribute. You can see this reflected in the dependency
 graph:
 
-![Dependency graph for `hello-world` displays how the target in the main package
-depends on the target in the `lib`
-package.](/versions/8.2.1/docs/images/cpp-tutorial-stage3.png "Dependency graph for
-`hello-world` displays how the target in the main package depends on the target
-in the `lib` package.")
+![Dependency graph for `hello-world` displays how the target in the main package depends on the target in the `lib` package.](/versions/8.2.1/docs/images/cpp-tutorial-stage3.png "Dependency graph for `hello-world` displays how the target in the main package depends on the target in the `lib` package.")
 
 For the build to succeed, you make the `//lib:hello-time` target in `lib/BUILD`
 explicitly visible to targets in `main/BUILD` using the visibility attribute.
@@ -395,15 +381,11 @@ Bazel journey.
 You've now completed your first basic build with Bazel, but this is just the
 start. Here are some more resources to continue learning with Bazel:
 
-*   To keep focusing on C++, read about common [C++ build use
-    cases](https://bazel.build/tutorials/cpp-use-cases).
+*   To keep focusing on C++, read about common [C++ build use cases](https://bazel.build/tutorials/cpp-use-cases).
 *   To get started with building other applications with Bazel, see the
-    tutorials for [Java](https://bazel.build/versions/8.2.1/start/java), [Android
-    application](https://bazel.build/start/android-app), or [iOS
-    application](https://bazel.build/start/ios-app).
+    tutorials for [Java](https://bazel.build/versions/8.2.1/start/java), [Android application](https://bazel.build/start/android-app), or [iOS application](https://bazel.build/start/ios-app).
 *   To learn more about working with local and remote repositories, read about
     [external dependencies](https://bazel.build/versions/8.2.1/docs/external).
-*   To learn more about Bazel's other rules, see this [reference
-    guide](https://bazel.build/rules).
+*   To learn more about Bazel's other rules, see this [reference guide](https://bazel.build/rules).
 
 Happy building!
\ No newline at end of file
diff --git a/versions/8.2.1/start/java.mdx b/versions/8.2.1/start/java.mdx
index ada49454..9f32ab1e 100644
--- a/versions/8.2.1/start/java.mdx
+++ b/versions/8.2.1/start/java.mdx
@@ -241,8 +241,7 @@ recompiles that file.
 Looking at the dependency graph, you can see that `ProjectRunner` depends on the
 same inputs as it did before, but the structure of the build is different:
 
-![Dependency graph of the target 'ProjectRunner' after adding a dependency](
-/docs/images/tutorial_java_02.svg)
+![Dependency graph of the target 'ProjectRunner' after adding a dependency](/docs/images/tutorial_java_02.svg)
 
 You've now built the project with two targets. The `ProjectRunner` target builds
 one source files and depends on one other target (`:greeter`), which builds
diff --git a/versions/8.2.1/tutorials/ccp-toolchain-config.mdx b/versions/8.2.1/tutorials/ccp-toolchain-config.mdx
index 4c3b46c7..d486e4d9 100644
--- a/versions/8.2.1/tutorials/ccp-toolchain-config.mdx
+++ b/versions/8.2.1/tutorials/ccp-toolchain-config.mdx
@@ -29,8 +29,7 @@ uses `clang version 16`, which you can install on your system.
 
 Set up your build environment as follows:
 
-1.  If you have not already done so, [download and install Bazel
-    7.0.2](https://bazel.build/install) or later.
+1.  If you have not already done so, [download and install Bazel 7.0.2](https://bazel.build/install) or later.
 
 2.  Add an empty `MODULE.bazel` file at the root folder.
 
@@ -450,8 +449,7 @@ The key takeaways are:
 
 -   You need to specify a matching `platforms` flag in the command line for
     Bazel to resolve to the toolchain for the same constraint values on the
-    platform. The documentation holds more [information about language specific
-    configuration flags](/versions/8.2.1/concepts/platforms).
+    platform. The documentation holds more [information about language specific configuration flags](/versions/8.2.1/concepts/platforms).
 -   You have to let the toolchain know where the tools live. In this tutorial
     there is a simplified version where you access the tools from the system. If
     you are interested in a more self-contained approach, you can read about
@@ -464,5 +462,4 @@ The key takeaways are:
 
 ## Further reading {#further-reading}
 
-For more details, see [C++ toolchain
-configuration](/versions/8.2.1/docs/cc-toolchain-config-reference)
\ No newline at end of file
+For more details, see [C++ toolchain configuration](/versions/8.2.1/docs/cc-toolchain-config-reference)
\ No newline at end of file
diff --git a/versions/8.3.1/about/roadmap.mdx b/versions/8.3.1/about/roadmap.mdx
index f36a5b4d..005a7c0f 100644
--- a/versions/8.3.1/about/roadmap.mdx
+++ b/versions/8.3.1/about/roadmap.mdx
@@ -13,8 +13,7 @@ projects.
 
 ## Bazel 8.0 Release
 
-We plan to bring Bazel 8.0 [long term support
-(LTS)](https://bazel.build/release/versioning) to you in late 2024.
+We plan to bring Bazel 8.0 [long term support (LTS)](https://bazel.build/release/versioning) to you in late 2024.
 The following features are planned to be implemented.
 
 ### Bzlmod: external dependency management system
@@ -29,8 +28,7 @@ support will be removed. Starting with Bazel 7.1, you can set
 `--noenable_workspace` to opt into the new behavior.
 
 Bazel 8.0 will contain a number of enhancements to
-[Bazel's external dependency management]
-(https://docs.google.com/document/d/1moQfNcEIttsk6vYanNKIy3ZuK53hQUFq1b1r0rmsYVg/edit#heading=h.lgyp7ubwxmjc)
+[Bazel's external dependency management](https://docs.google.com/document/d/1moQfNcEIttsk6vYanNKIy3ZuK53hQUFq1b1r0rmsYVg/edit#heading=h.lgyp7ubwxmjc)
 functionality, including:
 
 *   The new flag `--enable_workspace` can be set to `false` to completely
diff --git a/versions/8.3.1/basics/dependencies.mdx b/versions/8.3.1/basics/dependencies.mdx
index 206d99d5..0c178469 100644
--- a/versions/8.3.1/basics/dependencies.mdx
+++ b/versions/8.3.1/basics/dependencies.mdx
@@ -65,8 +65,7 @@ targets, we’ve made some strides in mitigating the downside by investing in
 tooling to automatically manage `BUILD` files to avoid burdening developers.
 
 Some of these tools, such as `buildifier` and `buildozer`, are available with
-Bazel in the [`buildtools`
-directory](https://github.com/bazelbuild/buildtools).
+Bazel in the [`buildtools` directory](https://github.com/bazelbuild/buildtools).
 
 ## Minimizing Module Visibility
 
@@ -106,8 +105,7 @@ transitive dependencies (Figure 1). Suppose target A depends on target B, which
 depends on a common library target C. Should target A be able to use classes
 defined in target C?
 
-[![Transitive
-dependencies](/versions/8.3.1/images/transitive-dependencies.png)](/versions/8.3.1/images/transitive-dependencies.png)
+[![Transitive dependencies](/versions/8.3.1/images/transitive-dependencies.png)](/versions/8.3.1/images/transitive-dependencies.png)
 
 **Figure 1**. Transitive dependencies
 
@@ -141,9 +139,7 @@ dependencies and adding them to a `BUILD` files without any developer
 intervention. But even without such tools, we’ve found the trade-off to be well
 worth it as the codebase scales: explicitly adding a dependency to `BUILD` file
 is a one-time cost, but dealing with implicit transitive dependencies can cause
-ongoing problems as long as the build target exists. Bazel [enforces strict
-transitive
-dependencies](https://blog.bazel.build/2017/06/28/sjd-unused_deps.html)
+ongoing problems as long as the build target exists. Bazel [enforces strict transitive dependencies](https://blog.bazel.build/2017/06/28/sjd-unused_deps.html)
 on Java code by default.
 
 ### External dependencies
@@ -192,8 +188,7 @@ so in theory there’s no reason that different versions of the same external
 dependency couldn’t both be declared in the build system under different names.
 That way, each target could choose which version of the dependency it wanted to
 use. This causes a lot of problems in practice, so Google enforces a strict
-[One-Version
-Rule](https://opensource.google/docs/thirdparty/oneversion/) for
+[One-Version Rule](https://opensource.google/docs/thirdparty/oneversion/) for
 all third-party dependencies in our codebase.
 
 The biggest problem with allowing multiple versions is the diamond dependency
@@ -232,8 +227,7 @@ Bazel did not use to automatically download transitive dependencies. It used to
 employ a `WORKSPACE` file that required all transitive dependencies to be
 listed, which led to a lot of pain when managing external dependencies. Bazel
 has since added support for automatic transitive external dependency management
-in the form of the `MODULE.bazel` file. See [external dependency
-overview](/versions/8.3.1/external/overview) for more details.
+in the form of the `MODULE.bazel` file. See [external dependency overview](/versions/8.3.1/external/overview) for more details.
 
 Yet again, the choice here is one between convenience and scalability. Small
 projects might prefer not having to worry about managing transitive dependencies
diff --git a/versions/8.3.1/community/roadmaps-configurability.mdx b/versions/8.3.1/community/roadmaps-configurability.mdx
index 82422d88..e8887edf 100644
--- a/versions/8.3.1/community/roadmaps-configurability.mdx
+++ b/versions/8.3.1/community/roadmaps-configurability.mdx
@@ -26,8 +26,7 @@ title: 'Bazel Configurability 2021 Roadmap'
 * Builds scale well, particularly w.r.t graph size and action caching.
 
 We also support
-[`cquery`](https://bazel.build/versions/8.3.1/query/cquery), [`Starlark
-configuration`](https://bazel.build/extending/config),
+[`cquery`](https://bazel.build/versions/8.3.1/query/cquery), [`Starlark configuration`](https://bazel.build/extending/config),
 and
 [`select()`](https://bazel.build/versions/8.3.1/docs/configurable-attributes).
 
@@ -41,15 +40,13 @@ interest of accurate expectations.
 ### Platforms
 
 

-Q3 2021**Android rules use the new [platforms
-API](https://bazel.build/concepts/platforms)**
+Q3 2021**Android rules use the new [platforms API](https://bazel.build/concepts/platforms)**
 IN PROGRESS ([#11749](https://github.com/bazelbuild/bazel/issues/11749))
 
 * This is our main priority for the beginning of 2021.
 
 

-Q3 2021**Builds support [multiple execution
-platforms](https://docs.google.com/document/d/1U9HzdDmtRnm244CaRM6JV-q2408mbNODAMewcGjnnbM/)**
+Q3 2021**Builds support [multiple execution platforms](https://docs.google.com/document/d/1U9HzdDmtRnm244CaRM6JV-q2408mbNODAMewcGjnnbM/)**
 IN PROGRESS ([#11748](https://github.com/bazelbuild/bazel/issues/11748))
 
 

diff --git a/versions/8.3.1/community/sig.mdx b/versions/8.3.1/community/sig.mdx
index 02c15497..9bde03d5 100644
--- a/versions/8.3.1/community/sig.mdx
+++ b/versions/8.3.1/community/sig.mdx
@@ -3,8 +3,7 @@ title: 'Bazel Special Interest Groups'
 ---
 
 Bazel hosts Special Interest Groups (SIGs) to focus collaboration on particular
-areas and to support communication and coordination between [Bazel owners,
-maintainers, and contributors](/versions/8.3.1/contribute/policy). This policy
+areas and to support communication and coordination between [Bazel owners, maintainers, and contributors](/versions/8.3.1/contribute/policy). This policy
 applies to [`bazelbuild`](http://github.com/bazelbuild).
 
 SIGs do their work in public. The ideal scope for a SIG covers a well-defined
diff --git a/versions/8.3.1/community/users.mdx b/versions/8.3.1/community/users.mdx
index 9ab2ef1f..ff669ef3 100644
--- a/versions/8.3.1/community/users.mdx
+++ b/versions/8.3.1/community/users.mdx
@@ -304,11 +304,9 @@ safety systems_.
 Pigweed is an open-source solution for sustained, robust, and rapid embedded
 product development for large teams. Pigweed has shipped in millions of
 devices, including Google's suite of Pixel devices, Nest thermostats,
-[satellites](https://www.spinlaunch.com/), and [autonomous aerial
-drones](https://www.flyzipline.com/).
+[satellites](https://www.spinlaunch.com/), and [autonomous aerial drones](https://www.flyzipline.com/).
 
-Pigweed [uses Bazel as its primary build
-system](https://pigweed.dev/seed/0111-build-systems.html). The [Bazel for
+Pigweed [uses Bazel as its primary build system](https://pigweed.dev/seed/0111-build-systems.html). The [Bazel for
 Embedded][pw-bazel-great] blog post discusses why we think it's a great build
 system for embedded projects!
 
diff --git a/versions/8.3.1/concepts/build-files.mdx b/versions/8.3.1/concepts/build-files.mdx
index 934730fb..0b4501f1 100644
--- a/versions/8.3.1/concepts/build-files.mdx
+++ b/versions/8.3.1/concepts/build-files.mdx
@@ -132,12 +132,3 @@ for anyone to create new rules.
     programming language. Libraries can depend on other libraries,
     and binaries and tests can depend on libraries, with the expected
     separate-compilation behavior.
-
-
-  
-    
-    
-  
-
LabelsDependencies

diff --git a/versions/8.3.1/concepts/build-ref.mdx b/versions/8.3.1/concepts/build-ref.mdx
index d14bae3d..6e6ecbd0 100644
--- a/versions/8.3.1/concepts/build-ref.mdx
+++ b/versions/8.3.1/concepts/build-ref.mdx
@@ -17,8 +17,7 @@ its root; such a boundary marker file could be `MODULE.bazel`, `REPO.bazel`, or
 in legacy contexts, `WORKSPACE` or `WORKSPACE.bazel`.
 
 The repo in which the current Bazel command is being run is called the _main
-repo_. Other, (external) repos are defined by _repo rules_; see [external
-dependencies overview](/versions/8.3.1/external/overview) for more information.
+repo_. Other, (external) repos are defined by _repo rules_; see [external dependencies overview](/versions/8.3.1/external/overview) for more information.
 
 ## Workspace {#workspace}
 
@@ -95,9 +94,4 @@ have three properties: the list of packages they contain, their name, and other
 package groups they include. The only allowed ways to refer to them are from the
 `visibility` attribute of rules or from the `default_visibility` attribute of
 the `package` function; they do not generate or consume files. For more
-information, refer to the [`package_group`
-documentation](/versions/8.3.1/reference/be/functions#package_group).
-
-
-  Labels
-
\ No newline at end of file
+information, refer to the [`package_group` documentation](/versions/8.3.1/reference/be/functions#package_group).
diff --git a/versions/8.3.1/concepts/dependencies.mdx b/versions/8.3.1/concepts/dependencies.mdx
index 19a142db..15af2848 100644
--- a/versions/8.3.1/concepts/dependencies.mdx
+++ b/versions/8.3.1/concepts/dependencies.mdx
@@ -349,13 +349,3 @@ filegroup(
 ```
 
 You can then reference the label `my_data` as the data dependency in your test.
-
-
-  
-    
-    
-  
-
BUILD filesVisibility

-
diff --git a/versions/8.3.1/concepts/labels.mdx b/versions/8.3.1/concepts/labels.mdx
index 69ba4335..3addec7a 100644
--- a/versions/8.3.1/concepts/labels.mdx
+++ b/versions/8.3.1/concepts/labels.mdx
@@ -10,8 +10,7 @@ form looks like:
 ```
 
 The first part of the label is the repository name, `@@myrepo`. The double-`@`
-syntax signifies that this is a [*canonical* repo
-name](/versions/8.3.1/external/overview#canonical-repo-name), which is unique within
+syntax signifies that this is a [*canonical* repo name](/versions/8.3.1/external/overview#canonical-repo-name), which is unique within
 the workspace. Labels with canonical repo names unambiguously identify a target
 no matter which context they appear in.
 
@@ -239,12 +238,3 @@ the build.
 This directed acyclic graph over targets is called the _target graph_ or
 _build dependency graph_, and is the domain over which the
 [Bazel Query tool](/versions/8.3.1/query/guide) operates.
-
-
-  
-    
-    
-  
-
TargetsBUILD files

diff --git a/versions/8.3.1/concepts/platforms.mdx b/versions/8.3.1/concepts/platforms.mdx
index e2ea73c7..034dc411 100644
--- a/versions/8.3.1/concepts/platforms.mdx
+++ b/versions/8.3.1/concepts/platforms.mdx
@@ -77,8 +77,7 @@ To test your Android project with platforms, see
 for support.
 
 You can still use platform APIs with Apple builds (for example, when building
-with a mixture of Apple rules and pure C++) with [platform
-mappings](#platform-mappings).
+with a mixture of Apple rules and pure C++) with [platform mappings](#platform-mappings).
 
 ### Other languages {#other-languages}
 
@@ -241,8 +240,7 @@ sets `--cpu`, `--crossstool_top`, or other legacy flags, rules that read
 
 When migrating your project to platforms, you must either convert changes like
 `return { "//command_line_option:cpu": "arm" }` to `return {
-"//command_line_option:platforms": "//:my_arm_platform" }` or use [platform
-mappings](#platform-mappings) to support both styles during migration.
+"//command_line_option:platforms": "//:my_arm_platform" }` or use [platform mappings](#platform-mappings) to support both styles during migration.
 window.
 
 ## Migrating your rule set {#migrating-your-rule-set}
@@ -361,10 +359,8 @@ attributes declare a language's tools (like `compiler =
 this information to rules that need to build with these tools.
 
 Toolchains declare the `constraint_value`s of machines they can
-[target][target_compatible_with Attribute]
-(`target_compatible_with = ["@platforms//os:linux"]`) and machines their tools can
-[run on][exec_compatible_with Attribute]
-(`exec_compatible_with = ["@platforms//os:mac"]`).
+[target][target_compatible_with Attribute](`target_compatible_with = ["@platforms//os:linux"]`) and machines their tools can
+[run on][exec_compatible_with Attribute](`exec_compatible_with = ["@platforms//os:mac"]`).
 
 When building `$ bazel build //:myproject --platforms=//:myplatform`, Bazel
 automatically selects a toolchain that can run on the build machine and
diff --git a/versions/8.3.1/configure/attributes.mdx b/versions/8.3.1/configure/attributes.mdx
index e69c40b6..13ccadd7 100644
--- a/versions/8.3.1/configure/attributes.mdx
+++ b/versions/8.3.1/configure/attributes.mdx
@@ -2,8 +2,7 @@
 title: 'Configurable Build Attributes'
 ---
 
-**_Configurable attributes_**, commonly known as [`select()`](
-/reference/be/functions#select), is a Bazel feature that lets users toggle the values
+**_Configurable attributes_**, commonly known as [`select()`](/reference/be/functions#select), is a Bazel feature that lets users toggle the values
 of build rule attributes at the command line.
 
 This can be used, for example, for a multiplatform library that automatically
@@ -407,8 +406,7 @@ sh_library(
 )
 ```
 
-If you need a `select` to match when multiple conditions match, consider [AND
-chaining](#and-chaining).
+If you need a `select` to match when multiple conditions match, consider [AND chaining](#and-chaining).
 
 ## OR chaining {#or-chaining}
 
diff --git a/versions/8.3.1/configure/integrate-cpp.mdx b/versions/8.3.1/configure/integrate-cpp.mdx
index 3285d0eb..b6fbd806 100644
--- a/versions/8.3.1/configure/integrate-cpp.mdx
+++ b/versions/8.3.1/configure/integrate-cpp.mdx
@@ -33,8 +33,7 @@ This is because when writing our own actions, they must behave
 consistently with the C++ toolchain - for example, passing C++ command line
 flags to a tool that invokes the C++ compiler behind the scenes.
 
-C++ rules use a special way of constructing command lines based on [feature
-configuration](/versions/8.3.1/docs/cc-toolchain-config-reference). To construct a command line,
+C++ rules use a special way of constructing command lines based on [feature configuration](/versions/8.3.1/docs/cc-toolchain-config-reference). To construct a command line,
 you need the following:
 
 * `features` and `action_configs` - these come from the `CcToolchainConfigInfo`
diff --git a/versions/8.3.1/configure/windows.mdx b/versions/8.3.1/configure/windows.mdx
index d7ec8c08..565de620 100644
--- a/versions/8.3.1/configure/windows.mdx
+++ b/versions/8.3.1/configure/windows.mdx
@@ -166,8 +166,7 @@ To build C++ targets with MSVC, you need:
         set BAZEL_VC=C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC
         ```
 
-*   The [Windows
-    SDK](https://developer.microsoft.com/en-us/windows/downloads/windows-10-sdk).
+*   The [Windows SDK](https://developer.microsoft.com/en-us/windows/downloads/windows-10-sdk).
 
     The Windows SDK contains header files and libraries you need when building
     Windows applications, including Bazel itself. By default, the latest Windows SDK installed will
@@ -186,8 +185,7 @@ To build C++ targets with MSVC, you need:
 
 If everything is set up, you can build a C++ target now!
 
-Try building a target from one of our [sample
-projects](https://github.com/bazelbuild/bazel/tree/master/examples):
+Try building a target from one of our [sample projects](https://github.com/bazelbuild/bazel/tree/master/examples):
 
 
 
 
-To build and use Dynamically Linked Libraries (DLL files), see [this
-example](https://github.com/bazelbuild/bazel/tree/master/examples/windows/dll).
+To build and use Dynamically Linked Libraries (DLL files), see [this example](https://github.com/bazelbuild/bazel/tree/master/examples/windows/dll).
 
 **Command Line Length Limit**: To prevent the
 [Windows command line length limit issue](https://github.com/bazelbuild/bazel/issues/5163),
@@ -292,8 +289,7 @@ On Windows, Bazel builds two output files for `java_binary` rules:
 *   a `.jar` file
 *   a `.exe` file that can set up the environment for the JVM and run the binary
 
-Try building a target from one of our [sample
-projects](https://github.com/bazelbuild/bazel/tree/master/examples):
+Try building a target from one of our [sample projects](https://github.com/bazelbuild/bazel/tree/master/examples):
 
 
   
   
 
 If you are interested in details about how Bazel builds Python targets on
-Windows, check out this [design
-doc](https://github.com/bazelbuild/bazel-website/blob/master/designs/_posts/2016-09-05-build-python-on-windows.md).
+Windows, check out this [design doc](https://github.com/bazelbuild/bazel-website/blob/master/designs/_posts/2016-09-05-build-python-on-windows.md).
diff --git a/versions/8.3.1/contribute/codebase.mdx b/versions/8.3.1/contribute/codebase.mdx
index 8e403a32..6b03e1f6 100644
--- a/versions/8.3.1/contribute/codebase.mdx
+++ b/versions/8.3.1/contribute/codebase.mdx
@@ -227,8 +227,7 @@ repository", the others are called "external repositories".
 A repository is marked by a repo boundary file (`MODULE.bazel`, `REPO.bazel`, or
 in legacy contexts, `WORKSPACE` or `WORKSPACE.bazel`) in its root directory. The
 main repo is the source tree where you're invoking Bazel from. External repos
-are defined in various ways; see [external dependencies
-overview](/versions/8.3.1/external/overview) for more information.
+are defined in various ways; see [external dependencies overview](/versions/8.3.1/external/overview) for more information.
 
 Code of external repositories is symlinked or downloaded under
 `$OUTPUT_BASE/external`.
diff --git a/versions/8.3.1/contribute/design-documents.mdx b/versions/8.3.1/contribute/design-documents.mdx
index 69e3ff86..3221deea 100644
--- a/versions/8.3.1/contribute/design-documents.mdx
+++ b/versions/8.3.1/contribute/design-documents.mdx
@@ -137,8 +137,7 @@ A lead reviewer should be a domain expert who is:
 *   Objective and capable of providing constructive feedback
 *   Available for the entire review period to lead the process
 
-Consider checking the contacts for various [team
-labels](/versions/8.3.1/contribute/maintainers-guide#team-labels).
+Consider checking the contacts for various [team labels](/versions/8.3.1/contribute/maintainers-guide#team-labels).
 
 ## Markdown vs Google Docs {#markdown-versus-gdocs}
 
@@ -168,12 +167,10 @@ Markdown for posterity.
 
 ### Using Google Docs {#gdocs}
 
-For consistency, use the [Bazel design doc template](
-https://docs.google.com/document/d/1cE5zrjrR40RXNg64XtRFewSv6FrLV6slGkkqxBumS1w/edit).
+For consistency, use the [Bazel design doc template](https://docs.google.com/document/d/1cE5zrjrR40RXNg64XtRFewSv6FrLV6slGkkqxBumS1w/edit).
 It includes the necessary header and creates visual
 consistency with other Bazel related documents. To do that, click on **File** >
-**Make a copy** or click this link to [make a copy of the design doc
-template](https://docs.google.com/document/d/1cE5zrjrR40RXNg64XtRFewSv6FrLV6slGkkqxBumS1w/copy).
+**Make a copy** or click this link to [make a copy of the design doc template](https://docs.google.com/document/d/1cE5zrjrR40RXNg64XtRFewSv6FrLV6slGkkqxBumS1w/copy).
 
 To make your document readable to the world, click on
 **Share** > **Advanced** > **Change…**, and
diff --git a/versions/8.3.1/contribute/index.mdx b/versions/8.3.1/contribute/index.mdx
index 8f99cfae..2e243a53 100644
--- a/versions/8.3.1/contribute/index.mdx
+++ b/versions/8.3.1/contribute/index.mdx
@@ -10,8 +10,7 @@ As you use Bazel, you may find things that can be improved.
 You can help by [reporting issues](http://github.com/bazelbuild/bazel/issues)
 when:
 
-   - Bazel crashes or you encounter a bug that can [only be resolved using `bazel
-     clean`](/versions/8.3.1/run/build#correct-incremental-rebuilds).
+   - Bazel crashes or you encounter a bug that can [only be resolved using `bazel clean`](/versions/8.3.1/run/build#correct-incremental-rebuilds).
    - The documentation is incomplete or unclear. You can also report issues
      from the page you are viewing by using the "Create issue"
      link at the top right corner of the page.
@@ -21,11 +20,9 @@ when:
 
 You can engage with the Bazel community by:
 
-   - Answering questions [on Stack Overflow](
-     https://stackoverflow.com/questions/tagged/bazel).
+   - Answering questions [on Stack Overflow](https://stackoverflow.com/questions/tagged/bazel).
    - Helping other users [on Slack](https://slack.bazel.build).
-   - Improving documentation or [contributing examples](
-     https://github.com/bazelbuild/examples).
+   - Improving documentation or [contributing examples](https://github.com/bazelbuild/examples).
    - Sharing your experience or your tips, for example, on a blog or social media.
 
 ## Contribute code {#contribute-code}
@@ -40,8 +37,7 @@ You can contribute to the Bazel ecosystem by:
    - Contributing to Bazel-related tools, for example, migration tools.
    - Improving Bazel integration with other IDEs and tools.
 
-Before making a change, [create a GitHub
-issue](http://github.com/bazelbuild/bazel/issues)
+Before making a change, [create a GitHub issue](http://github.com/bazelbuild/bazel/issues)
 or email [bazel-discuss@](mailto:bazel-discuss@googlegroups.com).
 
 The most helpful contributions fix bugs or add features (as opposed
diff --git a/versions/8.3.1/contribute/maintainers-guide.mdx b/versions/8.3.1/contribute/maintainers-guide.mdx
index 59789908..7f94e69b 100644
--- a/versions/8.3.1/contribute/maintainers-guide.mdx
+++ b/versions/8.3.1/contribute/maintainers-guide.mdx
@@ -4,8 +4,7 @@ title: 'Guide for Bazel Maintainers'
 
 This is a guide for the maintainers of the Bazel open source project.
 
-If you are looking to contribute to Bazel, please read [Contributing to
-Bazel](/versions/8.3.1/contribute) instead.
+If you are looking to contribute to Bazel, please read [Contributing to Bazel](/versions/8.3.1/contribute) instead.
 
 The objectives of this page are to:
 
@@ -37,8 +36,7 @@ repository.
 
 1. A user creates an issue by choosing one of the
 [issue templates](https://github.com/bazelbuild/bazel/issues/new/choose)
-   and it enters the pool of [unreviewed open
-   issues](https://github.com/bazelbuild/bazel/issues?utf8=%E2%9C%93&q=is%3Aissue+is%3Aopen+-label%3Auntriaged+-label%3Ap2+-label%3Ap1+-label%3Ap3+-label%3Ap4+-label%3Ateam-Starlark+-label%3Ateam-Rules-CPP+-label%3Ateam-Rules-Java+-label%3Ateam-XProduct+-label%3Ateam-Android+-label%3Ateam-Apple+-label%3Ateam-Configurability++-label%3Ateam-Performance+-label%3Ateam-Rules-Server+-label%3Ateam-Core+-label%3Ateam-Rules-Python+-label%3Ateam-Remote-Exec+-label%3Ateam-Local-Exec+-label%3Ateam-Bazel).
+   and it enters the pool of [unreviewed open issues](https://github.com/bazelbuild/bazel/issues?utf8=%E2%9C%93&q=is%3Aissue+is%3Aopen+-label%3Auntriaged+-label%3Ap2+-label%3Ap1+-label%3Ap3+-label%3Ap4+-label%3Ateam-Starlark+-label%3Ateam-Rules-CPP+-label%3Ateam-Rules-Java+-label%3Ateam-XProduct+-label%3Ateam-Android+-label%3Ateam-Apple+-label%3Ateam-Configurability++-label%3Ateam-Performance+-label%3Ateam-Rules-Server+-label%3Ateam-Core+-label%3Ateam-Rules-Python+-label%3Ateam-Remote-Exec+-label%3Ateam-Local-Exec+-label%3Ateam-Bazel).
 1. A member on the Developer Experience (DevEx) subteam rotation reviews the
    issue.
    1. If the issue is **not a bug** or a **feature request**, the DevEx member
@@ -58,21 +56,18 @@ repository.
 1. After reviewing the issue, the DevEx member decides if the issue requires
    immediate attention. If it does, they will assign the **P0**
    [priority](#priority) label and an owner from the list of team leads.
-1. The DevEx member assigns the `untriaged` label and exactly one [team
-   label](#team-labels) for routing.
+1. The DevEx member assigns the `untriaged` label and exactly one [team label](#team-labels) for routing.
 1. The DevEx member also assigns exactly one `type:` label, such as `type: bug`
    or `type: feature request`, according to the type of the issue.
 1. For platform-specific issues, the DevEx member assigns one `platform:` label,
    such as `platform:apple` for Mac-specific issues.
 1. If the issue is low priority and can be worked on by a new community
    contributor, the DevEx member assigns the `good first issue` label.
-At this stage, the issue enters the pool of [untriaged open
-issues](https://github.com/bazelbuild/bazel/issues?q=is%3Aissue+is%3Aopen+label%3Auntriaged).
+At this stage, the issue enters the pool of [untriaged open issues](https://github.com/bazelbuild/bazel/issues?q=is%3Aissue+is%3Aopen+label%3Auntriaged).
 
 Each Bazel subteam will triage all issues under labels they own, preferably on a
 weekly basis. The subteam will review and evaluate the issue and provide a
-resolution, if possible. If you are an owner of a team label, see [this section
-](#label-own) for more information.
+resolution, if possible. If you are an owner of a team label, see [this section](#label-own) for more information.
 
 When an issue is resolved, it can be closed.
 
@@ -111,8 +106,7 @@ preferably on a weekly basis.
      issue is either P0 or P1 we assume that is actively worked on.
 1. Remove the `untriaged` label.
 
-Note that you need to be in the [bazelbuild
-organization](https://github.com/bazelbuild) to be able to add or remove labels.
+Note that you need to be in the [bazelbuild organization](https://github.com/bazelbuild) to be able to add or remove labels.
 
 ### Pull Requests {#pull-requests}
 
@@ -138,8 +132,7 @@ issues.
   unusable, or a downed service that severely impacts development of the Bazel
   project. This includes regressions introduced in a new release that blocks a
   significant number of users, or an incompatible breaking change that was not
-  compliant to the [Breaking
-  Change](https://docs.google.com/document/d/1q5GGRxKrF_mnwtaPKI487P8OdDRh2nN7jX6U-FXnHL0/edit?pli=1#heading=h.ceof6vpkb3ik)
+  compliant to the [Breaking Change](https://docs.google.com/document/d/1q5GGRxKrF_mnwtaPKI487P8OdDRh2nN7jX6U-FXnHL0/edit?pli=1#heading=h.ceof6vpkb3ik)
   policy. No practical workaround exists.
 * [**P1**](https://github.com/bazelbuild/bazel/labels/P1) - Critical defect or
   feature which should be addressed in the next release, or a serious issue that
diff --git a/versions/8.3.1/contribute/naming.mdx b/versions/8.3.1/contribute/naming.mdx
index 5be66542..232ab686 100644
--- a/versions/8.3.1/contribute/naming.mdx
+++ b/versions/8.3.1/contribute/naming.mdx
@@ -4,8 +4,7 @@ title: 'Naming a Bazel related project'
 
 First, thank you for contributing to the Bazel ecosystem! Please reach out to
 the Bazel community on the
-[bazel-discuss mailing list](https://groups.google.com/forum/#!forum/bazel-discuss
-) to share your project and its suggested name.
+[bazel-discuss mailing list](https://groups.google.com/forum/#!forum/bazel-discuss) to share your project and its suggested name.
 
 If you are building a Bazel related tool or sharing your Skylark rules,
 we recommend following these guidelines for the name of your project:
diff --git a/versions/8.3.1/contribute/patch-acceptance.mdx b/versions/8.3.1/contribute/patch-acceptance.mdx
index f2ed8ad5..c97e11cf 100644
--- a/versions/8.3.1/contribute/patch-acceptance.mdx
+++ b/versions/8.3.1/contribute/patch-acceptance.mdx
@@ -11,29 +11,24 @@ code base.
    need a corresponding issue for tracking.
 1. If you're proposing significant changes, write a
    [design document](/versions/8.3.1/contribute/design-documents).
-1. Ensure you've signed a [Contributor License
-   Agreement](https://cla.developers.google.com).
+1. Ensure you've signed a [Contributor License Agreement](https://cla.developers.google.com).
 1. Prepare a git commit that implements the feature. Don't forget to add tests
    and update the documentation. If your change has user-visible effects, please
    [add release notes](/versions/8.3.1/contribute/release-notes). If it is an incompatible change,
    read the [guide for rolling out breaking changes](/versions/8.3.1/contribute/breaking-changes).
 1. Create a pull request on
    [GitHub](https://github.com/bazelbuild/bazel/pulls). If you're new to GitHub,
-   read [about pull
-   requests](https://help.github.com/articles/about-pull-requests/). Note that
+   read [about pull requests](https://help.github.com/articles/about-pull-requests/). Note that
    we restrict permissions to create branches on the main Bazel repository, so
-   you will need to push your commit to [your own fork of the
-   repository](https://help.github.com/articles/working-with-forks/).
+   you will need to push your commit to [your own fork of the repository](https://help.github.com/articles/working-with-forks/).
 1. A Bazel maintainer should assign you a reviewer within two business days
    (excluding holidays in the USA and Germany). If you aren't assigned a
    reviewer in that time, you can request one by emailing
-   [bazel-discuss@googlegroups.com]
-   (mailto:bazel-discuss@googlegroups.com).
+   [bazel-discuss@googlegroups.com](mailto:bazel-discuss@googlegroups.com).
 1. Work with the reviewer to complete a code review. For each change, create a
    new commit and push it to make changes to your pull request. If the review
    takes too long (for instance, if the reviewer is unresponsive), send an email to
-   [bazel-discuss@googlegroups.com]
-   (mailto:bazel-discuss@googlegroups.com).
+   [bazel-discuss@googlegroups.com](mailto:bazel-discuss@googlegroups.com).
 1. After your review is complete, a Bazel maintainer applies your patch to
    Google's internal version control system.
 
diff --git a/versions/8.3.1/contribute/release-notes.mdx b/versions/8.3.1/contribute/release-notes.mdx
index 751b9f0c..3c3f0d68 100644
--- a/versions/8.3.1/contribute/release-notes.mdx
+++ b/versions/8.3.1/contribute/release-notes.mdx
@@ -16,8 +16,7 @@ the release announcement.
 * If the change adds / removes / changes Bazel in a user-visible way, then it
   may be advantageous to mention it.
 
-If the change is significant, follow the [design document
-policy](/versions/8.3.1/contribute/design-documents) first.
+If the change is significant, follow the [design document policy](/versions/8.3.1/contribute/design-documents) first.
 
 ## Guidelines {#guidelines}
 
@@ -60,10 +59,8 @@ change is about.
 
 ## Process {#process}
 
-As part of the [release
-process](https://github.com/bazelbuild/continuous-integration/blob/master/docs/release-playbook.md),
-we collect the `RELNOTES` tags of every commit. We copy everything in a [Google
-Doc](https://docs.google.com/document/d/1wDvulLlj4NAlPZamdlEVFORks3YXJonCjyuQMUQEmB0/edit)
+As part of the [release process](https://github.com/bazelbuild/continuous-integration/blob/master/docs/release-playbook.md),
+we collect the `RELNOTES` tags of every commit. We copy everything in a [Google Doc](https://docs.google.com/document/d/1wDvulLlj4NAlPZamdlEVFORks3YXJonCjyuQMUQEmB0/edit)
 where we review, edit, and organize the notes.
 
 The release manager sends an email to the
@@ -71,6 +68,4 @@ The release manager sends an email to the
 Bazel contributors are invited to contribute to the document and make sure
 their changes are correctly reflected in the announcement.
 
-Later, the announcement will be submitted to the [Bazel
-blog](https://blog.bazel.build/), using the [bazel-blog
-repository](https://github.com/bazelbuild/bazel-blog/tree/master/_posts).
+Later, the announcement will be submitted to the [Bazel blog](https://blog.bazel.build/), using the [bazel-blog repository](https://github.com/bazelbuild/bazel-blog/tree/master/_posts).
diff --git a/versions/8.3.1/contribute/statemachine-guide.mdx b/versions/8.3.1/contribute/statemachine-guide.mdx
index 521201dd..f39faaab 100644
--- a/versions/8.3.1/contribute/statemachine-guide.mdx
+++ b/versions/8.3.1/contribute/statemachine-guide.mdx
@@ -172,8 +172,7 @@ instead, batches[^4] as many lookups as possible before doing so. The value
 might not be immediately available, for example, requiring a Skyframe restart,
 so the caller specifies what to do with the resulting value using a callback.
 
-The `StateMachine` processor ([`Driver`s and bridging to
-SkyFrame](#drivers-and-bridging)) guarantees that the value is available before
+The `StateMachine` processor ([`Driver`s and bridging to SkyFrame](#drivers-and-bridging)) guarantees that the value is available before
 the next state begins. An example follows.
 
 ```
@@ -284,8 +283,7 @@ and solutions to certain control flow problems.
 ### Sequential states
 
 This is the most common and straightforward control flow pattern. An example of
-this is shown in [Stateful computations inside
-`SkyKeyComputeState`](#stateful-computations).
+this is shown in [Stateful computations inside `SkyKeyComputeState`](#stateful-computations).
 
 ### Branching
 
@@ -545,8 +543,7 @@ section describes the propagation of data values.
 
 ### Implementing `Tasks.lookUp` callbacks
 
-There’s an example of implementing a `Tasks.lookUp` callback in [SkyValue
-lookups](#skyvalue-lookups). This section provides rationale and suggests
+There’s an example of implementing a `Tasks.lookUp` callback in [SkyValue lookups](#skyvalue-lookups). This section provides rationale and suggests
 approaches for handling multiple SkyValues.
 
 #### `Tasks.lookUp` callbacks {#tasks-lookup-callbacks}
@@ -710,8 +707,7 @@ class BarProducer implements StateMachine {
 Tip: It would be tempting to use the more concise signature void `accept(Bar
 value)` rather than the stuttery `void acceptBarValue(Bar value)` above.
 However, `Consumer` is a common overload of `void accept(Bar value)`,
-so doing this often leads to violations of the [Overloads: never
-split](https://google.github.io/styleguide/javaguide.html#s3.4.2-ordering-class-contents)
+so doing this often leads to violations of the [Overloads: never split](https://google.github.io/styleguide/javaguide.html#s3.4.2-ordering-class-contents)
 style-guide rule.
 
 Tip: Using a custom `ResultSink` type instead of a generic one from
@@ -774,14 +770,11 @@ pattern after accepting output from either a subtask or SkyValue lookup.
 Note that the implementation of `acceptBarError` eagerly forwards the result to
 the `Caller.ResultSink`, as required by [Error bubbling](#error-bubbling).
 
-Alternatives for top-level `StateMachine`s are described in [`Driver`s and
-bridging to SkyFunctions](#drivers-and-bridging).
+Alternatives for top-level `StateMachine`s are described in [`Driver`s and bridging to SkyFunctions](#drivers-and-bridging).
 
 ### Error handling {#error-handling}
 
-There's a couple of examples of error handling already in [`Tasks.lookUp`
-callbacks](#tasks-lookup-callbacks) and [Propagating values between
-`StateMachines`](#propagating-values). Exceptions, other than
+There's a couple of examples of error handling already in [`Tasks.lookUp` callbacks](#tasks-lookup-callbacks) and [Propagating values between `StateMachines`](#propagating-values). Exceptions, other than
 `InterruptedException` are not thrown, but instead passed around through
 callbacks as values. Such callbacks often have exclusive-or semantics, with
 exactly one of a value or error being passed.
@@ -1184,8 +1177,7 @@ states. Where it is possible, local stack `step` variables are young generation
 variables and efficiently GC'd.
 
 For `StateMachine` variables, breaking things down into subtasks and following
-the recommended pattern for [Propagating values between
-`StateMachine`s](#propagating-values) is also helpful. Observe that when
+the recommended pattern for [Propagating values between `StateMachine`s](#propagating-values) is also helpful. Observe that when
 following the pattern, only child `StateMachine`s have references to parent
 `StateMachine`s and not vice versa. This means that as children complete and
 update the parents using result callbacks, the children naturally fall out of
@@ -1207,8 +1199,7 @@ potentially reflecting local behavior.
 
 ### Concurrency tree diagram {#concurrency-tree-diagram}
 
-The following is an alternative view of the diagram in [Structured
-concurrency](#structured-concurrency) that better depicts the tree structure.
+The following is an alternative view of the diagram in [Structured concurrency](#structured-concurrency) that better depicts the tree structure.
 The blocks form a small tree.
 
 ![Structured Concurrency 3D](/versions/8.3.1/contribute/images/structured-concurrency-3d.svg)
diff --git a/versions/8.3.1/docs/android-instrumentation-test.mdx b/versions/8.3.1/docs/android-instrumentation-test.mdx
index 057851b8..26a2c8d0 100644
--- a/versions/8.3.1/docs/android-instrumentation-test.mdx
+++ b/versions/8.3.1/docs/android-instrumentation-test.mdx
@@ -2,8 +2,7 @@
 title: 'Android Instrumentation Tests'
 ---
 
-_If you're new to Bazel, start with the [Building Android with
-Bazel](/versions/8.3.1/start/android-app ) tutorial._
+_If you're new to Bazel, start with the [Building Android with Bazel](/versions/8.3.1/start/android-app) tutorial._
 
 ![Running Android instrumentation tests in parallel](/versions/8.3.1/docs/images/android_test.gif "Android instrumentation test")
 
@@ -18,9 +17,7 @@ emulators in a sandbox, ensuring that tests always run from a clean state. Each
 test gets an isolated emulator instance, allowing tests to run in parallel
 without passing states between them.
 
-For more information on Android instrumentation tests, check out the [Android
-developer
-documentation](https://developer.android.com/training/testing/unit-testing/instrumented-unit-tests.html).
+For more information on Android instrumentation tests, check out the [Android developer documentation](https://developer.android.com/training/testing/unit-testing/instrumented-unit-tests.html).
 
 Please file issues in the [GitHub issue tracker](https://github.com/bazelbuild/bazel/issues).
 
@@ -58,8 +55,7 @@ This results in output similar to the following:
 release 4.1.0
 ```
 
-- **KVM**. Bazel requires emulators to have [hardware
-  acceleration](https://developer.android.com/studio/run/emulator-acceleration.html#accel-check)
+- **KVM**. Bazel requires emulators to have [hardware acceleration](https://developer.android.com/studio/run/emulator-acceleration.html#accel-check)
   with KVM on Linux. You can follow these
   [installation instructions](https://help.ubuntu.com/community/KVM/Installation)
   for Ubuntu.
@@ -173,11 +169,9 @@ The main attributes of the rule `android_instrumentation_test` are:
 
 - `target_device`: An `android_device` target. This target describes the
   specifications of the Android emulator which Bazel uses to create, launch and
-  run the tests. See the [section on choosing an Android
-  device](#android-device-target) for more information.
+  run the tests. See the [section on choosing an Android device](#android-device-target) for more information.
 
-The test app's `AndroidManifest.xml` must include [an ``
-tag](https://developer.android.com/studio/test/#configure_instrumentation_manifest_settings).
+The test app's `AndroidManifest.xml` must include [an `` tag](https://developer.android.com/studio/test/#configure_instrumentation_manifest_settings).
 This tag must specify the attributes for the **package of the target app** and
 the **fully qualified class name of the instrumentation test runner**,
 `androidx.test.runner.AndroidJUnitRunner`.
@@ -214,8 +208,7 @@ repositories:
 - `@androidsdk`: The Android SDK. Download this through Android Studio.
 
 - `@android_test_support`: Hosts the test runner, emulator launcher, and
-  `android_device` targets. You can find the [latest release
-  here](https://github.com/android/android-test/releases).
+  `android_device` targets. You can find the [latest release here](https://github.com/android/android-test/releases).
 
 Enable these dependencies by adding the following lines to your `WORKSPACE`
 file:
@@ -240,8 +233,7 @@ android_test_repositories()
 
 ## Maven dependencies {#maven-dependencies}
 
-For managing dependencies on Maven artifacts from repositories, such as [Google
-Maven](https://maven.google.com) or [Maven Central](https://central.maven.org),
+For managing dependencies on Maven artifacts from repositories, such as [Google Maven](https://maven.google.com) or [Maven Central](https://central.maven.org),
 you should use a Maven resolver, such as
 [`rules_jvm_external`](https://github.com/bazelbuild/rules_jvm_external).
 
@@ -370,8 +362,7 @@ the device/emulator listed in `adb devices`.
 
 ## Sample projects {#sample-projects}
 
-If you are looking for canonical project samples, see the [Android testing
-samples](https://github.com/googlesamples/android-testing#experimental-bazel-support)
+If you are looking for canonical project samples, see the [Android testing samples](https://github.com/googlesamples/android-testing#experimental-bazel-support)
 for projects using Espresso and UIAutomator.
 
 ## Espresso setup {#espresso-setup}
@@ -560,8 +551,7 @@ API_LEVELS = [
 
 ## Known issues {#known-issues}
 
-- [Forked adb server processes are not terminated after
-  tests](https://github.com/bazelbuild/bazel/issues/4853)
+- [Forked adb server processes are not terminated after tests](https://github.com/bazelbuild/bazel/issues/4853)
 - While APK building works on all platforms (Linux, macOS, Windows), testing
   only works on Linux.
 - Even with `--config=local_adb`, users still need to specify
diff --git a/versions/8.3.1/docs/android-ndk.mdx b/versions/8.3.1/docs/android-ndk.mdx
index a12f5dec..d5ee45a6 100644
--- a/versions/8.3.1/docs/android-ndk.mdx
+++ b/versions/8.3.1/docs/android-ndk.mdx
@@ -2,8 +2,7 @@
 title: 'Using the Android Native Development Kit with Bazel'
 ---
 
-_If you're new to Bazel, please start with the [Building Android with
-Bazel](/versions/8.3.1/start/android-app ) tutorial._
+_If you're new to Bazel, please start with the [Building Android with Bazel](/versions/8.3.1/start/android-app) tutorial._
 
 ## Overview {#overview}
 
@@ -31,8 +30,7 @@ android_ndk_repository(
 )
 ```
 
-For more information about the `android_ndk_repository` rule, see the [Build
-Encyclopedia entry](/versions/8.3.1/reference/be/android#android_ndk_repository).
+For more information about the `android_ndk_repository` rule, see the [Build Encyclopedia entry](/versions/8.3.1/reference/be/android#android_ndk_repository).
 
 If you're using a recent version of the Android NDK (r22 and beyond), use the
 Starlark implementation of `android_ndk_repository`.
@@ -101,13 +99,11 @@ META-INF/MANIFEST.MF
 
 Bazel compiles all of the cc_libraries into a single shared object (`.so`) file,
 targeted for the `armeabi-v7a` ABI by default. To change this or build for
-multiple ABIs at the same time, see the section on [configuring the target
-ABI](#configuring-target-abi).
+multiple ABIs at the same time, see the section on [configuring the target ABI](#configuring-target-abi).
 
 ## Example setup {#example-setup}
 
-This example is available in the [Bazel examples
-repository](https://github.com/bazelbuild/examples/tree/master/android/ndk).
+This example is available in the [Bazel examples repository](https://github.com/bazelbuild/examples/tree/master/android/ndk).
 
 In the `BUILD.bazel` file, three targets are defined with the `android_binary`,
 `android_library`, and `cc_library` rules.
diff --git a/versions/8.3.1/docs/configurable-attributes.mdx b/versions/8.3.1/docs/configurable-attributes.mdx
index 3833d28e..bbf10d40 100644
--- a/versions/8.3.1/docs/configurable-attributes.mdx
+++ b/versions/8.3.1/docs/configurable-attributes.mdx
@@ -2,8 +2,7 @@
 title: 'Configurable Build Attributes'
 ---
 
-**_Configurable attributes_**, commonly known as [`select()`](
-/reference/be/functions#select), is a Bazel feature that lets users toggle the values
+**_Configurable attributes_**, commonly known as [`select()`](/reference/be/functions#select), is a Bazel feature that lets users toggle the values
 of build rule attributes at the command line.
 
 This can be used, for example, for a multiplatform library that automatically
@@ -407,8 +406,7 @@ sh_library(
 )
 ```
 
-If you need a `select` to match when multiple conditions match, consider [AND
-chaining](#and-chaining).
+If you need a `select` to match when multiple conditions match, consider [AND chaining](#and-chaining).
 
 ## OR chaining {#or-chaining}
 
diff --git a/versions/8.3.1/docs/user-manual.mdx b/versions/8.3.1/docs/user-manual.mdx
index c8d2e24b..fdd26cf6 100644
--- a/versions/8.3.1/docs/user-manual.mdx
+++ b/versions/8.3.1/docs/user-manual.mdx
@@ -1146,10 +1146,7 @@ This option causes Bazel's execution phase to print the full command line
 for each command prior to executing it.
 
 
-  >>>>> # //examples/cpp:hello-world [action 'Linking examples/cpp/hello-world']
-  (cd /home/johndoe/.cache/bazel/_bazel_johndoe/4c084335afceb392cfbe7c31afee3a9f/bazel && \
-    exec env - \
-    /usr/bin/gcc -o bazel-out/local-fastbuild/bin/examples/cpp/hello-world -B/usr/bin/ -Wl,-z,relro,-z,now -no-canonical-prefixes -pass-exit-codes -Wl,-S -Wl,@bazel-out/local_linux-fastbuild/bin/examples/cpp/hello-world-2.params)
+  >>>>> # //examples/cpp:hello-world [action 'Linking examples/cpp/hello-world'](cd /home/johndoe/.cache/bazel/_bazel_johndoe/4c084335afceb392cfbe7c31afee3a9f/bazel && \ exec env - \ /usr/bin/gcc -o bazel-out/local-fastbuild/bin/examples/cpp/hello-world -B/usr/bin/ -Wl,-z,relro,-z,now -no-canonical-prefixes -pass-exit-codes -Wl,-S -Wl,@bazel-out/local_linux-fastbuild/bin/examples/cpp/hello-world-2.params)
 

 
 Where possible, commands are printed in a Bourne shell compatible syntax,
diff --git a/versions/8.3.1/extending/auto-exec-groups.mdx b/versions/8.3.1/extending/auto-exec-groups.mdx
index 9c3d0d33..d7cef622 100644
--- a/versions/8.3.1/extending/auto-exec-groups.mdx
+++ b/versions/8.3.1/extending/auto-exec-groups.mdx
@@ -27,9 +27,7 @@ doesn't detect that ([the error](#first-error-message) is raised), you can set
 
 If you need to use multiple toolchains on a single execution platform (an action
 uses executable or tools from two or more toolchains), you need to manually
-define [exec_groups][exec_groups] (check
-[When should I use a custom exec_group?][multiple_toolchains_exec_groups]
-section).
+define [exec_groups][exec_groups](check [When should I use a custom exec_group?][multiple_toolchains_exec_groups] section).
 
 ## History {#history}
 
@@ -42,8 +40,7 @@ my_rule = rule(
 )
 ```
 
-Rule `my_rule` registers two toolchain types. This means that the [Toolchain
-Resolution](https://bazel.build/extending/toolchains#toolchain-resolution) used
+Rule `my_rule` registers two toolchain types. This means that the [Toolchain Resolution](https://bazel.build/extending/toolchains#toolchain-resolution) used
 to find an execution platform which supports both toolchain types. The selected
 execution platform was used for each registered action inside the rule, unless
 specified differently with [exec_groups][exec_groups].
diff --git a/versions/8.3.1/extending/concepts.mdx b/versions/8.3.1/extending/concepts.mdx
index d7307122..3ef1e5a7 100644
--- a/versions/8.3.1/extending/concepts.mdx
+++ b/versions/8.3.1/extending/concepts.mdx
@@ -20,16 +20,14 @@ Before learning the more advanced concepts, first:
 ## Macros and rules {#macros-and-rules}
 
 A macro is a function that instantiates rules. Macros come in two flavors:
-[symbolic macros](/versions/8.3.1/extending/macros) (new in Bazel 8) and [legacy
-macros](/versions/8.3.1/extending/legacy-macros). The two flavors of macros are defined
+[symbolic macros](/versions/8.3.1/extending/macros) (new in Bazel 8) and [legacy macros](/versions/8.3.1/extending/legacy-macros). The two flavors of macros are defined
 differently, but behave almost the same from the point of view of a user. A
 macro is useful when a `BUILD` file is getting too repetitive or too complex, as
 it lets you reuse some code. The function is evaluated as soon as the `BUILD`
 file is read. After the evaluation of the `BUILD` file, Bazel has little
 information about macros. If your macro generates a `genrule`, Bazel will
 behave *almost* as if you declared that `genrule` in the `BUILD` file. (The one
-exception is that targets declared in a symbolic macro have [special visibility
-semantics](/versions/8.3.1/extending/macros#visibility): a symbolic macro can hide its internal
+exception is that targets declared in a symbolic macro have [special visibility semantics](/versions/8.3.1/extending/macros#visibility): a symbolic macro can hide its internal
 targets from the rest of the package.)
 
 A [rule](/versions/8.3.1/extending/rules) is more powerful than a macro. It can access Bazel
@@ -76,8 +74,7 @@ they will not be executed.
 ## Creating extensions
 
 * [Create your first macro](/versions/8.3.1/rules/macro-tutorial) in order to reuse some code.
-  Then [learn more about macros](/versions/8.3.1/extending/macros) and [using them to create
-  "custom verbs"](/versions/8.3.1/rules/verbs-tutorial).
+  Then [learn more about macros](/versions/8.3.1/extending/macros) and [using them to create "custom verbs"](/versions/8.3.1/rules/verbs-tutorial).
 
 * [Follow the rules tutorial](/versions/8.3.1/rules/rules-tutorial) to get started with rules.
   Next, you can read more about the [rules concepts](/versions/8.3.1/extending/rules).
@@ -92,8 +89,7 @@ them within reach:
 ## Going further
 
 In addition to [macros](/versions/8.3.1/extending/macros) and [rules](/versions/8.3.1/extending/rules), you
-may want to write [aspects](/versions/8.3.1/extending/aspects) and [repository
-rules](/versions/8.3.1/extending/repo).
+may want to write [aspects](/versions/8.3.1/extending/aspects) and [repository rules](/versions/8.3.1/extending/repo).
 
 * Use [Buildifier](https://github.com/bazelbuild/buildtools)
   consistently to format and lint your code.
diff --git a/versions/8.3.1/extending/depsets.mdx b/versions/8.3.1/extending/depsets.mdx
index 541c5ef4..7bb6d477 100644
--- a/versions/8.3.1/extending/depsets.mdx
+++ b/versions/8.3.1/extending/depsets.mdx
@@ -111,8 +111,7 @@ need to ensure that if `B` depends on `A`, then `A.o` comes before `B.o` on the
 linker’s command line. Other tools might have the opposite requirement.
 
 Three traversal orders are supported: `postorder`, `preorder`, and
-`topological`. The first two work exactly like [tree
-traversals](https://en.wikipedia.org/wiki/Tree_traversal#Depth-first_search)
+`topological`. The first two work exactly like [tree traversals](https://en.wikipedia.org/wiki/Tree_traversal#Depth-first_search)
 except that they operate on DAGs and skip already visited nodes. The third order
 works as a topological sort from root to leaves, essentially the same as
 preorder except that shared children are listed only after all of their parents.
diff --git a/versions/8.3.1/extending/exec-groups.mdx b/versions/8.3.1/extending/exec-groups.mdx
index d9250bd8..5cfd2a4f 100644
--- a/versions/8.3.1/extending/exec-groups.mdx
+++ b/versions/8.3.1/extending/exec-groups.mdx
@@ -63,8 +63,7 @@ test rules.
 
 In the rule implementation, you can declare that actions should be run on the
 execution platform of an execution group. You can do this by using the `exec_group`
-param of action generating methods, specifically [`ctx.actions.run`]
-(/rules/lib/builtins/actions#run) and
+param of action generating methods, specifically [`ctx.actions.run`](/rules/lib/builtins/actions#run) and
 [`ctx.actions.run_shell`](/versions/8.3.1/rules/lib/builtins/actions#run_shell).
 
 ```python
diff --git a/versions/8.3.1/extending/macros.mdx b/versions/8.3.1/extending/macros.mdx
index 4de68793..8befb4b5 100644
--- a/versions/8.3.1/extending/macros.mdx
+++ b/versions/8.3.1/extending/macros.mdx
@@ -31,8 +31,7 @@ two required parameters: `attrs` and `implementation`.
 
 ### Attributes {#attributes}
 
-`attrs` accepts a dictionary of attribute name to [attribute
-types](https://bazel.build/rules/lib/toplevel/attr#members), which represents
+`attrs` accepts a dictionary of attribute name to [attribute types](https://bazel.build/rules/lib/toplevel/attr#members), which represents
 the arguments to the macro. Two common attributes – `name` and `visibility` –
 are implicitly added to all macros and are not included in the dictionary passed
 to `attrs`.
@@ -66,9 +65,7 @@ To support this pattern, a macro can *inherit attributes* from a rule or another
 macro by passing the [rule](https://bazel.build/versions/8.3.1/rules/lib/builtins/rule) or
 [macro symbol](https://bazel.build/versions/8.3.1/rules/lib/builtins/macro) to `macro()`'s
 `inherit_attrs` argument. (You can also use the special string `"common"`
-instead of a rule or macro symbol to inherit the [common attributes defined for
-all Starlark build
-rules](https://bazel.build/reference/be/common-definitions#common-attributes).)
+instead of a rule or macro symbol to inherit the [common attributes defined for all Starlark build rules](https://bazel.build/reference/be/common-definitions#common-attributes).)
 Only public attributes get inherited, and the attributes in the macro's own
 `attrs` dictionary override inherited attributes with the same name. You can
 also *remove* inherited attributes by using `None` as a value in the `attrs`
diff --git a/versions/8.3.1/extending/platforms.mdx b/versions/8.3.1/extending/platforms.mdx
index 4012667c..c3e87cf5 100644
--- a/versions/8.3.1/extending/platforms.mdx
+++ b/versions/8.3.1/extending/platforms.mdx
@@ -245,8 +245,7 @@ cc_library(
 
 You can use the
 [`IncompatiblePlatformProvider`](/versions/8.3.1/rules/lib/providers/IncompatiblePlatformProvider)
-in `bazel cquery`'s [Starlark output
-format](/versions/8.3.1/query/cquery#output-format-definition) to distinguish
+in `bazel cquery`'s [Starlark output format](/versions/8.3.1/query/cquery#output-format-definition) to distinguish
 incompatible targets from compatible ones.
 
 This can be used to filter out incompatible targets. The example below will
@@ -266,5 +265,4 @@ $ bazel cquery //... --output=starlark --starlark:file=example.cquery
 
 ### Known Issues
 
-Incompatible targets [ignore visibility
-restrictions](https://github.com/bazelbuild/bazel/issues/16044).
+Incompatible targets [ignore visibility restrictions](https://github.com/bazelbuild/bazel/issues/16044).
diff --git a/versions/8.3.1/extending/repo.mdx b/versions/8.3.1/extending/repo.mdx
index 0ab81226..6ca8e7de 100644
--- a/versions/8.3.1/extending/repo.mdx
+++ b/versions/8.3.1/extending/repo.mdx
@@ -74,8 +74,7 @@ specified.
 
 The input parameter `repository_ctx` can be used to access attribute values, and
 non-hermetic functions (finding a binary, executing a binary, creating a file in
-the repository or downloading a file from the Internet). See [the API
-docs](/versions/8.3.1/rules/lib/builtins/repository_ctx) for more context. Example:
+the repository or downloading a file from the Internet). See [the API docs](/versions/8.3.1/rules/lib/builtins/repository_ctx) for more context. Example:
 
 ```python
 def _impl(repository_ctx):
@@ -144,8 +143,7 @@ definition has the `configure` attribute set, use `bazel fetch --force
 
 ## Examples
 
--   [C++ auto-configured
-    toolchain](https://cs.opensource.google/bazel/bazel/+/master:tools/cpp/cc_configure.bzl;drc=644b7d41748e09eff9e47cbab2be2263bb71f29a;l=176):
+-   [C++ auto-configured toolchain](https://cs.opensource.google/bazel/bazel/+/master:tools/cpp/cc_configure.bzl;drc=644b7d41748e09eff9e47cbab2be2263bb71f29a;l=176):
     it uses a repo rule to automatically create the C++ configuration files for
     Bazel by looking for the local C++ compiler, the environment and the flags
     the C++ compiler supports.
diff --git a/versions/8.3.1/extending/rules.mdx b/versions/8.3.1/extending/rules.mdx
index 361c3995..076f61ed 100644
--- a/versions/8.3.1/extending/rules.mdx
+++ b/versions/8.3.1/extending/rules.mdx
@@ -449,8 +449,7 @@ def _example_library_impl(ctx):
 
 If `DefaultInfo` is not returned by a rule implementation or the `files`
 parameter is not specified, `DefaultInfo.files` defaults to all
-*predeclared outputs* (generally, those created by [output
-attributes](#output_attributes)).
+*predeclared outputs* (generally, those created by [output attributes](#output_attributes)).
 
 Rules that perform actions should provide default outputs, even if those outputs
 are not expected to be directly used. Actions that are not in the graph of the
@@ -995,8 +994,7 @@ By using `configuration_field`, the dependency on the Java LCOV merger tool can
 be avoided as long as coverage is not requested.
 
 When the test is run, it should emit coverage information in the form of one or
-more [LCOV files]
-(https://manpages.debian.org/unstable/lcov/geninfo.1.en.html#TRACEFILE_FORMAT)
+more [LCOV files](https://manpages.debian.org/unstable/lcov/geninfo.1.en.html#TRACEFILE_FORMAT)
 with unique names into the directory specified by the `COVERAGE_DIR` environment
 variable. Bazel will then merge these files into a single LCOV file using the
 `_lcov_merger` tool. If present, it will also collect C/C++ coverage using the
diff --git a/versions/8.3.1/extending/toolchains.mdx b/versions/8.3.1/extending/toolchains.mdx
index efe2957a..72403c6c 100644
--- a/versions/8.3.1/extending/toolchains.mdx
+++ b/versions/8.3.1/extending/toolchains.mdx
@@ -523,8 +523,7 @@ The set of available toolchains, in priority order, is created from
   4. Toolchains registered in the "WORKSPACE suffix"; this is only used by
      certain native rules bundled with the Bazel installation.
 
-**NOTE:** [Pseudo-targets like `:all`, `:*`, and
-`/...`](/versions/8.3.1/run/build#specifying-build-targets) are ordered by Bazel's package
+**NOTE:** [Pseudo-targets like `:all`, `:*`, and `/...`](/versions/8.3.1/run/build#specifying-build-targets) are ordered by Bazel's package
 loading mechanism, which uses a lexicographic ordering.
 
 The resolution steps are as follows.
diff --git a/versions/8.3.1/external/advanced.mdx b/versions/8.3.1/external/advanced.mdx
index a6de1008..b3895b92 100644
--- a/versions/8.3.1/external/advanced.mdx
+++ b/versions/8.3.1/external/advanced.mdx
@@ -4,10 +4,8 @@ title: 'Advanced topics on external dependencies'
 
 ## Shadowing dependencies in WORKSPACE
 
-Note: This section applies to the [WORKSPACE
-system](/versions/8.3.1/external/overview#workspace-system) only. For
-[Bzlmod](/versions/8.3.1/external/overview#bzlmod), use a [multiple-version
-override](/versions/8.3.1/external/module#multiple-version_override).
+Note: This section applies to the [WORKSPACE system](/versions/8.3.1/external/overview#workspace-system) only. For
+[Bzlmod](/versions/8.3.1/external/overview#bzlmod), use a [multiple-version override](/versions/8.3.1/external/module#multiple-version_override).
 
 Whenever possible, have a single version policy in your project, which is
 required for dependencies that you compile against and end up in your final
@@ -128,29 +126,24 @@ preferring IPv4 if enabled. In some situations, for example when the IPv4
 network cannot resolve/reach external addresses, this can cause `Network
 unreachable` exceptions and build failures. In these cases, you can override
 Bazel's behavior to prefer IPv6 by using the
-[`java.net.preferIPv6Addresses=true` system
-property](https://docs.oracle.com/javase/8/docs/api/java/net/doc-files/net-properties.html).
+[`java.net.preferIPv6Addresses=true` system property](https://docs.oracle.com/javase/8/docs/api/java/net/doc-files/net-properties.html).
 Specifically:
 
-*   Use `--host_jvm_args=-Djava.net.preferIPv6Addresses=true` [startup
-    option](/versions/8.3.1/docs/user-manual#startup-options), for example by adding the
+*   Use `--host_jvm_args=-Djava.net.preferIPv6Addresses=true` [startup option](/versions/8.3.1/docs/user-manual#startup-options), for example by adding the
     following line in your [`.bazelrc` file](/versions/8.3.1/run/bazelrc):
 
     `startup --host_jvm_args=-Djava.net.preferIPv6Addresses=true`
 
 *   When running Java build targets that need to connect to the internet (such
     as for integration tests), use the
-    `--jvmopt=-Djava.net.preferIPv6Addresses=true` [tool
-    flag](/versions/8.3.1/docs/user-manual#jvmopt). For example, include in your [`.bazelrc`
-    file](/versions/8.3.1/run/bazelrc):
+    `--jvmopt=-Djava.net.preferIPv6Addresses=true` [tool flag](/versions/8.3.1/docs/user-manual#jvmopt). For example, include in your [`.bazelrc` file](/versions/8.3.1/run/bazelrc):
 
     `build --jvmopt=-Djava.net.preferIPv6Addresses`
 
 *   If you are using [`rules_jvm_external`](https://github.com/bazelbuild/rules_jvm_external)
     for dependency version resolution, also add
     `-Djava.net.preferIPv6Addresses=true` to the `COURSIER_OPTS` environment
-    variable to [provide JVM options for
-    Coursier](https://github.com/bazelbuild/rules_jvm_external#provide-jvm-options-for-coursier-with-coursier_opts).
+    variable to [provide JVM options for Coursier](https://github.com/bazelbuild/rules_jvm_external#provide-jvm-options-for-coursier-with-coursier_opts).
 
 ## Offline builds
 
@@ -167,15 +160,12 @@ fetch a file with [`ctx.download`](/versions/8.3.1/rules/lib/builtins/repository
 providing a hash sum of the file needed, Bazel looks for a file matching the
 basename of the first URL, and uses the local copy if the hash matches.
 
-Bazel itself uses this technique to bootstrap offline from the [distribution
-artifact](https://github.com/bazelbuild/bazel-website/blob/master/designs/_posts/2016-10-11-distribution-artifact.md).
-It does so by [collecting all the needed external
-dependencies](https://github.com/bazelbuild/bazel/blob/5cfa0303d6ac3b5bd031ff60272ce80a704af8c2/WORKSPACE#L116)
+Bazel itself uses this technique to bootstrap offline from the [distribution artifact](https://github.com/bazelbuild/bazel-website/blob/master/designs/_posts/2016-10-11-distribution-artifact.md).
+It does so by [collecting all the needed external dependencies](https://github.com/bazelbuild/bazel/blob/5cfa0303d6ac3b5bd031ff60272ce80a704af8c2/WORKSPACE#L116)
 in an internal
 [`distdir_tar`](https://github.com/bazelbuild/bazel/blob/5cfa0303d6ac3b5bd031ff60272ce80a704af8c2/distdir.bzl#L44).
 
 Bazel allows execution of arbitrary commands in repository rules without knowing
 if they call out to the network, and so cannot enforce fully offline builds. To
 test if a build works correctly offline, manually block off the network (as
-Bazel does in its [bootstrap
-test](https://cs.opensource.google/bazel/bazel/+/master:src/test/shell/bazel/BUILD;l=1073;drc=88c426e73cc0eb0a41c0d7995e36acd94e7c9a48)).
\ No newline at end of file
+Bazel does in its [bootstrap test](https://cs.opensource.google/bazel/bazel/+/master:src/test/shell/bazel/BUILD;l=1073;drc=88c426e73cc0eb0a41c0d7995e36acd94e7c9a48)).
\ No newline at end of file
diff --git a/versions/8.3.1/external/migration.mdx b/versions/8.3.1/external/migration.mdx
index 86b75f20..8e4c42eb 100644
--- a/versions/8.3.1/external/migration.mdx
+++ b/versions/8.3.1/external/migration.mdx
@@ -2,8 +2,7 @@
 title: 'Bzlmod Migration Guide'
 ---
 
-Due to the [shortcomings of
-WORKSPACE](/versions/8.3.1/external/overview#workspace-shortcomings), Bzlmod is going to
+Due to the [shortcomings of WORKSPACE](/versions/8.3.1/external/overview#workspace-shortcomings), Bzlmod is going to
 replace the legacy WORKSPACE system. The WORKSPACE file will be disabled by
 default in Bazel 8 (late 2024) and will be removed in Bazel 9 (late 2025).
 This guide helps you migrate your project to Bzlmod and drop WORKSPACE for
@@ -117,9 +116,7 @@ Bazel module when it also adopts Bzlmod.
 
 *   **Bzlmod**
 
-    With Bzlmod, as long as the your dependency is available in [Bazel Central
-    Registry](https://registry.bazel.build) or your custom [Bazel
-    registry](/versions/8.3.1/external/registry), you can simply depend on it with a
+    With Bzlmod, as long as the your dependency is available in [Bazel Central Registry](https://registry.bazel.build) or your custom [Bazel registry](/versions/8.3.1/external/registry), you can simply depend on it with a
     [`bazel_dep`](/versions/8.3.1/rules/lib/globals/module#bazel_dep) directive.
 
     ```python
@@ -150,8 +147,7 @@ repository.
 
 If your dependency is not a Bazel project or not yet available in any Bazel
 registry, you can introduce it using
-[`use_repo_rule`](/versions/8.3.1/external/module#use_repo_rule) or [module
-extensions](/versions/8.3.1/external/extension).
+[`use_repo_rule`](/versions/8.3.1/external/module#use_repo_rule) or [module extensions](/versions/8.3.1/external/extension).
 
 *   **WORKSPACE**
 
@@ -604,8 +600,7 @@ macros.
 Fortunately, the flag
 [`--experimental_repository_resolved_file`][resolved_file_flag]
 can help. This flag essentially generates a "lock file" of all fetched external
-dependencies in your last Bazel command. You can find more details in this [blog
-post](https://blog.bazel.build/2018/07/09/bazel-sync-and-resolved-file.html).
+dependencies in your last Bazel command. You can find more details in this [blog post](https://blog.bazel.build/2018/07/09/bazel-sync-and-resolved-file.html).
 
 [resolved_file_flag]: /reference/command-line-reference#flag--experimental_repository_resolved_file
 
@@ -646,11 +641,9 @@ You may also know `bazel query` can be used for inspecting repository rules with
 bazel query --output=build //external:
 ```
 
-While it is more convenient and much faster, [bazel query can lie about
-external dependency version](https://github.com/bazelbuild/bazel/issues/12947),
+While it is more convenient and much faster, [bazel query can lie about external dependency version](https://github.com/bazelbuild/bazel/issues/12947),
 so be careful using it! Querying and inspecting external
-dependencies with Bzlmod is going to achieved by a [new
-subcommand](https://github.com/bazelbuild/bazel/issues/15365).
+dependencies with Bzlmod is going to achieved by a [new subcommand](https://github.com/bazelbuild/bazel/issues/15365).
 
 #### Built-in default dependencies {#builtin-default-deps}
 
@@ -697,8 +690,7 @@ Using the WORKSPACE.bzlmod file can make the migration easier because:
 #### Repository visibility {#repository-visibility}
 
 Bzlmod is able to control which other repositories are visible from a given
-repository, check [repository names and strict
-deps](/versions/8.3.1/external/module#repository_names_and_strict_deps) for more details.
+repository, check [repository names and strict deps](/versions/8.3.1/external/module#repository_names_and_strict_deps) for more details.
 
 Here is a summary of repository visibilities from different types of
 repositories when also taking WORKSPACE into consideration.
@@ -711,8 +703,7 @@ repositories when also taking WORKSPACE into consideration.
 | WORKSPACE Repos | All visible | Not visible | Not visible | All visible |
 
 Note: For the root module, if a repository `@foo` is defined in WORKSPACE and
-`@foo` is also used as an [apparent repository
-name](/versions/8.3.1/external/overview#apparent-repo-name) in MODULE.bazel, then `@foo`
+`@foo` is also used as an [apparent repository name](/versions/8.3.1/external/overview#apparent-repo-name) in MODULE.bazel, then `@foo`
 refers to the one introduced in MODULE.bazel.
 
 Note: For a module extension generated repository `@bar`, if `@foo` is used as
@@ -787,9 +778,7 @@ the project. Take note of a few things when creating the source archive:
     GitHub isn't going to guarantee the checksum of source archives generated on
     demand. In short, URLs in the form of
     `https://github.com///releases/download/...` is considered stable
-    while `https://github.com///archive/...` is not. Check [GitHub
-    Archive Checksum
-    Outage](https://blog.bazel.build/2023/02/15/github-archive-checksum.html)
+    while `https://github.com///archive/...` is not. Check [GitHub Archive Checksum Outage](https://blog.bazel.build/2023/02/15/github-archive-checksum.html)
     for more context.
 
 *   **Make sure the source tree follows the layout of the original repository.**
@@ -818,8 +807,7 @@ Pull Request.
 
 [bcr_contrib_guide]: https://github.com/bazelbuild/bazel-central-registry/tree/main/docs#contribute-a-bazel-module
 
-It is **highly recommended** to set up the [Publish to
-BCR](https://github.com/bazel-contrib/publish-to-bcr) GitHub App for your
+It is **highly recommended** to set up the [Publish to BCR](https://github.com/bazel-contrib/publish-to-bcr) GitHub App for your
 repository to automate the process of submitting your module to the BCR.
 
 ## Best practices {#best-practices}
diff --git a/versions/8.3.1/external/mod-command.mdx b/versions/8.3.1/external/mod-command.mdx
index e49acc52..f5ebb078 100644
--- a/versions/8.3.1/external/mod-command.mdx
+++ b/versions/8.3.1/external/mod-command.mdx
@@ -61,11 +61,9 @@ The available subcommands and their respective required arguments are:
 
 *   ``: All present versions of the module ``.
 
-*   `@`: The repo with the given [apparent
-    name](overview#apparent-repo-name) in the context of the `--base_module`.
+*   `@`: The repo with the given [apparent name](overview#apparent-repo-name) in the context of the `--base_module`.
 
-*   `@@`: The repo with the given [canonical
-    name](overview#canonical-repo-name).
+*   `@@`: The repo with the given [canonical name](overview#canonical-repo-name).
 
 In a context requiring specifying modules, ``s referring to repos that
 correspond to modules (as opposed to extension-generated repos) can also be
@@ -87,8 +85,7 @@ The following options only affect the subcommands that print graphs (`graph`,
     information about the version resolution of each module. If the module
     version changed during resolution, show either which version replaced it or
     what was the original version, the reason it was replaced, and which modules
-    requested the new version if the reason was [Minimal Version
-    Selection](module#version-selection).
+    requested the new version if the reason was [Minimal Version Selection](module#version-selection).
 
 *   `--include_unused` *default: "false"*: Include in the output graph the
     modules which were originally present in the dependency graph, but became
diff --git a/versions/8.3.1/external/module.mdx b/versions/8.3.1/external/module.mdx
index 42bfcfbf..ba934039 100644
--- a/versions/8.3.1/external/module.mdx
+++ b/versions/8.3.1/external/module.mdx
@@ -122,8 +122,7 @@ serves multiple purposes:
     version, regardless of which versions of the dependency are requested in the
     dependency graph.
 *   With the `registry` attribute, you can force this dependency to come from a
-    specific registry, instead of following the normal [registry
-    selection](/versions/8.3.1/external/registry#selecting_registries) process.
+    specific registry, instead of following the normal [registry selection](/versions/8.3.1/external/registry#selecting_registries) process.
 *   With the `patch*` attributes, you can specify a set of patches to apply to
     the downloaded module.
 
@@ -176,13 +175,11 @@ With `bazel_dep`, you can define repos that represent other Bazel modules.
 Sometimes there is a need to define a repo that does _not_ represent a Bazel
 module; for example, one that contains a plain JSON file to be read as data.
 
-In this case, you could use the [`use_repo_rule`
-directive](/versions/8.3.1/rules/lib/globals/module#use_repo_rule) to directly define a repo
+In this case, you could use the [`use_repo_rule` directive](/versions/8.3.1/rules/lib/globals/module#use_repo_rule) to directly define a repo
 by invoking a repo rule. This repo will only be visible to the module it's
 defined in.
 
-Under the hood, this is implemented using the same mechanism as [module
-extensions](/versions/8.3.1/external/extension), which lets you define repos with more
+Under the hood, this is implemented using the same mechanism as [module extensions](/versions/8.3.1/external/extension), which lets you define repos with more
 flexibility.
 
 ## Repository names and strict deps
diff --git a/versions/8.3.1/external/overview.mdx b/versions/8.3.1/external/overview.mdx
index 866e6a6e..99663b7d 100644
--- a/versions/8.3.1/external/overview.mdx
+++ b/versions/8.3.1/external/overview.mdx
@@ -128,8 +128,7 @@ for all build targets inside the repo.
 
 The syntax of a `REPO.bazel` file is similar to `BUILD` files, except that no
 `load` statements are supported, and only a single function, `repo()`, is
-available. `repo()` takes the same arguments as the [`package()`
-function](/versions/8.3.1/reference/be/functions#package) in `BUILD` files; whereas `package()`
+available. `repo()` takes the same arguments as the [`package()` function](/versions/8.3.1/reference/be/functions#package) in `BUILD` files; whereas `package()`
 specifies common attributes for all build targets inside the package, `repo()`
 analogously does so for all build targets inside the repo.
 
@@ -163,8 +162,7 @@ bazel_dep(name = "protobuf", version = "3.19.0")
 ```
 
 A module must only list its direct dependencies, which Bzlmod looks up in a
-[Bazel registry](/versions/8.3.1/external/registry) — by default, the [Bazel Central
-Registry](https://bcr.bazel.build/). The registry provides the
+[Bazel registry](/versions/8.3.1/external/registry) — by default, the [Bazel Central Registry](https://bcr.bazel.build/). The registry provides the
 dependencies' `MODULE.bazel` files, which allows Bazel to discover the entire
 transitive dependency graph before performing version resolution.
 
@@ -235,5 +233,4 @@ many pain points, including:
         `B` and `C`; `B` and `C` both depend on different versions of `D`).
 
 Due to the shortcomings of WORKSPACE, Bzlmod is going to replace the legacy
-WORKSPACE system in future Bazel releases. Please read the [Bzlmod migration
-guide](/versions/8.3.1/external/migration) on how to migrate to Bzlmod.
+WORKSPACE system in future Bazel releases. Please read the [Bzlmod migration guide](/versions/8.3.1/external/migration) on how to migrate to Bzlmod.
diff --git a/versions/8.3.1/external/registry.mdx b/versions/8.3.1/external/registry.mdx
index fdf438dd..57581359 100644
--- a/versions/8.3.1/external/registry.mdx
+++ b/versions/8.3.1/external/registry.mdx
@@ -42,8 +42,7 @@ An index registry must follow the format below:
             project
         *   `versions`: A list of all the versions of this module to be found in
             this registry
-        *   `yanked_versions`: A map of [*yanked*
-            versions](/versions/8.3.1/external/module#yanked_versions) of this module. The keys
+        *   `yanked_versions`: A map of [*yanked* versions](/versions/8.3.1/external/module#yanked_versions) of this module. The keys
             should be versions to yank and the values should be descriptions of
             why the version is yanked, ideally containing a link to more
             information
@@ -56,8 +55,7 @@ An index registry must follow the format below:
             *   `url`: The URL of the source archive
             *   `mirror_urls`: A list of string, the mirror URLs of the source archive.
                 The URLs are tried in order after `url` as backups.
-            *   `integrity`: The [Subresource
-                Integrity](https://w3c.github.io/webappsec-subresource-integrity/#integrity-metadata-description)
+            *   `integrity`: The [Subresource Integrity](https://w3c.github.io/webappsec-subresource-integrity/#integrity-metadata-description)
                 checksum of the archive
             *   `strip_prefix`: A directory prefix to strip when extracting the
                 source archive
@@ -105,8 +103,7 @@ You can browse its contents using the web frontend at
 https://registry.bazel.build/.
 
 The Bazel community maintains the BCR, and contributors are welcome to submit
-pull requests. See the [BCR contribution
-guidelines](https://github.com/bazelbuild/bazel-central-registry/blob/main/docs/README.md).
+pull requests. See the [BCR contribution guidelines](https://github.com/bazelbuild/bazel-central-registry/blob/main/docs/README.md).
 
 In addition to following the format of a normal index registry, the BCR requires
 a `presubmit.yml` file for each module version
diff --git a/versions/8.3.1/external/vendor.mdx b/versions/8.3.1/external/vendor.mdx
index 888f64ce..99750519 100644
--- a/versions/8.3.1/external/vendor.mdx
+++ b/versions/8.3.1/external/vendor.mdx
@@ -23,9 +23,7 @@ absolute path.
 ## Vendor a specific external repository {#vendor-specific-repository}
 
 You can use the `vendor` command with the `--repo` flag to specify which repo
-to vendor, it accepts both [canonical repo
-name](/versions/8.3.1/external/overview#canonical-repo-name) and [apparent repo
-name](/versions/8.3.1/external/overview#apparent-repo-name).
+to vendor, it accepts both [canonical repo name](/versions/8.3.1/external/overview#canonical-repo-name) and [apparent repo name](/versions/8.3.1/external/overview#apparent-repo-name).
 
 For example, running:
 
diff --git a/versions/8.3.1/help.mdx b/versions/8.3.1/help.mdx
index 7a401454..a06d83c9 100644
--- a/versions/8.3.1/help.mdx
+++ b/versions/8.3.1/help.mdx
@@ -46,5 +46,4 @@ what level of support Bazel provides.
 
 ## File a bug {#file-bug}
 
-If you encounter a bug or want to request a feature, file a [GitHub
-Issue](https://github.com/bazelbuild/bazel/issues).
+If you encounter a bug or want to request a feature, file a [GitHub Issue](https://github.com/bazelbuild/bazel/issues).
diff --git a/versions/8.3.1/install/bazelisk.mdx b/versions/8.3.1/install/bazelisk.mdx
index 8dd03b1e..aa10d046 100644
--- a/versions/8.3.1/install/bazelisk.mdx
+++ b/versions/8.3.1/install/bazelisk.mdx
@@ -16,8 +16,7 @@ For more details, see
 ## Updating Bazel
 
 Bazel has a [backward compatibility policy](/versions/8.3.1/release/backward-compatibility)
-(see [guidance for rolling out incompatible
-changes](/versions/8.3.1/contribute/breaking-changes) if you
+(see [guidance for rolling out incompatible changes](/versions/8.3.1/contribute/breaking-changes) if you
 are the author of one). That page summarizes best practices on how to test and
 migrate your project with upcoming incompatible changes and how to provide
 feedback to the incompatible change authors.
diff --git a/versions/8.3.1/install/compile-source.mdx b/versions/8.3.1/install/compile-source.mdx
index 47a813dd..11312f2e 100644
--- a/versions/8.3.1/install/compile-source.mdx
+++ b/versions/8.3.1/install/compile-source.mdx
@@ -45,8 +45,7 @@ it by typing `bazel` in a terminal.
 
 **Reason**: To build Bazel from a GitHub source tree, you need a pre-existing
 Bazel binary. You can install one from a package manager or download one from
-GitHub. See [Installing Bazel](/versions/8.3.1/install). (Or you can [build from
-scratch (bootstrap)](#bootstrap-bazel).)
+GitHub. See [Installing Bazel](/versions/8.3.1/install). (Or you can [build from scratch (bootstrap)](#bootstrap-bazel).)
 
 **Troubleshooting**:
 
@@ -239,8 +238,7 @@ For instructions for Unix-like systems, see
     ```
 
 *   **The Visual C++ compiler.** Install the Visual C++ compiler either as part
-    of Visual Studio 2015 or newer, or by installing the latest [Build Tools
-    for Visual Studio 2017](https://aka.ms/BuildTools).
+    of Visual Studio 2015 or newer, or by installing the latest [Build Tools for Visual Studio 2017](https://aka.ms/BuildTools).
 
 *   **JDK.** Version 21 is required.
 
diff --git a/versions/8.3.1/install/ide.mdx b/versions/8.3.1/install/ide.mdx
index 561d0e02..c42d95e9 100644
--- a/versions/8.3.1/install/ide.mdx
+++ b/versions/8.3.1/install/ide.mdx
@@ -38,10 +38,8 @@ To install, go to the IDE's plugin browser and search for `Bazel`.
 To manually install older versions, download the zip files from JetBrains'
 Plugin Repository and install the zip file from the IDE's plugin browser:
 
-*  [Android Studio
-   plugin](https://plugins.jetbrains.com/plugin/9185-android-studio-with-bazel)
-*  [IntelliJ
-   plugin](https://plugins.jetbrains.com/plugin/8609-intellij-with-bazel)
+*  [Android Studio plugin](https://plugins.jetbrains.com/plugin/9185-android-studio-with-bazel)
+*  [IntelliJ plugin](https://plugins.jetbrains.com/plugin/8609-intellij-with-bazel)
 *  [CLion plugin](https://plugins.jetbrains.com/plugin/9554-clion-with-bazel)
 
 ### Xcode {#xcode}
@@ -61,8 +59,7 @@ Features:
 * Starlark debugger for `.bzl` files during a build (set breakpoints, step
   through code, inspect variables, and so on)
 
-Find [the plugin on the Visual Studio
-marketplace](https://marketplace.visualstudio.com/items?itemName=BazelBuild.vscode-bazel).
+Find [the plugin on the Visual Studio marketplace](https://marketplace.visualstudio.com/items?itemName=BazelBuild.vscode-bazel).
 The plugin is [open source](https://github.com/bazelbuild/vscode-bazel).
 
 See also: [Autocomplete for Source Code](#autocomplete-for-source-code)
@@ -82,8 +79,7 @@ See also: [Autocomplete for Source Code](#autocomplete-for-source-code)
 
 ### Emacs {#emacs}
 
-See [`bazelbuild/bazel-emacs-mode` on
-GitHub](https://github.com/bazelbuild/emacs-bazel-mode)
+See [`bazelbuild/bazel-emacs-mode` on GitHub](https://github.com/bazelbuild/emacs-bazel-mode)
 
 See also: [Autocomplete for Source Code](#autocomplete-for-source-code)
 
@@ -115,6 +111,5 @@ tool for building Bazel targets when source files change.
 
 ## Building your own IDE plugin {#build-own-plugin}
 
-Read the [**IDE support** blog
-post](https://blog.bazel.build/2016/06/10/ide-support.html) to learn more about
+Read the [**IDE support** blog post](https://blog.bazel.build/2016/06/10/ide-support.html) to learn more about
 the Bazel APIs to use when building an IDE plugin.
diff --git a/versions/8.3.1/install/windows.mdx b/versions/8.3.1/install/windows.mdx
index beab6126..a0cd3939 100644
--- a/versions/8.3.1/install/windows.mdx
+++ b/versions/8.3.1/install/windows.mdx
@@ -31,8 +31,7 @@ To check your Windows version:
 
 Alternatively you can:
 
-*   [Download the Bazel binary (`bazel-version-windows-x86_64.exe`) from
- GitHub](https://github.com/bazelbuild/bazel/releases).
+*   [Download the Bazel binary (`bazel-version-windows-x86_64.exe`) from GitHub](https://github.com/bazelbuild/bazel/releases).
 *   [Install Bazel from Chocolatey](#chocolately)
 *   [Install Bazel from Scoop](#scoop)
 *   [Build Bazel from source](/versions/8.3.1/install/compile-source)
@@ -208,8 +207,7 @@ If that doesn't help:
     its dependencies, such as the MSYS2 shell. This will not install Visual C++
     though.
 
-See [Chocolatey installation and package maintenance
-guide](/versions/8.3.1/contribute/windows-chocolatey-maintenance) for more
+See [Chocolatey installation and package maintenance guide](/versions/8.3.1/contribute/windows-chocolatey-maintenance) for more
 information about the Chocolatey package.
 
 ### Using Scoop {#scoop}
@@ -226,8 +224,7 @@ information about the Chocolatey package.
     scoop install bazel
     ```
 
-See [Scoop installation and package maintenance
-guide](/versions/8.3.1/contribute/windows-scoop-maintenance) for more
+See [Scoop installation and package maintenance guide](/versions/8.3.1/contribute/windows-scoop-maintenance) for more
 information about the Scoop package.
 
 ### Build from source {#build-from-source}
diff --git a/versions/8.3.1/migrate/maven.mdx b/versions/8.3.1/migrate/maven.mdx
index 5615fd38..d2848efc 100644
--- a/versions/8.3.1/migrate/maven.mdx
+++ b/versions/8.3.1/migrate/maven.mdx
@@ -19,8 +19,7 @@ directly run by Bazel since there's no Maven compatibility layer.
 ## Before you begin {#before-you-begin}
 
 *   [Install Bazel](/versions/8.3.1/install) if it's not yet installed.
-*   If you're new to Bazel, go through the tutorial [Introduction to Bazel:
-    Build Java](/versions/8.3.1/start/java) before you start migrating. The tutorial explains
+*   If you're new to Bazel, go through the tutorial [Introduction to Bazel: Build Java](/versions/8.3.1/start/java) before you start migrating. The tutorial explains
     Bazel's concepts, structure, and label syntax.
 
 ## Differences between Maven and Bazel {#dif-maven-bazel}
@@ -44,8 +43,7 @@ The steps below describe how to migrate your project to Bazel:
 3.  [Create more BUILD files](#3-build)
 4.  [Build using Bazel](#4-build)
 
-Examples below come from a migration of the [Guava
-project](https://github.com/google/guava) from Maven to Bazel. The
+Examples below come from a migration of the [Guava project](https://github.com/google/guava) from Maven to Bazel. The
 Guava project used is release `v31.1`. The examples using Guava do not walk
 through each step in the migration, but they do show the files and contents that
 are generated or added manually for the migration.
@@ -63,14 +61,12 @@ has no external dependencies, this file can be empty.
 If your project depends on files or packages that are not in one of the
 project's directories, specify these external dependencies in the MODULE.bazel
 file. You can use `rules_jvm_external` to manage dependencies from Maven. For
-instructions about using this ruleset, see [the
-README](https://github.com/bazelbuild/rules_jvm_external/#rules_jvm_external)
+instructions about using this ruleset, see [the README](https://github.com/bazelbuild/rules_jvm_external/#rules_jvm_external)
 .
 
 #### Guava project example: external dependencies {#guava-1}
 
-You can list the external dependencies of the [Guava
-project](https://github.com/google/guava) with the
+You can list the external dependencies of the [Guava project](https://github.com/google/guava) with the
 [`rules_jvm_external`](https://github.com/bazelbuild/rules_jvm_external)
 ruleset.
 
@@ -164,8 +160,7 @@ your build by adding more `BUILD` files with more granular targets.
             *   `resources`: Use globbing to list all resources in your project.
             *   `deps`: You need to determine which external dependencies your
                 project needs.
-        *   Take a look at the [example below of this top-level BUILD
-            file](#guava-2) from the migration of the Guava project.
+        *   Take a look at the [example below of this top-level BUILD file](#guava-2) from the migration of the Guava project.
 
 3.  Now that you have a `BUILD` file at the root of your project, build your
     project to ensure that it works. On the command line, from your workspace
diff --git a/versions/8.3.1/migrate/xcode.mdx b/versions/8.3.1/migrate/xcode.mdx
index c65a095e..8744e79c 100644
--- a/versions/8.3.1/migrate/xcode.mdx
+++ b/versions/8.3.1/migrate/xcode.mdx
@@ -32,8 +32,7 @@ Before you begin, do the following:
 
 1.  [Install Bazel](/versions/8.3.1/install) if you have not already done so.
 
-2.  If you're not familiar with Bazel and its concepts, complete the [iOS app
-    tutorial](/versions/8.3.1/start/ios-app)). You should understand the Bazel workspace,
+2.  If you're not familiar with Bazel and its concepts, complete the [iOS app tutorial](/versions/8.3.1/start/ios-app)). You should understand the Bazel workspace,
     including the `MODULE.bazel` and `BUILD` files, as well as the concepts of
     targets, build rules, and Bazel packages.
 
@@ -44,8 +43,7 @@ Before you begin, do the following:
 Unlike Xcode, Bazel requires you to explicitly declare all dependencies for
 every target in the `BUILD` file.
 
-For more information on external dependencies, see [Working with external
-dependencies](/versions/8.3.1/docs/external).
+For more information on external dependencies, see [Working with external dependencies](/versions/8.3.1/docs/external).
 
 ## Build or test an Xcode project with Bazel {#build-xcode-project}
 
@@ -84,8 +82,7 @@ Note: Place the project source code within the directory tree containing the
 
 To integrate SwiftPM dependencies into the Bazel workspace with
 [swift_bazel](https://github.com/cgrindel/swift_bazel), you must
-convert them into Bazel packages as described in the [following
-tutorial](https://chuckgrindel.com/swift-packages-in-bazel-using-swift_bazel/)
+convert them into Bazel packages as described in the [following tutorial](https://chuckgrindel.com/swift-packages-in-bazel-using-swift_bazel/)
 .
 
 Note: SwiftPM support is a manual process with many variables. SwiftPM
@@ -103,8 +100,7 @@ initial build of the project as follows:
 *   [Step 3b: (Optional) Add the test target(s)](#step-3b-optional-add-the-test-target-s)
 *   [Step 3c: Add the library target(s)](#step-3c-add-the-library-target-s)
 
-**Tip:** To learn more about packages and other Bazel concepts, see [Workspaces,
-packages, and targets](/versions/8.3.1/concepts/build-ref).
+**Tip:** To learn more about packages and other Bazel concepts, see [Workspaces, packages, and targets](/versions/8.3.1/concepts/build-ref).
 
 #### Step 3a: Add the application target {#add-app-target}
 
@@ -132,8 +128,7 @@ In the target, specify the following at the minimum:
 
 #### Step 3b: (Optional) Add the test target(s) {#add-test-target}
 
-Bazel's [Apple build
-rules](https://github.com/bazelbuild/rules_apple) support running
+Bazel's [Apple build rules](https://github.com/bazelbuild/rules_apple) support running
 unit and UI tests on all Apple platforms. Add test targets as follows:
 
 *   [`macos_unit_test`](https://github.com/bazelbuild/rules_apple/blob/master/doc/rules-macos.md#macos_unit_test)
@@ -181,8 +176,7 @@ all sources and/or headers of a certain type. Use it carefully as it might
 include files you do not want Bazel to build.
 
 You can browse existing examples for various types of applications directly in
-the [rules_apple examples
-directory](https://github.com/bazelbuild/rules_apple/tree/master/examples/). For
+the [rules_apple examples directory](https://github.com/bazelbuild/rules_apple/tree/master/examples/). For
 example:
 
 *   [macOS application targets](https://github.com/bazelbuild/rules_apple/tree/master/examples/macos)
@@ -191,8 +185,7 @@ example:
 
 *   [Multi platform applications (macOS, iOS, watchOS, tvOS)](https://github.com/bazelbuild/rules_apple/tree/master/examples/multi_platform)
 
-For more information on build rules, see [Apple Rules for
-Bazel](https://github.com/bazelbuild/rules_apple).
+For more information on build rules, see [Apple Rules for Bazel](https://github.com/bazelbuild/rules_apple).
 
 At this point, it is a good idea to test the build:
 
diff --git a/versions/8.3.1/query/cquery.mdx b/versions/8.3.1/query/cquery.mdx
index fa5f48cb..455657b9 100644
--- a/versions/8.3.1/query/cquery.mdx
+++ b/versions/8.3.1/query/cquery.mdx
@@ -6,8 +6,7 @@ title: ' Configurable Query (cquery)'
 [`select()`](/versions/8.3.1/docs/configurable-attributes) and build options' effects on the build
 graph.
 
-It achieves this by running over the results of Bazel's [analysis
-phase](/versions/8.3.1/extending/concepts#evaluation-model),
+It achieves this by running over the results of Bazel's [analysis phase](/versions/8.3.1/extending/concepts#evaluation-model),
 which integrates these effects. `query`, by contrast, runs over the results of
 Bazel's loading phase, before options are evaluated.
 
@@ -137,8 +136,7 @@ $ bazel cquery //foo --universe_scope=//foo,//genrule_with_foo_as_tool
 If you want to precisely declare which instance to query over, use
 the [`config`](#config) function.
 
-See `query`'s [target pattern
-documentation](/versions/8.3.1/query/language#target-patterns) for more information on target patterns.
+See `query`'s [target pattern documentation](/versions/8.3.1/query/language#target-patterns) for more information on target patterns.
 
 ## Functions {#functions}
 
diff --git a/versions/8.3.1/query/language.mdx b/versions/8.3.1/query/language.mdx
index 7f3bfd7d..13a811a9 100644
--- a/versions/8.3.1/query/language.mdx
+++ b/versions/8.3.1/query/language.mdx
@@ -1105,8 +1105,7 @@ is being used.
 
 ### On the ordering of results {#results-ordering}
 
-Although query expressions always follow the "[law of
-conservation of graph order](#graph-order)", _presenting_ the results may be done
+Although query expressions always follow the "[law of conservation of graph order](#graph-order)", _presenting_ the results may be done
 in either a dependency-ordered or unordered manner. This does **not**
 influence the targets in the result set or how the query is computed. It only
 affects how the results are printed to stdout. Moreover, nodes that are
@@ -1252,8 +1251,7 @@ and `maxrank` output formats print the labels of each
 target in the resulting graph, but instead of appearing in
 topological order, they appear in rank order, preceded by their
 rank number. These are unaffected by the result ordering
-`--[no]order_results` flag (see [notes on
-the ordering of results](#result-order)).
+`--[no]order_results` flag (see [notes on the ordering of results](#result-order)).
 
 There are two variants of this format: `minrank` ranks
 each node by the length of the shortest path from a root node to it.
diff --git a/versions/8.3.1/reference/be/functions.mdx b/versions/8.3.1/reference/be/functions.mdx
index f2f18d50..7b37d0c2 100644
--- a/versions/8.3.1/reference/be/functions.mdx
+++ b/versions/8.3.1/reference/be/functions.mdx
@@ -262,8 +262,7 @@ There are several important limitations and caveats:
    package called "Foo.java" (which is allowed, though Bazel warns about it),
    then the consumer of the `glob()` will use the "Foo.java" rule
    (its outputs) instead of the "Foo.java" file. See
-   [GitHub
-   issue #10395](https://github.com/bazelbuild/bazel/issues/10395#issuecomment-583714657) for more details.
+   [GitHub issue #10395](https://github.com/bazelbuild/bazel/issues/10395#issuecomment-583714657) for more details.
 3. Globs may match files in subdirectories. And subdirectory names
    may be wildcarded. However...
 4. Labels are not allowed to cross the package boundary and glob does
diff --git a/versions/8.3.1/reference/be/java.mdx b/versions/8.3.1/reference/be/java.mdx
index 0779edf4..efeef11a 100644
--- a/versions/8.3.1/reference/be/java.mdx
+++ b/versions/8.3.1/reference/be/java.mdx
@@ -225,8 +225,7 @@ test code. The test runner's main method is invoked instead of the main class be
   [java\_binary](#java_binary) for more details.
 
 See the section on `java_binary()` arguments. This rule also
-supports all [attributes common
-to all test rules (\*\_test)](https://bazel.build/versions/8.3.1/reference/be/common-definitions#common-attributes-tests).
+supports all [attributes common to all test rules (\*\_test)](https://bazel.build/versions/8.3.1/reference/be/common-definitions#common-attributes-tests).
 
 #### Examples
 
diff --git a/versions/8.3.1/reference/be/make-variables.mdx b/versions/8.3.1/reference/be/make-variables.mdx
index 54146221..414edfa6 100644
--- a/versions/8.3.1/reference/be/make-variables.mdx
+++ b/versions/8.3.1/reference/be/make-variables.mdx
@@ -19,8 +19,7 @@ targets, and *custom* variables, which are defined in dependency targets
 and only available to targets that depend on them.
 
 The reason for the term "Make" is historical: the syntax and semantics of
-these variables were originally intended to match [GNU
-Make](https://www.gnu.org/software/make/manual/html_node/Using-Variables.html).
+these variables were originally intended to match [GNU Make](https://www.gnu.org/software/make/manual/html_node/Using-Variables.html).
 
 ## Use
 
@@ -64,8 +63,7 @@ and look at the top output lines with capital letters.
 **Toolchain option variables**
 
 * `COMPILATION_MODE`:
-  `fastbuild`, `dbg`, or `opt`. ([more
-  details](https://bazel.build/versions/8.3.1/docs/user-manual#flag--compilation_mode))
+  `fastbuild`, `dbg`, or `opt`. ([more details](https://bazel.build/versions/8.3.1/docs/user-manual#flag--compilation_mode))
 
 **Path variables**
 
diff --git a/versions/8.3.1/reference/be/workspace.mdx b/versions/8.3.1/reference/be/workspace.mdx
index e0318406..f4bf5dd6 100644
--- a/versions/8.3.1/reference/be/workspace.mdx
+++ b/versions/8.3.1/reference/be/workspace.mdx
@@ -25,8 +25,7 @@ bind(name, actual, compatible_with, deprecation, distribs, features, licenses, r
 
 *Warning: use of `bind()` is not recommended. See "[Consider removing bind](https://github.com/bazelbuild/bazel/issues/1952)" for a long
 discussion of its issues and alternatives. In particular, consider the use of
-[`repo_mapping`
-repository attributes](https://bazel.build/versions/8.3.1/rules/repository_rules#attributes).*
+[`repo_mapping` repository attributes](https://bazel.build/versions/8.3.1/rules/repository_rules#attributes).*
 
 *Warning: `select()` cannot be used in `bind()`. See the [Configurable Attributes FAQ](/versions/8.3.1/docs/configurable-attributes#bind-select) for
 details.*
@@ -114,8 +113,7 @@ local_repository(name, path, repo_mapping)
 ```
 
 Allows targets from a local directory to be bound. This means that the current repository can
-use targets defined in this other directory. See the [bind
-section](/versions/8.3.1/reference/be/workspace#bind_examples) for more details.
+use targets defined in this other directory. See the [bind section](/versions/8.3.1/reference/be/workspace#bind_examples) for more details.
 
 #### Examples
 
diff --git a/versions/8.3.1/reference/glossary.mdx b/versions/8.3.1/reference/glossary.mdx
index c2f0c71e..6d789fed 100644
--- a/versions/8.3.1/reference/glossary.mdx
+++ b/versions/8.3.1/reference/glossary.mdx
@@ -21,8 +21,7 @@ An in-memory graph of [actions](#action) and the [artifacts](#artifact) that
 these actions read and generate. The graph might include artifacts that exist as
 source files (for example, in the file system) as well as generated
 intermediate/final artifacts that are not mentioned in `BUILD` files. Produced
-during the [analysis phase](#analysis-phase) and used during the [execution
-phase](#execution-phase).
+during the [analysis phase](#analysis-phase) and used during the [execution phase](#execution-phase).
 
 ### Action graph query (aquery) {#action-graph-query}
 A [query](#query-concept) tool that can query over build [actions](#action).
@@ -37,8 +36,7 @@ invalidate individual actions deterministically.
 
 ### Analysis phase {#analysis-phase}
 The second phase of a build. Processes the [target graph](#target-graph)
-specified in [`BUILD` files](#build-file) to produce an in-memory [action
-graph](#action-graph) that determines the order of actions to run during the
+specified in [`BUILD` files](#build-file) to produce an in-memory [action graph](#action-graph) that determines the order of actions to run during the
 [execution phase](#execution-phase). This is the phase in which rule
 implementations are evaluated.
 
@@ -81,8 +79,7 @@ target's source files, dependencies, and custom compiler options. The particular
 attributes available for a given target depend on its rule type.
 
 ### .bazelrc {#bazelrc}
-Bazel’s configuration file used to change the default values for [startup
-flags](#startup-flags) and [command flags](#command-flags), and to define common
+Bazel’s configuration file used to change the default values for [startup flags](#startup-flags) and [command flags](#command-flags), and to define common
 groups of options that can then be set together on the Bazel command line using
 a `--config` flag. Bazel can combine settings from multiple bazelrc files
 (systemwide, per-workspace, per-user, or from a custom location), and a
@@ -108,8 +105,7 @@ directory.
 
 ### .bzl File {#bzl-file}
 A file that defines rules, [macros](#macro), and constants written in
-[Starlark](#starlark). These can then be imported into [`BUILD`
-files](#build-file) using the `load()` function.
+[Starlark](#starlark). These can then be imported into [`BUILD` files](#build-file) using the `load()` function.
 
 {/* TODO: ### Build event protocol */}
 
@@ -117,8 +113,7 @@ files](#build-file) using the `load()` function.
 
 ### Build graph {#build-graph}
 The dependency graph that Bazel constructs and traverses to perform a build.
-Includes nodes like [targets](#target), [configured
-targets](#configured-target), [actions](#action), and [artifacts](#artifact). A
+Includes nodes like [targets](#target), [configured targets](#configured-target), [actions](#action), and [artifacts](#artifact). A
 build is considered complete when all [artifacts](#artifact) on which a set of
 requested targets depend are verified as up-to-date.
 
@@ -158,8 +153,7 @@ graphs and restart the [analysis phase](#analysis-phase).
 ### Configuration {#configuration}
 Information outside of [rule](#rule) definitions that impacts how rules generate
 [actions](#action). Every build has at least one configuration specifying the
-target platform, action environment variables, and command-line [build
-flags](#command-flags). [Transitions](#transition) may create additional
+target platform, action environment variables, and command-line [build flags](#command-flags). [Transitions](#transition) may create additional
 configurations, such as for host tools or cross-compilation.
 
 **See also:** [Configurations](/versions/8.3.1/extending/rules#configurations)
@@ -174,8 +168,7 @@ configuration of `//:c` because changing `--javacopt` unnecessarily breaks C++
 build cacheability.
 
 ### Configured query (cquery) {#configured-query}
-A [query](#query-concept) tool that queries over [configured
-targets](#configured-target) (after the [analysis phase](#analysis-phase)
+A [query](#query-concept) tool that queries over [configured targets](#configured-target) (after the [analysis phase](#analysis-phase)
 completes). This means `select()` and [build flags](#command-flags) (such as
 `--platforms`) are accurately reflected in the results.
 
@@ -191,8 +184,7 @@ build, it has two configured targets: `` and ``.
 ### Correctness {#correctness}
 A build is correct when its output faithfully reflects the state of its
 transitive inputs. To achieve correct builds, Bazel strives to be
-[hermetic](#hermeticity), reproducible, and making [build
-analysis](#analysis-phase) and [action execution](#execution-phase)
+[hermetic](#hermeticity), reproducible, and making [build analysis](#analysis-phase) and [action execution](#execution-phase)
 deterministic.
 
 ### Dependency {#dependency}
@@ -234,8 +226,7 @@ compilation). A dynamic execution strategy can provide the best possible
 incremental and clean build times.
 
 ### Execution phase {#execution-phase}
-The third phase of a build. Executes the [actions](#action) in the [action
-graph](#action-graph) created during the [analysis phase](#analysis-phase).
+The third phase of a build. Executes the [actions](#action) in the [action graph](#action-graph) created during the [analysis phase](#analysis-phase).
 These actions invoke executables (compilers, scripts) to read and write
 [artifacts](#artifact). *Spawn strategies* control how these actions are
 executed: locally, remotely, dynamically, sandboxed, docker, and so on.
@@ -285,8 +276,7 @@ syntax may be omitted.
 The first phase of a build where Bazel executes [`BUILD` files](#build-file) to
 create [packages](#package). [Macros](#macro) and certain functions like
 `glob()` are evaluated in this phase. Interleaved with the second phase of the
-build, the [analysis phase](#analysis-phase), to build up a [target
-graph](#target-graph).
+build, the [analysis phase](#analysis-phase), to build up a [target graph](#target-graph).
 
 ### Legacy macro {#legacy-macro}
 A flavor of [macro](#macro) which is declared as an ordinary
@@ -336,8 +326,7 @@ Module metadata is hosted in Bazel registries.
 
 ### Module Extension {#module-extension}
 A piece of logic that can be run to generate [repos](#repository) by reading
-inputs from across the [module](#module) dependency graph and invoking [repo
-rules](#repository-rule). Module extensions have capabilities similar to repo
+inputs from across the [module](#module) dependency graph and invoking [repo rules](#repository-rule). Module extensions have capabilities similar to repo
 rules, allowing them to access the internet, perform file I/O, and so on.
 
 **See also:** [Module extensions](/versions/8.3.1/external/extension)
@@ -350,8 +339,7 @@ example, `native.cc_library` or `native.java_library`). User-defined rules
 
 ### Output base {#output-base}
 A [workspace](#workspace)-specific directory to store Bazel output files. Used
-to separate outputs from the *workspace*'s source tree (the [main
-repo](#repository)). Located in the [output user root](#output-user-root).
+to separate outputs from the *workspace*'s source tree (the [main repo](#repository)). Located in the [output user root](#output-user-root).
 
 ### Output groups {#output-groups}
 A group of files that is expected to be built when Bazel finishes building a
@@ -406,8 +394,7 @@ query variants: [query](#query-command), [cquery](#configured-query), and
 [aquery](#action-graph-query).
 
 ### query (command) {#query-command}
-A [query](#query-concept) tool that operates over the build's post-[loading
-phase](#loading-phase) [target graph](#target-graph). This is relatively fast,
+A [query](#query-concept) tool that operates over the build's post-[loading phase](#loading-phase) [target graph](#target-graph). This is relatively fast,
 but can't analyze the effects of `select()`, [build flags](#command-flags),
 [artifacts](#artifact), or build [actions](#action).
 
@@ -425,8 +412,7 @@ repo; multiple such files can coexist in a directory.
 The *main repo* is the repo in which the current Bazel command is being run.
 
 *External repos* are defined by specifying [modules](#module) in `MODULE.bazel`
-files, or invoking [repo rules](#repository-rule) in [module
-extensions](#module-extension). They can be fetched on demand to a predetermined
+files, or invoking [repo rules](#repository-rule) in [module extensions](#module-extension). They can be fetched on demand to a predetermined
 "magical" location on disk.
 
 Each repo has a unique, constant *canonical* name, and potentially different
@@ -437,8 +423,7 @@ Each repo has a unique, constant *canonical* name, and potentially different
 ### Repository cache {#repo-cache}
 A shared content-addressable cache of files downloaded by Bazel for builds,
 shareable across [workspaces](#workspace). Enables offline builds after the
-initial download. Commonly used to cache files downloaded through [repository
-rules](#repository-rule) like `http_archive` and repository rule APIs like
+initial download. Commonly used to cache files downloaded through [repository rules](#repository-rule) like `http_archive` and repository rule APIs like
 `repository_ctx.download`. Files are cached only if their SHA-256 checksums are
 specified for the download.
 
@@ -472,8 +457,7 @@ Rules are instantiated to produce rule targets in the
 [loading phase](#loading-phase). In the [analysis phase](#analysis-phase) rule
 targets communicate information to their downstream dependencies in the form of
 [providers](#provider), and register [actions](#action) describing how to
-generate their output artifacts. These actions are run in the [execution
-phase](#execution-phase).
+generate their output artifacts. These actions are run in the [execution phase](#execution-phase).
 
 Note: Historically the term "rule" has been used to refer to a rule target.
 This usage was inherited from tools like Make, but causes confusion and should
@@ -517,8 +501,7 @@ support the stamp attribute.
 ### Starlark {#starlark}
 The extension language for writing [rules](/versions/8.3.1/extending/rules) and [macros](#macro). A
 restricted subset of Python (syntactically and grammatically) aimed for the
-purpose of configuration, and for better performance. Uses the [`.bzl`
-file](#bzl-file) extension. [`BUILD` files](#build-file) use an even more
+purpose of configuration, and for better performance. Uses the [`.bzl` file](#bzl-file) extension. [`BUILD` files](#build-file) use an even more
 restricted version of Starlark (such as no `def` function definitions), formerly
 known as Skylark.
 
@@ -549,8 +532,7 @@ An object that is defined in a [`BUILD` file](#build-file) and identified by a
 [label](#label). Targets represent the buildable units of a workspace from
 the perspective of the end user.
 
-A target that is declared by instantiating a [rule](#rule) is called a [rule
-target](#rule-target). Depending on the rule, these may be runnable (like
+A target that is declared by instantiating a [rule](#rule) is called a [rule target](#rule-target). Depending on the rule, these may be runnable (like
 `cc_binary`) or testable (like `cc_test`). Rule targets typically depend on
 other targets via their [attributes](#attribute) (such as `deps`); these
 dependencies form the basis of the [target graph](#target-graph).
@@ -561,14 +543,11 @@ within a `BUILD` file. As a special case, the `BUILD` file of any package is
 always considered a source file target in that package.
 
 Targets are discovered during the [loading phase](#loading-phase). During the
-[analysis phase](#analysis-phase), targets are associated with [build
-configurations](#configuration) to form [configured
-targets](#configured-target).
+[analysis phase](#analysis-phase), targets are associated with [build configurations](#configuration) to form [configured targets](#configured-target).
 
 ### Target graph {#target-graph}
 An in-memory graph of [targets](#target) and their dependencies. Produced during
-the [loading phase](#loading-phase) and used as an input to the [analysis
-phase](#analysis-phase).
+the [loading phase](#loading-phase) and used as an input to the [analysis phase](#analysis-phase).
 
 ### Target pattern {#target-pattern}
 A way to specify a group of [targets](#target) on the command line. Commonly
@@ -581,8 +560,7 @@ packages recursively from the root of the [workspace](#workspace).
 Rule [targets](#target) instantiated from test rules, and therefore contains a
 test executable. A return code of zero from the completion of the executable
 indicates test success. The exact contract between Bazel and tests (such as test
-environment variables, test result collection methods) is specified in the [Test
-Encyclopedia](/versions/8.3.1/reference/test-encyclopedia).
+environment variables, test result collection methods) is specified in the [Test Encyclopedia](/versions/8.3.1/reference/test-encyclopedia).
 
 ### Toolchain {#toolchain}
 A set of tools to build outputs for a language. Typically, a toolchain includes
@@ -596,8 +574,7 @@ A build [target](#target) is top-level if it’s requested on the Bazel command
 line. For example, if `//:foo` depends on `//:bar`, and `bazel build //:foo` is
 called, then for this build, `//:foo` is top-level, and `//:bar` isn’t
 top-level, although both targets will need to be built. An important difference
-between top-level and non-top-level targets is that [command
-flags](#command-flags) set on the Bazel command line (or via
+between top-level and non-top-level targets is that [command flags](#command-flags) set on the Bazel command line (or via
 [.bazelrc](#bazelrc)) will set the [configuration](#configuration) for top-level
 targets, but might be modified by a [transition](#transition) for non-top-level
 targets.
@@ -628,8 +605,7 @@ or `.bzl` file may load a given `.bzl` file. Without context, usually
 **See also:** [Visibility documentation](/versions/8.3.1/concepts/visibility)
 
 ### Workspace {#workspace}
-The environment shared by all Bazel commands run from the same [main
-repository](#repository).
+The environment shared by all Bazel commands run from the same [main repository](#repository).
 
 Note that historically the concepts of "repository" and "workspace" have been
 conflated; the term "workspace" has often been used to refer to the main
diff --git a/versions/8.3.1/release/backward-compatibility.mdx b/versions/8.3.1/release/backward-compatibility.mdx
index c739264f..bc2add9d 100644
--- a/versions/8.3.1/release/backward-compatibility.mdx
+++ b/versions/8.3.1/release/backward-compatibility.mdx
@@ -6,11 +6,9 @@ This page provides information about how to handle backward compatibility,
 including migrating from one release to another and how to communicate
 incompatible changes.
 
-Bazel is evolving. Minor versions released as part of an [LTS major
-version](/versions/8.3.1/release#bazel-versioning) are fully backward-compatible. New major LTS
+Bazel is evolving. Minor versions released as part of an [LTS major version](/versions/8.3.1/release#bazel-versioning) are fully backward-compatible. New major LTS
 releases may contain incompatible changes that require some migration effort.
-For more information about Bazel's release model, please check out the [Release
-Model](/versions/8.3.1/release) page.
+For more information about Bazel's release model, please check out the [Release Model](/versions/8.3.1/release) page.
 
 ## Summary {#summary}
 
@@ -59,8 +57,7 @@ available.
 ## Communicating incompatible changes {#communicating-incompatible-changes}
 
 The primary source of information about incompatible changes are GitHub issues
-marked with an ["incompatible-change"
-label](https://github.com/bazelbuild/bazel/issues?q=label%3Aincompatible-change).
+marked with an ["incompatible-change" label](https://github.com/bazelbuild/bazel/issues?q=label%3Aincompatible-change).
 
 For every incompatible change, the issue specifies the following:
 
diff --git a/versions/8.3.1/release/index.mdx b/versions/8.3.1/release/index.mdx
index 6f63d765..f631b477 100644
--- a/versions/8.3.1/release/index.mdx
+++ b/versions/8.3.1/release/index.mdx
@@ -2,8 +2,7 @@
 title: 'Release Model'
 ---
 
-As announced in [the original blog
-post](https://blog.bazel.build/2020/11/10/long-term-support-release.html), Bazel
+As announced in [the original blog post](https://blog.bazel.build/2020/11/10/long-term-support-release.html), Bazel
 4.0 and higher versions provides support for two release tracks: rolling
 releases and long term support (LTS) releases. This page covers the latest
 information about Bazel's release model.
@@ -19,8 +18,7 @@ information about Bazel's release model.
 | Bazel 5 | Maintenance | [5.4.1](https://github.com/bazelbuild/bazel/releases/tag/5.4.1) | Jan 2025 |
 | Bazel 4 | Deprecated | [4.2.4](https://github.com/bazelbuild/bazel/releases/tag/4.2.4) | Jan 2024 |
 
-All Bazel LTS releases can be found on the [release
-page](https://github.com/bazelbuild/bazel/releases) on GitHub.
+All Bazel LTS releases can be found on the [release page](https://github.com/bazelbuild/bazel/releases) on GitHub.
 
 Note: Bazel version older than Bazel 5 are no longer supported, Bazel users are
 recommended to upgrade to the latest LTS release or use rolling releases if you
@@ -28,8 +26,7 @@ want to keep up with the latest changes at HEAD.
 
 ## Release versioning {#bazel-versioning}
 
-Bazel uses a _major.minor.patch_ [Semantic
-Versioning](https://semver.org/) scheme.
+Bazel uses a _major.minor.patch_ [Semantic Versioning](https://semver.org/) scheme.
 
 *   A _major release_ contains features that are not backward compatible with
     the previous release. Each major Bazel version is an LTS release.
@@ -72,8 +69,7 @@ Bazel regularly publish releases for two release tracks.
     release.
 *   Rolling releases can ship incompatible changes. Incompatible flags are
     recommended for major breaking changes, rolling out incompatible changes
-    should follow our [backward compatibility
-    policy](/versions/8.3.1/release/backward-compatibility).
+    should follow our [backward compatibility policy](/versions/8.3.1/release/backward-compatibility).
 
 ### LTS releases {#lts-releases}
 
@@ -89,8 +85,7 @@ Bazel regularly publish releases for two release tracks.
 *   A Bazel LTS release enters the Deprecated stage after being in ​​the
     Maintenance stage for 2 years.
 
-For planned releases, please check our [release
-issues](https://github.com/bazelbuild/bazel/issues?q=is%3Aopen+is%3Aissue+label%3Arelease)
+For planned releases, please check our [release issues](https://github.com/bazelbuild/bazel/issues?q=is%3Aopen+is%3Aissue+label%3Arelease)
 on Github.
 
 ## Release procedure & policies {#release-procedure-policies}
@@ -153,8 +148,7 @@ For LTS releases, the procedure and policies below are followed:
 1.  Identify release blockers and fix issues found on the release branch.
     *   The release branch is tested with the same test suite in
         [postsubmit](https://buildkite.com/bazel/bazel-bazel) and
-        [downstream test pipeline]
-        (https://buildkite.com/bazel/bazel-at-head-plus-downstream)
+        [downstream test pipeline](https://buildkite.com/bazel/bazel-at-head-plus-downstream)
         on Bazel CI. The Bazel team monitors testing results of the release
         branch and fixes any regressions found.
 1.  Create a new release candidate from the release branch when all known
@@ -210,5 +204,4 @@ feature.
 ## Rule compatibility {#rule-compatibility}
 
 If you are a rule authors and want to maintain compatibility with different
-Bazel versions, please check out the [Rule
-Compatibility](/versions/8.3.1/release/rule-compatibility) page.
+Bazel versions, please check out the [Rule Compatibility](/versions/8.3.1/release/rule-compatibility) page.
diff --git a/versions/8.3.1/release/rule-compatibility.mdx b/versions/8.3.1/release/rule-compatibility.mdx
index 0413d259..6fa841cb 100644
--- a/versions/8.3.1/release/rule-compatibility.mdx
+++ b/versions/8.3.1/release/rule-compatibility.mdx
@@ -53,18 +53,15 @@ Bazel LTS release.
 As Bazel rules authors, you can ensure a manageable migration process for users
 by following these best practices:
 
-1.  The rule should follow [Semantic
-    Versioning](https://semver.org/): minor versions of the same
+1.  The rule should follow [Semantic Versioning](https://semver.org/): minor versions of the same
     major version are backward compatible.
 1.  The rule at HEAD should be compatible with the latest Bazel LTS release.
 1.  The rule at HEAD should be compatible with Bazel at HEAD. To achieve this,
     you can
     *   Set up your own CI testing with Bazel at HEAD
-    *   Add your project to [Bazel downstream
-        testing](https://github.com/bazelbuild/continuous-integration/blob/master/docs/downstream-testing.md);
+    *   Add your project to [Bazel downstream testing](https://github.com/bazelbuild/continuous-integration/blob/master/docs/downstream-testing.md);
         the Bazel team files issues to your project if breaking changes in Bazel
-        affect your project, and you must follow our [downstream project
-        policies](https://github.com/bazelbuild/continuous-integration/blob/master/docs/downstream-testing.md#downstream-project-policies)
+        affect your project, and you must follow our [downstream project policies](https://github.com/bazelbuild/continuous-integration/blob/master/docs/downstream-testing.md#downstream-project-policies)
         to address issues timely.
 1.  The latest major version of the rule must be compatible with the latest
     Bazel LTS release.
diff --git a/versions/8.3.1/remote/bep-glossary.mdx b/versions/8.3.1/remote/bep-glossary.mdx
index fee36d59..8b73b546 100644
--- a/versions/8.3.1/remote/bep-glossary.mdx
+++ b/versions/8.3.1/remote/bep-glossary.mdx
@@ -410,5 +410,4 @@ workspace, such as the execution root.
 
 ## WorkspaceStatus {#workspacestatus}
 
-A single `WorkspaceStatus` event contains the result of the [workspace status
-command](/versions/8.3.1/docs/user-manual#workspace-status).
+A single `WorkspaceStatus` event contains the result of the [workspace status command](/versions/8.3.1/docs/user-manual#workspace-status).
diff --git a/versions/8.3.1/remote/bep.mdx b/versions/8.3.1/remote/bep.mdx
index 89921412..b87cb89c 100644
--- a/versions/8.3.1/remote/bep.mdx
+++ b/versions/8.3.1/remote/bep.mdx
@@ -2,14 +2,12 @@
 title: 'Build Event Protocol'
 ---
 
-The [Build Event
-Protocol](https://github.com/bazelbuild/bazel/blob/master/src/main/java/com/google/devtools/build/lib/buildeventstream/proto/build_event_stream.proto)
+The [Build Event Protocol](https://github.com/bazelbuild/bazel/blob/master/src/main/java/com/google/devtools/build/lib/buildeventstream/proto/build_event_stream.proto)
 (BEP) allows third-party programs to gain insight into a Bazel invocation. For
 example, you could use the BEP to gather information for an IDE
 plugin or a dashboard that displays build results.
 
-The protocol is a set of [protocol
-buffer](https://developers.google.com/protocol-buffers/) messages with some
+The protocol is a set of [protocol buffer](https://developers.google.com/protocol-buffers/) messages with some
 semantics defined on top of it. It includes information about build and test
 results, build progress, the build configuration and much more. The BEP is
 intended to be consumed programmatically and makes parsing Bazel’s
@@ -20,16 +18,13 @@ build event is a protocol buffer message consisting of a build event identifier,
 a set of child event identifiers, and a payload.
 
 *  __Build Event Identifier:__ Depending on the kind of build event, it might be
-an [opaque
-string](https://github.com/bazelbuild/bazel/blob/7.1.0/src/main/java/com/google/devtools/build/lib/buildeventstream/proto/build_event_stream.proto#L131-L140)
-or [structured
-information](https://github.com/bazelbuild/bazel/blob/7.1.0/src/main/java/com/google/devtools/build/lib/buildeventstream/proto/build_event_stream.proto#L194-L205)
+an [opaque string](https://github.com/bazelbuild/bazel/blob/7.1.0/src/main/java/com/google/devtools/build/lib/buildeventstream/proto/build_event_stream.proto#L131-L140)
+or [structured information](https://github.com/bazelbuild/bazel/blob/7.1.0/src/main/java/com/google/devtools/build/lib/buildeventstream/proto/build_event_stream.proto#L194-L205)
 revealing more about the build event. A build event identifier is unique within
 a build.
 
 *  __Children:__ A build event may announce other build events, by including
-their build event identifiers in its [children
-field](https://github.com/bazelbuild/bazel/blob/7.1.0/src/main/java/com/google/devtools/build/lib/buildeventstream/proto/build_event_stream.proto#L1276).
+their build event identifiers in its [children field](https://github.com/bazelbuild/bazel/blob/7.1.0/src/main/java/com/google/devtools/build/lib/buildeventstream/proto/build_event_stream.proto#L1276).
 For example, the `PatternExpanded` build event announces the targets it expands
 to as children. The protocol guarantees that all events, except for the first
 event, are announced by a previous event.
@@ -91,8 +86,7 @@ human-readable formats, such as text and JSON:
 
 ## Build Event Service {#build-event-service}
 
-The [Build Event
-Service](https://github.com/googleapis/googleapis/blob/master/google/devtools/build/v1/publish_build_event.proto)
+The [Build Event Service](https://github.com/googleapis/googleapis/blob/master/google/devtools/build/v1/publish_build_event.proto)
 Protocol is a generic [gRPC](https://www.grpc.io) service for publishing build events. The Build Event
 Service protocol is independent of the BEP and treats BEP events as opaque bytes.
 Bazel ships with a gRPC client implementation of the Build Event Service protocol that
@@ -136,8 +130,7 @@ For a description of each of these flags, see the
 The BEP typically contains many references to log files (test.log, test.xml,
 etc. ) stored on the machine where Bazel is running. A remote BES server
 typically can't access these files as they are on different machines. A way to
-work around this issue is to use Bazel with [remote
-caching](/versions/8.3.1/remote/caching).
+work around this issue is to use Bazel with [remote caching](/versions/8.3.1/remote/caching).
 Bazel will upload all output files to the remote cache (including files
 referenced in the BEP) and the BES server can then fetch the referenced files
 from the cache.
diff --git a/versions/8.3.1/remote/cache-local.mdx b/versions/8.3.1/remote/cache-local.mdx
index 29538cea..4684f35f 100644
--- a/versions/8.3.1/remote/cache-local.mdx
+++ b/versions/8.3.1/remote/cache-local.mdx
@@ -18,8 +18,7 @@ execution. However, local execution presents some additional challenges.
 ## Checking your cache hit rate {#cache-hits}
 
 Successful remote cache hits will show up in the status line, similar to
-[Cache Hits rate with Remote
-Execution](/versions/8.3.1/remote/cache-remote#check-cache-hits).
+[Cache Hits rate with Remote Execution](/versions/8.3.1/remote/cache-remote#check-cache-hits).
 
 In the standard output of your Bazel run, you will see something like the
 following:
@@ -66,8 +65,7 @@ the steps in this section.
    message you see does not give you enough information, try adding
    `--verbose_failures`.
 
-2. Follow the steps from [Troubleshooting cache hits for remote
-   execution](/versions/8.3.1/remote/cache-remote#troubleshooting_cache_hits) to
+2. Follow the steps from [Troubleshooting cache hits for remote execution](/versions/8.3.1/remote/cache-remote#troubleshooting_cache_hits) to
    ensure that your cache-writing Bazel invocations are able to get cache hits
    on the same machine and across machines.
 
@@ -81,7 +79,6 @@ the steps in this section.
    b. Ensure your cache-reading Bazel invocations build the same targets as the
       cache-writing Bazel invocations.
 
-   c. Follow the same steps as to [ensure caching across
-      machines](/versions/8.3.1/remote/cache-remote#caching-across-machines),
+   c. Follow the same steps as to [ensure caching across machines](/versions/8.3.1/remote/cache-remote#caching-across-machines),
       to ensure caching from your cache-writing Bazel invocation to your
       cache-reading Bazel invocation.
diff --git a/versions/8.3.1/remote/caching.mdx b/versions/8.3.1/remote/caching.mdx
index 6141c102..c78267fd 100644
--- a/versions/8.3.1/remote/caching.mdx
+++ b/versions/8.3.1/remote/caching.mdx
@@ -308,8 +308,7 @@ or for the age of individual cache entries. Bazel will automatically garbage
 collect the disk cache while idling between builds; the idle timer can be set
 with `--experimental_disk_cache_gc_idle_delay` (defaulting to 5 minutes).
 
-As an alternative to automatic garbage collection, we also provide a [tool](
-https://github.com/bazelbuild/bazel/tree/master/src/tools/diskcache) to run a
+As an alternative to automatic garbage collection, we also provide a [tool](https://github.com/bazelbuild/bazel/tree/master/src/tools/diskcache) to run a
 garbage collection on demand.
 
 ## Known issues {#known-issues}
diff --git a/versions/8.3.1/remote/dynamic.mdx b/versions/8.3.1/remote/dynamic.mdx
index 851555d0..f2564efe 100644
--- a/versions/8.3.1/remote/dynamic.mdx
+++ b/versions/8.3.1/remote/dynamic.mdx
@@ -12,8 +12,7 @@ alike.
 This page describes how to enable, tune, and debug dynamic execution. If you
 have both local and remote execution set up and are trying to adjust Bazel
 settings for better performance, this page is for you. If you don't already have
-remote execution set up, go to the Bazel [Remote Execution
-Overview](/versions/8.3.1/remote/rbe) first.
+remote execution set up, go to the Bazel [Remote Execution Overview](/versions/8.3.1/remote/rbe) first.
 
 ## Enabling dynamic execution? {#enabling-dynamic-execution}
 
@@ -44,14 +43,12 @@ are likely. The default value is 1000ms, but should be tuned to being just a bit
 longer than cache hits usually take. The actual time depends both on the remote
 system and on how long a round-trip takes. Usually, the value will be the same
 for all users of a given remote system, unless some of them are far enough away
-to add roundtrip latency. You can use the [Bazel profiling
-features](/versions/8.3.1/rules/performance#performance-profiling) to look at how long typical
+to add roundtrip latency. You can use the [Bazel profiling features](/versions/8.3.1/rules/performance#performance-profiling) to look at how long typical
 cache hits take.
 
 Dynamic execution can be used with local sandboxed strategy as well as with
 [persistent workers](/versions/8.3.1/remote/persistent). Persistent workers will automatically
-run with sandboxing when used with dynamic execution, and cannot use [multiplex
-workers](/versions/8.3.1/remote/multiplex). On Darwin and Windows systems, the sandboxed
+run with sandboxing when used with dynamic execution, and cannot use [multiplex workers](/versions/8.3.1/remote/multiplex). On Darwin and Windows systems, the sandboxed
 strategy can be slow; you can pass `--reuse_sandbox_directories` to reduce
 overhead of creating sandboxes on these systems.
 
@@ -67,8 +64,7 @@ entire action fails. This is an intentional choice to prevent differences
 between local and remote execution from going unnoticed.
 
 For more background on how dynamic execution and its locking works, see Julio
-Merino's excellent [blog
-posts](https://jmmv.dev/series/bazel-dynamic-execution/)
+Merino's excellent [blog posts](https://jmmv.dev/series/bazel-dynamic-execution/)
 
 ## When should I use dynamic execution? {#when-to-use}
 
diff --git a/versions/8.3.1/remote/persistent.mdx b/versions/8.3.1/remote/persistent.mdx
index 9e6a3ccb..04117a20 100644
--- a/versions/8.3.1/remote/persistent.mdx
+++ b/versions/8.3.1/remote/persistent.mdx
@@ -257,7 +257,6 @@ For more information on persistent workers, see:
 *   [Original persistent workers blog post](https://blog.bazel.build/2015/12/10/java-workers.html)
 *   [Haskell implementation description](https://www.tweag.io/blog/2019-09-25-bazel-ghc-persistent-worker-internship/)
 *   [Blog post by Mike Morearty](https://medium.com/@mmorearty/how-to-create-a-persistent-worker-for-bazel-7738bba2cabb)
-*   [Front End Development with Bazel: Angular/TypeScript and Persistent Workers
-    w/ Asana](https://www.youtube.com/watch?v=0pgERydGyqo)
+*   [Front End Development with Bazel: Angular/TypeScript and Persistent Workers w/ Asana](https://www.youtube.com/watch?v=0pgERydGyqo)
 *   [Bazel strategies explained](https://jmmv.dev/2019/12/bazel-strategies.html)
 *   [Informative worker strategy discussion on the bazel-discuss mailing list](https://groups.google.com/forum/#!msg/bazel-discuss/oAEnuhYOPm8/ol7hf4KWJgAJ)
diff --git a/versions/8.3.1/remote/rules.mdx b/versions/8.3.1/remote/rules.mdx
index 5c48f4f2..7a6f54c8 100644
--- a/versions/8.3.1/remote/rules.mdx
+++ b/versions/8.3.1/remote/rules.mdx
@@ -54,8 +54,7 @@ variables that may not be set to equivalent values (or at all) in the remote
 execution environment.
 
 Toolchain rules currently exist for Bazel build and test rules for
-[Scala](https://github.com/bazelbuild/rules_scala/blob/master/scala/scala_toolch
-ain.bzl),
+[Scala](https://github.com/bazelbuild/rules_scala/blob/master/scala/scala_toolch ain.bzl),
 [Rust](https://github.com/bazelbuild/rules_rust/blob/main/rust/toolchain.bzl),
 and [Go](https://github.com/bazelbuild/rules_go/blob/master/go/toolchains.rst),
 and new toolchain rules are under way for other languages and tools such as
diff --git a/versions/8.3.1/remote/workspace.mdx b/versions/8.3.1/remote/workspace.mdx
index f4b91d64..35589d74 100644
--- a/versions/8.3.1/remote/workspace.mdx
+++ b/versions/8.3.1/remote/workspace.mdx
@@ -11,8 +11,7 @@ on the host machine. If your workspace rules access information about the
 host machine for use during execution, your build is likely to break due to
 incompatibilities between the environments.
 
-As part of [adapting Bazel rules for remote
-execution](/versions/8.3.1/remote/rules), you need to find such workspace rules
+As part of [adapting Bazel rules for remote execution](/versions/8.3.1/remote/rules), you need to find such workspace rules
 and fix them. This page describes how to find potentially problematic workspace
 rules using the workspace log.
 
diff --git a/versions/8.3.1/rules/language.mdx b/versions/8.3.1/rules/language.mdx
index 9a860ffd..50e01f51 100644
--- a/versions/8.3.1/rules/language.mdx
+++ b/versions/8.3.1/rules/language.mdx
@@ -93,10 +93,8 @@ values returned by rules are immutable.
 `BUILD` files register targets via making calls to rules. `.bzl` files provide
 definitions for constants, rules, macros, and functions.
 
-[Native functions](/versions/8.3.1/reference/be/functions) and [native rules](
-/reference/be/overview#language-specific-native-rules) are global symbols in
-`BUILD` files. `bzl` files need to load them using the [`native` module](
-/rules/lib/toplevel/native).
+[Native functions](/versions/8.3.1/reference/be/functions) and [native rules](/reference/be/overview#language-specific-native-rules) are global symbols in
+`BUILD` files. `bzl` files need to load them using the [`native` module](/rules/lib/toplevel/native).
 
 There are two syntactic restrictions in `BUILD` files: 1) declaring functions is
 illegal, and 2) `*args` and `**kwargs` arguments are not allowed.
diff --git a/versions/8.3.1/rules/legacy-macro-tutorial.mdx b/versions/8.3.1/rules/legacy-macro-tutorial.mdx
index 9a729284..00c02996 100644
--- a/versions/8.3.1/rules/legacy-macro-tutorial.mdx
+++ b/versions/8.3.1/rules/legacy-macro-tutorial.mdx
@@ -3,9 +3,7 @@ title: 'Creating a Legacy Macro'
 ---
 
 IMPORTANT: This tutorial is for [*legacy macros*](/versions/8.3.1/extending/legacy-macros). If
-you only need to support Bazel 8 or newer, we recommend using [symbolic
-macros](/versions/8.3.1/extending/macros) instead; take a look at [Creating a Symbolic
-Macro](../macro-tutorial).
+you only need to support Bazel 8 or newer, we recommend using [symbolic macros](/versions/8.3.1/extending/macros) instead; take a look at [Creating a Symbolic Macro](../macro-tutorial).
 
 Imagine that you need to run a tool as part of your build. For example, you
 may want to generate or preprocess a source file, or compress a binary. In this
diff --git a/versions/8.3.1/rules/verbs-tutorial.mdx b/versions/8.3.1/rules/verbs-tutorial.mdx
index b34725ee..599b7acf 100644
--- a/versions/8.3.1/rules/verbs-tutorial.mdx
+++ b/versions/8.3.1/rules/verbs-tutorial.mdx
@@ -49,8 +49,7 @@ This pattern can also be seen in the Angular project. The
 produces two targets. The first is a standard `nodejs_test` target which compares
 some generated output against a "golden" file (that is, a file containing the
 expected output). This can be built and run with a normal `bazel
-test` invocation. In `angular-cli`, you can run [one such
-target](https://github.com/angular/angular-cli/blob/e1269cb520871ee29b1a4eec6e6c0e4a94f0b5fc/etc/api/BUILD)
+test` invocation. In `angular-cli`, you can run [one such target](https://github.com/angular/angular-cli/blob/e1269cb520871ee29b1a4eec6e6c0e4a94f0b5fc/etc/api/BUILD)
 with `bazel test //etc/api:angular_devkit_core_api`.
 
 Over time, this golden file may need to be updated for legitimate reasons.
diff --git a/versions/8.3.1/run/build.mdx b/versions/8.3.1/run/build.mdx
index 92fb3fc1..8a3fabca 100644
--- a/versions/8.3.1/run/build.mdx
+++ b/versions/8.3.1/run/build.mdx
@@ -626,8 +626,7 @@ Note: Hermeticity means that the action only uses its declared input
 files and no other files in the filesystem, and it only produces its declared
 output files. See [Hermeticity](/versions/8.3.1/basics/hermeticity) for more details.
 
-On some platforms such as [Google Kubernetes
-Engine](https://cloud.google.com/kubernetes-engine/) cluster nodes or Debian,
+On some platforms such as [Google Kubernetes Engine](https://cloud.google.com/kubernetes-engine/) cluster nodes or Debian,
 user namespaces are deactivated by default due to security
 concerns. This can be checked by looking at the file
 `/proc/sys/kernel/unprivileged_userns_clone`: if it exists and contains a 0,
diff --git a/versions/8.3.1/start/android-app.mdx b/versions/8.3.1/start/android-app.mdx
index 8abda7da..f6bc09fd 100644
--- a/versions/8.3.1/start/android-app.mdx
+++ b/versions/8.3.1/start/android-app.mdx
@@ -36,8 +36,7 @@ In this tutorial you learn how to:
 Before you begin the tutorial, install the following software:
 
 * **Bazel.** To install, follow the [installation instructions](/versions/8.3.1/install).
-* **Android Studio.** To install, follow the steps to [download Android
-  Studio](https://developer.android.com/sdk/index.html).
+* **Android Studio.** To install, follow the steps to [download Android Studio](https://developer.android.com/sdk/index.html).
   Execute the setup wizard to download the SDK and configure your environment.
 * (Optional) **Git.** Use `git` to download the Android app project.
 
@@ -52,8 +51,7 @@ This app has a single button that prints a greeting when clicked:
 
 **Figure 1.** Android app button greeting.
 
-Clone the repository with `git` (or [download the ZIP file
-directly](https://github.com/bazelbuild/examples/archive/master.zip)):
+Clone the repository with `git` (or [download the ZIP file directly](https://github.com/bazelbuild/examples/archive/master.zip)):
 
 ```posix-terminal
 git clone https://github.com/bazelbuild/examples
@@ -103,8 +101,7 @@ A [workspace](/versions/8.3.1/concepts/build-ref#workspace) is a directory that
 source files for one or more software projects, and has a `MODULE.bazel` file at
 its root.
 
-The `MODULE.bazel` file may be empty or may contain references to [external
-dependencies](/versions/8.3.1/external/overview) required to build your project.
+The `MODULE.bazel` file may be empty or may contain references to [external dependencies](/versions/8.3.1/external/overview) required to build your project.
 
 First, run the following command to create an empty `MODULE.bazel` file:
 
@@ -147,8 +144,7 @@ environment variable, and automatically detect the highest API level and the
 latest version of build tools installed within that location.
 
 You can set the `ANDROID_HOME` variable to the location of the Android SDK. Find
-the path to the installed SDK using Android Studio's [SDK
-Manager](https://developer.android.com/studio/intro/update#sdk-manager).
+the path to the installed SDK using Android Studio's [SDK Manager](https://developer.android.com/studio/intro/update#sdk-manager).
 Assuming the SDK is installed to default locations, you can use the following
 commands to set the `ANDROID_HOME` variable:
 
@@ -170,16 +166,14 @@ them permanent, run the following commands:
 | Windows (PowerShell)     | `[System.Environment]::SetEnvironmentVariable('ANDROID_HOME', "$env:LOCALAPPDATA\Android\Sdk", [System.EnvironmentVariableTarget]::User)` |
 
 **Optional:** If you want to compile native code into your Android app, you
-also need to download the [Android
-NDK](https://developer.android.com/ndk/downloads/index.html)
+also need to download the [Android NDK](https://developer.android.com/ndk/downloads/index.html)
 and use `rules_android_ndk` by adding the following line to your `MODULE.bazel` file:
 
 ```python
 bazel_dep(name = "rules_android_ndk", version = "0.1.2")
 ```
 
-For more information, read [Using the Android Native Development Kit with
-Bazel](/versions/8.3.1/docs/android-ndk).
+For more information, read [Using the Android Native Development Kit with Bazel](/versions/8.3.1/docs/android-ndk).
 
 It's not necessary to set the API levels to the same value for the SDK and NDK.
 [This page](https://developer.android.com/ndk/guides/stable_apis.html)
@@ -221,8 +215,7 @@ files or other dependencies. Bazel provides two build rules,
 build an Android app.
 
 For this tutorial, you'll first use the
-`android_library` rule to tell Bazel to build an [Android library
-module](http://developer.android.com/tools/projects/index.html#LibraryProjects)
+`android_library` rule to tell Bazel to build an [Android library module](http://developer.android.com/tools/projects/index.html#LibraryProjects)
 from the app source code and resource files. You'll then use the
 `android_binary` rule to tell Bazel how to build the Android application package.
 
@@ -337,11 +330,9 @@ file:
 ### Run the app
 
 You can now deploy the app to a connected Android device or emulator from the
-command line using the [`bazel
-mobile-install`](/versions/8.3.1/docs/user-manual#mobile-install) command. This command uses
+command line using the [`bazel mobile-install`](/versions/8.3.1/docs/user-manual#mobile-install) command. This command uses
 the Android Debug Bridge (`adb`) to communicate with the device. You must set up
-your device to use `adb` following the instructions in [Android Debug
-Bridge](http://developer.android.com/tools/help/adb.html) before deployment. You
+your device to use `adb` following the instructions in [Android Debug Bridge](http://developer.android.com/tools/help/adb.html) before deployment. You
 can also choose to install the app on the Android emulator included in Android
 Studio. Make sure the emulator is running before executing the command below.
 
diff --git a/versions/8.3.1/start/cpp.mdx b/versions/8.3.1/start/cpp.mdx
index 8cd927ec..cbbdd9b7 100644
--- a/versions/8.3.1/start/cpp.mdx
+++ b/versions/8.3.1/start/cpp.mdx
@@ -19,8 +19,7 @@ Estimated completion time: 30 minutes.
 ### Prerequisites {#prerequisites}
 
 Start by [installing Bazel](https://bazel.build/versions/8.3.1/install), if you haven't
-already. This tutorial uses Git for source control, so for best results [install
-Git](https://git-scm.com/book/en/v2/Getting-Started-Installing-Git) as well.
+already. This tutorial uses Git for source control, so for best results [install Git](https://git-scm.com/book/en/v2/Getting-Started-Installing-Git) as well.
 
 Next, retrieve the sample project from Bazel's GitHub repository by running the
 following in your command-line tool of choice:
@@ -63,9 +62,7 @@ examples
 ```
 
 There are three sets of files, each set representing a stage in this tutorial.
-In the first stage, you will build a single [target]
-(https://bazel.build/reference/glossary#target) residing in a single [package]
-(https://bazel.build/reference/glossary#package). In the second stage, you will
+In the first stage, you will build a single [target](https://bazel.build/reference/glossary#target) residing in a single [package](https://bazel.build/reference/glossary#package). In the second stage, you will
 build both a binary and a library from a single package. In the third and final
 stage, you will build a project with multiple packages and build it with
 multiple targets.
@@ -86,8 +83,7 @@ It also contains these significant files:
 *   The `MODULE.bazel` file, which identifies the directory and its contents as
     a Bazel workspace and lives at the root of the project's directory
     structure. It's also where you specify your external dependencies.
-*   One or more [`BUILD`
-    files](https://bazel.build/reference/glossary#build-file), which tell Bazel
+*   One or more [`BUILD` files](https://bazel.build/reference/glossary#build-file), which tell Bazel
     how to build different parts of the project. A directory within the
     workspace that contains a `BUILD` file is a
     [package](https://bazel.build/versions/8.3.1/reference/glossary#package). (More on packages
@@ -182,9 +178,7 @@ This results in a printed "`Hello world`" message.
 
 Here's the dependency graph of Stage 1:
 
-![Dependency graph for hello-world displays a single target with a single source
-file.](/versions/8.3.1/docs/images/cpp-tutorial-stage1.png "Dependency graph for hello-world
-displays a single target with a single source file.")
+![Dependency graph for hello-world displays a single target with a single source file.](/versions/8.3.1/docs/images/cpp-tutorial-stage1.png "Dependency graph for hello-world displays a single target with a single source file.")
 
 ### Summary: stage 1 {#summary-stage-1}
 
@@ -231,8 +225,7 @@ cc_binary(
 ```
 
 With this `BUILD` file, Bazel first builds the `hello-greet` library (using
-Bazel's built-in [`cc_library`
-rule](https://bazel.build/reference/be/c-cpp#cc_library)), then the
+Bazel's built-in [`cc_library` rule](https://bazel.build/reference/be/c-cpp#cc_library)), then the
 `hello-world` binary. The `deps` attribute in the `hello-world` target tells
 Bazel that the `hello-greet` library is required to build the `hello-world`
 binary.
@@ -272,10 +265,7 @@ recompiles that file.
 Looking at the dependency graph, you can see that `hello-world` depends on an
 extra input named `hello-greet`:
 
-![Dependency graph for `hello-world` displays dependency changes after
-modification to the file.](/versions/8.3.1/docs/images/cpp-tutorial-stage2.png "Dependency
-graph for `hello-world` displays dependency changes after modification to the
-file.")
+![Dependency graph for `hello-world` displays dependency changes after modification to the file.](/versions/8.3.1/docs/images/cpp-tutorial-stage2.png "Dependency graph for `hello-world` displays dependency changes after modification to the file.")
 
 ### Summary: stage 2 {#summary-stage-2}
 
@@ -343,11 +333,7 @@ in the `lib` package (hence the target label `//lib:hello-time`) - Bazel knows
 this through the `deps` attribute. You can see this reflected in the dependency
 graph:
 
-![Dependency graph for `hello-world` displays how the target in the main package
-depends on the target in the `lib`
-package.](/versions/8.3.1/docs/images/cpp-tutorial-stage3.png "Dependency graph for
-`hello-world` displays how the target in the main package depends on the target
-in the `lib` package.")
+![Dependency graph for `hello-world` displays how the target in the main package depends on the target in the `lib` package.](/versions/8.3.1/docs/images/cpp-tutorial-stage3.png "Dependency graph for `hello-world` displays how the target in the main package depends on the target in the `lib` package.")
 
 For the build to succeed, you make the `//lib:hello-time` target in `lib/BUILD`
 explicitly visible to targets in `main/BUILD` using the visibility attribute.
@@ -395,15 +381,11 @@ Bazel journey.
 You've now completed your first basic build with Bazel, but this is just the
 start. Here are some more resources to continue learning with Bazel:
 
-*   To keep focusing on C++, read about common [C++ build use
-    cases](https://bazel.build/tutorials/cpp-use-cases).
+*   To keep focusing on C++, read about common [C++ build use cases](https://bazel.build/tutorials/cpp-use-cases).
 *   To get started with building other applications with Bazel, see the
-    tutorials for [Java](https://bazel.build/versions/8.3.1/start/java), [Android
-    application](https://bazel.build/start/android-app), or [iOS
-    application](https://bazel.build/start/ios-app).
+    tutorials for [Java](https://bazel.build/versions/8.3.1/start/java), [Android application](https://bazel.build/start/android-app), or [iOS application](https://bazel.build/start/ios-app).
 *   To learn more about working with local and remote repositories, read about
     [external dependencies](https://bazel.build/versions/8.3.1/docs/external).
-*   To learn more about Bazel's other rules, see this [reference
-    guide](https://bazel.build/rules).
+*   To learn more about Bazel's other rules, see this [reference guide](https://bazel.build/rules).
 
 Happy building!
\ No newline at end of file
diff --git a/versions/8.3.1/start/java.mdx b/versions/8.3.1/start/java.mdx
index 4ffd1b3d..4938955e 100644
--- a/versions/8.3.1/start/java.mdx
+++ b/versions/8.3.1/start/java.mdx
@@ -241,8 +241,7 @@ recompiles that file.
 Looking at the dependency graph, you can see that `ProjectRunner` depends on the
 same inputs as it did before, but the structure of the build is different:
 
-![Dependency graph of the target 'ProjectRunner' after adding a dependency](
-/docs/images/tutorial_java_02.svg)
+![Dependency graph of the target 'ProjectRunner' after adding a dependency](/docs/images/tutorial_java_02.svg)
 
 You've now built the project with two targets. The `ProjectRunner` target builds
 one source files and depends on one other target (`:greeter`), which builds
diff --git a/versions/8.3.1/tutorials/ccp-toolchain-config.mdx b/versions/8.3.1/tutorials/ccp-toolchain-config.mdx
index 55f65877..128226db 100644
--- a/versions/8.3.1/tutorials/ccp-toolchain-config.mdx
+++ b/versions/8.3.1/tutorials/ccp-toolchain-config.mdx
@@ -29,8 +29,7 @@ uses `clang version 16`, which you can install on your system.
 
 Set up your build environment as follows:
 
-1.  If you have not already done so, [download and install Bazel
-    7.0.2](https://bazel.build/install) or later.
+1.  If you have not already done so, [download and install Bazel 7.0.2](https://bazel.build/install) or later.
 
 2.  Add an empty `MODULE.bazel` file at the root folder.
 
@@ -450,8 +449,7 @@ The key takeaways are:
 
 -   You need to specify a matching `platforms` flag in the command line for
     Bazel to resolve to the toolchain for the same constraint values on the
-    platform. The documentation holds more [information about language specific
-    configuration flags](/versions/8.3.1/concepts/platforms).
+    platform. The documentation holds more [information about language specific configuration flags](/versions/8.3.1/concepts/platforms).
 -   You have to let the toolchain know where the tools live. In this tutorial
     there is a simplified version where you access the tools from the system. If
     you are interested in a more self-contained approach, you can read about
@@ -464,5 +462,4 @@ The key takeaways are:
 
 ## Further reading {#further-reading}
 
-For more details, see [C++ toolchain
-configuration](/versions/8.3.1/docs/cc-toolchain-config-reference)
\ No newline at end of file
+For more details, see [C++ toolchain configuration](/versions/8.3.1/docs/cc-toolchain-config-reference)
\ No newline at end of file
diff --git a/versions/8.4.2/about/roadmap.mdx b/versions/8.4.2/about/roadmap.mdx
index 285b97e1..f35b85bc 100644
--- a/versions/8.4.2/about/roadmap.mdx
+++ b/versions/8.4.2/about/roadmap.mdx
@@ -13,8 +13,7 @@ projects.
 
 ## Bazel 8.0 Release
 
-We plan to bring Bazel 8.0 [long term support
-(LTS)](https://bazel.build/release/versioning) to you in late 2024.
+We plan to bring Bazel 8.0 [long term support (LTS)](https://bazel.build/release/versioning) to you in late 2024.
 The following features are planned to be implemented.
 
 ### Bzlmod: external dependency management system
@@ -29,8 +28,7 @@ support will be removed. Starting with Bazel 7.1, you can set
 `--noenable_workspace` to opt into the new behavior.
 
 Bazel 8.0 will contain a number of enhancements to
-[Bazel's external dependency management]
-(https://docs.google.com/document/d/1moQfNcEIttsk6vYanNKIy3ZuK53hQUFq1b1r0rmsYVg/edit#heading=h.lgyp7ubwxmjc)
+[Bazel's external dependency management](https://docs.google.com/document/d/1moQfNcEIttsk6vYanNKIy3ZuK53hQUFq1b1r0rmsYVg/edit#heading=h.lgyp7ubwxmjc)
 functionality, including:
 
 *   The new flag `--enable_workspace` can be set to `false` to completely
diff --git a/versions/8.4.2/basics/dependencies.mdx b/versions/8.4.2/basics/dependencies.mdx
index df852d50..f7512b07 100644
--- a/versions/8.4.2/basics/dependencies.mdx
+++ b/versions/8.4.2/basics/dependencies.mdx
@@ -65,8 +65,7 @@ targets, we’ve made some strides in mitigating the downside by investing in
 tooling to automatically manage `BUILD` files to avoid burdening developers.
 
 Some of these tools, such as `buildifier` and `buildozer`, are available with
-Bazel in the [`buildtools`
-directory](https://github.com/bazelbuild/buildtools).
+Bazel in the [`buildtools` directory](https://github.com/bazelbuild/buildtools).
 
 ## Minimizing Module Visibility
 
@@ -106,8 +105,7 @@ transitive dependencies (Figure 1). Suppose target A depends on target B, which
 depends on a common library target C. Should target A be able to use classes
 defined in target C?
 
-[![Transitive
-dependencies](/versions/8.4.2/images/transitive-dependencies.png)](/versions/8.4.2/images/transitive-dependencies.png)
+[![Transitive dependencies](/versions/8.4.2/images/transitive-dependencies.png)](/versions/8.4.2/images/transitive-dependencies.png)
 
 **Figure 1**. Transitive dependencies
 
@@ -141,9 +139,7 @@ dependencies and adding them to a `BUILD` files without any developer
 intervention. But even without such tools, we’ve found the trade-off to be well
 worth it as the codebase scales: explicitly adding a dependency to `BUILD` file
 is a one-time cost, but dealing with implicit transitive dependencies can cause
-ongoing problems as long as the build target exists. Bazel [enforces strict
-transitive
-dependencies](https://blog.bazel.build/2017/06/28/sjd-unused_deps.html)
+ongoing problems as long as the build target exists. Bazel [enforces strict transitive dependencies](https://blog.bazel.build/2017/06/28/sjd-unused_deps.html)
 on Java code by default.
 
 ### External dependencies
@@ -192,8 +188,7 @@ so in theory there’s no reason that different versions of the same external
 dependency couldn’t both be declared in the build system under different names.
 That way, each target could choose which version of the dependency it wanted to
 use. This causes a lot of problems in practice, so Google enforces a strict
-[One-Version
-Rule](https://opensource.google/docs/thirdparty/oneversion/) for
+[One-Version Rule](https://opensource.google/docs/thirdparty/oneversion/) for
 all third-party dependencies in our codebase.
 
 The biggest problem with allowing multiple versions is the diamond dependency
@@ -232,8 +227,7 @@ Bazel did not use to automatically download transitive dependencies. It used to
 employ a `WORKSPACE` file that required all transitive dependencies to be
 listed, which led to a lot of pain when managing external dependencies. Bazel
 has since added support for automatic transitive external dependency management
-in the form of the `MODULE.bazel` file. See [external dependency
-overview](/versions/8.4.2/external/overview) for more details.
+in the form of the `MODULE.bazel` file. See [external dependency overview](/versions/8.4.2/external/overview) for more details.
 
 Yet again, the choice here is one between convenience and scalability. Small
 projects might prefer not having to worry about managing transitive dependencies
diff --git a/versions/8.4.2/community/roadmaps-configurability.mdx b/versions/8.4.2/community/roadmaps-configurability.mdx
index 70069a49..790dea1f 100644
--- a/versions/8.4.2/community/roadmaps-configurability.mdx
+++ b/versions/8.4.2/community/roadmaps-configurability.mdx
@@ -26,8 +26,7 @@ title: 'Bazel Configurability 2021 Roadmap'
 * Builds scale well, particularly w.r.t graph size and action caching.
 
 We also support
-[`cquery`](https://bazel.build/versions/8.4.2/query/cquery), [`Starlark
-configuration`](https://bazel.build/extending/config),
+[`cquery`](https://bazel.build/versions/8.4.2/query/cquery), [`Starlark configuration`](https://bazel.build/extending/config),
 and
 [`select()`](https://bazel.build/versions/8.4.2/docs/configurable-attributes).
 
@@ -41,15 +40,13 @@ interest of accurate expectations.
 ### Platforms
 
 

-Q3 2021**Android rules use the new [platforms
-API](https://bazel.build/concepts/platforms)**
+Q3 2021**Android rules use the new [platforms API](https://bazel.build/concepts/platforms)**
 IN PROGRESS ([#11749](https://github.com/bazelbuild/bazel/issues/11749))
 
 * This is our main priority for the beginning of 2021.
 
 

-Q3 2021**Builds support [multiple execution
-platforms](https://docs.google.com/document/d/1U9HzdDmtRnm244CaRM6JV-q2408mbNODAMewcGjnnbM/)**
+Q3 2021**Builds support [multiple execution platforms](https://docs.google.com/document/d/1U9HzdDmtRnm244CaRM6JV-q2408mbNODAMewcGjnnbM/)**
 IN PROGRESS ([#11748](https://github.com/bazelbuild/bazel/issues/11748))
 
 

diff --git a/versions/8.4.2/community/sig.mdx b/versions/8.4.2/community/sig.mdx
index 83e5be51..ef361188 100644
--- a/versions/8.4.2/community/sig.mdx
+++ b/versions/8.4.2/community/sig.mdx
@@ -3,8 +3,7 @@ title: 'Bazel Special Interest Groups'
 ---
 
 Bazel hosts Special Interest Groups (SIGs) to focus collaboration on particular
-areas and to support communication and coordination between [Bazel owners,
-maintainers, and contributors](/versions/8.4.2/contribute/policy). This policy
+areas and to support communication and coordination between [Bazel owners, maintainers, and contributors](/versions/8.4.2/contribute/policy). This policy
 applies to [`bazelbuild`](http://github.com/bazelbuild).
 
 SIGs do their work in public. The ideal scope for a SIG covers a well-defined
diff --git a/versions/8.4.2/community/users.mdx b/versions/8.4.2/community/users.mdx
index c2a62677..70d3c436 100644
--- a/versions/8.4.2/community/users.mdx
+++ b/versions/8.4.2/community/users.mdx
@@ -304,11 +304,9 @@ safety systems_.
 Pigweed is an open-source solution for sustained, robust, and rapid embedded
 product development for large teams. Pigweed has shipped in millions of
 devices, including Google's suite of Pixel devices, Nest thermostats,
-[satellites](https://www.spinlaunch.com/), and [autonomous aerial
-drones](https://www.flyzipline.com/).
+[satellites](https://www.spinlaunch.com/), and [autonomous aerial drones](https://www.flyzipline.com/).
 
-Pigweed [uses Bazel as its primary build
-system](https://pigweed.dev/seed/0111-build-systems.html). The [Bazel for
+Pigweed [uses Bazel as its primary build system](https://pigweed.dev/seed/0111-build-systems.html). The [Bazel for
 Embedded][pw-bazel-great] blog post discusses why we think it's a great build
 system for embedded projects!
 
diff --git a/versions/8.4.2/concepts/build-files.mdx b/versions/8.4.2/concepts/build-files.mdx
index 2a8bec93..db47dddf 100644
--- a/versions/8.4.2/concepts/build-files.mdx
+++ b/versions/8.4.2/concepts/build-files.mdx
@@ -132,10 +132,3 @@ for anyone to create new rules.
     programming language. Libraries can depend on other libraries,
     and binaries and tests can depend on libraries, with the expected
     separate-compilation behavior.
-
-
-  
-    
-    
-  
-
LabelsDependencies

diff --git a/versions/8.4.2/concepts/build-ref.mdx b/versions/8.4.2/concepts/build-ref.mdx
index 4a1875b7..28d423fb 100644
--- a/versions/8.4.2/concepts/build-ref.mdx
+++ b/versions/8.4.2/concepts/build-ref.mdx
@@ -17,8 +17,7 @@ its root; such a boundary marker file could be `MODULE.bazel`, `REPO.bazel`, or
 in legacy contexts, `WORKSPACE` or `WORKSPACE.bazel`.
 
 The repo in which the current Bazel command is being run is called the _main
-repo_. Other, (external) repos are defined by _repo rules_; see [external
-dependencies overview](/versions/8.4.2/external/overview) for more information.
+repo_. Other, (external) repos are defined by _repo rules_; see [external dependencies overview](/versions/8.4.2/external/overview) for more information.
 
 ## Workspace {#workspace}
 
@@ -95,9 +94,4 @@ have three properties: the list of packages they contain, their name, and other
 package groups they include. The only allowed ways to refer to them are from the
 `visibility` attribute of rules or from the `default_visibility` attribute of
 the `package` function; they do not generate or consume files. For more
-information, refer to the [`package_group`
-documentation](/versions/8.4.2/reference/be/functions#package_group).
-
-
-  Labels
-
\ No newline at end of file
+information, refer to the [`package_group` documentation](/versions/8.4.2/reference/be/functions#package_group).
diff --git a/versions/8.4.2/concepts/dependencies.mdx b/versions/8.4.2/concepts/dependencies.mdx
index de4279ff..11ebe5e6 100644
--- a/versions/8.4.2/concepts/dependencies.mdx
+++ b/versions/8.4.2/concepts/dependencies.mdx
@@ -332,11 +332,3 @@ filegroup(
 ```
 
 You can then reference the label `my_data` as the data dependency in your test.
-
-
-  
-    
-    
-  
-
BUILD filesVisibility

-
diff --git a/versions/8.4.2/concepts/labels.mdx b/versions/8.4.2/concepts/labels.mdx
index 72601041..66585828 100644
--- a/versions/8.4.2/concepts/labels.mdx
+++ b/versions/8.4.2/concepts/labels.mdx
@@ -10,8 +10,7 @@ form looks like:
 ```
 
 The first part of the label is the repository name, `@@myrepo`. The double-`@`
-syntax signifies that this is a [*canonical* repo
-name](/versions/8.4.2/external/overview#canonical-repo-name), which is unique within
+syntax signifies that this is a [*canonical* repo name](/versions/8.4.2/external/overview#canonical-repo-name), which is unique within
 the workspace. Labels with canonical repo names unambiguously identify a target
 no matter which context they appear in.
 
@@ -239,10 +238,3 @@ the build.
 This directed acyclic graph over targets is called the _target graph_ or
 _build dependency graph_, and is the domain over which the
 [Bazel Query tool](/versions/8.4.2/query/guide) operates.
-
-
-  
-    
-    
-  
-
TargetsBUILD files

diff --git a/versions/8.4.2/concepts/platforms.mdx b/versions/8.4.2/concepts/platforms.mdx
index 6d6af144..625434bf 100644
--- a/versions/8.4.2/concepts/platforms.mdx
+++ b/versions/8.4.2/concepts/platforms.mdx
@@ -77,8 +77,7 @@ To test your Android project with platforms, see
 for support.
 
 You can still use platform APIs with Apple builds (for example, when building
-with a mixture of Apple rules and pure C++) with [platform
-mappings](#platform-mappings).
+with a mixture of Apple rules and pure C++) with [platform mappings](#platform-mappings).
 
 ### Other languages {#other-languages}
 
@@ -241,8 +240,7 @@ sets `--cpu`, `--crossstool_top`, or other legacy flags, rules that read
 
 When migrating your project to platforms, you must either convert changes like
 `return { "//command_line_option:cpu": "arm" }` to `return {
-"//command_line_option:platforms": "//:my_arm_platform" }` or use [platform
-mappings](#platform-mappings) to support both styles during migration.
+"//command_line_option:platforms": "//:my_arm_platform" }` or use [platform mappings](#platform-mappings) to support both styles during migration.
 window.
 
 ## Migrating your rule set {#migrating-your-rule-set}
@@ -361,10 +359,8 @@ attributes declare a language's tools (like `compiler =
 this information to rules that need to build with these tools.
 
 Toolchains declare the `constraint_value`s of machines they can
-[target][target_compatible_with Attribute]
-(`target_compatible_with = ["@platforms//os:linux"]`) and machines their tools can
-[run on][exec_compatible_with Attribute]
-(`exec_compatible_with = ["@platforms//os:mac"]`).
+[target][target_compatible_with Attribute](`target_compatible_with = ["@platforms//os:linux"]`) and machines their tools can
+[run on][exec_compatible_with Attribute](`exec_compatible_with = ["@platforms//os:mac"]`).
 
 When building `$ bazel build //:myproject --platforms=//:myplatform`, Bazel
 automatically selects a toolchain that can run on the build machine and
diff --git a/versions/8.4.2/configure/attributes.mdx b/versions/8.4.2/configure/attributes.mdx
index aa431fae..f8d82770 100644
--- a/versions/8.4.2/configure/attributes.mdx
+++ b/versions/8.4.2/configure/attributes.mdx
@@ -2,8 +2,7 @@
 title: 'Configurable Build Attributes'
 ---
 
-**_Configurable attributes_**, commonly known as [`select()`](
-/reference/be/functions#select), is a Bazel feature that lets users toggle the values
+**_Configurable attributes_**, commonly known as [`select()`](/reference/be/functions#select), is a Bazel feature that lets users toggle the values
 of build rule attributes at the command line.
 
 This can be used, for example, for a multiplatform library that automatically
@@ -407,8 +406,7 @@ sh_library(
 )
 ```
 
-If you need a `select` to match when multiple conditions match, consider [AND
-chaining](#and-chaining).
+If you need a `select` to match when multiple conditions match, consider [AND chaining](#and-chaining).
 
 ## OR chaining {#or-chaining}
 
diff --git a/versions/8.4.2/configure/integrate-cpp.mdx b/versions/8.4.2/configure/integrate-cpp.mdx
index 5d7c4284..45a456cc 100644
--- a/versions/8.4.2/configure/integrate-cpp.mdx
+++ b/versions/8.4.2/configure/integrate-cpp.mdx
@@ -33,8 +33,7 @@ This is because when writing our own actions, they must behave
 consistently with the C++ toolchain - for example, passing C++ command line
 flags to a tool that invokes the C++ compiler behind the scenes.
 
-C++ rules use a special way of constructing command lines based on [feature
-configuration](/versions/8.4.2/docs/cc-toolchain-config-reference). To construct a command line,
+C++ rules use a special way of constructing command lines based on [feature configuration](/versions/8.4.2/docs/cc-toolchain-config-reference). To construct a command line,
 you need the following:
 
 * `features` and `action_configs` - these come from the `CcToolchainConfigInfo`
diff --git a/versions/8.4.2/configure/windows.mdx b/versions/8.4.2/configure/windows.mdx
index 075dc0a3..5f2a69f5 100644
--- a/versions/8.4.2/configure/windows.mdx
+++ b/versions/8.4.2/configure/windows.mdx
@@ -166,8 +166,7 @@ To build C++ targets with MSVC, you need:
         set BAZEL_VC=C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC
         ```
 
-*   The [Windows
-    SDK](https://developer.microsoft.com/en-us/windows/downloads/windows-10-sdk).
+*   The [Windows SDK](https://developer.microsoft.com/en-us/windows/downloads/windows-10-sdk).
 
     The Windows SDK contains header files and libraries you need when building
     Windows applications, including Bazel itself. By default, the latest Windows SDK installed will
@@ -186,8 +185,7 @@ To build C++ targets with MSVC, you need:
 
 If everything is set up, you can build a C++ target now!
 
-Try building a target from one of our [sample
-projects](https://github.com/bazelbuild/bazel/tree/master/examples):
+Try building a target from one of our [sample projects](https://github.com/bazelbuild/bazel/tree/master/examples):
 
 
 
 
-To build and use Dynamically Linked Libraries (DLL files), see [this
-example](https://github.com/bazelbuild/bazel/tree/master/examples/windows/dll).
+To build and use Dynamically Linked Libraries (DLL files), see [this example](https://github.com/bazelbuild/bazel/tree/master/examples/windows/dll).
 
 **Command Line Length Limit**: To prevent the
 [Windows command line length limit issue](https://github.com/bazelbuild/bazel/issues/5163),
@@ -292,8 +289,7 @@ On Windows, Bazel builds two output files for `java_binary` rules:
 *   a `.jar` file
 *   a `.exe` file that can set up the environment for the JVM and run the binary
 
-Try building a target from one of our [sample
-projects](https://github.com/bazelbuild/bazel/tree/master/examples):
+Try building a target from one of our [sample projects](https://github.com/bazelbuild/bazel/tree/master/examples):
 
 
   
   
 
 If you are interested in details about how Bazel builds Python targets on
-Windows, check out this [design
-doc](https://github.com/bazelbuild/bazel-website/blob/master/designs/_posts/2016-09-05-build-python-on-windows.md).
+Windows, check out this [design doc](https://github.com/bazelbuild/bazel-website/blob/master/designs/_posts/2016-09-05-build-python-on-windows.md).
diff --git a/versions/8.4.2/contribute/codebase.mdx b/versions/8.4.2/contribute/codebase.mdx
index ceb6f7aa..0dee2a09 100644
--- a/versions/8.4.2/contribute/codebase.mdx
+++ b/versions/8.4.2/contribute/codebase.mdx
@@ -227,8 +227,7 @@ repository", the others are called "external repositories".
 A repository is marked by a repo boundary file (`MODULE.bazel`, `REPO.bazel`, or
 in legacy contexts, `WORKSPACE` or `WORKSPACE.bazel`) in its root directory. The
 main repo is the source tree where you're invoking Bazel from. External repos
-are defined in various ways; see [external dependencies
-overview](/versions/8.4.2/external/overview) for more information.
+are defined in various ways; see [external dependencies overview](/versions/8.4.2/external/overview) for more information.
 
 Code of external repositories is symlinked or downloaded under
 `$OUTPUT_BASE/external`.
diff --git a/versions/8.4.2/contribute/design-documents.mdx b/versions/8.4.2/contribute/design-documents.mdx
index 888258f8..1be2013e 100644
--- a/versions/8.4.2/contribute/design-documents.mdx
+++ b/versions/8.4.2/contribute/design-documents.mdx
@@ -137,8 +137,7 @@ A lead reviewer should be a domain expert who is:
 *   Objective and capable of providing constructive feedback
 *   Available for the entire review period to lead the process
 
-Consider checking the contacts for various [team
-labels](/versions/8.4.2/contribute/maintainers-guide#team-labels).
+Consider checking the contacts for various [team labels](/versions/8.4.2/contribute/maintainers-guide#team-labels).
 
 ## Markdown vs Google Docs {#markdown-versus-gdocs}
 
@@ -168,12 +167,10 @@ Markdown for posterity.
 
 ### Using Google Docs {#gdocs}
 
-For consistency, use the [Bazel design doc template](
-https://docs.google.com/document/d/1cE5zrjrR40RXNg64XtRFewSv6FrLV6slGkkqxBumS1w/edit).
+For consistency, use the [Bazel design doc template](https://docs.google.com/document/d/1cE5zrjrR40RXNg64XtRFewSv6FrLV6slGkkqxBumS1w/edit).
 It includes the necessary header and creates visual
 consistency with other Bazel related documents. To do that, click on **File** >
-**Make a copy** or click this link to [make a copy of the design doc
-template](https://docs.google.com/document/d/1cE5zrjrR40RXNg64XtRFewSv6FrLV6slGkkqxBumS1w/copy).
+**Make a copy** or click this link to [make a copy of the design doc template](https://docs.google.com/document/d/1cE5zrjrR40RXNg64XtRFewSv6FrLV6slGkkqxBumS1w/copy).
 
 To make your document readable to the world, click on
 **Share** > **Advanced** > **Change…**, and
diff --git a/versions/8.4.2/contribute/index.mdx b/versions/8.4.2/contribute/index.mdx
index 70cce39a..94927d21 100644
--- a/versions/8.4.2/contribute/index.mdx
+++ b/versions/8.4.2/contribute/index.mdx
@@ -10,8 +10,7 @@ As you use Bazel, you may find things that can be improved.
 You can help by [reporting issues](http://github.com/bazelbuild/bazel/issues)
 when:
 
-   - Bazel crashes or you encounter a bug that can [only be resolved using `bazel
-     clean`](/versions/8.4.2/run/build#correct-incremental-rebuilds).
+   - Bazel crashes or you encounter a bug that can [only be resolved using `bazel clean`](/versions/8.4.2/run/build#correct-incremental-rebuilds).
    - The documentation is incomplete or unclear. You can also report issues
      from the page you are viewing by using the "Create issue"
      link at the top right corner of the page.
@@ -21,11 +20,9 @@ when:
 
 You can engage with the Bazel community by:
 
-   - Answering questions [on Stack Overflow](
-     https://stackoverflow.com/questions/tagged/bazel).
+   - Answering questions [on Stack Overflow](https://stackoverflow.com/questions/tagged/bazel).
    - Helping other users [on Slack](https://slack.bazel.build).
-   - Improving documentation or [contributing examples](
-     https://github.com/bazelbuild/examples).
+   - Improving documentation or [contributing examples](https://github.com/bazelbuild/examples).
    - Sharing your experience or your tips, for example, on a blog or social media.
 
 ## Contribute code {#contribute-code}
@@ -40,8 +37,7 @@ You can contribute to the Bazel ecosystem by:
    - Contributing to Bazel-related tools, for example, migration tools.
    - Improving Bazel integration with other IDEs and tools.
 
-Before making a change, [create a GitHub
-issue](http://github.com/bazelbuild/bazel/issues)
+Before making a change, [create a GitHub issue](http://github.com/bazelbuild/bazel/issues)
 or email [bazel-discuss@](mailto:bazel-discuss@googlegroups.com).
 
 The most helpful contributions fix bugs or add features (as opposed
diff --git a/versions/8.4.2/contribute/maintainers-guide.mdx b/versions/8.4.2/contribute/maintainers-guide.mdx
index a5799174..bd281f83 100644
--- a/versions/8.4.2/contribute/maintainers-guide.mdx
+++ b/versions/8.4.2/contribute/maintainers-guide.mdx
@@ -4,8 +4,7 @@ title: 'Guide for Bazel Maintainers'
 
 This is a guide for the maintainers of the Bazel open source project.
 
-If you are looking to contribute to Bazel, please read [Contributing to
-Bazel](/versions/8.4.2/contribute) instead.
+If you are looking to contribute to Bazel, please read [Contributing to Bazel](/versions/8.4.2/contribute) instead.
 
 The objectives of this page are to:
 
@@ -37,8 +36,7 @@ repository.
 
 1. A user creates an issue by choosing one of the
 [issue templates](https://github.com/bazelbuild/bazel/issues/new/choose)
-   and it enters the pool of [unreviewed open
-   issues](https://github.com/bazelbuild/bazel/issues?utf8=%E2%9C%93&q=is%3Aissue+is%3Aopen+-label%3Auntriaged+-label%3Ap2+-label%3Ap1+-label%3Ap3+-label%3Ap4+-label%3Ateam-Starlark+-label%3Ateam-Rules-CPP+-label%3Ateam-Rules-Java+-label%3Ateam-XProduct+-label%3Ateam-Android+-label%3Ateam-Apple+-label%3Ateam-Configurability++-label%3Ateam-Performance+-label%3Ateam-Rules-Server+-label%3Ateam-Core+-label%3Ateam-Rules-Python+-label%3Ateam-Remote-Exec+-label%3Ateam-Local-Exec+-label%3Ateam-Bazel).
+   and it enters the pool of [unreviewed open issues](https://github.com/bazelbuild/bazel/issues?utf8=%E2%9C%93&q=is%3Aissue+is%3Aopen+-label%3Auntriaged+-label%3Ap2+-label%3Ap1+-label%3Ap3+-label%3Ap4+-label%3Ateam-Starlark+-label%3Ateam-Rules-CPP+-label%3Ateam-Rules-Java+-label%3Ateam-XProduct+-label%3Ateam-Android+-label%3Ateam-Apple+-label%3Ateam-Configurability++-label%3Ateam-Performance+-label%3Ateam-Rules-Server+-label%3Ateam-Core+-label%3Ateam-Rules-Python+-label%3Ateam-Remote-Exec+-label%3Ateam-Local-Exec+-label%3Ateam-Bazel).
 1. A member on the Developer Experience (DevEx) subteam rotation reviews the
    issue.
    1. If the issue is **not a bug** or a **feature request**, the DevEx member
@@ -58,21 +56,18 @@ repository.
 1. After reviewing the issue, the DevEx member decides if the issue requires
    immediate attention. If it does, they will assign the **P0**
    [priority](#priority) label and an owner from the list of team leads.
-1. The DevEx member assigns the `untriaged` label and exactly one [team
-   label](#team-labels) for routing.
+1. The DevEx member assigns the `untriaged` label and exactly one [team label](#team-labels) for routing.
 1. The DevEx member also assigns exactly one `type:` label, such as `type: bug`
    or `type: feature request`, according to the type of the issue.
 1. For platform-specific issues, the DevEx member assigns one `platform:` label,
    such as `platform:apple` for Mac-specific issues.
 1. If the issue is low priority and can be worked on by a new community
    contributor, the DevEx member assigns the `good first issue` label.
-At this stage, the issue enters the pool of [untriaged open
-issues](https://github.com/bazelbuild/bazel/issues?q=is%3Aissue+is%3Aopen+label%3Auntriaged).
+At this stage, the issue enters the pool of [untriaged open issues](https://github.com/bazelbuild/bazel/issues?q=is%3Aissue+is%3Aopen+label%3Auntriaged).
 
 Each Bazel subteam will triage all issues under labels they own, preferably on a
 weekly basis. The subteam will review and evaluate the issue and provide a
-resolution, if possible. If you are an owner of a team label, see [this section
-](#label-own) for more information.
+resolution, if possible. If you are an owner of a team label, see [this section](#label-own) for more information.
 
 When an issue is resolved, it can be closed.
 
@@ -111,8 +106,7 @@ preferably on a weekly basis.
      issue is either P0 or P1 we assume that is actively worked on.
 1. Remove the `untriaged` label.
 
-Note that you need to be in the [bazelbuild
-organization](https://github.com/bazelbuild) to be able to add or remove labels.
+Note that you need to be in the [bazelbuild organization](https://github.com/bazelbuild) to be able to add or remove labels.
 
 ### Pull Requests {#pull-requests}
 
@@ -138,8 +132,7 @@ issues.
   unusable, or a downed service that severely impacts development of the Bazel
   project. This includes regressions introduced in a new release that blocks a
   significant number of users, or an incompatible breaking change that was not
-  compliant to the [Breaking
-  Change](https://docs.google.com/document/d/1q5GGRxKrF_mnwtaPKI487P8OdDRh2nN7jX6U-FXnHL0/edit?pli=1#heading=h.ceof6vpkb3ik)
+  compliant to the [Breaking Change](https://docs.google.com/document/d/1q5GGRxKrF_mnwtaPKI487P8OdDRh2nN7jX6U-FXnHL0/edit?pli=1#heading=h.ceof6vpkb3ik)
   policy. No practical workaround exists.
 * [**P1**](https://github.com/bazelbuild/bazel/labels/P1) - Critical defect or
   feature which should be addressed in the next release, or a serious issue that
diff --git a/versions/8.4.2/contribute/naming.mdx b/versions/8.4.2/contribute/naming.mdx
index 1c2fd0de..d18cd8f5 100644
--- a/versions/8.4.2/contribute/naming.mdx
+++ b/versions/8.4.2/contribute/naming.mdx
@@ -4,8 +4,7 @@ title: 'Naming a Bazel related project'
 
 First, thank you for contributing to the Bazel ecosystem! Please reach out to
 the Bazel community on the
-[bazel-discuss mailing list](https://groups.google.com/forum/#!forum/bazel-discuss
-) to share your project and its suggested name.
+[bazel-discuss mailing list](https://groups.google.com/forum/#!forum/bazel-discuss) to share your project and its suggested name.
 
 If you are building a Bazel related tool or sharing your Skylark rules,
 we recommend following these guidelines for the name of your project:
diff --git a/versions/8.4.2/contribute/patch-acceptance.mdx b/versions/8.4.2/contribute/patch-acceptance.mdx
index 1bad7123..abfec71e 100644
--- a/versions/8.4.2/contribute/patch-acceptance.mdx
+++ b/versions/8.4.2/contribute/patch-acceptance.mdx
@@ -11,29 +11,24 @@ code base.
    need a corresponding issue for tracking.
 1. If you're proposing significant changes, write a
    [design document](/versions/8.4.2/contribute/design-documents).
-1. Ensure you've signed a [Contributor License
-   Agreement](https://cla.developers.google.com).
+1. Ensure you've signed a [Contributor License Agreement](https://cla.developers.google.com).
 1. Prepare a git commit that implements the feature. Don't forget to add tests
    and update the documentation. If your change has user-visible effects, please
    [add release notes](/versions/8.4.2/contribute/release-notes). If it is an incompatible change,
    read the [guide for rolling out breaking changes](/versions/8.4.2/contribute/breaking-changes).
 1. Create a pull request on
    [GitHub](https://github.com/bazelbuild/bazel/pulls). If you're new to GitHub,
-   read [about pull
-   requests](https://help.github.com/articles/about-pull-requests/). Note that
+   read [about pull requests](https://help.github.com/articles/about-pull-requests/). Note that
    we restrict permissions to create branches on the main Bazel repository, so
-   you will need to push your commit to [your own fork of the
-   repository](https://help.github.com/articles/working-with-forks/).
+   you will need to push your commit to [your own fork of the repository](https://help.github.com/articles/working-with-forks/).
 1. A Bazel maintainer should assign you a reviewer within two business days
    (excluding holidays in the USA and Germany). If you aren't assigned a
    reviewer in that time, you can request one by emailing
-   [bazel-discuss@googlegroups.com]
-   (mailto:bazel-discuss@googlegroups.com).
+   [bazel-discuss@googlegroups.com](mailto:bazel-discuss@googlegroups.com).
 1. Work with the reviewer to complete a code review. For each change, create a
    new commit and push it to make changes to your pull request. If the review
    takes too long (for instance, if the reviewer is unresponsive), send an email to
-   [bazel-discuss@googlegroups.com]
-   (mailto:bazel-discuss@googlegroups.com).
+   [bazel-discuss@googlegroups.com](mailto:bazel-discuss@googlegroups.com).
 1. After your review is complete, a Bazel maintainer applies your patch to
    Google's internal version control system.
 
diff --git a/versions/8.4.2/contribute/release-notes.mdx b/versions/8.4.2/contribute/release-notes.mdx
index 7dd604d5..84105e81 100644
--- a/versions/8.4.2/contribute/release-notes.mdx
+++ b/versions/8.4.2/contribute/release-notes.mdx
@@ -16,8 +16,7 @@ the release announcement.
 * If the change adds / removes / changes Bazel in a user-visible way, then it
   may be advantageous to mention it.
 
-If the change is significant, follow the [design document
-policy](/versions/8.4.2/contribute/design-documents) first.
+If the change is significant, follow the [design document policy](/versions/8.4.2/contribute/design-documents) first.
 
 ## Guidelines {#guidelines}
 
@@ -60,10 +59,8 @@ change is about.
 
 ## Process {#process}
 
-As part of the [release
-process](https://github.com/bazelbuild/continuous-integration/blob/master/docs/release-playbook.md),
-we collect the `RELNOTES` tags of every commit. We copy everything in a [Google
-Doc](https://docs.google.com/document/d/1wDvulLlj4NAlPZamdlEVFORks3YXJonCjyuQMUQEmB0/edit)
+As part of the [release process](https://github.com/bazelbuild/continuous-integration/blob/master/docs/release-playbook.md),
+we collect the `RELNOTES` tags of every commit. We copy everything in a [Google Doc](https://docs.google.com/document/d/1wDvulLlj4NAlPZamdlEVFORks3YXJonCjyuQMUQEmB0/edit)
 where we review, edit, and organize the notes.
 
 The release manager sends an email to the
@@ -71,6 +68,4 @@ The release manager sends an email to the
 Bazel contributors are invited to contribute to the document and make sure
 their changes are correctly reflected in the announcement.
 
-Later, the announcement will be submitted to the [Bazel
-blog](https://blog.bazel.build/), using the [bazel-blog
-repository](https://github.com/bazelbuild/bazel-blog/tree/master/_posts).
+Later, the announcement will be submitted to the [Bazel blog](https://blog.bazel.build/), using the [bazel-blog repository](https://github.com/bazelbuild/bazel-blog/tree/master/_posts).
diff --git a/versions/8.4.2/contribute/statemachine-guide.mdx b/versions/8.4.2/contribute/statemachine-guide.mdx
index 44c6d5ea..aef298fc 100644
--- a/versions/8.4.2/contribute/statemachine-guide.mdx
+++ b/versions/8.4.2/contribute/statemachine-guide.mdx
@@ -172,8 +172,7 @@ instead, batches[^4] as many lookups as possible before doing so. The value
 might not be immediately available, for example, requiring a Skyframe restart,
 so the caller specifies what to do with the resulting value using a callback.
 
-The `StateMachine` processor ([`Driver`s and bridging to
-SkyFrame](#drivers-and-bridging)) guarantees that the value is available before
+The `StateMachine` processor ([`Driver`s and bridging to SkyFrame](#drivers-and-bridging)) guarantees that the value is available before
 the next state begins. An example follows.
 
 ```
@@ -284,8 +283,7 @@ and solutions to certain control flow problems.
 ### Sequential states
 
 This is the most common and straightforward control flow pattern. An example of
-this is shown in [Stateful computations inside
-`SkyKeyComputeState`](#stateful-computations).
+this is shown in [Stateful computations inside `SkyKeyComputeState`](#stateful-computations).
 
 ### Branching
 
@@ -545,8 +543,7 @@ section describes the propagation of data values.
 
 ### Implementing `Tasks.lookUp` callbacks
 
-There’s an example of implementing a `Tasks.lookUp` callback in [SkyValue
-lookups](#skyvalue-lookups). This section provides rationale and suggests
+There’s an example of implementing a `Tasks.lookUp` callback in [SkyValue lookups](#skyvalue-lookups). This section provides rationale and suggests
 approaches for handling multiple SkyValues.
 
 #### `Tasks.lookUp` callbacks {#tasks-lookup-callbacks}
@@ -710,8 +707,7 @@ class BarProducer implements StateMachine {
 Tip: It would be tempting to use the more concise signature void `accept(Bar
 value)` rather than the stuttery `void acceptBarValue(Bar value)` above.
 However, `Consumer` is a common overload of `void accept(Bar value)`,
-so doing this often leads to violations of the [Overloads: never
-split](https://google.github.io/styleguide/javaguide.html#s3.4.2-ordering-class-contents)
+so doing this often leads to violations of the [Overloads: never split](https://google.github.io/styleguide/javaguide.html#s3.4.2-ordering-class-contents)
 style-guide rule.
 
 Tip: Using a custom `ResultSink` type instead of a generic one from
@@ -774,14 +770,11 @@ pattern after accepting output from either a subtask or SkyValue lookup.
 Note that the implementation of `acceptBarError` eagerly forwards the result to
 the `Caller.ResultSink`, as required by [Error bubbling](#error-bubbling).
 
-Alternatives for top-level `StateMachine`s are described in [`Driver`s and
-bridging to SkyFunctions](#drivers-and-bridging).
+Alternatives for top-level `StateMachine`s are described in [`Driver`s and bridging to SkyFunctions](#drivers-and-bridging).
 
 ### Error handling {#error-handling}
 
-There's a couple of examples of error handling already in [`Tasks.lookUp`
-callbacks](#tasks-lookup-callbacks) and [Propagating values between
-`StateMachines`](#propagating-values). Exceptions, other than
+There's a couple of examples of error handling already in [`Tasks.lookUp` callbacks](#tasks-lookup-callbacks) and [Propagating values between `StateMachines`](#propagating-values). Exceptions, other than
 `InterruptedException` are not thrown, but instead passed around through
 callbacks as values. Such callbacks often have exclusive-or semantics, with
 exactly one of a value or error being passed.
@@ -1184,8 +1177,7 @@ states. Where it is possible, local stack `step` variables are young generation
 variables and efficiently GC'd.
 
 For `StateMachine` variables, breaking things down into subtasks and following
-the recommended pattern for [Propagating values between
-`StateMachine`s](#propagating-values) is also helpful. Observe that when
+the recommended pattern for [Propagating values between `StateMachine`s](#propagating-values) is also helpful. Observe that when
 following the pattern, only child `StateMachine`s have references to parent
 `StateMachine`s and not vice versa. This means that as children complete and
 update the parents using result callbacks, the children naturally fall out of
@@ -1207,8 +1199,7 @@ potentially reflecting local behavior.
 
 ### Concurrency tree diagram {#concurrency-tree-diagram}
 
-The following is an alternative view of the diagram in [Structured
-concurrency](#structured-concurrency) that better depicts the tree structure.
+The following is an alternative view of the diagram in [Structured concurrency](#structured-concurrency) that better depicts the tree structure.
 The blocks form a small tree.
 
 ![Structured Concurrency 3D](/versions/8.4.2/contribute/images/structured-concurrency-3d.svg)
diff --git a/versions/8.4.2/docs/android-instrumentation-test.mdx b/versions/8.4.2/docs/android-instrumentation-test.mdx
index fd5bfffa..c9a76051 100644
--- a/versions/8.4.2/docs/android-instrumentation-test.mdx
+++ b/versions/8.4.2/docs/android-instrumentation-test.mdx
@@ -2,8 +2,7 @@
 title: 'Android Instrumentation Tests'
 ---
 
-_If you're new to Bazel, start with the [Building Android with
-Bazel](/versions/8.4.2/start/android-app ) tutorial._
+_If you're new to Bazel, start with the [Building Android with Bazel](/versions/8.4.2/start/android-app) tutorial._
 
 ![Running Android instrumentation tests in parallel](/versions/8.4.2/docs/images/android_test.gif "Android instrumentation test")
 
@@ -18,9 +17,7 @@ emulators in a sandbox, ensuring that tests always run from a clean state. Each
 test gets an isolated emulator instance, allowing tests to run in parallel
 without passing states between them.
 
-For more information on Android instrumentation tests, check out the [Android
-developer
-documentation](https://developer.android.com/training/testing/unit-testing/instrumented-unit-tests.html).
+For more information on Android instrumentation tests, check out the [Android developer documentation](https://developer.android.com/training/testing/unit-testing/instrumented-unit-tests.html).
 
 Please file issues in the [GitHub issue tracker](https://github.com/bazelbuild/bazel/issues).
 
@@ -58,8 +55,7 @@ This results in output similar to the following:
 release 4.1.0
 ```
 
-- **KVM**. Bazel requires emulators to have [hardware
-  acceleration](https://developer.android.com/studio/run/emulator-acceleration.html#accel-check)
+- **KVM**. Bazel requires emulators to have [hardware acceleration](https://developer.android.com/studio/run/emulator-acceleration.html#accel-check)
   with KVM on Linux. You can follow these
   [installation instructions](https://help.ubuntu.com/community/KVM/Installation)
   for Ubuntu.
@@ -173,11 +169,9 @@ The main attributes of the rule `android_instrumentation_test` are:
 
 - `target_device`: An `android_device` target. This target describes the
   specifications of the Android emulator which Bazel uses to create, launch and
-  run the tests. See the [section on choosing an Android
-  device](#android-device-target) for more information.
+  run the tests. See the [section on choosing an Android device](#android-device-target) for more information.
 
-The test app's `AndroidManifest.xml` must include [an ``
-tag](https://developer.android.com/studio/test/#configure_instrumentation_manifest_settings).
+The test app's `AndroidManifest.xml` must include [an `` tag](https://developer.android.com/studio/test/#configure_instrumentation_manifest_settings).
 This tag must specify the attributes for the **package of the target app** and
 the **fully qualified class name of the instrumentation test runner**,
 `androidx.test.runner.AndroidJUnitRunner`.
@@ -214,8 +208,7 @@ repositories:
 - `@androidsdk`: The Android SDK. Download this through Android Studio.
 
 - `@android_test_support`: Hosts the test runner, emulator launcher, and
-  `android_device` targets. You can find the [latest release
-  here](https://github.com/android/android-test/releases).
+  `android_device` targets. You can find the [latest release here](https://github.com/android/android-test/releases).
 
 Enable these dependencies by adding the following lines to your `WORKSPACE`
 file:
@@ -240,8 +233,7 @@ android_test_repositories()
 
 ## Maven dependencies {#maven-dependencies}
 
-For managing dependencies on Maven artifacts from repositories, such as [Google
-Maven](https://maven.google.com) or [Maven Central](https://central.maven.org),
+For managing dependencies on Maven artifacts from repositories, such as [Google Maven](https://maven.google.com) or [Maven Central](https://central.maven.org),
 you should use a Maven resolver, such as
 [`rules_jvm_external`](https://github.com/bazelbuild/rules_jvm_external).
 
@@ -370,8 +362,7 @@ the device/emulator listed in `adb devices`.
 
 ## Sample projects {#sample-projects}
 
-If you are looking for canonical project samples, see the [Android testing
-samples](https://github.com/googlesamples/android-testing#experimental-bazel-support)
+If you are looking for canonical project samples, see the [Android testing samples](https://github.com/googlesamples/android-testing#experimental-bazel-support)
 for projects using Espresso and UIAutomator.
 
 ## Espresso setup {#espresso-setup}
@@ -560,8 +551,7 @@ API_LEVELS = [
 
 ## Known issues {#known-issues}
 
-- [Forked adb server processes are not terminated after
-  tests](https://github.com/bazelbuild/bazel/issues/4853)
+- [Forked adb server processes are not terminated after tests](https://github.com/bazelbuild/bazel/issues/4853)
 - While APK building works on all platforms (Linux, macOS, Windows), testing
   only works on Linux.
 - Even with `--config=local_adb`, users still need to specify
diff --git a/versions/8.4.2/docs/android-ndk.mdx b/versions/8.4.2/docs/android-ndk.mdx
index f897e4e9..3a964118 100644
--- a/versions/8.4.2/docs/android-ndk.mdx
+++ b/versions/8.4.2/docs/android-ndk.mdx
@@ -2,8 +2,7 @@
 title: 'Using the Android Native Development Kit with Bazel'
 ---
 
-_If you're new to Bazel, please start with the [Building Android with
-Bazel](/versions/8.4.2/start/android-app ) tutorial._
+_If you're new to Bazel, please start with the [Building Android with Bazel](/versions/8.4.2/start/android-app) tutorial._
 
 ## Overview {#overview}
 
@@ -31,8 +30,7 @@ android_ndk_repository(
 )
 ```
 
-For more information about the `android_ndk_repository` rule, see the [Build
-Encyclopedia entry](/versions/8.4.2/reference/be/android#android_ndk_repository).
+For more information about the `android_ndk_repository` rule, see the [Build Encyclopedia entry](/versions/8.4.2/reference/be/android#android_ndk_repository).
 
 If you're using a recent version of the Android NDK (r22 and beyond), use the
 Starlark implementation of `android_ndk_repository`.
@@ -101,13 +99,11 @@ META-INF/MANIFEST.MF
 
 Bazel compiles all of the cc_libraries into a single shared object (`.so`) file,
 targeted for the `armeabi-v7a` ABI by default. To change this or build for
-multiple ABIs at the same time, see the section on [configuring the target
-ABI](#configuring-target-abi).
+multiple ABIs at the same time, see the section on [configuring the target ABI](#configuring-target-abi).
 
 ## Example setup {#example-setup}
 
-This example is available in the [Bazel examples
-repository](https://github.com/bazelbuild/examples/tree/master/android/ndk).
+This example is available in the [Bazel examples repository](https://github.com/bazelbuild/examples/tree/master/android/ndk).
 
 In the `BUILD.bazel` file, three targets are defined with the `android_binary`,
 `android_library`, and `cc_library` rules.
diff --git a/versions/8.4.2/docs/configurable-attributes.mdx b/versions/8.4.2/docs/configurable-attributes.mdx
index b4682fb6..275544b6 100644
--- a/versions/8.4.2/docs/configurable-attributes.mdx
+++ b/versions/8.4.2/docs/configurable-attributes.mdx
@@ -2,8 +2,7 @@
 title: 'Configurable Build Attributes'
 ---
 
-**_Configurable attributes_**, commonly known as [`select()`](
-/reference/be/functions#select), is a Bazel feature that lets users toggle the values
+**_Configurable attributes_**, commonly known as [`select()`](/reference/be/functions#select), is a Bazel feature that lets users toggle the values
 of build rule attributes at the command line.
 
 This can be used, for example, for a multiplatform library that automatically
@@ -407,8 +406,7 @@ sh_library(
 )
 ```
 
-If you need a `select` to match when multiple conditions match, consider [AND
-chaining](#and-chaining).
+If you need a `select` to match when multiple conditions match, consider [AND chaining](#and-chaining).
 
 ## OR chaining {#or-chaining}
 
diff --git a/versions/8.4.2/docs/user-manual.mdx b/versions/8.4.2/docs/user-manual.mdx
index 3903f7d4..2dba8580 100644
--- a/versions/8.4.2/docs/user-manual.mdx
+++ b/versions/8.4.2/docs/user-manual.mdx
@@ -1146,10 +1146,7 @@ This option causes Bazel's execution phase to print the full command line
 for each command prior to executing it.
 
 
-  >>>>> # //examples/cpp:hello-world [action 'Linking examples/cpp/hello-world']
-  (cd /home/johndoe/.cache/bazel/_bazel_johndoe/4c084335afceb392cfbe7c31afee3a9f/bazel && \
-    exec env - \
-    /usr/bin/gcc -o bazel-out/local-fastbuild/bin/examples/cpp/hello-world -B/usr/bin/ -Wl,-z,relro,-z,now -no-canonical-prefixes -pass-exit-codes -Wl,-S -Wl,@bazel-out/local_linux-fastbuild/bin/examples/cpp/hello-world-2.params)
+  >>>>> # //examples/cpp:hello-world [action 'Linking examples/cpp/hello-world'](cd /home/johndoe/.cache/bazel/_bazel_johndoe/4c084335afceb392cfbe7c31afee3a9f/bazel && \ exec env - \ /usr/bin/gcc -o bazel-out/local-fastbuild/bin/examples/cpp/hello-world -B/usr/bin/ -Wl,-z,relro,-z,now -no-canonical-prefixes -pass-exit-codes -Wl,-S -Wl,@bazel-out/local_linux-fastbuild/bin/examples/cpp/hello-world-2.params)
 

 
 Where possible, commands are printed in a Bourne shell compatible syntax,
diff --git a/versions/8.4.2/extending/auto-exec-groups.mdx b/versions/8.4.2/extending/auto-exec-groups.mdx
index 9c3d0d33..d7cef622 100644
--- a/versions/8.4.2/extending/auto-exec-groups.mdx
+++ b/versions/8.4.2/extending/auto-exec-groups.mdx
@@ -27,9 +27,7 @@ doesn't detect that ([the error](#first-error-message) is raised), you can set
 
 If you need to use multiple toolchains on a single execution platform (an action
 uses executable or tools from two or more toolchains), you need to manually
-define [exec_groups][exec_groups] (check
-[When should I use a custom exec_group?][multiple_toolchains_exec_groups]
-section).
+define [exec_groups][exec_groups](check [When should I use a custom exec_group?][multiple_toolchains_exec_groups] section).
 
 ## History {#history}
 
@@ -42,8 +40,7 @@ my_rule = rule(
 )
 ```
 
-Rule `my_rule` registers two toolchain types. This means that the [Toolchain
-Resolution](https://bazel.build/extending/toolchains#toolchain-resolution) used
+Rule `my_rule` registers two toolchain types. This means that the [Toolchain Resolution](https://bazel.build/extending/toolchains#toolchain-resolution) used
 to find an execution platform which supports both toolchain types. The selected
 execution platform was used for each registered action inside the rule, unless
 specified differently with [exec_groups][exec_groups].
diff --git a/versions/8.4.2/extending/concepts.mdx b/versions/8.4.2/extending/concepts.mdx
index ae668507..4e8ea4a2 100644
--- a/versions/8.4.2/extending/concepts.mdx
+++ b/versions/8.4.2/extending/concepts.mdx
@@ -20,16 +20,14 @@ Before learning the more advanced concepts, first:
 ## Macros and rules {#macros-and-rules}
 
 A macro is a function that instantiates rules. Macros come in two flavors:
-[symbolic macros](/versions/8.4.2/extending/macros) (new in Bazel 8) and [legacy
-macros](/versions/8.4.2/extending/legacy-macros). The two flavors of macros are defined
+[symbolic macros](/versions/8.4.2/extending/macros) (new in Bazel 8) and [legacy macros](/versions/8.4.2/extending/legacy-macros). The two flavors of macros are defined
 differently, but behave almost the same from the point of view of a user. A
 macro is useful when a `BUILD` file is getting too repetitive or too complex, as
 it lets you reuse some code. The function is evaluated as soon as the `BUILD`
 file is read. After the evaluation of the `BUILD` file, Bazel has little
 information about macros. If your macro generates a `genrule`, Bazel will
 behave *almost* as if you declared that `genrule` in the `BUILD` file. (The one
-exception is that targets declared in a symbolic macro have [special visibility
-semantics](/versions/8.4.2/extending/macros#visibility): a symbolic macro can hide its internal
+exception is that targets declared in a symbolic macro have [special visibility semantics](/versions/8.4.2/extending/macros#visibility): a symbolic macro can hide its internal
 targets from the rest of the package.)
 
 A [rule](/versions/8.4.2/extending/rules) is more powerful than a macro. It can access Bazel
@@ -76,8 +74,7 @@ they will not be executed.
 ## Creating extensions
 
 * [Create your first macro](/versions/8.4.2/rules/macro-tutorial) in order to reuse some code.
-  Then [learn more about macros](/versions/8.4.2/extending/macros) and [using them to create
-  "custom verbs"](/versions/8.4.2/rules/verbs-tutorial).
+  Then [learn more about macros](/versions/8.4.2/extending/macros) and [using them to create "custom verbs"](/versions/8.4.2/rules/verbs-tutorial).
 
 * [Follow the rules tutorial](/versions/8.4.2/rules/rules-tutorial) to get started with rules.
   Next, you can read more about the [rules concepts](/versions/8.4.2/extending/rules).
@@ -92,8 +89,7 @@ them within reach:
 ## Going further
 
 In addition to [macros](/versions/8.4.2/extending/macros) and [rules](/versions/8.4.2/extending/rules), you
-may want to write [aspects](/versions/8.4.2/extending/aspects) and [repository
-rules](/versions/8.4.2/extending/repo).
+may want to write [aspects](/versions/8.4.2/extending/aspects) and [repository rules](/versions/8.4.2/extending/repo).
 
 * Use [Buildifier](https://github.com/bazelbuild/buildtools)
   consistently to format and lint your code.
diff --git a/versions/8.4.2/extending/depsets.mdx b/versions/8.4.2/extending/depsets.mdx
index bbb975a7..762d6c63 100644
--- a/versions/8.4.2/extending/depsets.mdx
+++ b/versions/8.4.2/extending/depsets.mdx
@@ -111,8 +111,7 @@ need to ensure that if `B` depends on `A`, then `A.o` comes before `B.o` on the
 linker’s command line. Other tools might have the opposite requirement.
 
 Three traversal orders are supported: `postorder`, `preorder`, and
-`topological`. The first two work exactly like [tree
-traversals](https://en.wikipedia.org/wiki/Tree_traversal#Depth-first_search)
+`topological`. The first two work exactly like [tree traversals](https://en.wikipedia.org/wiki/Tree_traversal#Depth-first_search)
 except that they operate on DAGs and skip already visited nodes. The third order
 works as a topological sort from root to leaves, essentially the same as
 preorder except that shared children are listed only after all of their parents.
diff --git a/versions/8.4.2/extending/exec-groups.mdx b/versions/8.4.2/extending/exec-groups.mdx
index ab85c99c..a99af3c2 100644
--- a/versions/8.4.2/extending/exec-groups.mdx
+++ b/versions/8.4.2/extending/exec-groups.mdx
@@ -63,8 +63,7 @@ test rules.
 
 In the rule implementation, you can declare that actions should be run on the
 execution platform of an execution group. You can do this by using the `exec_group`
-param of action generating methods, specifically [`ctx.actions.run`]
-(/rules/lib/builtins/actions#run) and
+param of action generating methods, specifically [`ctx.actions.run`](/rules/lib/builtins/actions#run) and
 [`ctx.actions.run_shell`](/versions/8.4.2/rules/lib/builtins/actions#run_shell).
 
 ```python
diff --git a/versions/8.4.2/extending/macros.mdx b/versions/8.4.2/extending/macros.mdx
index 068d15fb..6779dfe0 100644
--- a/versions/8.4.2/extending/macros.mdx
+++ b/versions/8.4.2/extending/macros.mdx
@@ -31,8 +31,7 @@ two required parameters: `attrs` and `implementation`.
 
 ### Attributes {#attributes}
 
-`attrs` accepts a dictionary of attribute name to [attribute
-types](https://bazel.build/rules/lib/toplevel/attr#members), which represents
+`attrs` accepts a dictionary of attribute name to [attribute types](https://bazel.build/rules/lib/toplevel/attr#members), which represents
 the arguments to the macro. Two common attributes – `name` and `visibility` –
 are implicitly added to all macros and are not included in the dictionary passed
 to `attrs`.
@@ -66,9 +65,7 @@ To support this pattern, a macro can *inherit attributes* from a rule or another
 macro by passing the [rule](https://bazel.build/versions/8.4.2/rules/lib/builtins/rule) or
 [macro symbol](https://bazel.build/versions/8.4.2/rules/lib/builtins/macro) to `macro()`'s
 `inherit_attrs` argument. (You can also use the special string `"common"`
-instead of a rule or macro symbol to inherit the [common attributes defined for
-all Starlark build
-rules](https://bazel.build/reference/be/common-definitions#common-attributes).)
+instead of a rule or macro symbol to inherit the [common attributes defined for all Starlark build rules](https://bazel.build/reference/be/common-definitions#common-attributes).)
 Only public attributes get inherited, and the attributes in the macro's own
 `attrs` dictionary override inherited attributes with the same name. You can
 also *remove* inherited attributes by using `None` as a value in the `attrs`
diff --git a/versions/8.4.2/extending/platforms.mdx b/versions/8.4.2/extending/platforms.mdx
index 8d9bd1c1..31ef5469 100644
--- a/versions/8.4.2/extending/platforms.mdx
+++ b/versions/8.4.2/extending/platforms.mdx
@@ -245,8 +245,7 @@ cc_library(
 
 You can use the
 [`IncompatiblePlatformProvider`](/versions/8.4.2/rules/lib/providers/IncompatiblePlatformProvider)
-in `bazel cquery`'s [Starlark output
-format](/versions/8.4.2/query/cquery#output-format-definition) to distinguish
+in `bazel cquery`'s [Starlark output format](/versions/8.4.2/query/cquery#output-format-definition) to distinguish
 incompatible targets from compatible ones.
 
 This can be used to filter out incompatible targets. The example below will
@@ -266,5 +265,4 @@ $ bazel cquery //... --output=starlark --starlark:file=example.cquery
 
 ### Known Issues
 
-Incompatible targets [ignore visibility
-restrictions](https://github.com/bazelbuild/bazel/issues/16044).
+Incompatible targets [ignore visibility restrictions](https://github.com/bazelbuild/bazel/issues/16044).
diff --git a/versions/8.4.2/extending/repo.mdx b/versions/8.4.2/extending/repo.mdx
index 0744dc40..9dbc0c92 100644
--- a/versions/8.4.2/extending/repo.mdx
+++ b/versions/8.4.2/extending/repo.mdx
@@ -74,8 +74,7 @@ specified.
 
 The input parameter `repository_ctx` can be used to access attribute values, and
 non-hermetic functions (finding a binary, executing a binary, creating a file in
-the repository or downloading a file from the Internet). See [the API
-docs](/versions/8.4.2/rules/lib/builtins/repository_ctx) for more context. Example:
+the repository or downloading a file from the Internet). See [the API docs](/versions/8.4.2/rules/lib/builtins/repository_ctx) for more context. Example:
 
 ```python
 def _impl(repository_ctx):
@@ -144,8 +143,7 @@ definition has the `configure` attribute set, use `bazel fetch --force
 
 ## Examples
 
--   [C++ auto-configured
-    toolchain](https://cs.opensource.google/bazel/bazel/+/master:tools/cpp/cc_configure.bzl;drc=644b7d41748e09eff9e47cbab2be2263bb71f29a;l=176):
+-   [C++ auto-configured toolchain](https://cs.opensource.google/bazel/bazel/+/master:tools/cpp/cc_configure.bzl;drc=644b7d41748e09eff9e47cbab2be2263bb71f29a;l=176):
     it uses a repo rule to automatically create the C++ configuration files for
     Bazel by looking for the local C++ compiler, the environment and the flags
     the C++ compiler supports.
diff --git a/versions/8.4.2/extending/rules.mdx b/versions/8.4.2/extending/rules.mdx
index 4bc21657..37ca68fe 100644
--- a/versions/8.4.2/extending/rules.mdx
+++ b/versions/8.4.2/extending/rules.mdx
@@ -449,8 +449,7 @@ def _example_library_impl(ctx):
 
 If `DefaultInfo` is not returned by a rule implementation or the `files`
 parameter is not specified, `DefaultInfo.files` defaults to all
-*predeclared outputs* (generally, those created by [output
-attributes](#output_attributes)).
+*predeclared outputs* (generally, those created by [output attributes](#output_attributes)).
 
 Rules that perform actions should provide default outputs, even if those outputs
 are not expected to be directly used. Actions that are not in the graph of the
@@ -995,8 +994,7 @@ By using `configuration_field`, the dependency on the Java LCOV merger tool can
 be avoided as long as coverage is not requested.
 
 When the test is run, it should emit coverage information in the form of one or
-more [LCOV files]
-(https://manpages.debian.org/unstable/lcov/geninfo.1.en.html#TRACEFILE_FORMAT)
+more [LCOV files](https://manpages.debian.org/unstable/lcov/geninfo.1.en.html#TRACEFILE_FORMAT)
 with unique names into the directory specified by the `COVERAGE_DIR` environment
 variable. Bazel will then merge these files into a single LCOV file using the
 `_lcov_merger` tool. If present, it will also collect C/C++ coverage using the
diff --git a/versions/8.4.2/extending/toolchains.mdx b/versions/8.4.2/extending/toolchains.mdx
index 810e6469..0bc673c9 100644
--- a/versions/8.4.2/extending/toolchains.mdx
+++ b/versions/8.4.2/extending/toolchains.mdx
@@ -523,8 +523,7 @@ The set of available toolchains, in priority order, is created from
   4. Toolchains registered in the "WORKSPACE suffix"; this is only used by
      certain native rules bundled with the Bazel installation.
 
-**NOTE:** [Pseudo-targets like `:all`, `:*`, and
-`/...`](/versions/8.4.2/run/build#specifying-build-targets) are ordered by Bazel's package
+**NOTE:** [Pseudo-targets like `:all`, `:*`, and `/...`](/versions/8.4.2/run/build#specifying-build-targets) are ordered by Bazel's package
 loading mechanism, which uses a lexicographic ordering.
 
 The resolution steps are as follows.
diff --git a/versions/8.4.2/external/advanced.mdx b/versions/8.4.2/external/advanced.mdx
index 63520d82..98dd9ab8 100644
--- a/versions/8.4.2/external/advanced.mdx
+++ b/versions/8.4.2/external/advanced.mdx
@@ -4,10 +4,8 @@ title: 'Advanced topics on external dependencies'
 
 ## Shadowing dependencies in WORKSPACE
 
-Note: This section applies to the [WORKSPACE
-system](/versions/8.4.2/external/overview#workspace-system) only. For
-[Bzlmod](/versions/8.4.2/external/overview#bzlmod), use a [multiple-version
-override](/versions/8.4.2/external/module#multiple-version_override).
+Note: This section applies to the [WORKSPACE system](/versions/8.4.2/external/overview#workspace-system) only. For
+[Bzlmod](/versions/8.4.2/external/overview#bzlmod), use a [multiple-version override](/versions/8.4.2/external/module#multiple-version_override).
 
 Whenever possible, have a single version policy in your project, which is
 required for dependencies that you compile against and end up in your final
@@ -128,29 +126,24 @@ preferring IPv4 if enabled. In some situations, for example when the IPv4
 network cannot resolve/reach external addresses, this can cause `Network
 unreachable` exceptions and build failures. In these cases, you can override
 Bazel's behavior to prefer IPv6 by using the
-[`java.net.preferIPv6Addresses=true` system
-property](https://docs.oracle.com/javase/8/docs/api/java/net/doc-files/net-properties.html).
+[`java.net.preferIPv6Addresses=true` system property](https://docs.oracle.com/javase/8/docs/api/java/net/doc-files/net-properties.html).
 Specifically:
 
-*   Use `--host_jvm_args=-Djava.net.preferIPv6Addresses=true` [startup
-    option](/versions/8.4.2/docs/user-manual#startup-options), for example by adding the
+*   Use `--host_jvm_args=-Djava.net.preferIPv6Addresses=true` [startup option](/versions/8.4.2/docs/user-manual#startup-options), for example by adding the
     following line in your [`.bazelrc` file](/versions/8.4.2/run/bazelrc):
 
     `startup --host_jvm_args=-Djava.net.preferIPv6Addresses=true`
 
 *   When running Java build targets that need to connect to the internet (such
     as for integration tests), use the
-    `--jvmopt=-Djava.net.preferIPv6Addresses=true` [tool
-    flag](/versions/8.4.2/docs/user-manual#jvmopt). For example, include in your [`.bazelrc`
-    file](/versions/8.4.2/run/bazelrc):
+    `--jvmopt=-Djava.net.preferIPv6Addresses=true` [tool flag](/versions/8.4.2/docs/user-manual#jvmopt). For example, include in your [`.bazelrc` file](/versions/8.4.2/run/bazelrc):
 
     `build --jvmopt=-Djava.net.preferIPv6Addresses`
 
 *   If you are using [`rules_jvm_external`](https://github.com/bazelbuild/rules_jvm_external)
     for dependency version resolution, also add
     `-Djava.net.preferIPv6Addresses=true` to the `COURSIER_OPTS` environment
-    variable to [provide JVM options for
-    Coursier](https://github.com/bazelbuild/rules_jvm_external#provide-jvm-options-for-coursier-with-coursier_opts).
+    variable to [provide JVM options for Coursier](https://github.com/bazelbuild/rules_jvm_external#provide-jvm-options-for-coursier-with-coursier_opts).
 
 ## Offline builds
 
@@ -167,15 +160,12 @@ fetch a file with [`ctx.download`](/versions/8.4.2/rules/lib/builtins/repository
 providing a hash sum of the file needed, Bazel looks for a file matching the
 basename of the first URL, and uses the local copy if the hash matches.
 
-Bazel itself uses this technique to bootstrap offline from the [distribution
-artifact](https://github.com/bazelbuild/bazel-website/blob/master/designs/_posts/2016-10-11-distribution-artifact.md).
-It does so by [collecting all the needed external
-dependencies](https://github.com/bazelbuild/bazel/blob/5cfa0303d6ac3b5bd031ff60272ce80a704af8c2/WORKSPACE#L116)
+Bazel itself uses this technique to bootstrap offline from the [distribution artifact](https://github.com/bazelbuild/bazel-website/blob/master/designs/_posts/2016-10-11-distribution-artifact.md).
+It does so by [collecting all the needed external dependencies](https://github.com/bazelbuild/bazel/blob/5cfa0303d6ac3b5bd031ff60272ce80a704af8c2/WORKSPACE#L116)
 in an internal
 [`distdir_tar`](https://github.com/bazelbuild/bazel/blob/5cfa0303d6ac3b5bd031ff60272ce80a704af8c2/distdir.bzl#L44).
 
 Bazel allows execution of arbitrary commands in repository rules without knowing
 if they call out to the network, and so cannot enforce fully offline builds. To
 test if a build works correctly offline, manually block off the network (as
-Bazel does in its [bootstrap
-test](https://cs.opensource.google/bazel/bazel/+/master:src/test/shell/bazel/BUILD;l=1073;drc=88c426e73cc0eb0a41c0d7995e36acd94e7c9a48)).
\ No newline at end of file
+Bazel does in its [bootstrap test](https://cs.opensource.google/bazel/bazel/+/master:src/test/shell/bazel/BUILD;l=1073;drc=88c426e73cc0eb0a41c0d7995e36acd94e7c9a48)).
\ No newline at end of file
diff --git a/versions/8.4.2/external/migration.mdx b/versions/8.4.2/external/migration.mdx
index e3d79ab4..bfdc6ad5 100644
--- a/versions/8.4.2/external/migration.mdx
+++ b/versions/8.4.2/external/migration.mdx
@@ -2,8 +2,7 @@
 title: 'Bzlmod Migration Guide'
 ---
 
-Due to the [shortcomings of
-WORKSPACE](/versions/8.4.2/external/overview#workspace-shortcomings), Bzlmod is going to
+Due to the [shortcomings of WORKSPACE](/versions/8.4.2/external/overview#workspace-shortcomings), Bzlmod is going to
 replace the legacy WORKSPACE system. The WORKSPACE file will be disabled by
 default in Bazel 8 (late 2024) and will be removed in Bazel 9 (late 2025).
 This guide helps you migrate your project to Bzlmod and drop WORKSPACE for
@@ -117,9 +116,7 @@ Bazel module when it also adopts Bzlmod.
 
 *   **Bzlmod**
 
-    With Bzlmod, as long as the your dependency is available in [Bazel Central
-    Registry](https://registry.bazel.build) or your custom [Bazel
-    registry](/versions/8.4.2/external/registry), you can simply depend on it with a
+    With Bzlmod, as long as the your dependency is available in [Bazel Central Registry](https://registry.bazel.build) or your custom [Bazel registry](/versions/8.4.2/external/registry), you can simply depend on it with a
     [`bazel_dep`](/versions/8.4.2/rules/lib/globals/module#bazel_dep) directive.
 
     ```python
@@ -150,8 +147,7 @@ repository.
 
 If your dependency is not a Bazel project or not yet available in any Bazel
 registry, you can introduce it using
-[`use_repo_rule`](/versions/8.4.2/external/module#use_repo_rule) or [module
-extensions](/versions/8.4.2/external/extension).
+[`use_repo_rule`](/versions/8.4.2/external/module#use_repo_rule) or [module extensions](/versions/8.4.2/external/extension).
 
 *   **WORKSPACE**
 
@@ -604,8 +600,7 @@ macros.
 Fortunately, the flag
 [`--experimental_repository_resolved_file`][resolved_file_flag]
 can help. This flag essentially generates a "lock file" of all fetched external
-dependencies in your last Bazel command. You can find more details in this [blog
-post](https://blog.bazel.build/2018/07/09/bazel-sync-and-resolved-file.html).
+dependencies in your last Bazel command. You can find more details in this [blog post](https://blog.bazel.build/2018/07/09/bazel-sync-and-resolved-file.html).
 
 [resolved_file_flag]: /reference/command-line-reference#flag--experimental_repository_resolved_file
 
@@ -646,11 +641,9 @@ You may also know `bazel query` can be used for inspecting repository rules with
 bazel query --output=build //external:
 ```
 
-While it is more convenient and much faster, [bazel query can lie about
-external dependency version](https://github.com/bazelbuild/bazel/issues/12947),
+While it is more convenient and much faster, [bazel query can lie about external dependency version](https://github.com/bazelbuild/bazel/issues/12947),
 so be careful using it! Querying and inspecting external
-dependencies with Bzlmod is going to achieved by a [new
-subcommand](https://github.com/bazelbuild/bazel/issues/15365).
+dependencies with Bzlmod is going to achieved by a [new subcommand](https://github.com/bazelbuild/bazel/issues/15365).
 
 #### Built-in default dependencies {#builtin-default-deps}
 
@@ -697,8 +690,7 @@ Using the WORKSPACE.bzlmod file can make the migration easier because:
 #### Repository visibility {#repository-visibility}
 
 Bzlmod is able to control which other repositories are visible from a given
-repository, check [repository names and strict
-deps](/versions/8.4.2/external/module#repository_names_and_strict_deps) for more details.
+repository, check [repository names and strict deps](/versions/8.4.2/external/module#repository_names_and_strict_deps) for more details.
 
 Here is a summary of repository visibilities from different types of
 repositories when also taking WORKSPACE into consideration.
@@ -711,8 +703,7 @@ repositories when also taking WORKSPACE into consideration.
 | WORKSPACE Repos | All visible | Not visible | Not visible | All visible |
 
 Note: For the root module, if a repository `@foo` is defined in WORKSPACE and
-`@foo` is also used as an [apparent repository
-name](/versions/8.4.2/external/overview#apparent-repo-name) in MODULE.bazel, then `@foo`
+`@foo` is also used as an [apparent repository name](/versions/8.4.2/external/overview#apparent-repo-name) in MODULE.bazel, then `@foo`
 refers to the one introduced in MODULE.bazel.
 
 Note: For a module extension generated repository `@bar`, if `@foo` is used as
@@ -787,9 +778,7 @@ the project. Take note of a few things when creating the source archive:
     GitHub isn't going to guarantee the checksum of source archives generated on
     demand. In short, URLs in the form of
     `https://github.com///releases/download/...` is considered stable
-    while `https://github.com///archive/...` is not. Check [GitHub
-    Archive Checksum
-    Outage](https://blog.bazel.build/2023/02/15/github-archive-checksum.html)
+    while `https://github.com///archive/...` is not. Check [GitHub Archive Checksum Outage](https://blog.bazel.build/2023/02/15/github-archive-checksum.html)
     for more context.
 
 *   **Make sure the source tree follows the layout of the original repository.**
@@ -818,8 +807,7 @@ Pull Request.
 
 [bcr_contrib_guide]: https://github.com/bazelbuild/bazel-central-registry/tree/main/docs#contribute-a-bazel-module
 
-It is **highly recommended** to set up the [Publish to
-BCR](https://github.com/bazel-contrib/publish-to-bcr) GitHub App for your
+It is **highly recommended** to set up the [Publish to BCR](https://github.com/bazel-contrib/publish-to-bcr) GitHub App for your
 repository to automate the process of submitting your module to the BCR.
 
 ## Best practices {#best-practices}
diff --git a/versions/8.4.2/external/mod-command.mdx b/versions/8.4.2/external/mod-command.mdx
index e49acc52..f5ebb078 100644
--- a/versions/8.4.2/external/mod-command.mdx
+++ b/versions/8.4.2/external/mod-command.mdx
@@ -61,11 +61,9 @@ The available subcommands and their respective required arguments are:
 
 *   ``: All present versions of the module ``.
 
-*   `@`: The repo with the given [apparent
-    name](overview#apparent-repo-name) in the context of the `--base_module`.
+*   `@`: The repo with the given [apparent name](overview#apparent-repo-name) in the context of the `--base_module`.
 
-*   `@@`: The repo with the given [canonical
-    name](overview#canonical-repo-name).
+*   `@@`: The repo with the given [canonical name](overview#canonical-repo-name).
 
 In a context requiring specifying modules, ``s referring to repos that
 correspond to modules (as opposed to extension-generated repos) can also be
@@ -87,8 +85,7 @@ The following options only affect the subcommands that print graphs (`graph`,
     information about the version resolution of each module. If the module
     version changed during resolution, show either which version replaced it or
     what was the original version, the reason it was replaced, and which modules
-    requested the new version if the reason was [Minimal Version
-    Selection](module#version-selection).
+    requested the new version if the reason was [Minimal Version Selection](module#version-selection).
 
 *   `--include_unused` *default: "false"*: Include in the output graph the
     modules which were originally present in the dependency graph, but became
diff --git a/versions/8.4.2/external/module.mdx b/versions/8.4.2/external/module.mdx
index f99f6cfa..211773e9 100644
--- a/versions/8.4.2/external/module.mdx
+++ b/versions/8.4.2/external/module.mdx
@@ -122,8 +122,7 @@ serves multiple purposes:
     version, regardless of which versions of the dependency are requested in the
     dependency graph.
 *   With the `registry` attribute, you can force this dependency to come from a
-    specific registry, instead of following the normal [registry
-    selection](/versions/8.4.2/external/registry#selecting_registries) process.
+    specific registry, instead of following the normal [registry selection](/versions/8.4.2/external/registry#selecting_registries) process.
 *   With the `patch*` attributes, you can specify a set of patches to apply to
     the downloaded module.
 
@@ -176,13 +175,11 @@ With `bazel_dep`, you can define repos that represent other Bazel modules.
 Sometimes there is a need to define a repo that does _not_ represent a Bazel
 module; for example, one that contains a plain JSON file to be read as data.
 
-In this case, you could use the [`use_repo_rule`
-directive](/versions/8.4.2/rules/lib/globals/module#use_repo_rule) to directly define a repo
+In this case, you could use the [`use_repo_rule` directive](/versions/8.4.2/rules/lib/globals/module#use_repo_rule) to directly define a repo
 by invoking a repo rule. This repo will only be visible to the module it's
 defined in.
 
-Under the hood, this is implemented using the same mechanism as [module
-extensions](/versions/8.4.2/external/extension), which lets you define repos with more
+Under the hood, this is implemented using the same mechanism as [module extensions](/versions/8.4.2/external/extension), which lets you define repos with more
 flexibility.
 
 ## Repository names and strict deps
diff --git a/versions/8.4.2/external/overview.mdx b/versions/8.4.2/external/overview.mdx
index f478bfc8..1bd53ef6 100644
--- a/versions/8.4.2/external/overview.mdx
+++ b/versions/8.4.2/external/overview.mdx
@@ -128,8 +128,7 @@ for all build targets inside the repo.
 
 The syntax of a `REPO.bazel` file is similar to `BUILD` files, except that no
 `load` statements are supported, and only a single function, `repo()`, is
-available. `repo()` takes the same arguments as the [`package()`
-function](/versions/8.4.2/reference/be/functions#package) in `BUILD` files; whereas `package()`
+available. `repo()` takes the same arguments as the [`package()` function](/versions/8.4.2/reference/be/functions#package) in `BUILD` files; whereas `package()`
 specifies common attributes for all build targets inside the package, `repo()`
 analogously does so for all build targets inside the repo.
 
@@ -163,8 +162,7 @@ bazel_dep(name = "protobuf", version = "3.19.0")
 ```
 
 A module must only list its direct dependencies, which Bzlmod looks up in a
-[Bazel registry](/versions/8.4.2/external/registry) — by default, the [Bazel Central
-Registry](https://bcr.bazel.build/). The registry provides the
+[Bazel registry](/versions/8.4.2/external/registry) — by default, the [Bazel Central Registry](https://bcr.bazel.build/). The registry provides the
 dependencies' `MODULE.bazel` files, which allows Bazel to discover the entire
 transitive dependency graph before performing version resolution.
 
@@ -235,5 +233,4 @@ many pain points, including:
         `B` and `C`; `B` and `C` both depend on different versions of `D`).
 
 Due to the shortcomings of WORKSPACE, Bzlmod is going to replace the legacy
-WORKSPACE system in future Bazel releases. Please read the [Bzlmod migration
-guide](/versions/8.4.2/external/migration) on how to migrate to Bzlmod.
+WORKSPACE system in future Bazel releases. Please read the [Bzlmod migration guide](/versions/8.4.2/external/migration) on how to migrate to Bzlmod.
diff --git a/versions/8.4.2/external/registry.mdx b/versions/8.4.2/external/registry.mdx
index fe14da63..616bef30 100644
--- a/versions/8.4.2/external/registry.mdx
+++ b/versions/8.4.2/external/registry.mdx
@@ -42,8 +42,7 @@ An index registry must follow the format below:
             project
         *   `versions`: A list of all the versions of this module to be found in
             this registry
-        *   `yanked_versions`: A map of [*yanked*
-            versions](/versions/8.4.2/external/module#yanked_versions) of this module. The keys
+        *   `yanked_versions`: A map of [*yanked* versions](/versions/8.4.2/external/module#yanked_versions) of this module. The keys
             should be versions to yank and the values should be descriptions of
             why the version is yanked, ideally containing a link to more
             information
@@ -56,8 +55,7 @@ An index registry must follow the format below:
             *   `url`: The URL of the source archive
             *   `mirror_urls`: A list of string, the mirror URLs of the source archive.
                 The URLs are tried in order after `url` as backups.
-            *   `integrity`: The [Subresource
-                Integrity](https://w3c.github.io/webappsec-subresource-integrity/#integrity-metadata-description)
+            *   `integrity`: The [Subresource Integrity](https://w3c.github.io/webappsec-subresource-integrity/#integrity-metadata-description)
                 checksum of the archive
             *   `strip_prefix`: A directory prefix to strip when extracting the
                 source archive
@@ -105,8 +103,7 @@ You can browse its contents using the web frontend at
 https://registry.bazel.build/.
 
 The Bazel community maintains the BCR, and contributors are welcome to submit
-pull requests. See the [BCR contribution
-guidelines](https://github.com/bazelbuild/bazel-central-registry/blob/main/docs/README.md).
+pull requests. See the [BCR contribution guidelines](https://github.com/bazelbuild/bazel-central-registry/blob/main/docs/README.md).
 
 In addition to following the format of a normal index registry, the BCR requires
 a `presubmit.yml` file for each module version
diff --git a/versions/8.4.2/external/vendor.mdx b/versions/8.4.2/external/vendor.mdx
index 22d6c65a..fa441fd5 100644
--- a/versions/8.4.2/external/vendor.mdx
+++ b/versions/8.4.2/external/vendor.mdx
@@ -23,9 +23,7 @@ absolute path.
 ## Vendor a specific external repository {#vendor-specific-repository}
 
 You can use the `vendor` command with the `--repo` flag to specify which repo
-to vendor, it accepts both [canonical repo
-name](/versions/8.4.2/external/overview#canonical-repo-name) and [apparent repo
-name](/versions/8.4.2/external/overview#apparent-repo-name).
+to vendor, it accepts both [canonical repo name](/versions/8.4.2/external/overview#canonical-repo-name) and [apparent repo name](/versions/8.4.2/external/overview#apparent-repo-name).
 
 For example, running:
 
diff --git a/versions/8.4.2/help.mdx b/versions/8.4.2/help.mdx
index 3c5ebd27..1aef1e7c 100644
--- a/versions/8.4.2/help.mdx
+++ b/versions/8.4.2/help.mdx
@@ -46,5 +46,4 @@ what level of support Bazel provides.
 
 ## File a bug {#file-bug}
 
-If you encounter a bug or want to request a feature, file a [GitHub
-Issue](https://github.com/bazelbuild/bazel/issues).
+If you encounter a bug or want to request a feature, file a [GitHub Issue](https://github.com/bazelbuild/bazel/issues).
diff --git a/versions/8.4.2/install/bazelisk.mdx b/versions/8.4.2/install/bazelisk.mdx
index 89fb2cb9..79e33cab 100644
--- a/versions/8.4.2/install/bazelisk.mdx
+++ b/versions/8.4.2/install/bazelisk.mdx
@@ -16,8 +16,7 @@ For more details, see
 ## Updating Bazel
 
 Bazel has a [backward compatibility policy](/versions/8.4.2/release/backward-compatibility)
-(see [guidance for rolling out incompatible
-changes](/versions/8.4.2/contribute/breaking-changes) if you
+(see [guidance for rolling out incompatible changes](/versions/8.4.2/contribute/breaking-changes) if you
 are the author of one). That page summarizes best practices on how to test and
 migrate your project with upcoming incompatible changes and how to provide
 feedback to the incompatible change authors.
diff --git a/versions/8.4.2/install/compile-source.mdx b/versions/8.4.2/install/compile-source.mdx
index 5f6f2f57..245fa27e 100644
--- a/versions/8.4.2/install/compile-source.mdx
+++ b/versions/8.4.2/install/compile-source.mdx
@@ -45,8 +45,7 @@ it by typing `bazel` in a terminal.
 
 **Reason**: To build Bazel from a GitHub source tree, you need a pre-existing
 Bazel binary. You can install one from a package manager or download one from
-GitHub. See [Installing Bazel](/versions/8.4.2/install). (Or you can [build from
-scratch (bootstrap)](#bootstrap-bazel).)
+GitHub. See [Installing Bazel](/versions/8.4.2/install). (Or you can [build from scratch (bootstrap)](#bootstrap-bazel).)
 
 **Troubleshooting**:
 
@@ -239,8 +238,7 @@ For instructions for Unix-like systems, see
     ```
 
 *   **The Visual C++ compiler.** Install the Visual C++ compiler either as part
-    of Visual Studio 2015 or newer, or by installing the latest [Build Tools
-    for Visual Studio 2017](https://aka.ms/BuildTools).
+    of Visual Studio 2015 or newer, or by installing the latest [Build Tools for Visual Studio 2017](https://aka.ms/BuildTools).
 
 *   **JDK.** Version 21 is required.
 
diff --git a/versions/8.4.2/install/ide.mdx b/versions/8.4.2/install/ide.mdx
index 561d0e02..c42d95e9 100644
--- a/versions/8.4.2/install/ide.mdx
+++ b/versions/8.4.2/install/ide.mdx
@@ -38,10 +38,8 @@ To install, go to the IDE's plugin browser and search for `Bazel`.
 To manually install older versions, download the zip files from JetBrains'
 Plugin Repository and install the zip file from the IDE's plugin browser:
 
-*  [Android Studio
-   plugin](https://plugins.jetbrains.com/plugin/9185-android-studio-with-bazel)
-*  [IntelliJ
-   plugin](https://plugins.jetbrains.com/plugin/8609-intellij-with-bazel)
+*  [Android Studio plugin](https://plugins.jetbrains.com/plugin/9185-android-studio-with-bazel)
+*  [IntelliJ plugin](https://plugins.jetbrains.com/plugin/8609-intellij-with-bazel)
 *  [CLion plugin](https://plugins.jetbrains.com/plugin/9554-clion-with-bazel)
 
 ### Xcode {#xcode}
@@ -61,8 +59,7 @@ Features:
 * Starlark debugger for `.bzl` files during a build (set breakpoints, step
   through code, inspect variables, and so on)
 
-Find [the plugin on the Visual Studio
-marketplace](https://marketplace.visualstudio.com/items?itemName=BazelBuild.vscode-bazel).
+Find [the plugin on the Visual Studio marketplace](https://marketplace.visualstudio.com/items?itemName=BazelBuild.vscode-bazel).
 The plugin is [open source](https://github.com/bazelbuild/vscode-bazel).
 
 See also: [Autocomplete for Source Code](#autocomplete-for-source-code)
@@ -82,8 +79,7 @@ See also: [Autocomplete for Source Code](#autocomplete-for-source-code)
 
 ### Emacs {#emacs}
 
-See [`bazelbuild/bazel-emacs-mode` on
-GitHub](https://github.com/bazelbuild/emacs-bazel-mode)
+See [`bazelbuild/bazel-emacs-mode` on GitHub](https://github.com/bazelbuild/emacs-bazel-mode)
 
 See also: [Autocomplete for Source Code](#autocomplete-for-source-code)
 
@@ -115,6 +111,5 @@ tool for building Bazel targets when source files change.
 
 ## Building your own IDE plugin {#build-own-plugin}
 
-Read the [**IDE support** blog
-post](https://blog.bazel.build/2016/06/10/ide-support.html) to learn more about
+Read the [**IDE support** blog post](https://blog.bazel.build/2016/06/10/ide-support.html) to learn more about
 the Bazel APIs to use when building an IDE plugin.
diff --git a/versions/8.4.2/install/windows.mdx b/versions/8.4.2/install/windows.mdx
index 8db7ad81..3cd4173e 100644
--- a/versions/8.4.2/install/windows.mdx
+++ b/versions/8.4.2/install/windows.mdx
@@ -31,8 +31,7 @@ To check your Windows version:
 
 Alternatively you can:
 
-*   [Download the Bazel binary (`bazel-version-windows-x86_64.exe`) from
- GitHub](https://github.com/bazelbuild/bazel/releases).
+*   [Download the Bazel binary (`bazel-version-windows-x86_64.exe`) from GitHub](https://github.com/bazelbuild/bazel/releases).
 *   [Install Bazel from Chocolatey](#chocolately)
 *   [Install Bazel from Scoop](#scoop)
 *   [Build Bazel from source](/versions/8.4.2/install/compile-source)
@@ -208,8 +207,7 @@ If that doesn't help:
     its dependencies, such as the MSYS2 shell. This will not install Visual C++
     though.
 
-See [Chocolatey installation and package maintenance
-guide](/versions/8.4.2/contribute/windows-chocolatey-maintenance) for more
+See [Chocolatey installation and package maintenance guide](/versions/8.4.2/contribute/windows-chocolatey-maintenance) for more
 information about the Chocolatey package.
 
 ### Using Scoop {#scoop}
@@ -226,8 +224,7 @@ information about the Chocolatey package.
     scoop install bazel
     ```
 
-See [Scoop installation and package maintenance
-guide](/versions/8.4.2/contribute/windows-scoop-maintenance) for more
+See [Scoop installation and package maintenance guide](/versions/8.4.2/contribute/windows-scoop-maintenance) for more
 information about the Scoop package.
 
 ### Build from source {#build-from-source}
diff --git a/versions/8.4.2/migrate/maven.mdx b/versions/8.4.2/migrate/maven.mdx
index 159ca3f5..60348d55 100644
--- a/versions/8.4.2/migrate/maven.mdx
+++ b/versions/8.4.2/migrate/maven.mdx
@@ -19,8 +19,7 @@ directly run by Bazel since there's no Maven compatibility layer.
 ## Before you begin {#before-you-begin}
 
 *   [Install Bazel](/versions/8.4.2/install) if it's not yet installed.
-*   If you're new to Bazel, go through the tutorial [Introduction to Bazel:
-    Build Java](/versions/8.4.2/start/java) before you start migrating. The tutorial explains
+*   If you're new to Bazel, go through the tutorial [Introduction to Bazel: Build Java](/versions/8.4.2/start/java) before you start migrating. The tutorial explains
     Bazel's concepts, structure, and label syntax.
 
 ## Differences between Maven and Bazel {#dif-maven-bazel}
@@ -44,8 +43,7 @@ The steps below describe how to migrate your project to Bazel:
 3.  [Create more BUILD files](#3-build)
 4.  [Build using Bazel](#4-build)
 
-Examples below come from a migration of the [Guava
-project](https://github.com/google/guava) from Maven to Bazel. The
+Examples below come from a migration of the [Guava project](https://github.com/google/guava) from Maven to Bazel. The
 Guava project used is release `v31.1`. The examples using Guava do not walk
 through each step in the migration, but they do show the files and contents that
 are generated or added manually for the migration.
@@ -63,14 +61,12 @@ has no external dependencies, this file can be empty.
 If your project depends on files or packages that are not in one of the
 project's directories, specify these external dependencies in the MODULE.bazel
 file. You can use `rules_jvm_external` to manage dependencies from Maven. For
-instructions about using this ruleset, see [the
-README](https://github.com/bazelbuild/rules_jvm_external/#rules_jvm_external)
+instructions about using this ruleset, see [the README](https://github.com/bazelbuild/rules_jvm_external/#rules_jvm_external)
 .
 
 #### Guava project example: external dependencies {#guava-1}
 
-You can list the external dependencies of the [Guava
-project](https://github.com/google/guava) with the
+You can list the external dependencies of the [Guava project](https://github.com/google/guava) with the
 [`rules_jvm_external`](https://github.com/bazelbuild/rules_jvm_external)
 ruleset.
 
@@ -164,8 +160,7 @@ your build by adding more `BUILD` files with more granular targets.
             *   `resources`: Use globbing to list all resources in your project.
             *   `deps`: You need to determine which external dependencies your
                 project needs.
-        *   Take a look at the [example below of this top-level BUILD
-            file](#guava-2) from the migration of the Guava project.
+        *   Take a look at the [example below of this top-level BUILD file](#guava-2) from the migration of the Guava project.
 
 3.  Now that you have a `BUILD` file at the root of your project, build your
     project to ensure that it works. On the command line, from your workspace
diff --git a/versions/8.4.2/migrate/xcode.mdx b/versions/8.4.2/migrate/xcode.mdx
index 554706df..673593b7 100644
--- a/versions/8.4.2/migrate/xcode.mdx
+++ b/versions/8.4.2/migrate/xcode.mdx
@@ -32,8 +32,7 @@ Before you begin, do the following:
 
 1.  [Install Bazel](/versions/8.4.2/install) if you have not already done so.
 
-2.  If you're not familiar with Bazel and its concepts, complete the [iOS app
-    tutorial](/versions/8.4.2/start/ios-app)). You should understand the Bazel workspace,
+2.  If you're not familiar with Bazel and its concepts, complete the [iOS app tutorial](/versions/8.4.2/start/ios-app)). You should understand the Bazel workspace,
     including the `MODULE.bazel` and `BUILD` files, as well as the concepts of
     targets, build rules, and Bazel packages.
 
@@ -44,8 +43,7 @@ Before you begin, do the following:
 Unlike Xcode, Bazel requires you to explicitly declare all dependencies for
 every target in the `BUILD` file.
 
-For more information on external dependencies, see [Working with external
-dependencies](/versions/8.4.2/docs/external).
+For more information on external dependencies, see [Working with external dependencies](/versions/8.4.2/docs/external).
 
 ## Build or test an Xcode project with Bazel {#build-xcode-project}
 
@@ -84,8 +82,7 @@ Note: Place the project source code within the directory tree containing the
 
 To integrate SwiftPM dependencies into the Bazel workspace with
 [swift_bazel](https://github.com/cgrindel/swift_bazel), you must
-convert them into Bazel packages as described in the [following
-tutorial](https://chuckgrindel.com/swift-packages-in-bazel-using-swift_bazel/)
+convert them into Bazel packages as described in the [following tutorial](https://chuckgrindel.com/swift-packages-in-bazel-using-swift_bazel/)
 .
 
 Note: SwiftPM support is a manual process with many variables. SwiftPM
@@ -103,8 +100,7 @@ initial build of the project as follows:
 *   [Step 3b: (Optional) Add the test target(s)](#step-3b-optional-add-the-test-target-s)
 *   [Step 3c: Add the library target(s)](#step-3c-add-the-library-target-s)
 
-**Tip:** To learn more about packages and other Bazel concepts, see [Workspaces,
-packages, and targets](/versions/8.4.2/concepts/build-ref).
+**Tip:** To learn more about packages and other Bazel concepts, see [Workspaces, packages, and targets](/versions/8.4.2/concepts/build-ref).
 
 #### Step 3a: Add the application target {#add-app-target}
 
@@ -132,8 +128,7 @@ In the target, specify the following at the minimum:
 
 #### Step 3b: (Optional) Add the test target(s) {#add-test-target}
 
-Bazel's [Apple build
-rules](https://github.com/bazelbuild/rules_apple) support running
+Bazel's [Apple build rules](https://github.com/bazelbuild/rules_apple) support running
 unit and UI tests on all Apple platforms. Add test targets as follows:
 
 *   [`macos_unit_test`](https://github.com/bazelbuild/rules_apple/blob/master/doc/rules-macos.md#macos_unit_test)
@@ -181,8 +176,7 @@ all sources and/or headers of a certain type. Use it carefully as it might
 include files you do not want Bazel to build.
 
 You can browse existing examples for various types of applications directly in
-the [rules_apple examples
-directory](https://github.com/bazelbuild/rules_apple/tree/master/examples/). For
+the [rules_apple examples directory](https://github.com/bazelbuild/rules_apple/tree/master/examples/). For
 example:
 
 *   [macOS application targets](https://github.com/bazelbuild/rules_apple/tree/master/examples/macos)
@@ -191,8 +185,7 @@ example:
 
 *   [Multi platform applications (macOS, iOS, watchOS, tvOS)](https://github.com/bazelbuild/rules_apple/tree/master/examples/multi_platform)
 
-For more information on build rules, see [Apple Rules for
-Bazel](https://github.com/bazelbuild/rules_apple).
+For more information on build rules, see [Apple Rules for Bazel](https://github.com/bazelbuild/rules_apple).
 
 At this point, it is a good idea to test the build:
 
diff --git a/versions/8.4.2/query/cquery.mdx b/versions/8.4.2/query/cquery.mdx
index 8b469ece..3903397f 100644
--- a/versions/8.4.2/query/cquery.mdx
+++ b/versions/8.4.2/query/cquery.mdx
@@ -6,8 +6,7 @@ title: ' Configurable Query (cquery)'
 [`select()`](/versions/8.4.2/docs/configurable-attributes) and build options' effects on the build
 graph.
 
-It achieves this by running over the results of Bazel's [analysis
-phase](/versions/8.4.2/extending/concepts#evaluation-model),
+It achieves this by running over the results of Bazel's [analysis phase](/versions/8.4.2/extending/concepts#evaluation-model),
 which integrates these effects. `query`, by contrast, runs over the results of
 Bazel's loading phase, before options are evaluated.
 
@@ -137,8 +136,7 @@ $ bazel cquery //foo --universe_scope=//foo,//genrule_with_foo_as_tool
 If you want to precisely declare which instance to query over, use
 the [`config`](#config) function.
 
-See `query`'s [target pattern
-documentation](/versions/8.4.2/query/language#target-patterns) for more information on target patterns.
+See `query`'s [target pattern documentation](/versions/8.4.2/query/language#target-patterns) for more information on target patterns.
 
 ## Functions {#functions}
 
diff --git a/versions/8.4.2/query/language.mdx b/versions/8.4.2/query/language.mdx
index 7def9b63..28f6b002 100644
--- a/versions/8.4.2/query/language.mdx
+++ b/versions/8.4.2/query/language.mdx
@@ -1105,8 +1105,7 @@ is being used.
 
 ### On the ordering of results {#results-ordering}
 
-Although query expressions always follow the "[law of
-conservation of graph order](#graph-order)", _presenting_ the results may be done
+Although query expressions always follow the "[law of conservation of graph order](#graph-order)", _presenting_ the results may be done
 in either a dependency-ordered or unordered manner. This does **not**
 influence the targets in the result set or how the query is computed. It only
 affects how the results are printed to stdout. Moreover, nodes that are
@@ -1252,8 +1251,7 @@ and `maxrank` output formats print the labels of each
 target in the resulting graph, but instead of appearing in
 topological order, they appear in rank order, preceded by their
 rank number. These are unaffected by the result ordering
-`--[no]order_results` flag (see [notes on
-the ordering of results](#result-order)).
+`--[no]order_results` flag (see [notes on the ordering of results](#result-order)).
 
 There are two variants of this format: `minrank` ranks
 each node by the length of the shortest path from a root node to it.
diff --git a/versions/8.4.2/reference/be/functions.mdx b/versions/8.4.2/reference/be/functions.mdx
index 5c5af2a5..48d17d4c 100644
--- a/versions/8.4.2/reference/be/functions.mdx
+++ b/versions/8.4.2/reference/be/functions.mdx
@@ -262,8 +262,7 @@ There are several important limitations and caveats:
    package called "Foo.java" (which is allowed, though Bazel warns about it),
    then the consumer of the `glob()` will use the "Foo.java" rule
    (its outputs) instead of the "Foo.java" file. See
-   [GitHub
-   issue #10395](https://github.com/bazelbuild/bazel/issues/10395#issuecomment-583714657) for more details.
+   [GitHub issue #10395](https://github.com/bazelbuild/bazel/issues/10395#issuecomment-583714657) for more details.
 3. Globs may match files in subdirectories. And subdirectory names
    may be wildcarded. However...
 4. Labels are not allowed to cross the package boundary and glob does
diff --git a/versions/8.4.2/reference/be/java.mdx b/versions/8.4.2/reference/be/java.mdx
index eba1c248..b4955ce8 100644
--- a/versions/8.4.2/reference/be/java.mdx
+++ b/versions/8.4.2/reference/be/java.mdx
@@ -225,8 +225,7 @@ test code. The test runner's main method is invoked instead of the main class be
   [java\_binary](#java_binary) for more details.
 
 See the section on `java_binary()` arguments. This rule also
-supports all [attributes common
-to all test rules (\*\_test)](https://bazel.build/versions/8.4.2/reference/be/common-definitions#common-attributes-tests).
+supports all [attributes common to all test rules (\*\_test)](https://bazel.build/versions/8.4.2/reference/be/common-definitions#common-attributes-tests).
 
 #### Examples
 
diff --git a/versions/8.4.2/reference/be/make-variables.mdx b/versions/8.4.2/reference/be/make-variables.mdx
index 8836e398..d361005a 100644
--- a/versions/8.4.2/reference/be/make-variables.mdx
+++ b/versions/8.4.2/reference/be/make-variables.mdx
@@ -19,8 +19,7 @@ targets, and *custom* variables, which are defined in dependency targets
 and only available to targets that depend on them.
 
 The reason for the term "Make" is historical: the syntax and semantics of
-these variables were originally intended to match [GNU
-Make](https://www.gnu.org/software/make/manual/html_node/Using-Variables.html).
+these variables were originally intended to match [GNU Make](https://www.gnu.org/software/make/manual/html_node/Using-Variables.html).
 
 ## Use
 
@@ -64,8 +63,7 @@ and look at the top output lines with capital letters.
 **Toolchain option variables**
 
 * `COMPILATION_MODE`:
-  `fastbuild`, `dbg`, or `opt`. ([more
-  details](https://bazel.build/versions/8.4.2/docs/user-manual#flag--compilation_mode))
+  `fastbuild`, `dbg`, or `opt`. ([more details](https://bazel.build/versions/8.4.2/docs/user-manual#flag--compilation_mode))
 
 **Path variables**
 
diff --git a/versions/8.4.2/reference/be/workspace.mdx b/versions/8.4.2/reference/be/workspace.mdx
index fb05cfa5..36de1e3c 100644
--- a/versions/8.4.2/reference/be/workspace.mdx
+++ b/versions/8.4.2/reference/be/workspace.mdx
@@ -25,8 +25,7 @@ bind(name, actual, compatible_with, deprecation, distribs, features, licenses, r
 
 *Warning: use of `bind()` is not recommended. See "[Consider removing bind](https://github.com/bazelbuild/bazel/issues/1952)" for a long
 discussion of its issues and alternatives. In particular, consider the use of
-[`repo_mapping`
-repository attributes](https://bazel.build/versions/8.4.2/rules/repository_rules#attributes).*
+[`repo_mapping` repository attributes](https://bazel.build/versions/8.4.2/rules/repository_rules#attributes).*
 
 *Warning: `select()` cannot be used in `bind()`. See the [Configurable Attributes FAQ](/versions/8.4.2/docs/configurable-attributes#bind-select) for
 details.*
@@ -114,8 +113,7 @@ local_repository(name, path, repo_mapping)
 ```
 
 Allows targets from a local directory to be bound. This means that the current repository can
-use targets defined in this other directory. See the [bind
-section](/versions/8.4.2/reference/be/workspace#bind_examples) for more details.
+use targets defined in this other directory. See the [bind section](/versions/8.4.2/reference/be/workspace#bind_examples) for more details.
 
 #### Examples
 
diff --git a/versions/8.4.2/reference/glossary.mdx b/versions/8.4.2/reference/glossary.mdx
index 9732d9f7..128e82c4 100644
--- a/versions/8.4.2/reference/glossary.mdx
+++ b/versions/8.4.2/reference/glossary.mdx
@@ -21,8 +21,7 @@ An in-memory graph of [actions](#action) and the [artifacts](#artifact) that
 these actions read and generate. The graph might include artifacts that exist as
 source files (for example, in the file system) as well as generated
 intermediate/final artifacts that are not mentioned in `BUILD` files. Produced
-during the [analysis phase](#analysis-phase) and used during the [execution
-phase](#execution-phase).
+during the [analysis phase](#analysis-phase) and used during the [execution phase](#execution-phase).
 
 ### Action graph query (aquery) {#action-graph-query}
 A [query](#query-concept) tool that can query over build [actions](#action).
@@ -37,8 +36,7 @@ invalidate individual actions deterministically.
 
 ### Analysis phase {#analysis-phase}
 The second phase of a build. Processes the [target graph](#target-graph)
-specified in [`BUILD` files](#build-file) to produce an in-memory [action
-graph](#action-graph) that determines the order of actions to run during the
+specified in [`BUILD` files](#build-file) to produce an in-memory [action graph](#action-graph) that determines the order of actions to run during the
 [execution phase](#execution-phase). This is the phase in which rule
 implementations are evaluated.
 
@@ -81,8 +79,7 @@ target's source files, dependencies, and custom compiler options. The particular
 attributes available for a given target depend on its rule type.
 
 ### .bazelrc {#bazelrc}
-Bazel’s configuration file used to change the default values for [startup
-flags](#startup-flags) and [command flags](#command-flags), and to define common
+Bazel’s configuration file used to change the default values for [startup flags](#startup-flags) and [command flags](#command-flags), and to define common
 groups of options that can then be set together on the Bazel command line using
 a `--config` flag. Bazel can combine settings from multiple bazelrc files
 (systemwide, per-workspace, per-user, or from a custom location), and a
@@ -108,8 +105,7 @@ directory.
 
 ### .bzl File {#bzl-file}
 A file that defines rules, [macros](#macro), and constants written in
-[Starlark](#starlark). These can then be imported into [`BUILD`
-files](#build-file) using the `load()` function.
+[Starlark](#starlark). These can then be imported into [`BUILD` files](#build-file) using the `load()` function.
 
 {/* TODO: ### Build event protocol */}
 
@@ -117,8 +113,7 @@ files](#build-file) using the `load()` function.
 
 ### Build graph {#build-graph}
 The dependency graph that Bazel constructs and traverses to perform a build.
-Includes nodes like [targets](#target), [configured
-targets](#configured-target), [actions](#action), and [artifacts](#artifact). A
+Includes nodes like [targets](#target), [configured targets](#configured-target), [actions](#action), and [artifacts](#artifact). A
 build is considered complete when all [artifacts](#artifact) on which a set of
 requested targets depend are verified as up-to-date.
 
@@ -158,8 +153,7 @@ graphs and restart the [analysis phase](#analysis-phase).
 ### Configuration {#configuration}
 Information outside of [rule](#rule) definitions that impacts how rules generate
 [actions](#action). Every build has at least one configuration specifying the
-target platform, action environment variables, and command-line [build
-flags](#command-flags). [Transitions](#transition) may create additional
+target platform, action environment variables, and command-line [build flags](#command-flags). [Transitions](#transition) may create additional
 configurations, such as for host tools or cross-compilation.
 
 **See also:** [Configurations](/versions/8.4.2/extending/rules#configurations)
@@ -174,8 +168,7 @@ configuration of `//:c` because changing `--javacopt` unnecessarily breaks C++
 build cacheability.
 
 ### Configured query (cquery) {#configured-query}
-A [query](#query-concept) tool that queries over [configured
-targets](#configured-target) (after the [analysis phase](#analysis-phase)
+A [query](#query-concept) tool that queries over [configured targets](#configured-target) (after the [analysis phase](#analysis-phase)
 completes). This means `select()` and [build flags](#command-flags) (such as
 `--platforms`) are accurately reflected in the results.
 
@@ -191,8 +184,7 @@ build, it has two configured targets: `` and ``.
 ### Correctness {#correctness}
 A build is correct when its output faithfully reflects the state of its
 transitive inputs. To achieve correct builds, Bazel strives to be
-[hermetic](#hermeticity), reproducible, and making [build
-analysis](#analysis-phase) and [action execution](#execution-phase)
+[hermetic](#hermeticity), reproducible, and making [build analysis](#analysis-phase) and [action execution](#execution-phase)
 deterministic.
 
 ### Dependency {#dependency}
@@ -234,8 +226,7 @@ compilation). A dynamic execution strategy can provide the best possible
 incremental and clean build times.
 
 ### Execution phase {#execution-phase}
-The third phase of a build. Executes the [actions](#action) in the [action
-graph](#action-graph) created during the [analysis phase](#analysis-phase).
+The third phase of a build. Executes the [actions](#action) in the [action graph](#action-graph) created during the [analysis phase](#analysis-phase).
 These actions invoke executables (compilers, scripts) to read and write
 [artifacts](#artifact). *Spawn strategies* control how these actions are
 executed: locally, remotely, dynamically, sandboxed, docker, and so on.
@@ -285,8 +276,7 @@ syntax may be omitted.
 The first phase of a build where Bazel executes [`BUILD` files](#build-file) to
 create [packages](#package). [Macros](#macro) and certain functions like
 `glob()` are evaluated in this phase. Interleaved with the second phase of the
-build, the [analysis phase](#analysis-phase), to build up a [target
-graph](#target-graph).
+build, the [analysis phase](#analysis-phase), to build up a [target graph](#target-graph).
 
 ### Legacy macro {#legacy-macro}
 A flavor of [macro](#macro) which is declared as an ordinary
@@ -336,8 +326,7 @@ Module metadata is hosted in Bazel registries.
 
 ### Module Extension {#module-extension}
 A piece of logic that can be run to generate [repos](#repository) by reading
-inputs from across the [module](#module) dependency graph and invoking [repo
-rules](#repository-rule). Module extensions have capabilities similar to repo
+inputs from across the [module](#module) dependency graph and invoking [repo rules](#repository-rule). Module extensions have capabilities similar to repo
 rules, allowing them to access the internet, perform file I/O, and so on.
 
 **See also:** [Module extensions](/versions/8.4.2/external/extension)
@@ -350,8 +339,7 @@ example, `native.cc_library` or `native.java_library`). User-defined rules
 
 ### Output base {#output-base}
 A [workspace](#workspace)-specific directory to store Bazel output files. Used
-to separate outputs from the *workspace*'s source tree (the [main
-repo](#repository)). Located in the [output user root](#output-user-root).
+to separate outputs from the *workspace*'s source tree (the [main repo](#repository)). Located in the [output user root](#output-user-root).
 
 ### Output groups {#output-groups}
 A group of files that is expected to be built when Bazel finishes building a
@@ -406,8 +394,7 @@ query variants: [query](#query-command), [cquery](#configured-query), and
 [aquery](#action-graph-query).
 
 ### query (command) {#query-command}
-A [query](#query-concept) tool that operates over the build's post-[loading
-phase](#loading-phase) [target graph](#target-graph). This is relatively fast,
+A [query](#query-concept) tool that operates over the build's post-[loading phase](#loading-phase) [target graph](#target-graph). This is relatively fast,
 but can't analyze the effects of `select()`, [build flags](#command-flags),
 [artifacts](#artifact), or build [actions](#action).
 
@@ -425,8 +412,7 @@ repo; multiple such files can coexist in a directory.
 The *main repo* is the repo in which the current Bazel command is being run.
 
 *External repos* are defined by specifying [modules](#module) in `MODULE.bazel`
-files, or invoking [repo rules](#repository-rule) in [module
-extensions](#module-extension). They can be fetched on demand to a predetermined
+files, or invoking [repo rules](#repository-rule) in [module extensions](#module-extension). They can be fetched on demand to a predetermined
 "magical" location on disk.
 
 Each repo has a unique, constant *canonical* name, and potentially different
@@ -437,8 +423,7 @@ Each repo has a unique, constant *canonical* name, and potentially different
 ### Repository cache {#repo-cache}
 A shared content-addressable cache of files downloaded by Bazel for builds,
 shareable across [workspaces](#workspace). Enables offline builds after the
-initial download. Commonly used to cache files downloaded through [repository
-rules](#repository-rule) like `http_archive` and repository rule APIs like
+initial download. Commonly used to cache files downloaded through [repository rules](#repository-rule) like `http_archive` and repository rule APIs like
 `repository_ctx.download`. Files are cached only if their SHA-256 checksums are
 specified for the download.
 
@@ -472,8 +457,7 @@ Rules are instantiated to produce rule targets in the
 [loading phase](#loading-phase). In the [analysis phase](#analysis-phase) rule
 targets communicate information to their downstream dependencies in the form of
 [providers](#provider), and register [actions](#action) describing how to
-generate their output artifacts. These actions are run in the [execution
-phase](#execution-phase).
+generate their output artifacts. These actions are run in the [execution phase](#execution-phase).
 
 Note: Historically the term "rule" has been used to refer to a rule target.
 This usage was inherited from tools like Make, but causes confusion and should
@@ -517,8 +501,7 @@ support the stamp attribute.
 ### Starlark {#starlark}
 The extension language for writing [rules](/versions/8.4.2/extending/rules) and [macros](#macro). A
 restricted subset of Python (syntactically and grammatically) aimed for the
-purpose of configuration, and for better performance. Uses the [`.bzl`
-file](#bzl-file) extension. [`BUILD` files](#build-file) use an even more
+purpose of configuration, and for better performance. Uses the [`.bzl` file](#bzl-file) extension. [`BUILD` files](#build-file) use an even more
 restricted version of Starlark (such as no `def` function definitions), formerly
 known as Skylark.
 
@@ -549,8 +532,7 @@ An object that is defined in a [`BUILD` file](#build-file) and identified by a
 [label](#label). Targets represent the buildable units of a workspace from
 the perspective of the end user.
 
-A target that is declared by instantiating a [rule](#rule) is called a [rule
-target](#rule-target). Depending on the rule, these may be runnable (like
+A target that is declared by instantiating a [rule](#rule) is called a [rule target](#rule-target). Depending on the rule, these may be runnable (like
 `cc_binary`) or testable (like `cc_test`). Rule targets typically depend on
 other targets via their [attributes](#attribute) (such as `deps`); these
 dependencies form the basis of the [target graph](#target-graph).
@@ -561,14 +543,11 @@ within a `BUILD` file. As a special case, the `BUILD` file of any package is
 always considered a source file target in that package.
 
 Targets are discovered during the [loading phase](#loading-phase). During the
-[analysis phase](#analysis-phase), targets are associated with [build
-configurations](#configuration) to form [configured
-targets](#configured-target).
+[analysis phase](#analysis-phase), targets are associated with [build configurations](#configuration) to form [configured targets](#configured-target).
 
 ### Target graph {#target-graph}
 An in-memory graph of [targets](#target) and their dependencies. Produced during
-the [loading phase](#loading-phase) and used as an input to the [analysis
-phase](#analysis-phase).
+the [loading phase](#loading-phase) and used as an input to the [analysis phase](#analysis-phase).
 
 ### Target pattern {#target-pattern}
 A way to specify a group of [targets](#target) on the command line. Commonly
@@ -581,8 +560,7 @@ packages recursively from the root of the [workspace](#workspace).
 Rule [targets](#target) instantiated from test rules, and therefore contains a
 test executable. A return code of zero from the completion of the executable
 indicates test success. The exact contract between Bazel and tests (such as test
-environment variables, test result collection methods) is specified in the [Test
-Encyclopedia](/versions/8.4.2/reference/test-encyclopedia).
+environment variables, test result collection methods) is specified in the [Test Encyclopedia](/versions/8.4.2/reference/test-encyclopedia).
 
 ### Toolchain {#toolchain}
 A set of tools to build outputs for a language. Typically, a toolchain includes
@@ -596,8 +574,7 @@ A build [target](#target) is top-level if it’s requested on the Bazel command
 line. For example, if `//:foo` depends on `//:bar`, and `bazel build //:foo` is
 called, then for this build, `//:foo` is top-level, and `//:bar` isn’t
 top-level, although both targets will need to be built. An important difference
-between top-level and non-top-level targets is that [command
-flags](#command-flags) set on the Bazel command line (or via
+between top-level and non-top-level targets is that [command flags](#command-flags) set on the Bazel command line (or via
 [.bazelrc](#bazelrc)) will set the [configuration](#configuration) for top-level
 targets, but might be modified by a [transition](#transition) for non-top-level
 targets.
@@ -628,8 +605,7 @@ or `.bzl` file may load a given `.bzl` file. Without context, usually
 **See also:** [Visibility documentation](/versions/8.4.2/concepts/visibility)
 
 ### Workspace {#workspace}
-The environment shared by all Bazel commands run from the same [main
-repository](#repository).
+The environment shared by all Bazel commands run from the same [main repository](#repository).
 
 Note that historically the concepts of "repository" and "workspace" have been
 conflated; the term "workspace" has often been used to refer to the main
diff --git a/versions/8.4.2/release/backward-compatibility.mdx b/versions/8.4.2/release/backward-compatibility.mdx
index fad4582e..f71bcc21 100644
--- a/versions/8.4.2/release/backward-compatibility.mdx
+++ b/versions/8.4.2/release/backward-compatibility.mdx
@@ -6,11 +6,9 @@ This page provides information about how to handle backward compatibility,
 including migrating from one release to another and how to communicate
 incompatible changes.
 
-Bazel is evolving. Minor versions released as part of an [LTS major
-version](/versions/8.4.2/release#bazel-versioning) are fully backward-compatible. New major LTS
+Bazel is evolving. Minor versions released as part of an [LTS major version](/versions/8.4.2/release#bazel-versioning) are fully backward-compatible. New major LTS
 releases may contain incompatible changes that require some migration effort.
-For more information about Bazel's release model, please check out the [Release
-Model](/versions/8.4.2/release) page.
+For more information about Bazel's release model, please check out the [Release Model](/versions/8.4.2/release) page.
 
 ## Summary {#summary}
 
@@ -59,8 +57,7 @@ available.
 ## Communicating incompatible changes {#communicating-incompatible-changes}
 
 The primary source of information about incompatible changes are GitHub issues
-marked with an ["incompatible-change"
-label](https://github.com/bazelbuild/bazel/issues?q=label%3Aincompatible-change).
+marked with an ["incompatible-change" label](https://github.com/bazelbuild/bazel/issues?q=label%3Aincompatible-change).
 
 For every incompatible change, the issue specifies the following:
 
diff --git a/versions/8.4.2/release/index.mdx b/versions/8.4.2/release/index.mdx
index a7a37681..0c00fd8e 100644
--- a/versions/8.4.2/release/index.mdx
+++ b/versions/8.4.2/release/index.mdx
@@ -2,8 +2,7 @@
 title: 'Release Model'
 ---
 
-As announced in [the original blog
-post](https://blog.bazel.build/2020/11/10/long-term-support-release.html), Bazel
+As announced in [the original blog post](https://blog.bazel.build/2020/11/10/long-term-support-release.html), Bazel
 4.0 and higher versions provides support for two release tracks: rolling
 releases and long term support (LTS) releases. This page covers the latest
 information about Bazel's release model.
@@ -19,8 +18,7 @@ information about Bazel's release model.
 | Bazel 5 | Maintenance | [5.4.1](https://github.com/bazelbuild/bazel/releases/tag/5.4.1) | Jan 2025 |
 | Bazel 4 | Deprecated | [4.2.4](https://github.com/bazelbuild/bazel/releases/tag/4.2.4) | Jan 2024 |
 
-All Bazel LTS releases can be found on the [release
-page](https://github.com/bazelbuild/bazel/releases) on GitHub.
+All Bazel LTS releases can be found on the [release page](https://github.com/bazelbuild/bazel/releases) on GitHub.
 
 Note: Bazel version older than Bazel 5 are no longer supported, Bazel users are
 recommended to upgrade to the latest LTS release or use rolling releases if you
@@ -28,8 +26,7 @@ want to keep up with the latest changes at HEAD.
 
 ## Release versioning {#bazel-versioning}
 
-Bazel uses a _major.minor.patch_ [Semantic
-Versioning](https://semver.org/) scheme.
+Bazel uses a _major.minor.patch_ [Semantic Versioning](https://semver.org/) scheme.
 
 *   A _major release_ contains features that are not backward compatible with
     the previous release. Each major Bazel version is an LTS release.
@@ -72,8 +69,7 @@ Bazel regularly publish releases for two release tracks.
     release.
 *   Rolling releases can ship incompatible changes. Incompatible flags are
     recommended for major breaking changes, rolling out incompatible changes
-    should follow our [backward compatibility
-    policy](/versions/8.4.2/release/backward-compatibility).
+    should follow our [backward compatibility policy](/versions/8.4.2/release/backward-compatibility).
 
 ### LTS releases {#lts-releases}
 
@@ -89,8 +85,7 @@ Bazel regularly publish releases for two release tracks.
 *   A Bazel LTS release enters the Deprecated stage after being in ​​the
     Maintenance stage for 2 years.
 
-For planned releases, please check our [release
-issues](https://github.com/bazelbuild/bazel/issues?q=is%3Aopen+is%3Aissue+label%3Arelease)
+For planned releases, please check our [release issues](https://github.com/bazelbuild/bazel/issues?q=is%3Aopen+is%3Aissue+label%3Arelease)
 on Github.
 
 ## Release procedure & policies {#release-procedure-policies}
@@ -153,8 +148,7 @@ For LTS releases, the procedure and policies below are followed:
 1.  Identify release blockers and fix issues found on the release branch.
     *   The release branch is tested with the same test suite in
         [postsubmit](https://buildkite.com/bazel/bazel-bazel) and
-        [downstream test pipeline]
-        (https://buildkite.com/bazel/bazel-at-head-plus-downstream)
+        [downstream test pipeline](https://buildkite.com/bazel/bazel-at-head-plus-downstream)
         on Bazel CI. The Bazel team monitors testing results of the release
         branch and fixes any regressions found.
 1.  Create a new release candidate from the release branch when all known
@@ -210,5 +204,4 @@ feature.
 ## Rule compatibility {#rule-compatibility}
 
 If you are a rule authors and want to maintain compatibility with different
-Bazel versions, please check out the [Rule
-Compatibility](/versions/8.4.2/release/rule-compatibility) page.
+Bazel versions, please check out the [Rule Compatibility](/versions/8.4.2/release/rule-compatibility) page.
diff --git a/versions/8.4.2/release/rule-compatibility.mdx b/versions/8.4.2/release/rule-compatibility.mdx
index 17c88b35..729a62e5 100644
--- a/versions/8.4.2/release/rule-compatibility.mdx
+++ b/versions/8.4.2/release/rule-compatibility.mdx
@@ -53,18 +53,15 @@ Bazel LTS release.
 As Bazel rules authors, you can ensure a manageable migration process for users
 by following these best practices:
 
-1.  The rule should follow [Semantic
-    Versioning](https://semver.org/): minor versions of the same
+1.  The rule should follow [Semantic Versioning](https://semver.org/): minor versions of the same
     major version are backward compatible.
 1.  The rule at HEAD should be compatible with the latest Bazel LTS release.
 1.  The rule at HEAD should be compatible with Bazel at HEAD. To achieve this,
     you can
     *   Set up your own CI testing with Bazel at HEAD
-    *   Add your project to [Bazel downstream
-        testing](https://github.com/bazelbuild/continuous-integration/blob/master/docs/downstream-testing.md);
+    *   Add your project to [Bazel downstream testing](https://github.com/bazelbuild/continuous-integration/blob/master/docs/downstream-testing.md);
         the Bazel team files issues to your project if breaking changes in Bazel
-        affect your project, and you must follow our [downstream project
-        policies](https://github.com/bazelbuild/continuous-integration/blob/master/docs/downstream-testing.md#downstream-project-policies)
+        affect your project, and you must follow our [downstream project policies](https://github.com/bazelbuild/continuous-integration/blob/master/docs/downstream-testing.md#downstream-project-policies)
         to address issues timely.
 1.  The latest major version of the rule must be compatible with the latest
     Bazel LTS release.
diff --git a/versions/8.4.2/remote/bep-glossary.mdx b/versions/8.4.2/remote/bep-glossary.mdx
index 6916cd3c..2363d817 100644
--- a/versions/8.4.2/remote/bep-glossary.mdx
+++ b/versions/8.4.2/remote/bep-glossary.mdx
@@ -410,5 +410,4 @@ workspace, such as the execution root.
 
 ## WorkspaceStatus {#workspacestatus}
 
-A single `WorkspaceStatus` event contains the result of the [workspace status
-command](/versions/8.4.2/docs/user-manual#workspace-status).
+A single `WorkspaceStatus` event contains the result of the [workspace status command](/versions/8.4.2/docs/user-manual#workspace-status).
diff --git a/versions/8.4.2/remote/bep.mdx b/versions/8.4.2/remote/bep.mdx
index 3485b928..9adb8cd9 100644
--- a/versions/8.4.2/remote/bep.mdx
+++ b/versions/8.4.2/remote/bep.mdx
@@ -2,14 +2,12 @@
 title: 'Build Event Protocol'
 ---
 
-The [Build Event
-Protocol](https://github.com/bazelbuild/bazel/blob/master/src/main/java/com/google/devtools/build/lib/buildeventstream/proto/build_event_stream.proto)
+The [Build Event Protocol](https://github.com/bazelbuild/bazel/blob/master/src/main/java/com/google/devtools/build/lib/buildeventstream/proto/build_event_stream.proto)
 (BEP) allows third-party programs to gain insight into a Bazel invocation. For
 example, you could use the BEP to gather information for an IDE
 plugin or a dashboard that displays build results.
 
-The protocol is a set of [protocol
-buffer](https://developers.google.com/protocol-buffers/) messages with some
+The protocol is a set of [protocol buffer](https://developers.google.com/protocol-buffers/) messages with some
 semantics defined on top of it. It includes information about build and test
 results, build progress, the build configuration and much more. The BEP is
 intended to be consumed programmatically and makes parsing Bazel’s
@@ -20,16 +18,13 @@ build event is a protocol buffer message consisting of a build event identifier,
 a set of child event identifiers, and a payload.
 
 *  __Build Event Identifier:__ Depending on the kind of build event, it might be
-an [opaque
-string](https://github.com/bazelbuild/bazel/blob/7.1.0/src/main/java/com/google/devtools/build/lib/buildeventstream/proto/build_event_stream.proto#L131-L140)
-or [structured
-information](https://github.com/bazelbuild/bazel/blob/7.1.0/src/main/java/com/google/devtools/build/lib/buildeventstream/proto/build_event_stream.proto#L194-L205)
+an [opaque string](https://github.com/bazelbuild/bazel/blob/7.1.0/src/main/java/com/google/devtools/build/lib/buildeventstream/proto/build_event_stream.proto#L131-L140)
+or [structured information](https://github.com/bazelbuild/bazel/blob/7.1.0/src/main/java/com/google/devtools/build/lib/buildeventstream/proto/build_event_stream.proto#L194-L205)
 revealing more about the build event. A build event identifier is unique within
 a build.
 
 *  __Children:__ A build event may announce other build events, by including
-their build event identifiers in its [children
-field](https://github.com/bazelbuild/bazel/blob/7.1.0/src/main/java/com/google/devtools/build/lib/buildeventstream/proto/build_event_stream.proto#L1276).
+their build event identifiers in its [children field](https://github.com/bazelbuild/bazel/blob/7.1.0/src/main/java/com/google/devtools/build/lib/buildeventstream/proto/build_event_stream.proto#L1276).
 For example, the `PatternExpanded` build event announces the targets it expands
 to as children. The protocol guarantees that all events, except for the first
 event, are announced by a previous event.
@@ -91,8 +86,7 @@ human-readable formats, such as text and JSON:
 
 ## Build Event Service {#build-event-service}
 
-The [Build Event
-Service](https://github.com/googleapis/googleapis/blob/master/google/devtools/build/v1/publish_build_event.proto)
+The [Build Event Service](https://github.com/googleapis/googleapis/blob/master/google/devtools/build/v1/publish_build_event.proto)
 Protocol is a generic [gRPC](https://www.grpc.io) service for publishing build events. The Build Event
 Service protocol is independent of the BEP and treats BEP events as opaque bytes.
 Bazel ships with a gRPC client implementation of the Build Event Service protocol that
@@ -136,8 +130,7 @@ For a description of each of these flags, see the
 The BEP typically contains many references to log files (test.log, test.xml,
 etc. ) stored on the machine where Bazel is running. A remote BES server
 typically can't access these files as they are on different machines. A way to
-work around this issue is to use Bazel with [remote
-caching](/versions/8.4.2/remote/caching).
+work around this issue is to use Bazel with [remote caching](/versions/8.4.2/remote/caching).
 Bazel will upload all output files to the remote cache (including files
 referenced in the BEP) and the BES server can then fetch the referenced files
 from the cache.
diff --git a/versions/8.4.2/remote/cache-local.mdx b/versions/8.4.2/remote/cache-local.mdx
index 5df18a90..dc6918ff 100644
--- a/versions/8.4.2/remote/cache-local.mdx
+++ b/versions/8.4.2/remote/cache-local.mdx
@@ -18,8 +18,7 @@ execution. However, local execution presents some additional challenges.
 ## Checking your cache hit rate {#cache-hits}
 
 Successful remote cache hits will show up in the status line, similar to
-[Cache Hits rate with Remote
-Execution](/versions/8.4.2/remote/cache-remote#check-cache-hits).
+[Cache Hits rate with Remote Execution](/versions/8.4.2/remote/cache-remote#check-cache-hits).
 
 In the standard output of your Bazel run, you will see something like the
 following:
@@ -66,8 +65,7 @@ the steps in this section.
    message you see does not give you enough information, try adding
    `--verbose_failures`.
 
-2. Follow the steps from [Troubleshooting cache hits for remote
-   execution](/versions/8.4.2/remote/cache-remote#troubleshooting_cache_hits) to
+2. Follow the steps from [Troubleshooting cache hits for remote execution](/versions/8.4.2/remote/cache-remote#troubleshooting_cache_hits) to
    ensure that your cache-writing Bazel invocations are able to get cache hits
    on the same machine and across machines.
 
@@ -81,7 +79,6 @@ the steps in this section.
    b. Ensure your cache-reading Bazel invocations build the same targets as the
       cache-writing Bazel invocations.
 
-   c. Follow the same steps as to [ensure caching across
-      machines](/versions/8.4.2/remote/cache-remote#caching-across-machines),
+   c. Follow the same steps as to [ensure caching across machines](/versions/8.4.2/remote/cache-remote#caching-across-machines),
       to ensure caching from your cache-writing Bazel invocation to your
       cache-reading Bazel invocation.
diff --git a/versions/8.4.2/remote/caching.mdx b/versions/8.4.2/remote/caching.mdx
index 5b85e31d..29c76957 100644
--- a/versions/8.4.2/remote/caching.mdx
+++ b/versions/8.4.2/remote/caching.mdx
@@ -308,8 +308,7 @@ or for the age of individual cache entries. Bazel will automatically garbage
 collect the disk cache while idling between builds; the idle timer can be set
 with `--experimental_disk_cache_gc_idle_delay` (defaulting to 5 minutes).
 
-As an alternative to automatic garbage collection, we also provide a [tool](
-https://github.com/bazelbuild/bazel/tree/master/src/tools/diskcache) to run a
+As an alternative to automatic garbage collection, we also provide a [tool](https://github.com/bazelbuild/bazel/tree/master/src/tools/diskcache) to run a
 garbage collection on demand.
 
 ## Known issues {#known-issues}
diff --git a/versions/8.4.2/remote/dynamic.mdx b/versions/8.4.2/remote/dynamic.mdx
index dec854f7..b2ab6ca6 100644
--- a/versions/8.4.2/remote/dynamic.mdx
+++ b/versions/8.4.2/remote/dynamic.mdx
@@ -12,8 +12,7 @@ alike.
 This page describes how to enable, tune, and debug dynamic execution. If you
 have both local and remote execution set up and are trying to adjust Bazel
 settings for better performance, this page is for you. If you don't already have
-remote execution set up, go to the Bazel [Remote Execution
-Overview](/versions/8.4.2/remote/rbe) first.
+remote execution set up, go to the Bazel [Remote Execution Overview](/versions/8.4.2/remote/rbe) first.
 
 ## Enabling dynamic execution? {#enabling-dynamic-execution}
 
@@ -44,14 +43,12 @@ are likely. The default value is 1000ms, but should be tuned to being just a bit
 longer than cache hits usually take. The actual time depends both on the remote
 system and on how long a round-trip takes. Usually, the value will be the same
 for all users of a given remote system, unless some of them are far enough away
-to add roundtrip latency. You can use the [Bazel profiling
-features](/versions/8.4.2/rules/performance#performance-profiling) to look at how long typical
+to add roundtrip latency. You can use the [Bazel profiling features](/versions/8.4.2/rules/performance#performance-profiling) to look at how long typical
 cache hits take.
 
 Dynamic execution can be used with local sandboxed strategy as well as with
 [persistent workers](/versions/8.4.2/remote/persistent). Persistent workers will automatically
-run with sandboxing when used with dynamic execution, and cannot use [multiplex
-workers](/versions/8.4.2/remote/multiplex). On Darwin and Windows systems, the sandboxed
+run with sandboxing when used with dynamic execution, and cannot use [multiplex workers](/versions/8.4.2/remote/multiplex). On Darwin and Windows systems, the sandboxed
 strategy can be slow; you can pass `--reuse_sandbox_directories` to reduce
 overhead of creating sandboxes on these systems.
 
@@ -67,8 +64,7 @@ entire action fails. This is an intentional choice to prevent differences
 between local and remote execution from going unnoticed.
 
 For more background on how dynamic execution and its locking works, see Julio
-Merino's excellent [blog
-posts](https://jmmv.dev/series/bazel-dynamic-execution/)
+Merino's excellent [blog posts](https://jmmv.dev/series/bazel-dynamic-execution/)
 
 ## When should I use dynamic execution? {#when-to-use}
 
diff --git a/versions/8.4.2/remote/persistent.mdx b/versions/8.4.2/remote/persistent.mdx
index 76baeaa6..ebc9678f 100644
--- a/versions/8.4.2/remote/persistent.mdx
+++ b/versions/8.4.2/remote/persistent.mdx
@@ -257,7 +257,6 @@ For more information on persistent workers, see:
 *   [Original persistent workers blog post](https://blog.bazel.build/2015/12/10/java-workers.html)
 *   [Haskell implementation description](https://www.tweag.io/blog/2019-09-25-bazel-ghc-persistent-worker-internship/)
 *   [Blog post by Mike Morearty](https://medium.com/@mmorearty/how-to-create-a-persistent-worker-for-bazel-7738bba2cabb)
-*   [Front End Development with Bazel: Angular/TypeScript and Persistent Workers
-    w/ Asana](https://www.youtube.com/watch?v=0pgERydGyqo)
+*   [Front End Development with Bazel: Angular/TypeScript and Persistent Workers w/ Asana](https://www.youtube.com/watch?v=0pgERydGyqo)
 *   [Bazel strategies explained](https://jmmv.dev/2019/12/bazel-strategies.html)
 *   [Informative worker strategy discussion on the bazel-discuss mailing list](https://groups.google.com/forum/#!msg/bazel-discuss/oAEnuhYOPm8/ol7hf4KWJgAJ)
diff --git a/versions/8.4.2/remote/rules.mdx b/versions/8.4.2/remote/rules.mdx
index 528a9f28..9dfb8d81 100644
--- a/versions/8.4.2/remote/rules.mdx
+++ b/versions/8.4.2/remote/rules.mdx
@@ -54,8 +54,7 @@ variables that may not be set to equivalent values (or at all) in the remote
 execution environment.
 
 Toolchain rules currently exist for Bazel build and test rules for
-[Scala](https://github.com/bazelbuild/rules_scala/blob/master/scala/scala_toolch
-ain.bzl),
+[Scala](https://github.com/bazelbuild/rules_scala/blob/master/scala/scala_toolch ain.bzl),
 [Rust](https://github.com/bazelbuild/rules_rust/blob/main/rust/toolchain.bzl),
 and [Go](https://github.com/bazelbuild/rules_go/blob/master/go/toolchains.rst),
 and new toolchain rules are under way for other languages and tools such as
diff --git a/versions/8.4.2/remote/workspace.mdx b/versions/8.4.2/remote/workspace.mdx
index f79779af..cf904c3a 100644
--- a/versions/8.4.2/remote/workspace.mdx
+++ b/versions/8.4.2/remote/workspace.mdx
@@ -11,8 +11,7 @@ on the host machine. If your workspace rules access information about the
 host machine for use during execution, your build is likely to break due to
 incompatibilities between the environments.
 
-As part of [adapting Bazel rules for remote
-execution](/versions/8.4.2/remote/rules), you need to find such workspace rules
+As part of [adapting Bazel rules for remote execution](/versions/8.4.2/remote/rules), you need to find such workspace rules
 and fix them. This page describes how to find potentially problematic workspace
 rules using the workspace log.
 
diff --git a/versions/8.4.2/rules/language.mdx b/versions/8.4.2/rules/language.mdx
index e2a953af..62511e0f 100644
--- a/versions/8.4.2/rules/language.mdx
+++ b/versions/8.4.2/rules/language.mdx
@@ -93,10 +93,8 @@ values returned by rules are immutable.
 `BUILD` files register targets via making calls to rules. `.bzl` files provide
 definitions for constants, rules, macros, and functions.
 
-[Native functions](/versions/8.4.2/reference/be/functions) and [native rules](
-/reference/be/overview#language-specific-native-rules) are global symbols in
-`BUILD` files. `bzl` files need to load them using the [`native` module](
-/rules/lib/toplevel/native).
+[Native functions](/versions/8.4.2/reference/be/functions) and [native rules](/reference/be/overview#language-specific-native-rules) are global symbols in
+`BUILD` files. `bzl` files need to load them using the [`native` module](/rules/lib/toplevel/native).
 
 There are two syntactic restrictions in `BUILD` files: 1) declaring functions is
 illegal, and 2) `*args` and `**kwargs` arguments are not allowed.
diff --git a/versions/8.4.2/rules/legacy-macro-tutorial.mdx b/versions/8.4.2/rules/legacy-macro-tutorial.mdx
index 87120c6d..30f780fd 100644
--- a/versions/8.4.2/rules/legacy-macro-tutorial.mdx
+++ b/versions/8.4.2/rules/legacy-macro-tutorial.mdx
@@ -3,9 +3,7 @@ title: 'Creating a Legacy Macro'
 ---
 
 IMPORTANT: This tutorial is for [*legacy macros*](/versions/8.4.2/extending/legacy-macros). If
-you only need to support Bazel 8 or newer, we recommend using [symbolic
-macros](/versions/8.4.2/extending/macros) instead; take a look at [Creating a Symbolic
-Macro](../macro-tutorial).
+you only need to support Bazel 8 or newer, we recommend using [symbolic macros](/versions/8.4.2/extending/macros) instead; take a look at [Creating a Symbolic Macro](../macro-tutorial).
 
 Imagine that you need to run a tool as part of your build. For example, you
 may want to generate or preprocess a source file, or compress a binary. In this
diff --git a/versions/8.4.2/rules/verbs-tutorial.mdx b/versions/8.4.2/rules/verbs-tutorial.mdx
index 707b00da..d76b2a8a 100644
--- a/versions/8.4.2/rules/verbs-tutorial.mdx
+++ b/versions/8.4.2/rules/verbs-tutorial.mdx
@@ -49,8 +49,7 @@ This pattern can also be seen in the Angular project. The
 produces two targets. The first is a standard `nodejs_test` target which compares
 some generated output against a "golden" file (that is, a file containing the
 expected output). This can be built and run with a normal `bazel
-test` invocation. In `angular-cli`, you can run [one such
-target](https://github.com/angular/angular-cli/blob/e1269cb520871ee29b1a4eec6e6c0e4a94f0b5fc/etc/api/BUILD)
+test` invocation. In `angular-cli`, you can run [one such target](https://github.com/angular/angular-cli/blob/e1269cb520871ee29b1a4eec6e6c0e4a94f0b5fc/etc/api/BUILD)
 with `bazel test //etc/api:angular_devkit_core_api`.
 
 Over time, this golden file may need to be updated for legitimate reasons.
diff --git a/versions/8.4.2/run/build.mdx b/versions/8.4.2/run/build.mdx
index 8019e019..43ee0190 100644
--- a/versions/8.4.2/run/build.mdx
+++ b/versions/8.4.2/run/build.mdx
@@ -626,8 +626,7 @@ Note: Hermeticity means that the action only uses its declared input
 files and no other files in the filesystem, and it only produces its declared
 output files. See [Hermeticity](/versions/8.4.2/basics/hermeticity) for more details.
 
-On some platforms such as [Google Kubernetes
-Engine](https://cloud.google.com/kubernetes-engine/) cluster nodes or Debian,
+On some platforms such as [Google Kubernetes Engine](https://cloud.google.com/kubernetes-engine/) cluster nodes or Debian,
 user namespaces are deactivated by default due to security
 concerns. This can be checked by looking at the file
 `/proc/sys/kernel/unprivileged_userns_clone`: if it exists and contains a 0,
diff --git a/versions/8.4.2/start/android-app.mdx b/versions/8.4.2/start/android-app.mdx
index 8bac659e..dbe20e8c 100644
--- a/versions/8.4.2/start/android-app.mdx
+++ b/versions/8.4.2/start/android-app.mdx
@@ -36,8 +36,7 @@ In this tutorial you learn how to:
 Before you begin the tutorial, install the following software:
 
 * **Bazel.** To install, follow the [installation instructions](/versions/8.4.2/install).
-* **Android Studio.** To install, follow the steps to [download Android
-  Studio](https://developer.android.com/sdk/index.html).
+* **Android Studio.** To install, follow the steps to [download Android Studio](https://developer.android.com/sdk/index.html).
   Execute the setup wizard to download the SDK and configure your environment.
 * (Optional) **Git.** Use `git` to download the Android app project.
 
@@ -52,8 +51,7 @@ This app has a single button that prints a greeting when clicked:
 
 **Figure 1.** Android app button greeting.
 
-Clone the repository with `git` (or [download the ZIP file
-directly](https://github.com/bazelbuild/examples/archive/master.zip)):
+Clone the repository with `git` (or [download the ZIP file directly](https://github.com/bazelbuild/examples/archive/master.zip)):
 
 ```posix-terminal
 git clone https://github.com/bazelbuild/examples
@@ -103,8 +101,7 @@ A [workspace](/versions/8.4.2/concepts/build-ref#workspace) is a directory that
 source files for one or more software projects, and has a `MODULE.bazel` file at
 its root.
 
-The `MODULE.bazel` file may be empty or may contain references to [external
-dependencies](/versions/8.4.2/external/overview) required to build your project.
+The `MODULE.bazel` file may be empty or may contain references to [external dependencies](/versions/8.4.2/external/overview) required to build your project.
 
 First, run the following command to create an empty `MODULE.bazel` file:
 
@@ -147,8 +144,7 @@ environment variable, and automatically detect the highest API level and the
 latest version of build tools installed within that location.
 
 You can set the `ANDROID_HOME` variable to the location of the Android SDK. Find
-the path to the installed SDK using Android Studio's [SDK
-Manager](https://developer.android.com/studio/intro/update#sdk-manager).
+the path to the installed SDK using Android Studio's [SDK Manager](https://developer.android.com/studio/intro/update#sdk-manager).
 Assuming the SDK is installed to default locations, you can use the following
 commands to set the `ANDROID_HOME` variable:
 
@@ -170,16 +166,14 @@ them permanent, run the following commands:
 | Windows (PowerShell)     | `[System.Environment]::SetEnvironmentVariable('ANDROID_HOME', "$env:LOCALAPPDATA\Android\Sdk", [System.EnvironmentVariableTarget]::User)` |
 
 **Optional:** If you want to compile native code into your Android app, you
-also need to download the [Android
-NDK](https://developer.android.com/ndk/downloads/index.html)
+also need to download the [Android NDK](https://developer.android.com/ndk/downloads/index.html)
 and use `rules_android_ndk` by adding the following line to your `MODULE.bazel` file:
 
 ```python
 bazel_dep(name = "rules_android_ndk", version = "0.1.2")
 ```
 
-For more information, read [Using the Android Native Development Kit with
-Bazel](/versions/8.4.2/docs/android-ndk).
+For more information, read [Using the Android Native Development Kit with Bazel](/versions/8.4.2/docs/android-ndk).
 
 It's not necessary to set the API levels to the same value for the SDK and NDK.
 [This page](https://developer.android.com/ndk/guides/stable_apis.html)
@@ -221,8 +215,7 @@ files or other dependencies. Bazel provides two build rules,
 build an Android app.
 
 For this tutorial, you'll first use the
-`android_library` rule to tell Bazel to build an [Android library
-module](http://developer.android.com/tools/projects/index.html#LibraryProjects)
+`android_library` rule to tell Bazel to build an [Android library module](http://developer.android.com/tools/projects/index.html#LibraryProjects)
 from the app source code and resource files. You'll then use the
 `android_binary` rule to tell Bazel how to build the Android application package.
 
@@ -337,11 +330,9 @@ file:
 ### Run the app
 
 You can now deploy the app to a connected Android device or emulator from the
-command line using the [`bazel
-mobile-install`](/versions/8.4.2/docs/user-manual#mobile-install) command. This command uses
+command line using the [`bazel mobile-install`](/versions/8.4.2/docs/user-manual#mobile-install) command. This command uses
 the Android Debug Bridge (`adb`) to communicate with the device. You must set up
-your device to use `adb` following the instructions in [Android Debug
-Bridge](http://developer.android.com/tools/help/adb.html) before deployment. You
+your device to use `adb` following the instructions in [Android Debug Bridge](http://developer.android.com/tools/help/adb.html) before deployment. You
 can also choose to install the app on the Android emulator included in Android
 Studio. Make sure the emulator is running before executing the command below.
 
diff --git a/versions/8.4.2/start/cpp.mdx b/versions/8.4.2/start/cpp.mdx
index 435bf46d..a935c9f3 100644
--- a/versions/8.4.2/start/cpp.mdx
+++ b/versions/8.4.2/start/cpp.mdx
@@ -19,8 +19,7 @@ Estimated completion time: 30 minutes.
 ### Prerequisites {#prerequisites}
 
 Start by [installing Bazel](https://bazel.build/versions/8.4.2/install), if you haven't
-already. This tutorial uses Git for source control, so for best results [install
-Git](https://git-scm.com/book/en/v2/Getting-Started-Installing-Git) as well.
+already. This tutorial uses Git for source control, so for best results [install Git](https://git-scm.com/book/en/v2/Getting-Started-Installing-Git) as well.
 
 Next, retrieve the sample project from Bazel's GitHub repository by running the
 following in your command-line tool of choice:
@@ -63,9 +62,7 @@ examples
 ```
 
 There are three sets of files, each set representing a stage in this tutorial.
-In the first stage, you will build a single [target]
-(https://bazel.build/reference/glossary#target) residing in a single [package]
-(https://bazel.build/reference/glossary#package). In the second stage, you will
+In the first stage, you will build a single [target](https://bazel.build/reference/glossary#target) residing in a single [package](https://bazel.build/reference/glossary#package). In the second stage, you will
 build both a binary and a library from a single package. In the third and final
 stage, you will build a project with multiple packages and build it with
 multiple targets.
@@ -86,8 +83,7 @@ It also contains these significant files:
 *   The `MODULE.bazel` file, which identifies the directory and its contents as
     a Bazel workspace and lives at the root of the project's directory
     structure. It's also where you specify your external dependencies.
-*   One or more [`BUILD`
-    files](https://bazel.build/reference/glossary#build-file), which tell Bazel
+*   One or more [`BUILD` files](https://bazel.build/reference/glossary#build-file), which tell Bazel
     how to build different parts of the project. A directory within the
     workspace that contains a `BUILD` file is a
     [package](https://bazel.build/versions/8.4.2/reference/glossary#package). (More on packages
@@ -182,9 +178,7 @@ This results in a printed "`Hello world`" message.
 
 Here's the dependency graph of Stage 1:
 
-![Dependency graph for hello-world displays a single target with a single source
-file.](/versions/8.4.2/docs/images/cpp-tutorial-stage1.png "Dependency graph for hello-world
-displays a single target with a single source file.")
+![Dependency graph for hello-world displays a single target with a single source file.](/versions/8.4.2/docs/images/cpp-tutorial-stage1.png "Dependency graph for hello-world displays a single target with a single source file.")
 
 ### Summary: stage 1 {#summary-stage-1}
 
@@ -231,8 +225,7 @@ cc_binary(
 ```
 
 With this `BUILD` file, Bazel first builds the `hello-greet` library (using
-Bazel's built-in [`cc_library`
-rule](https://bazel.build/reference/be/c-cpp#cc_library)), then the
+Bazel's built-in [`cc_library` rule](https://bazel.build/reference/be/c-cpp#cc_library)), then the
 `hello-world` binary. The `deps` attribute in the `hello-world` target tells
 Bazel that the `hello-greet` library is required to build the `hello-world`
 binary.
@@ -272,10 +265,7 @@ recompiles that file.
 Looking at the dependency graph, you can see that `hello-world` depends on an
 extra input named `hello-greet`:
 
-![Dependency graph for `hello-world` displays dependency changes after
-modification to the file.](/versions/8.4.2/docs/images/cpp-tutorial-stage2.png "Dependency
-graph for `hello-world` displays dependency changes after modification to the
-file.")
+![Dependency graph for `hello-world` displays dependency changes after modification to the file.](/versions/8.4.2/docs/images/cpp-tutorial-stage2.png "Dependency graph for `hello-world` displays dependency changes after modification to the file.")
 
 ### Summary: stage 2 {#summary-stage-2}
 
@@ -343,11 +333,7 @@ in the `lib` package (hence the target label `//lib:hello-time`) - Bazel knows
 this through the `deps` attribute. You can see this reflected in the dependency
 graph:
 
-![Dependency graph for `hello-world` displays how the target in the main package
-depends on the target in the `lib`
-package.](/versions/8.4.2/docs/images/cpp-tutorial-stage3.png "Dependency graph for
-`hello-world` displays how the target in the main package depends on the target
-in the `lib` package.")
+![Dependency graph for `hello-world` displays how the target in the main package depends on the target in the `lib` package.](/versions/8.4.2/docs/images/cpp-tutorial-stage3.png "Dependency graph for `hello-world` displays how the target in the main package depends on the target in the `lib` package.")
 
 For the build to succeed, you make the `//lib:hello-time` target in `lib/BUILD`
 explicitly visible to targets in `main/BUILD` using the visibility attribute.
@@ -395,15 +381,11 @@ Bazel journey.
 You've now completed your first basic build with Bazel, but this is just the
 start. Here are some more resources to continue learning with Bazel:
 
-*   To keep focusing on C++, read about common [C++ build use
-    cases](https://bazel.build/tutorials/cpp-use-cases).
+*   To keep focusing on C++, read about common [C++ build use cases](https://bazel.build/tutorials/cpp-use-cases).
 *   To get started with building other applications with Bazel, see the
-    tutorials for [Java](https://bazel.build/versions/8.4.2/start/java), [Android
-    application](https://bazel.build/start/android-app), or [iOS
-    application](https://bazel.build/start/ios-app).
+    tutorials for [Java](https://bazel.build/versions/8.4.2/start/java), [Android application](https://bazel.build/start/android-app), or [iOS application](https://bazel.build/start/ios-app).
 *   To learn more about working with local and remote repositories, read about
     [external dependencies](https://bazel.build/versions/8.4.2/docs/external).
-*   To learn more about Bazel's other rules, see this [reference
-    guide](https://bazel.build/rules).
+*   To learn more about Bazel's other rules, see this [reference guide](https://bazel.build/rules).
 
 Happy building!
\ No newline at end of file
diff --git a/versions/8.4.2/start/java.mdx b/versions/8.4.2/start/java.mdx
index 2db06d40..f8929adc 100644
--- a/versions/8.4.2/start/java.mdx
+++ b/versions/8.4.2/start/java.mdx
@@ -241,8 +241,7 @@ recompiles that file.
 Looking at the dependency graph, you can see that `ProjectRunner` depends on the
 same inputs as it did before, but the structure of the build is different:
 
-![Dependency graph of the target 'ProjectRunner' after adding a dependency](
-/docs/images/tutorial_java_02.svg)
+![Dependency graph of the target 'ProjectRunner' after adding a dependency](/docs/images/tutorial_java_02.svg)
 
 You've now built the project with two targets. The `ProjectRunner` target builds
 one source files and depends on one other target (`:greeter`), which builds
diff --git a/versions/8.4.2/tutorials/ccp-toolchain-config.mdx b/versions/8.4.2/tutorials/ccp-toolchain-config.mdx
index 40952f56..1e76e546 100644
--- a/versions/8.4.2/tutorials/ccp-toolchain-config.mdx
+++ b/versions/8.4.2/tutorials/ccp-toolchain-config.mdx
@@ -29,8 +29,7 @@ uses `clang version 16`, which you can install on your system.
 
 Set up your build environment as follows:
 
-1.  If you have not already done so, [download and install Bazel
-    7.0.2](https://bazel.build/install) or later.
+1.  If you have not already done so, [download and install Bazel 7.0.2](https://bazel.build/install) or later.
 
 2.  Add an empty `MODULE.bazel` file at the root folder.
 
@@ -450,8 +449,7 @@ The key takeaways are:
 
 -   You need to specify a matching `platforms` flag in the command line for
     Bazel to resolve to the toolchain for the same constraint values on the
-    platform. The documentation holds more [information about language specific
-    configuration flags](/versions/8.4.2/concepts/platforms).
+    platform. The documentation holds more [information about language specific configuration flags](/versions/8.4.2/concepts/platforms).
 -   You have to let the toolchain know where the tools live. In this tutorial
     there is a simplified version where you access the tools from the system. If
     you are interested in a more self-contained approach, you can read about
@@ -464,5 +462,4 @@ The key takeaways are:
 
 ## Further reading {#further-reading}
 
-For more details, see [C++ toolchain
-configuration](/versions/8.4.2/docs/cc-toolchain-config-reference)
\ No newline at end of file
+For more details, see [C++ toolchain configuration](/versions/8.4.2/docs/cc-toolchain-config-reference)
\ No newline at end of file
diff --git a/versions/8.5.1/about/roadmap.mdx b/versions/8.5.1/about/roadmap.mdx
index c86f27da..d36c8eb9 100644
--- a/versions/8.5.1/about/roadmap.mdx
+++ b/versions/8.5.1/about/roadmap.mdx
@@ -13,8 +13,7 @@ projects.
 
 ## Bazel 8.0 Release
 
-We plan to bring Bazel 8.0 [long term support
-(LTS)](https://bazel.build/release/versioning) to you in late 2024.
+We plan to bring Bazel 8.0 [long term support (LTS)](https://bazel.build/release/versioning) to you in late 2024.
 The following features are planned to be implemented.
 
 ### Bzlmod: external dependency management system
@@ -29,8 +28,7 @@ support will be removed. Starting with Bazel 7.1, you can set
 `--noenable_workspace` to opt into the new behavior.
 
 Bazel 8.0 will contain a number of enhancements to
-[Bazel's external dependency management]
-(https://docs.google.com/document/d/1moQfNcEIttsk6vYanNKIy3ZuK53hQUFq1b1r0rmsYVg/edit#heading=h.lgyp7ubwxmjc)
+[Bazel's external dependency management](https://docs.google.com/document/d/1moQfNcEIttsk6vYanNKIy3ZuK53hQUFq1b1r0rmsYVg/edit#heading=h.lgyp7ubwxmjc)
 functionality, including:
 
 *   The new flag `--enable_workspace` can be set to `false` to completely
diff --git a/versions/8.5.1/basics/dependencies.mdx b/versions/8.5.1/basics/dependencies.mdx
index 82667e8d..06af7914 100644
--- a/versions/8.5.1/basics/dependencies.mdx
+++ b/versions/8.5.1/basics/dependencies.mdx
@@ -65,8 +65,7 @@ targets, we’ve made some strides in mitigating the downside by investing in
 tooling to automatically manage `BUILD` files to avoid burdening developers.
 
 Some of these tools, such as `buildifier` and `buildozer`, are available with
-Bazel in the [`buildtools`
-directory](https://github.com/bazelbuild/buildtools).
+Bazel in the [`buildtools` directory](https://github.com/bazelbuild/buildtools).
 
 ## Minimizing Module Visibility
 
@@ -106,8 +105,7 @@ transitive dependencies (Figure 1). Suppose target A depends on target B, which
 depends on a common library target C. Should target A be able to use classes
 defined in target C?
 
-[![Transitive
-dependencies](/versions/8.5.1/images/transitive-dependencies.png)](/versions/8.5.1/images/transitive-dependencies.png)
+[![Transitive dependencies](/versions/8.5.1/images/transitive-dependencies.png)](/versions/8.5.1/images/transitive-dependencies.png)
 
 **Figure 1**. Transitive dependencies
 
@@ -141,9 +139,7 @@ dependencies and adding them to a `BUILD` files without any developer
 intervention. But even without such tools, we’ve found the trade-off to be well
 worth it as the codebase scales: explicitly adding a dependency to `BUILD` file
 is a one-time cost, but dealing with implicit transitive dependencies can cause
-ongoing problems as long as the build target exists. Bazel [enforces strict
-transitive
-dependencies](https://blog.bazel.build/2017/06/28/sjd-unused_deps.html)
+ongoing problems as long as the build target exists. Bazel [enforces strict transitive dependencies](https://blog.bazel.build/2017/06/28/sjd-unused_deps.html)
 on Java code by default.
 
 ### External dependencies
@@ -192,8 +188,7 @@ so in theory there’s no reason that different versions of the same external
 dependency couldn’t both be declared in the build system under different names.
 That way, each target could choose which version of the dependency it wanted to
 use. This causes a lot of problems in practice, so Google enforces a strict
-[One-Version
-Rule](https://opensource.google/docs/thirdparty/oneversion/) for
+[One-Version Rule](https://opensource.google/docs/thirdparty/oneversion/) for
 all third-party dependencies in our codebase.
 
 The biggest problem with allowing multiple versions is the diamond dependency
@@ -232,8 +227,7 @@ Bazel did not use to automatically download transitive dependencies. It used to
 employ a `WORKSPACE` file that required all transitive dependencies to be
 listed, which led to a lot of pain when managing external dependencies. Bazel
 has since added support for automatic transitive external dependency management
-in the form of the `MODULE.bazel` file. See [external dependency
-overview](/versions/8.5.1/external/overview) for more details.
+in the form of the `MODULE.bazel` file. See [external dependency overview](/versions/8.5.1/external/overview) for more details.
 
 Yet again, the choice here is one between convenience and scalability. Small
 projects might prefer not having to worry about managing transitive dependencies
diff --git a/versions/8.5.1/community/roadmaps-configurability.mdx b/versions/8.5.1/community/roadmaps-configurability.mdx
index b516dd59..66fcb8ae 100644
--- a/versions/8.5.1/community/roadmaps-configurability.mdx
+++ b/versions/8.5.1/community/roadmaps-configurability.mdx
@@ -26,8 +26,7 @@ title: 'Bazel Configurability 2021 Roadmap'
 * Builds scale well, particularly w.r.t graph size and action caching.
 
 We also support
-[`cquery`](https://bazel.build/versions/8.5.1/query/cquery), [`Starlark
-configuration`](https://bazel.build/extending/config),
+[`cquery`](https://bazel.build/versions/8.5.1/query/cquery), [`Starlark configuration`](https://bazel.build/extending/config),
 and
 [`select()`](https://bazel.build/versions/8.5.1/docs/configurable-attributes).
 
@@ -41,15 +40,13 @@ interest of accurate expectations.
 ### Platforms
 
 

-Q3 2021**Android rules use the new [platforms
-API](https://bazel.build/concepts/platforms)**
+Q3 2021**Android rules use the new [platforms API](https://bazel.build/concepts/platforms)**
 IN PROGRESS ([#11749](https://github.com/bazelbuild/bazel/issues/11749))
 
 * This is our main priority for the beginning of 2021.
 
 

-Q3 2021**Builds support [multiple execution
-platforms](https://docs.google.com/document/d/1U9HzdDmtRnm244CaRM6JV-q2408mbNODAMewcGjnnbM/)**
+Q3 2021**Builds support [multiple execution platforms](https://docs.google.com/document/d/1U9HzdDmtRnm244CaRM6JV-q2408mbNODAMewcGjnnbM/)**
 IN PROGRESS ([#11748](https://github.com/bazelbuild/bazel/issues/11748))
 
 

diff --git a/versions/8.5.1/community/sig.mdx b/versions/8.5.1/community/sig.mdx
index a99f246a..b4643dd9 100644
--- a/versions/8.5.1/community/sig.mdx
+++ b/versions/8.5.1/community/sig.mdx
@@ -3,8 +3,7 @@ title: 'Bazel Special Interest Groups'
 ---
 
 Bazel hosts Special Interest Groups (SIGs) to focus collaboration on particular
-areas and to support communication and coordination between [Bazel owners,
-maintainers, and contributors](/versions/8.5.1/contribute/policy). This policy
+areas and to support communication and coordination between [Bazel owners, maintainers, and contributors](/versions/8.5.1/contribute/policy). This policy
 applies to [`bazelbuild`](http://github.com/bazelbuild).
 
 SIGs do their work in public. The ideal scope for a SIG covers a well-defined
diff --git a/versions/8.5.1/community/users.mdx b/versions/8.5.1/community/users.mdx
index 17cf6c64..63f0d026 100644
--- a/versions/8.5.1/community/users.mdx
+++ b/versions/8.5.1/community/users.mdx
@@ -304,11 +304,9 @@ safety systems_.
 Pigweed is an open-source solution for sustained, robust, and rapid embedded
 product development for large teams. Pigweed has shipped in millions of
 devices, including Google's suite of Pixel devices, Nest thermostats,
-[satellites](https://www.spinlaunch.com/), and [autonomous aerial
-drones](https://www.flyzipline.com/).
+[satellites](https://www.spinlaunch.com/), and [autonomous aerial drones](https://www.flyzipline.com/).
 
-Pigweed [uses Bazel as its primary build
-system](https://pigweed.dev/seed/0111-build-systems.html). The [Bazel for
+Pigweed [uses Bazel as its primary build system](https://pigweed.dev/seed/0111-build-systems.html). The [Bazel for
 Embedded][pw-bazel-great] blog post discusses why we think it's a great build
 system for embedded projects!
 
diff --git a/versions/8.5.1/concepts/build-files.mdx b/versions/8.5.1/concepts/build-files.mdx
index 303cfc71..6a9c6680 100644
--- a/versions/8.5.1/concepts/build-files.mdx
+++ b/versions/8.5.1/concepts/build-files.mdx
@@ -132,14 +132,3 @@ for anyone to create new rules.
     programming language. Libraries can depend on other libraries,
     and binaries and tests can depend on libraries, with the expected
     separate-compilation behavior.
-
-
-  
-    
-    
-  
-

-      Labels
-    
-      Dependencies
-    

diff --git a/versions/8.5.1/concepts/build-ref.mdx b/versions/8.5.1/concepts/build-ref.mdx
index 756f5fe1..6b7ac1c2 100644
--- a/versions/8.5.1/concepts/build-ref.mdx
+++ b/versions/8.5.1/concepts/build-ref.mdx
@@ -17,8 +17,7 @@ its root; such a boundary marker file could be `MODULE.bazel`, `REPO.bazel`, or
 in legacy contexts, `WORKSPACE` or `WORKSPACE.bazel`.
 
 The repo in which the current Bazel command is being run is called the _main
-repo_. Other, (external) repos are defined by _repo rules_; see [external
-dependencies overview](/versions/8.5.1/external/overview) for more information.
+repo_. Other, (external) repos are defined by _repo rules_; see [external dependencies overview](/versions/8.5.1/external/overview) for more information.
 
 ## Workspace {#workspace}
 
@@ -95,9 +94,4 @@ have three properties: the list of packages they contain, their name, and other
 package groups they include. The only allowed ways to refer to them are from the
 `visibility` attribute of rules or from the `default_visibility` attribute of
 the `package` function; they do not generate or consume files. For more
-information, refer to the [`package_group`
-documentation](/versions/8.5.1/reference/be/functions#package_group).
-
-
-  Labels
-
\ No newline at end of file
+information, refer to the [`package_group` documentation](/versions/8.5.1/reference/be/functions#package_group).
diff --git a/versions/8.5.1/concepts/dependencies.mdx b/versions/8.5.1/concepts/dependencies.mdx
index 2a46e91f..4220df4b 100644
--- a/versions/8.5.1/concepts/dependencies.mdx
+++ b/versions/8.5.1/concepts/dependencies.mdx
@@ -352,21 +352,3 @@ filegroup(
 ```
 
 You can then reference the label `my_data` as the data dependency in your test.
-
-
-  
-    
-    
-  
-

-      
-        BUILD files
-      
-    
-      
-        Visibility
-      
-    

-
diff --git a/versions/8.5.1/concepts/labels.mdx b/versions/8.5.1/concepts/labels.mdx
index 5f6bff90..c6a2d650 100644
--- a/versions/8.5.1/concepts/labels.mdx
+++ b/versions/8.5.1/concepts/labels.mdx
@@ -10,8 +10,7 @@ form looks like:
 ```
 
 The first part of the label is the repository name, `@@myrepo`. The double-`@`
-syntax signifies that this is a [*canonical* repo
-name](/versions/8.5.1/external/overview#canonical-repo-name), which is unique within
+syntax signifies that this is a [*canonical* repo name](/versions/8.5.1/external/overview#canonical-repo-name), which is unique within
 the workspace. Labels with canonical repo names unambiguously identify a target
 no matter which context they appear in.
 
@@ -239,14 +238,3 @@ the build.
 This directed acyclic graph over targets is called the _target graph_ or
 _build dependency graph_, and is the domain over which the
 [Bazel Query tool](/versions/8.5.1/query/guide) operates.
-
-
-  
-    
-    
-  
-

-      Targets
-    
-      BUILD files
-    

diff --git a/versions/8.5.1/concepts/platforms.mdx b/versions/8.5.1/concepts/platforms.mdx
index a9c45b09..b9f48e3e 100644
--- a/versions/8.5.1/concepts/platforms.mdx
+++ b/versions/8.5.1/concepts/platforms.mdx
@@ -77,8 +77,7 @@ To test your Android project with platforms, see
 for support.
 
 You can still use platform APIs with Apple builds (for example, when building
-with a mixture of Apple rules and pure C++) with [platform
-mappings](#platform-mappings).
+with a mixture of Apple rules and pure C++) with [platform mappings](#platform-mappings).
 
 ### Other languages {#other-languages}
 
@@ -241,8 +240,7 @@ sets `--cpu`, `--crossstool_top`, or other legacy flags, rules that read
 
 When migrating your project to platforms, you must either convert changes like
 `return { "//command_line_option:cpu": "arm" }` to `return {
-"//command_line_option:platforms": "//:my_arm_platform" }` or use [platform
-mappings](#platform-mappings) to support both styles during migration.
+"//command_line_option:platforms": "//:my_arm_platform" }` or use [platform mappings](#platform-mappings) to support both styles during migration.
 window.
 
 ## Migrating your rule set {#migrating-your-rule-set}
@@ -361,10 +359,8 @@ attributes declare a language's tools (like `compiler =
 this information to rules that need to build with these tools.
 
 Toolchains declare the `constraint_value`s of machines they can
-[target][target_compatible_with Attribute]
-(`target_compatible_with = ["@platforms//os:linux"]`) and machines their tools can
-[run on][exec_compatible_with Attribute]
-(`exec_compatible_with = ["@platforms//os:mac"]`).
+[target][target_compatible_with Attribute](`target_compatible_with = ["@platforms//os:linux"]`) and machines their tools can
+[run on][exec_compatible_with Attribute](`exec_compatible_with = ["@platforms//os:mac"]`).
 
 When building `$ bazel build //:myproject --platforms=//:myplatform`, Bazel
 automatically selects a toolchain that can run on the build machine and
diff --git a/versions/8.5.1/configure/attributes.mdx b/versions/8.5.1/configure/attributes.mdx
index 53c4d7b0..576b4735 100644
--- a/versions/8.5.1/configure/attributes.mdx
+++ b/versions/8.5.1/configure/attributes.mdx
@@ -2,8 +2,7 @@
 title: 'Configurable Build Attributes'
 ---
 
-**_Configurable attributes_**, commonly known as [`select()`](
-/reference/be/functions#select), is a Bazel feature that lets users toggle the values
+**_Configurable attributes_**, commonly known as [`select()`](/reference/be/functions#select), is a Bazel feature that lets users toggle the values
 of build rule attributes at the command line.
 
 This can be used, for example, for a multiplatform library that automatically
@@ -407,8 +406,7 @@ sh_library(
 )
 ```
 
-If you need a `select` to match when multiple conditions match, consider [AND
-chaining](#and-chaining).
+If you need a `select` to match when multiple conditions match, consider [AND chaining](#and-chaining).
 
 ## OR chaining {#or-chaining}
 
diff --git a/versions/8.5.1/configure/integrate-cpp.mdx b/versions/8.5.1/configure/integrate-cpp.mdx
index 0ea5a00c..f162a1bc 100644
--- a/versions/8.5.1/configure/integrate-cpp.mdx
+++ b/versions/8.5.1/configure/integrate-cpp.mdx
@@ -33,8 +33,7 @@ This is because when writing our own actions, they must behave
 consistently with the C++ toolchain - for example, passing C++ command line
 flags to a tool that invokes the C++ compiler behind the scenes.
 
-C++ rules use a special way of constructing command lines based on [feature
-configuration](/versions/8.5.1/docs/cc-toolchain-config-reference). To construct a command line,
+C++ rules use a special way of constructing command lines based on [feature configuration](/versions/8.5.1/docs/cc-toolchain-config-reference). To construct a command line,
 you need the following:
 
 * `features` and `action_configs` - these come from the `CcToolchainConfigInfo`
diff --git a/versions/8.5.1/configure/windows.mdx b/versions/8.5.1/configure/windows.mdx
index a370cca4..cb69752b 100644
--- a/versions/8.5.1/configure/windows.mdx
+++ b/versions/8.5.1/configure/windows.mdx
@@ -166,8 +166,7 @@ To build C++ targets with MSVC, you need:
         set BAZEL_VC=C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC
         ```
 
-*   The [Windows
-    SDK](https://developer.microsoft.com/en-us/windows/downloads/windows-10-sdk).
+*   The [Windows SDK](https://developer.microsoft.com/en-us/windows/downloads/windows-10-sdk).
 
     The Windows SDK contains header files and libraries you need when building
     Windows applications, including Bazel itself. By default, the latest Windows SDK installed will
@@ -186,8 +185,7 @@ To build C++ targets with MSVC, you need:
 
 If everything is set up, you can build a C++ target now!
 
-Try building a target from one of our [sample
-projects](https://github.com/bazelbuild/bazel/tree/master/examples):
+Try building a target from one of our [sample projects](https://github.com/bazelbuild/bazel/tree/master/examples):
 
 
 
 
-To build and use Dynamically Linked Libraries (DLL files), see [this
-example](https://github.com/bazelbuild/bazel/tree/master/examples/windows/dll).
+To build and use Dynamically Linked Libraries (DLL files), see [this example](https://github.com/bazelbuild/bazel/tree/master/examples/windows/dll).
 
 **Command Line Length Limit**: To prevent the
 [Windows command line length limit issue](https://github.com/bazelbuild/bazel/issues/5163),
@@ -292,8 +289,7 @@ On Windows, Bazel builds two output files for `java_binary` rules:
 *   a `.jar` file
 *   a `.exe` file that can set up the environment for the JVM and run the binary
 
-Try building a target from one of our [sample
-projects](https://github.com/bazelbuild/bazel/tree/master/examples):
+Try building a target from one of our [sample projects](https://github.com/bazelbuild/bazel/tree/master/examples):
 
 ```
 bazel build //examples/java-native/src/main/java/com/example/myproject:hello-world
@@ -315,8 +311,7 @@ On Windows, Bazel builds two output files for `py_binary` rules:
 You can either run the executable file (it has a `.exe` extension) or you can run
 Python with the self-extracting zip file as the argument.
 
-Try building a target from one of our [sample
-projects](https://github.com/bazelbuild/bazel/tree/master/examples):
+Try building a target from one of our [sample projects](https://github.com/bazelbuild/bazel/tree/master/examples):
 
 ```
 bazel build //examples/py_native:bin
@@ -325,5 +320,4 @@ python bazel-bin\examples\py_native\bin.zip
 ```
 
 If you are interested in details about how Bazel builds Python targets on
-Windows, check out this [design
-doc](https://github.com/bazelbuild/bazel-website/blob/master/designs/_posts/2016-09-05-build-python-on-windows.md).
+Windows, check out this [design doc](https://github.com/bazelbuild/bazel-website/blob/master/designs/_posts/2016-09-05-build-python-on-windows.md).
diff --git a/versions/8.5.1/contribute/codebase.mdx b/versions/8.5.1/contribute/codebase.mdx
index fac52984..cbfdecab 100644
--- a/versions/8.5.1/contribute/codebase.mdx
+++ b/versions/8.5.1/contribute/codebase.mdx
@@ -227,8 +227,7 @@ repository", the others are called "external repositories".
 A repository is marked by a repo boundary file (`MODULE.bazel`, `REPO.bazel`, or
 in legacy contexts, `WORKSPACE` or `WORKSPACE.bazel`) in its root directory. The
 main repo is the source tree where you're invoking Bazel from. External repos
-are defined in various ways; see [external dependencies
-overview](/versions/8.5.1/external/overview) for more information.
+are defined in various ways; see [external dependencies overview](/versions/8.5.1/external/overview) for more information.
 
 Code of external repositories is symlinked or downloaded under
 `$OUTPUT_BASE/external`.
diff --git a/versions/8.5.1/contribute/design-documents.mdx b/versions/8.5.1/contribute/design-documents.mdx
index d57b1633..db02814c 100644
--- a/versions/8.5.1/contribute/design-documents.mdx
+++ b/versions/8.5.1/contribute/design-documents.mdx
@@ -137,8 +137,7 @@ A lead reviewer should be a domain expert who is:
 *   Objective and capable of providing constructive feedback
 *   Available for the entire review period to lead the process
 
-Consider checking the contacts for various [team
-labels](/versions/8.5.1/contribute/maintainers-guide#team-labels).
+Consider checking the contacts for various [team labels](/versions/8.5.1/contribute/maintainers-guide#team-labels).
 
 ## Markdown vs Google Docs {#markdown-versus-gdocs}
 
@@ -168,12 +167,10 @@ Markdown for posterity.
 
 ### Using Google Docs {#gdocs}
 
-For consistency, use the [Bazel design doc template](
-https://docs.google.com/document/d/1cE5zrjrR40RXNg64XtRFewSv6FrLV6slGkkqxBumS1w/edit).
+For consistency, use the [Bazel design doc template](https://docs.google.com/document/d/1cE5zrjrR40RXNg64XtRFewSv6FrLV6slGkkqxBumS1w/edit).
 It includes the necessary header and creates visual
 consistency with other Bazel related documents. To do that, click on **File** >
-**Make a copy** or click this link to [make a copy of the design doc
-template](https://docs.google.com/document/d/1cE5zrjrR40RXNg64XtRFewSv6FrLV6slGkkqxBumS1w/copy).
+**Make a copy** or click this link to [make a copy of the design doc template](https://docs.google.com/document/d/1cE5zrjrR40RXNg64XtRFewSv6FrLV6slGkkqxBumS1w/copy).
 
 To make your document readable to the world, click on
 **Share** > **Advanced** > **Change…**, and
diff --git a/versions/8.5.1/contribute/index.mdx b/versions/8.5.1/contribute/index.mdx
index 997229f8..33b9ecfc 100644
--- a/versions/8.5.1/contribute/index.mdx
+++ b/versions/8.5.1/contribute/index.mdx
@@ -10,8 +10,7 @@ As you use Bazel, you may find things that can be improved.
 You can help by [reporting issues](http://github.com/bazelbuild/bazel/issues)
 when:
 
-   - Bazel crashes or you encounter a bug that can [only be resolved using `bazel
-     clean`](/versions/8.5.1/run/build#correct-incremental-rebuilds).
+   - Bazel crashes or you encounter a bug that can [only be resolved using `bazel clean`](/versions/8.5.1/run/build#correct-incremental-rebuilds).
    - The documentation is incomplete or unclear. You can also report issues
      from the page you are viewing by using the "Create issue"
      link at the top right corner of the page.
@@ -21,11 +20,9 @@ when:
 
 You can engage with the Bazel community by:
 
-   - Answering questions [on Stack Overflow](
-     https://stackoverflow.com/questions/tagged/bazel).
+   - Answering questions [on Stack Overflow](https://stackoverflow.com/questions/tagged/bazel).
    - Helping other users [on Slack](https://slack.bazel.build).
-   - Improving documentation or [contributing examples](
-     https://github.com/bazelbuild/examples).
+   - Improving documentation or [contributing examples](https://github.com/bazelbuild/examples).
    - Sharing your experience or your tips, for example, on a blog or social media.
 
 ## Contribute code {#contribute-code}
@@ -40,8 +37,7 @@ You can contribute to the Bazel ecosystem by:
    - Contributing to Bazel-related tools, for example, migration tools.
    - Improving Bazel integration with other IDEs and tools.
 
-Before making a change, [create a GitHub
-issue](http://github.com/bazelbuild/bazel/issues)
+Before making a change, [create a GitHub issue](http://github.com/bazelbuild/bazel/issues)
 or email [bazel-discuss@](mailto:bazel-discuss@googlegroups.com).
 
 The most helpful contributions fix bugs or add features (as opposed
diff --git a/versions/8.5.1/contribute/maintainers-guide.mdx b/versions/8.5.1/contribute/maintainers-guide.mdx
index 8ee9e37d..576973cd 100644
--- a/versions/8.5.1/contribute/maintainers-guide.mdx
+++ b/versions/8.5.1/contribute/maintainers-guide.mdx
@@ -4,8 +4,7 @@ title: 'Guide for Bazel Maintainers'
 
 This is a guide for the maintainers of the Bazel open source project.
 
-If you are looking to contribute to Bazel, please read [Contributing to
-Bazel](/versions/8.5.1/contribute) instead.
+If you are looking to contribute to Bazel, please read [Contributing to Bazel](/versions/8.5.1/contribute) instead.
 
 The objectives of this page are to:
 
@@ -37,8 +36,7 @@ repository.
 
 1. A user creates an issue by choosing one of the
 [issue templates](https://github.com/bazelbuild/bazel/issues/new/choose)
-   and it enters the pool of [unreviewed open
-   issues](https://github.com/bazelbuild/bazel/issues?utf8=%E2%9C%93&q=is%3Aissue+is%3Aopen+-label%3Auntriaged+-label%3Ap2+-label%3Ap1+-label%3Ap3+-label%3Ap4+-label%3Ateam-Starlark+-label%3Ateam-Rules-CPP+-label%3Ateam-Rules-Java+-label%3Ateam-XProduct+-label%3Ateam-Android+-label%3Ateam-Apple+-label%3Ateam-Configurability++-label%3Ateam-Performance+-label%3Ateam-Rules-Server+-label%3Ateam-Core+-label%3Ateam-Rules-Python+-label%3Ateam-Remote-Exec+-label%3Ateam-Local-Exec+-label%3Ateam-Bazel).
+   and it enters the pool of [unreviewed open issues](https://github.com/bazelbuild/bazel/issues?utf8=%E2%9C%93&q=is%3Aissue+is%3Aopen+-label%3Auntriaged+-label%3Ap2+-label%3Ap1+-label%3Ap3+-label%3Ap4+-label%3Ateam-Starlark+-label%3Ateam-Rules-CPP+-label%3Ateam-Rules-Java+-label%3Ateam-XProduct+-label%3Ateam-Android+-label%3Ateam-Apple+-label%3Ateam-Configurability++-label%3Ateam-Performance+-label%3Ateam-Rules-Server+-label%3Ateam-Core+-label%3Ateam-Rules-Python+-label%3Ateam-Remote-Exec+-label%3Ateam-Local-Exec+-label%3Ateam-Bazel).
 1. A member on the Developer Experience (DevEx) subteam rotation reviews the
    issue.
    1. If the issue is **not a bug** or a **feature request**, the DevEx member
@@ -58,21 +56,18 @@ repository.
 1. After reviewing the issue, the DevEx member decides if the issue requires
    immediate attention. If it does, they will assign the **P0**
    [priority](#priority) label and an owner from the list of team leads.
-1. The DevEx member assigns the `untriaged` label and exactly one [team
-   label](#team-labels) for routing.
+1. The DevEx member assigns the `untriaged` label and exactly one [team label](#team-labels) for routing.
 1. The DevEx member also assigns exactly one `type:` label, such as `type: bug`
    or `type: feature request`, according to the type of the issue.
 1. For platform-specific issues, the DevEx member assigns one `platform:` label,
    such as `platform:apple` for Mac-specific issues.
 1. If the issue is low priority and can be worked on by a new community
    contributor, the DevEx member assigns the `good first issue` label.
-At this stage, the issue enters the pool of [untriaged open
-issues](https://github.com/bazelbuild/bazel/issues?q=is%3Aissue+is%3Aopen+label%3Auntriaged).
+At this stage, the issue enters the pool of [untriaged open issues](https://github.com/bazelbuild/bazel/issues?q=is%3Aissue+is%3Aopen+label%3Auntriaged).
 
 Each Bazel subteam will triage all issues under labels they own, preferably on a
 weekly basis. The subteam will review and evaluate the issue and provide a
-resolution, if possible. If you are an owner of a team label, see [this section
-](#label-own) for more information.
+resolution, if possible. If you are an owner of a team label, see [this section](#label-own) for more information.
 
 When an issue is resolved, it can be closed.
 
@@ -111,8 +106,7 @@ preferably on a weekly basis.
      issue is either P0 or P1 we assume that is actively worked on.
 1. Remove the `untriaged` label.
 
-Note that you need to be in the [bazelbuild
-organization](https://github.com/bazelbuild) to be able to add or remove labels.
+Note that you need to be in the [bazelbuild organization](https://github.com/bazelbuild) to be able to add or remove labels.
 
 ### Pull Requests {#pull-requests}
 
@@ -138,8 +132,7 @@ issues.
   unusable, or a downed service that severely impacts development of the Bazel
   project. This includes regressions introduced in a new release that blocks a
   significant number of users, or an incompatible breaking change that was not
-  compliant to the [Breaking
-  Change](https://docs.google.com/document/d/1q5GGRxKrF_mnwtaPKI487P8OdDRh2nN7jX6U-FXnHL0/edit?pli=1#heading=h.ceof6vpkb3ik)
+  compliant to the [Breaking Change](https://docs.google.com/document/d/1q5GGRxKrF_mnwtaPKI487P8OdDRh2nN7jX6U-FXnHL0/edit?pli=1#heading=h.ceof6vpkb3ik)
   policy. No practical workaround exists.
 * [**P1**](https://github.com/bazelbuild/bazel/labels/P1) - Critical defect or
   feature which should be addressed in the next release, or a serious issue that
diff --git a/versions/8.5.1/contribute/naming.mdx b/versions/8.5.1/contribute/naming.mdx
index eb32e772..1edb560b 100644
--- a/versions/8.5.1/contribute/naming.mdx
+++ b/versions/8.5.1/contribute/naming.mdx
@@ -4,8 +4,7 @@ title: 'Naming a Bazel related project'
 
 First, thank you for contributing to the Bazel ecosystem! Please reach out to
 the Bazel community on the
-[bazel-discuss mailing list](https://groups.google.com/forum/#!forum/bazel-discuss
-) to share your project and its suggested name.
+[bazel-discuss mailing list](https://groups.google.com/forum/#!forum/bazel-discuss) to share your project and its suggested name.
 
 If you are building a Bazel related tool or sharing your Skylark rules,
 we recommend following these guidelines for the name of your project:
diff --git a/versions/8.5.1/contribute/patch-acceptance.mdx b/versions/8.5.1/contribute/patch-acceptance.mdx
index 6573de5d..9ea286cf 100644
--- a/versions/8.5.1/contribute/patch-acceptance.mdx
+++ b/versions/8.5.1/contribute/patch-acceptance.mdx
@@ -11,29 +11,24 @@ code base.
    need a corresponding issue for tracking.
 1. If you're proposing significant changes, write a
    [design document](/versions/8.5.1/contribute/design-documents).
-1. Ensure you've signed a [Contributor License
-   Agreement](https://cla.developers.google.com).
+1. Ensure you've signed a [Contributor License Agreement](https://cla.developers.google.com).
 1. Prepare a git commit that implements the feature. Don't forget to add tests
    and update the documentation. If your change has user-visible effects, please
    [add release notes](/versions/8.5.1/contribute/release-notes). If it is an incompatible change,
    read the [guide for rolling out breaking changes](/versions/8.5.1/contribute/breaking-changes).
 1. Create a pull request on
    [GitHub](https://github.com/bazelbuild/bazel/pulls). If you're new to GitHub,
-   read [about pull
-   requests](https://help.github.com/articles/about-pull-requests/). Note that
+   read [about pull requests](https://help.github.com/articles/about-pull-requests/). Note that
    we restrict permissions to create branches on the main Bazel repository, so
-   you will need to push your commit to [your own fork of the
-   repository](https://help.github.com/articles/working-with-forks/).
+   you will need to push your commit to [your own fork of the repository](https://help.github.com/articles/working-with-forks/).
 1. A Bazel maintainer should assign you a reviewer within two business days
    (excluding holidays in the USA and Germany). If you aren't assigned a
    reviewer in that time, you can request one by emailing
-   [bazel-discuss@googlegroups.com]
-   (mailto:bazel-discuss@googlegroups.com).
+   [bazel-discuss@googlegroups.com](mailto:bazel-discuss@googlegroups.com).
 1. Work with the reviewer to complete a code review. For each change, create a
    new commit and push it to make changes to your pull request. If the review
    takes too long (for instance, if the reviewer is unresponsive), send an email to
-   [bazel-discuss@googlegroups.com]
-   (mailto:bazel-discuss@googlegroups.com).
+   [bazel-discuss@googlegroups.com](mailto:bazel-discuss@googlegroups.com).
 1. After your review is complete, a Bazel maintainer applies your patch to
    Google's internal version control system.
 
diff --git a/versions/8.5.1/contribute/release-notes.mdx b/versions/8.5.1/contribute/release-notes.mdx
index 134915d3..4267d3d2 100644
--- a/versions/8.5.1/contribute/release-notes.mdx
+++ b/versions/8.5.1/contribute/release-notes.mdx
@@ -16,8 +16,7 @@ the release announcement.
 * If the change adds / removes / changes Bazel in a user-visible way, then it
   may be advantageous to mention it.
 
-If the change is significant, follow the [design document
-policy](/versions/8.5.1/contribute/design-documents) first.
+If the change is significant, follow the [design document policy](/versions/8.5.1/contribute/design-documents) first.
 
 ## Guidelines {#guidelines}
 
@@ -60,10 +59,8 @@ change is about.
 
 ## Process {#process}
 
-As part of the [release
-process](https://github.com/bazelbuild/continuous-integration/blob/master/docs/release-playbook.md),
-we collect the `RELNOTES` tags of every commit. We copy everything in a [Google
-Doc](https://docs.google.com/document/d/1wDvulLlj4NAlPZamdlEVFORks3YXJonCjyuQMUQEmB0/edit)
+As part of the [release process](https://github.com/bazelbuild/continuous-integration/blob/master/docs/release-playbook.md),
+we collect the `RELNOTES` tags of every commit. We copy everything in a [Google Doc](https://docs.google.com/document/d/1wDvulLlj4NAlPZamdlEVFORks3YXJonCjyuQMUQEmB0/edit)
 where we review, edit, and organize the notes.
 
 The release manager sends an email to the
@@ -71,6 +68,4 @@ The release manager sends an email to the
 Bazel contributors are invited to contribute to the document and make sure
 their changes are correctly reflected in the announcement.
 
-Later, the announcement will be submitted to the [Bazel
-blog](https://blog.bazel.build/), using the [bazel-blog
-repository](https://github.com/bazelbuild/bazel-blog/tree/master/_posts).
+Later, the announcement will be submitted to the [Bazel blog](https://blog.bazel.build/), using the [bazel-blog repository](https://github.com/bazelbuild/bazel-blog/tree/master/_posts).
diff --git a/versions/8.5.1/contribute/statemachine-guide.mdx b/versions/8.5.1/contribute/statemachine-guide.mdx
index 28a6ebf8..4d2a8263 100644
--- a/versions/8.5.1/contribute/statemachine-guide.mdx
+++ b/versions/8.5.1/contribute/statemachine-guide.mdx
@@ -172,8 +172,7 @@ instead, batches[^4] as many lookups as possible before doing so. The value
 might not be immediately available, for example, requiring a Skyframe restart,
 so the caller specifies what to do with the resulting value using a callback.
 
-The `StateMachine` processor ([`Driver`s and bridging to
-SkyFrame](#drivers-and-bridging)) guarantees that the value is available before
+The `StateMachine` processor ([`Driver`s and bridging to SkyFrame](#drivers-and-bridging)) guarantees that the value is available before
 the next state begins. An example follows.
 
 ```
@@ -284,8 +283,7 @@ and solutions to certain control flow problems.
 ### Sequential states
 
 This is the most common and straightforward control flow pattern. An example of
-this is shown in [Stateful computations inside
-`SkyKeyComputeState`](#stateful-computations).
+this is shown in [Stateful computations inside `SkyKeyComputeState`](#stateful-computations).
 
 ### Branching
 
@@ -545,8 +543,7 @@ section describes the propagation of data values.
 
 ### Implementing `Tasks.lookUp` callbacks
 
-There’s an example of implementing a `Tasks.lookUp` callback in [SkyValue
-lookups](#skyvalue-lookups). This section provides rationale and suggests
+There’s an example of implementing a `Tasks.lookUp` callback in [SkyValue lookups](#skyvalue-lookups). This section provides rationale and suggests
 approaches for handling multiple SkyValues.
 
 #### `Tasks.lookUp` callbacks {#tasks-lookup-callbacks}
@@ -710,8 +707,7 @@ class BarProducer implements StateMachine {
 Tip: It would be tempting to use the more concise signature void `accept(Bar
 value)` rather than the stuttery `void acceptBarValue(Bar value)` above.
 However, `Consumer` is a common overload of `void accept(Bar value)`,
-so doing this often leads to violations of the [Overloads: never
-split](https://google.github.io/styleguide/javaguide.html#s3.4.2-ordering-class-contents)
+so doing this often leads to violations of the [Overloads: never split](https://google.github.io/styleguide/javaguide.html#s3.4.2-ordering-class-contents)
 style-guide rule.
 
 Tip: Using a custom `ResultSink` type instead of a generic one from
@@ -774,14 +770,11 @@ pattern after accepting output from either a subtask or SkyValue lookup.
 Note that the implementation of `acceptBarError` eagerly forwards the result to
 the `Caller.ResultSink`, as required by [Error bubbling](#error-bubbling).
 
-Alternatives for top-level `StateMachine`s are described in [`Driver`s and
-bridging to SkyFunctions](#drivers-and-bridging).
+Alternatives for top-level `StateMachine`s are described in [`Driver`s and bridging to SkyFunctions](#drivers-and-bridging).
 
 ### Error handling {#error-handling}
 
-There's a couple of examples of error handling already in [`Tasks.lookUp`
-callbacks](#tasks-lookup-callbacks) and [Propagating values between
-`StateMachines`](#propagating-values). Exceptions, other than
+There's a couple of examples of error handling already in [`Tasks.lookUp` callbacks](#tasks-lookup-callbacks) and [Propagating values between `StateMachines`](#propagating-values). Exceptions, other than
 `InterruptedException` are not thrown, but instead passed around through
 callbacks as values. Such callbacks often have exclusive-or semantics, with
 exactly one of a value or error being passed.
@@ -1184,8 +1177,7 @@ states. Where it is possible, local stack `step` variables are young generation
 variables and efficiently GC'd.
 
 For `StateMachine` variables, breaking things down into subtasks and following
-the recommended pattern for [Propagating values between
-`StateMachine`s](#propagating-values) is also helpful. Observe that when
+the recommended pattern for [Propagating values between `StateMachine`s](#propagating-values) is also helpful. Observe that when
 following the pattern, only child `StateMachine`s have references to parent
 `StateMachine`s and not vice versa. This means that as children complete and
 update the parents using result callbacks, the children naturally fall out of
@@ -1207,8 +1199,7 @@ potentially reflecting local behavior.
 
 ### Concurrency tree diagram {#concurrency-tree-diagram}
 
-The following is an alternative view of the diagram in [Structured
-concurrency](#structured-concurrency) that better depicts the tree structure.
+The following is an alternative view of the diagram in [Structured concurrency](#structured-concurrency) that better depicts the tree structure.
 The blocks form a small tree.
 
 ![Structured Concurrency 3D](/versions/8.5.1/contribute/images/structured-concurrency-3d.svg)
diff --git a/versions/8.5.1/docs/android-instrumentation-test.mdx b/versions/8.5.1/docs/android-instrumentation-test.mdx
index c825e2f0..78be6bc9 100644
--- a/versions/8.5.1/docs/android-instrumentation-test.mdx
+++ b/versions/8.5.1/docs/android-instrumentation-test.mdx
@@ -2,8 +2,7 @@
 title: 'Android Instrumentation Tests'
 ---
 
-_If you're new to Bazel, start with the [Building Android with
-Bazel](/versions/8.5.1/start/android-app ) tutorial._
+_If you're new to Bazel, start with the [Building Android with Bazel](/versions/8.5.1/start/android-app) tutorial._
 
 ![Running Android instrumentation tests in parallel](/versions/8.5.1/docs/images/android_test.gif "Android instrumentation test")
 
@@ -18,9 +17,7 @@ emulators in a sandbox, ensuring that tests always run from a clean state. Each
 test gets an isolated emulator instance, allowing tests to run in parallel
 without passing states between them.
 
-For more information on Android instrumentation tests, check out the [Android
-developer
-documentation](https://developer.android.com/training/testing/unit-testing/instrumented-unit-tests.html).
+For more information on Android instrumentation tests, check out the [Android developer documentation](https://developer.android.com/training/testing/unit-testing/instrumented-unit-tests.html).
 
 Please file issues in the [GitHub issue tracker](https://github.com/bazelbuild/bazel/issues).
 
@@ -58,8 +55,7 @@ This results in output similar to the following:
 release 4.1.0
 ```
 
-- **KVM**. Bazel requires emulators to have [hardware
-  acceleration](https://developer.android.com/studio/run/emulator-acceleration.html#accel-check)
+- **KVM**. Bazel requires emulators to have [hardware acceleration](https://developer.android.com/studio/run/emulator-acceleration.html#accel-check)
   with KVM on Linux. You can follow these
   [installation instructions](https://help.ubuntu.com/community/KVM/Installation)
   for Ubuntu.
@@ -173,11 +169,9 @@ The main attributes of the rule `android_instrumentation_test` are:
 
 - `target_device`: An `android_device` target. This target describes the
   specifications of the Android emulator which Bazel uses to create, launch and
-  run the tests. See the [section on choosing an Android
-  device](#android-device-target) for more information.
+  run the tests. See the [section on choosing an Android device](#android-device-target) for more information.
 
-The test app's `AndroidManifest.xml` must include [an ``
-tag](https://developer.android.com/studio/test/#configure_instrumentation_manifest_settings).
+The test app's `AndroidManifest.xml` must include [an `` tag](https://developer.android.com/studio/test/#configure_instrumentation_manifest_settings).
 This tag must specify the attributes for the **package of the target app** and
 the **fully qualified class name of the instrumentation test runner**,
 `androidx.test.runner.AndroidJUnitRunner`.
@@ -214,8 +208,7 @@ repositories:
 - `@androidsdk`: The Android SDK. Download this through Android Studio.
 
 - `@android_test_support`: Hosts the test runner, emulator launcher, and
-  `android_device` targets. You can find the [latest release
-  here](https://github.com/android/android-test/releases).
+  `android_device` targets. You can find the [latest release here](https://github.com/android/android-test/releases).
 
 Enable these dependencies by adding the following lines to your `WORKSPACE`
 file:
@@ -240,8 +233,7 @@ android_test_repositories()
 
 ## Maven dependencies {#maven-dependencies}
 
-For managing dependencies on Maven artifacts from repositories, such as [Google
-Maven](https://maven.google.com) or [Maven Central](https://central.maven.org),
+For managing dependencies on Maven artifacts from repositories, such as [Google Maven](https://maven.google.com) or [Maven Central](https://central.maven.org),
 you should use a Maven resolver, such as
 [`rules_jvm_external`](https://github.com/bazelbuild/rules_jvm_external).
 
@@ -370,8 +362,7 @@ the device/emulator listed in `adb devices`.
 
 ## Sample projects {#sample-projects}
 
-If you are looking for canonical project samples, see the [Android testing
-samples](https://github.com/googlesamples/android-testing#experimental-bazel-support)
+If you are looking for canonical project samples, see the [Android testing samples](https://github.com/googlesamples/android-testing#experimental-bazel-support)
 for projects using Espresso and UIAutomator.
 
 ## Espresso setup {#espresso-setup}
@@ -560,8 +551,7 @@ API_LEVELS = [
 
 ## Known issues {#known-issues}
 
-- [Forked adb server processes are not terminated after
-  tests](https://github.com/bazelbuild/bazel/issues/4853)
+- [Forked adb server processes are not terminated after tests](https://github.com/bazelbuild/bazel/issues/4853)
 - While APK building works on all platforms (Linux, macOS, Windows), testing
   only works on Linux.
 - Even with `--config=local_adb`, users still need to specify
diff --git a/versions/8.5.1/docs/android-ndk.mdx b/versions/8.5.1/docs/android-ndk.mdx
index f0628538..e343b6af 100644
--- a/versions/8.5.1/docs/android-ndk.mdx
+++ b/versions/8.5.1/docs/android-ndk.mdx
@@ -2,8 +2,7 @@
 title: 'Using the Android Native Development Kit with Bazel'
 ---
 
-_If you're new to Bazel, please start with the [Building Android with
-Bazel](/versions/8.5.1/start/android-app ) tutorial._
+_If you're new to Bazel, please start with the [Building Android with Bazel](/versions/8.5.1/start/android-app) tutorial._
 
 ## Overview {#overview}
 
@@ -31,8 +30,7 @@ android_ndk_repository(
 )
 ```
 
-For more information about the `android_ndk_repository` rule, see the [Build
-Encyclopedia entry](/versions/8.5.1/reference/be/android#android_ndk_repository).
+For more information about the `android_ndk_repository` rule, see the [Build Encyclopedia entry](/versions/8.5.1/reference/be/android#android_ndk_repository).
 
 If you're using a recent version of the Android NDK (r22 and beyond), use the
 Starlark implementation of `android_ndk_repository`.
@@ -101,13 +99,11 @@ META-INF/MANIFEST.MF
 
 Bazel compiles all of the cc_libraries into a single shared object (`.so`) file,
 targeted for the `armeabi-v7a` ABI by default. To change this or build for
-multiple ABIs at the same time, see the section on [configuring the target
-ABI](#configuring-target-abi).
+multiple ABIs at the same time, see the section on [configuring the target ABI](#configuring-target-abi).
 
 ## Example setup {#example-setup}
 
-This example is available in the [Bazel examples
-repository](https://github.com/bazelbuild/examples/tree/master/android/ndk).
+This example is available in the [Bazel examples repository](https://github.com/bazelbuild/examples/tree/master/android/ndk).
 
 In the `BUILD.bazel` file, three targets are defined with the `android_binary`,
 `android_library`, and `cc_library` rules.
diff --git a/versions/8.5.1/docs/configurable-attributes.mdx b/versions/8.5.1/docs/configurable-attributes.mdx
index d69cc498..9c48de4b 100644
--- a/versions/8.5.1/docs/configurable-attributes.mdx
+++ b/versions/8.5.1/docs/configurable-attributes.mdx
@@ -2,8 +2,7 @@
 title: 'Configurable Build Attributes'
 ---
 
-**_Configurable attributes_**, commonly known as [`select()`](
-/reference/be/functions#select), is a Bazel feature that lets users toggle the values
+**_Configurable attributes_**, commonly known as [`select()`](/reference/be/functions#select), is a Bazel feature that lets users toggle the values
 of build rule attributes at the command line.
 
 This can be used, for example, for a multiplatform library that automatically
@@ -407,8 +406,7 @@ sh_library(
 )
 ```
 
-If you need a `select` to match when multiple conditions match, consider [AND
-chaining](#and-chaining).
+If you need a `select` to match when multiple conditions match, consider [AND chaining](#and-chaining).
 
 ## OR chaining {#or-chaining}
 
diff --git a/versions/8.5.1/extending/auto-exec-groups.mdx b/versions/8.5.1/extending/auto-exec-groups.mdx
index 9c3d0d33..d7cef622 100644
--- a/versions/8.5.1/extending/auto-exec-groups.mdx
+++ b/versions/8.5.1/extending/auto-exec-groups.mdx
@@ -27,9 +27,7 @@ doesn't detect that ([the error](#first-error-message) is raised), you can set
 
 If you need to use multiple toolchains on a single execution platform (an action
 uses executable or tools from two or more toolchains), you need to manually
-define [exec_groups][exec_groups] (check
-[When should I use a custom exec_group?][multiple_toolchains_exec_groups]
-section).
+define [exec_groups][exec_groups](check [When should I use a custom exec_group?][multiple_toolchains_exec_groups] section).
 
 ## History {#history}
 
@@ -42,8 +40,7 @@ my_rule = rule(
 )
 ```
 
-Rule `my_rule` registers two toolchain types. This means that the [Toolchain
-Resolution](https://bazel.build/extending/toolchains#toolchain-resolution) used
+Rule `my_rule` registers two toolchain types. This means that the [Toolchain Resolution](https://bazel.build/extending/toolchains#toolchain-resolution) used
 to find an execution platform which supports both toolchain types. The selected
 execution platform was used for each registered action inside the rule, unless
 specified differently with [exec_groups][exec_groups].
diff --git a/versions/8.5.1/extending/concepts.mdx b/versions/8.5.1/extending/concepts.mdx
index 8cb6fbff..d5e72977 100644
--- a/versions/8.5.1/extending/concepts.mdx
+++ b/versions/8.5.1/extending/concepts.mdx
@@ -20,16 +20,14 @@ Before learning the more advanced concepts, first:
 ## Macros and rules {#macros-and-rules}
 
 A macro is a function that instantiates rules. Macros come in two flavors:
-[symbolic macros](/versions/8.5.1/extending/macros) (new in Bazel 8) and [legacy
-macros](/versions/8.5.1/extending/legacy-macros). The two flavors of macros are defined
+[symbolic macros](/versions/8.5.1/extending/macros) (new in Bazel 8) and [legacy macros](/versions/8.5.1/extending/legacy-macros). The two flavors of macros are defined
 differently, but behave almost the same from the point of view of a user. A
 macro is useful when a `BUILD` file is getting too repetitive or too complex, as
 it lets you reuse some code. The function is evaluated as soon as the `BUILD`
 file is read. After the evaluation of the `BUILD` file, Bazel has little
 information about macros. If your macro generates a `genrule`, Bazel will
 behave *almost* as if you declared that `genrule` in the `BUILD` file. (The one
-exception is that targets declared in a symbolic macro have [special visibility
-semantics](/versions/8.5.1/extending/macros#visibility): a symbolic macro can hide its internal
+exception is that targets declared in a symbolic macro have [special visibility semantics](/versions/8.5.1/extending/macros#visibility): a symbolic macro can hide its internal
 targets from the rest of the package.)
 
 A [rule](/versions/8.5.1/extending/rules) is more powerful than a macro. It can access Bazel
@@ -76,8 +74,7 @@ they will not be executed.
 ## Creating extensions
 
 * [Create your first macro](/versions/8.5.1/rules/macro-tutorial) in order to reuse some code.
-  Then [learn more about macros](/versions/8.5.1/extending/macros) and [using them to create
-  "custom verbs"](/versions/8.5.1/rules/verbs-tutorial).
+  Then [learn more about macros](/versions/8.5.1/extending/macros) and [using them to create "custom verbs"](/versions/8.5.1/rules/verbs-tutorial).
 
 * [Follow the rules tutorial](/versions/8.5.1/rules/rules-tutorial) to get started with rules.
   Next, you can read more about the [rules concepts](/versions/8.5.1/extending/rules).
@@ -92,8 +89,7 @@ them within reach:
 ## Going further
 
 In addition to [macros](/versions/8.5.1/extending/macros) and [rules](/versions/8.5.1/extending/rules), you
-may want to write [aspects](/versions/8.5.1/extending/aspects) and [repository
-rules](/versions/8.5.1/extending/repo).
+may want to write [aspects](/versions/8.5.1/extending/aspects) and [repository rules](/versions/8.5.1/extending/repo).
 
 * Use [Buildifier](https://github.com/bazelbuild/buildtools)
   consistently to format and lint your code.
diff --git a/versions/8.5.1/extending/depsets.mdx b/versions/8.5.1/extending/depsets.mdx
index 9a2c217b..29551df0 100644
--- a/versions/8.5.1/extending/depsets.mdx
+++ b/versions/8.5.1/extending/depsets.mdx
@@ -111,8 +111,7 @@ need to ensure that if `B` depends on `A`, then `A.o` comes before `B.o` on the
 linker’s command line. Other tools might have the opposite requirement.
 
 Three traversal orders are supported: `postorder`, `preorder`, and
-`topological`. The first two work exactly like [tree
-traversals](https://en.wikipedia.org/wiki/Tree_traversal#Depth-first_search)
+`topological`. The first two work exactly like [tree traversals](https://en.wikipedia.org/wiki/Tree_traversal#Depth-first_search)
 except that they operate on DAGs and skip already visited nodes. The third order
 works as a topological sort from root to leaves, essentially the same as
 preorder except that shared children are listed only after all of their parents.
diff --git a/versions/8.5.1/extending/exec-groups.mdx b/versions/8.5.1/extending/exec-groups.mdx
index b7ad7a22..4d806724 100644
--- a/versions/8.5.1/extending/exec-groups.mdx
+++ b/versions/8.5.1/extending/exec-groups.mdx
@@ -63,8 +63,7 @@ test rules.
 
 In the rule implementation, you can declare that actions should be run on the
 execution platform of an execution group. You can do this by using the `exec_group`
-param of action generating methods, specifically [`ctx.actions.run`]
-(/rules/lib/builtins/actions#run) and
+param of action generating methods, specifically [`ctx.actions.run`](/rules/lib/builtins/actions#run) and
 [`ctx.actions.run_shell`](/versions/8.5.1/rules/lib/builtins/actions#run_shell).
 
 ```python
diff --git a/versions/8.5.1/extending/macros.mdx b/versions/8.5.1/extending/macros.mdx
index 2cb2b528..4a86aa2b 100644
--- a/versions/8.5.1/extending/macros.mdx
+++ b/versions/8.5.1/extending/macros.mdx
@@ -31,8 +31,7 @@ two required parameters: `attrs` and `implementation`.
 
 ### Attributes {#attributes}
 
-`attrs` accepts a dictionary of attribute name to [attribute
-types](https://bazel.build/rules/lib/toplevel/attr#members), which represents
+`attrs` accepts a dictionary of attribute name to [attribute types](https://bazel.build/rules/lib/toplevel/attr#members), which represents
 the arguments to the macro. Two common attributes – `name` and `visibility` –
 are implicitly added to all macros and are not included in the dictionary passed
 to `attrs`.
@@ -66,9 +65,7 @@ To support this pattern, a macro can *inherit attributes* from a rule or another
 macro by passing the [rule](https://bazel.build/versions/8.5.1/rules/lib/builtins/rule) or
 [macro symbol](https://bazel.build/versions/8.5.1/rules/lib/builtins/macro) to `macro()`'s
 `inherit_attrs` argument. (You can also use the special string `"common"`
-instead of a rule or macro symbol to inherit the [common attributes defined for
-all Starlark build
-rules](https://bazel.build/reference/be/common-definitions#common-attributes).)
+instead of a rule or macro symbol to inherit the [common attributes defined for all Starlark build rules](https://bazel.build/reference/be/common-definitions#common-attributes).)
 Only public attributes get inherited, and the attributes in the macro's own
 `attrs` dictionary override inherited attributes with the same name. You can
 also *remove* inherited attributes by using `None` as a value in the `attrs`
diff --git a/versions/8.5.1/extending/platforms.mdx b/versions/8.5.1/extending/platforms.mdx
index 68d302c7..c3f6748f 100644
--- a/versions/8.5.1/extending/platforms.mdx
+++ b/versions/8.5.1/extending/platforms.mdx
@@ -245,8 +245,7 @@ cc_library(
 
 You can use the
 [`IncompatiblePlatformProvider`](/versions/8.5.1/rules/lib/providers/IncompatiblePlatformProvider)
-in `bazel cquery`'s [Starlark output
-format](/versions/8.5.1/query/cquery#output-format-definition) to distinguish
+in `bazel cquery`'s [Starlark output format](/versions/8.5.1/query/cquery#output-format-definition) to distinguish
 incompatible targets from compatible ones.
 
 This can be used to filter out incompatible targets. The example below will
@@ -266,5 +265,4 @@ $ bazel cquery //... --output=starlark --starlark:file=example.cquery
 
 ### Known Issues
 
-Incompatible targets [ignore visibility
-restrictions](https://github.com/bazelbuild/bazel/issues/16044).
+Incompatible targets [ignore visibility restrictions](https://github.com/bazelbuild/bazel/issues/16044).
diff --git a/versions/8.5.1/extending/repo.mdx b/versions/8.5.1/extending/repo.mdx
index e5771852..c216da30 100644
--- a/versions/8.5.1/extending/repo.mdx
+++ b/versions/8.5.1/extending/repo.mdx
@@ -74,8 +74,7 @@ specified.
 
 The input parameter `repository_ctx` can be used to access attribute values, and
 non-hermetic functions (finding a binary, executing a binary, creating a file in
-the repository or downloading a file from the Internet). See [the API
-docs](/versions/8.5.1/rules/lib/builtins/repository_ctx) for more context. Example:
+the repository or downloading a file from the Internet). See [the API docs](/versions/8.5.1/rules/lib/builtins/repository_ctx) for more context. Example:
 
 ```python
 def _impl(repository_ctx):
@@ -144,8 +143,7 @@ definition has the `configure` attribute set, use `bazel fetch --force
 
 ## Examples
 
--   [C++ auto-configured
-    toolchain](https://cs.opensource.google/bazel/bazel/+/master:tools/cpp/cc_configure.bzl;drc=644b7d41748e09eff9e47cbab2be2263bb71f29a;l=176):
+-   [C++ auto-configured toolchain](https://cs.opensource.google/bazel/bazel/+/master:tools/cpp/cc_configure.bzl;drc=644b7d41748e09eff9e47cbab2be2263bb71f29a;l=176):
     it uses a repo rule to automatically create the C++ configuration files for
     Bazel by looking for the local C++ compiler, the environment and the flags
     the C++ compiler supports.
diff --git a/versions/8.5.1/extending/rules.mdx b/versions/8.5.1/extending/rules.mdx
index 022899d1..6d103fe9 100644
--- a/versions/8.5.1/extending/rules.mdx
+++ b/versions/8.5.1/extending/rules.mdx
@@ -449,8 +449,7 @@ def _example_library_impl(ctx):
 
 If `DefaultInfo` is not returned by a rule implementation or the `files`
 parameter is not specified, `DefaultInfo.files` defaults to all
-*predeclared outputs* (generally, those created by [output
-attributes](#output_attributes)).
+*predeclared outputs* (generally, those created by [output attributes](#output_attributes)).
 
 Rules that perform actions should provide default outputs, even if those outputs
 are not expected to be directly used. Actions that are not in the graph of the
@@ -995,8 +994,7 @@ By using `configuration_field`, the dependency on the Java LCOV merger tool can
 be avoided as long as coverage is not requested.
 
 When the test is run, it should emit coverage information in the form of one or
-more [LCOV files]
-(https://manpages.debian.org/unstable/lcov/geninfo.1.en.html#TRACEFILE_FORMAT)
+more [LCOV files](https://manpages.debian.org/unstable/lcov/geninfo.1.en.html#TRACEFILE_FORMAT)
 with unique names into the directory specified by the `COVERAGE_DIR` environment
 variable. Bazel will then merge these files into a single LCOV file using the
 `_lcov_merger` tool. If present, it will also collect C/C++ coverage using the
diff --git a/versions/8.5.1/extending/toolchains.mdx b/versions/8.5.1/extending/toolchains.mdx
index 6da4aba3..b4fe4a6f 100644
--- a/versions/8.5.1/extending/toolchains.mdx
+++ b/versions/8.5.1/extending/toolchains.mdx
@@ -523,8 +523,7 @@ The set of available toolchains, in priority order, is created from
   4. Toolchains registered in the "WORKSPACE suffix"; this is only used by
      certain native rules bundled with the Bazel installation.
 
-**NOTE:** [Pseudo-targets like `:all`, `:*`, and
-`/...`](/versions/8.5.1/run/build#specifying-build-targets) are ordered by Bazel's package
+**NOTE:** [Pseudo-targets like `:all`, `:*`, and `/...`](/versions/8.5.1/run/build#specifying-build-targets) are ordered by Bazel's package
 loading mechanism, which uses a lexicographic ordering.
 
 The resolution steps are as follows.
diff --git a/versions/8.5.1/external/advanced.mdx b/versions/8.5.1/external/advanced.mdx
index 3d9cedf9..a9d9674a 100644
--- a/versions/8.5.1/external/advanced.mdx
+++ b/versions/8.5.1/external/advanced.mdx
@@ -4,10 +4,8 @@ title: 'Advanced topics on external dependencies'
 
 ## Shadowing dependencies in WORKSPACE
 
-Note: This section applies to the [WORKSPACE
-system](/versions/8.5.1/external/overview#workspace-system) only. For
-[Bzlmod](/versions/8.5.1/external/overview#bzlmod), use a [multiple-version
-override](/versions/8.5.1/external/module#multiple-version_override).
+Note: This section applies to the [WORKSPACE system](/versions/8.5.1/external/overview#workspace-system) only. For
+[Bzlmod](/versions/8.5.1/external/overview#bzlmod), use a [multiple-version override](/versions/8.5.1/external/module#multiple-version_override).
 
 Whenever possible, have a single version policy in your project, which is
 required for dependencies that you compile against and end up in your final
@@ -128,29 +126,24 @@ preferring IPv4 if enabled. In some situations, for example when the IPv4
 network cannot resolve/reach external addresses, this can cause `Network
 unreachable` exceptions and build failures. In these cases, you can override
 Bazel's behavior to prefer IPv6 by using the
-[`java.net.preferIPv6Addresses=true` system
-property](https://docs.oracle.com/javase/8/docs/api/java/net/doc-files/net-properties.html).
+[`java.net.preferIPv6Addresses=true` system property](https://docs.oracle.com/javase/8/docs/api/java/net/doc-files/net-properties.html).
 Specifically:
 
-*   Use `--host_jvm_args=-Djava.net.preferIPv6Addresses=true` [startup
-    option](/versions/8.5.1/docs/user-manual#startup-options), for example by adding the
+*   Use `--host_jvm_args=-Djava.net.preferIPv6Addresses=true` [startup option](/versions/8.5.1/docs/user-manual#startup-options), for example by adding the
     following line in your [`.bazelrc` file](/versions/8.5.1/run/bazelrc):
 
     `startup --host_jvm_args=-Djava.net.preferIPv6Addresses=true`
 
 *   When running Java build targets that need to connect to the internet (such
     as for integration tests), use the
-    `--jvmopt=-Djava.net.preferIPv6Addresses=true` [tool
-    flag](/versions/8.5.1/docs/user-manual#jvmopt). For example, include in your [`.bazelrc`
-    file](/versions/8.5.1/run/bazelrc):
+    `--jvmopt=-Djava.net.preferIPv6Addresses=true` [tool flag](/versions/8.5.1/docs/user-manual#jvmopt). For example, include in your [`.bazelrc` file](/versions/8.5.1/run/bazelrc):
 
     `build --jvmopt=-Djava.net.preferIPv6Addresses`
 
 *   If you are using [`rules_jvm_external`](https://github.com/bazelbuild/rules_jvm_external)
     for dependency version resolution, also add
     `-Djava.net.preferIPv6Addresses=true` to the `COURSIER_OPTS` environment
-    variable to [provide JVM options for
-    Coursier](https://github.com/bazelbuild/rules_jvm_external#provide-jvm-options-for-coursier-with-coursier_opts).
+    variable to [provide JVM options for Coursier](https://github.com/bazelbuild/rules_jvm_external#provide-jvm-options-for-coursier-with-coursier_opts).
 
 ## Offline builds
 
@@ -167,15 +160,12 @@ fetch a file with [`ctx.download`](/versions/8.5.1/rules/lib/builtins/repository
 providing a hash sum of the file needed, Bazel looks for a file matching the
 basename of the first URL, and uses the local copy if the hash matches.
 
-Bazel itself uses this technique to bootstrap offline from the [distribution
-artifact](https://github.com/bazelbuild/bazel-website/blob/master/designs/_posts/2016-10-11-distribution-artifact.md).
-It does so by [collecting all the needed external
-dependencies](https://github.com/bazelbuild/bazel/blob/5cfa0303d6ac3b5bd031ff60272ce80a704af8c2/WORKSPACE#L116)
+Bazel itself uses this technique to bootstrap offline from the [distribution artifact](https://github.com/bazelbuild/bazel-website/blob/master/designs/_posts/2016-10-11-distribution-artifact.md).
+It does so by [collecting all the needed external dependencies](https://github.com/bazelbuild/bazel/blob/5cfa0303d6ac3b5bd031ff60272ce80a704af8c2/WORKSPACE#L116)
 in an internal
 [`distdir_tar`](https://github.com/bazelbuild/bazel/blob/5cfa0303d6ac3b5bd031ff60272ce80a704af8c2/distdir.bzl#L44).
 
 Bazel allows execution of arbitrary commands in repository rules without knowing
 if they call out to the network, and so cannot enforce fully offline builds. To
 test if a build works correctly offline, manually block off the network (as
-Bazel does in its [bootstrap
-test](https://cs.opensource.google/bazel/bazel/+/master:src/test/shell/bazel/BUILD;l=1073;drc=88c426e73cc0eb0a41c0d7995e36acd94e7c9a48)).
\ No newline at end of file
+Bazel does in its [bootstrap test](https://cs.opensource.google/bazel/bazel/+/master:src/test/shell/bazel/BUILD;l=1073;drc=88c426e73cc0eb0a41c0d7995e36acd94e7c9a48)).
\ No newline at end of file
diff --git a/versions/8.5.1/external/migration.mdx b/versions/8.5.1/external/migration.mdx
index e7f6f9eb..d86238b8 100644
--- a/versions/8.5.1/external/migration.mdx
+++ b/versions/8.5.1/external/migration.mdx
@@ -2,8 +2,7 @@
 title: 'Bzlmod Migration Guide'
 ---
 
-Due to the [shortcomings of
-WORKSPACE](/versions/8.5.1/external/overview#workspace-shortcomings), Bzlmod is going to
+Due to the [shortcomings of WORKSPACE](/versions/8.5.1/external/overview#workspace-shortcomings), Bzlmod is going to
 replace the legacy WORKSPACE system. The WORKSPACE file will be disabled by
 default in Bazel 8 (late 2024) and will be removed in Bazel 9 (late 2025).
 This guide helps you migrate your project to Bzlmod and drop WORKSPACE for
@@ -117,9 +116,7 @@ Bazel module when it also adopts Bzlmod.
 
 *   **Bzlmod**
 
-    With Bzlmod, as long as the your dependency is available in [Bazel Central
-    Registry](https://registry.bazel.build) or your custom [Bazel
-    registry](/versions/8.5.1/external/registry), you can simply depend on it with a
+    With Bzlmod, as long as the your dependency is available in [Bazel Central Registry](https://registry.bazel.build) or your custom [Bazel registry](/versions/8.5.1/external/registry), you can simply depend on it with a
     [`bazel_dep`](/versions/8.5.1/rules/lib/globals/module#bazel_dep) directive.
 
     ```python
@@ -150,8 +147,7 @@ repository.
 
 If your dependency is not a Bazel project or not yet available in any Bazel
 registry, you can introduce it using
-[`use_repo_rule`](/versions/8.5.1/external/module#use_repo_rule) or [module
-extensions](/versions/8.5.1/external/extension).
+[`use_repo_rule`](/versions/8.5.1/external/module#use_repo_rule) or [module extensions](/versions/8.5.1/external/extension).
 
 *   **WORKSPACE**
 
@@ -604,8 +600,7 @@ macros.
 Fortunately, the flag
 [`--experimental_repository_resolved_file`][resolved_file_flag]
 can help. This flag essentially generates a "lock file" of all fetched external
-dependencies in your last Bazel command. You can find more details in this [blog
-post](https://blog.bazel.build/2018/07/09/bazel-sync-and-resolved-file.html).
+dependencies in your last Bazel command. You can find more details in this [blog post](https://blog.bazel.build/2018/07/09/bazel-sync-and-resolved-file.html).
 
 [resolved_file_flag]: /reference/command-line-reference#flag--experimental_repository_resolved_file
 
@@ -646,11 +641,9 @@ You may also know `bazel query` can be used for inspecting repository rules with
 bazel query --output=build //external:
 ```
 
-While it is more convenient and much faster, [bazel query can lie about
-external dependency version](https://github.com/bazelbuild/bazel/issues/12947),
+While it is more convenient and much faster, [bazel query can lie about external dependency version](https://github.com/bazelbuild/bazel/issues/12947),
 so be careful using it! Querying and inspecting external
-dependencies with Bzlmod is going to achieved by a [new
-subcommand](https://github.com/bazelbuild/bazel/issues/15365).
+dependencies with Bzlmod is going to achieved by a [new subcommand](https://github.com/bazelbuild/bazel/issues/15365).
 
 #### Built-in default dependencies {#builtin-default-deps}
 
@@ -697,8 +690,7 @@ Using the WORKSPACE.bzlmod file can make the migration easier because:
 #### Repository visibility {#repository-visibility}
 
 Bzlmod is able to control which other repositories are visible from a given
-repository, check [repository names and strict
-deps](/versions/8.5.1/external/module#repository_names_and_strict_deps) for more details.
+repository, check [repository names and strict deps](/versions/8.5.1/external/module#repository_names_and_strict_deps) for more details.
 
 Here is a summary of repository visibilities from different types of
 repositories when also taking WORKSPACE into consideration.
@@ -711,8 +703,7 @@ repositories when also taking WORKSPACE into consideration.
 | WORKSPACE Repos | All visible | Not visible | Not visible | All visible |
 
 Note: For the root module, if a repository `@foo` is defined in WORKSPACE and
-`@foo` is also used as an [apparent repository
-name](/versions/8.5.1/external/overview#apparent-repo-name) in MODULE.bazel, then `@foo`
+`@foo` is also used as an [apparent repository name](/versions/8.5.1/external/overview#apparent-repo-name) in MODULE.bazel, then `@foo`
 refers to the one introduced in MODULE.bazel.
 
 Note: For a module extension generated repository `@bar`, if `@foo` is used as
@@ -787,9 +778,7 @@ the project. Take note of a few things when creating the source archive:
     GitHub isn't going to guarantee the checksum of source archives generated on
     demand. In short, URLs in the form of
     `https://github.com///releases/download/...` is considered stable
-    while `https://github.com///archive/...` is not. Check [GitHub
-    Archive Checksum
-    Outage](https://blog.bazel.build/2023/02/15/github-archive-checksum.html)
+    while `https://github.com///archive/...` is not. Check [GitHub Archive Checksum Outage](https://blog.bazel.build/2023/02/15/github-archive-checksum.html)
     for more context.
 
 *   **Make sure the source tree follows the layout of the original repository.**
@@ -818,8 +807,7 @@ Pull Request.
 
 [bcr_contrib_guide]: https://github.com/bazelbuild/bazel-central-registry/tree/main/docs#contribute-a-bazel-module
 
-It is **highly recommended** to set up the [Publish to
-BCR](https://github.com/bazel-contrib/publish-to-bcr) GitHub App for your
+It is **highly recommended** to set up the [Publish to BCR](https://github.com/bazel-contrib/publish-to-bcr) GitHub App for your
 repository to automate the process of submitting your module to the BCR.
 
 ## Best practices {#best-practices}
diff --git a/versions/8.5.1/external/mod-command.mdx b/versions/8.5.1/external/mod-command.mdx
index a0412220..7c5db280 100644
--- a/versions/8.5.1/external/mod-command.mdx
+++ b/versions/8.5.1/external/mod-command.mdx
@@ -62,11 +62,9 @@ The available subcommands and their respective required arguments are:
 
 *   ``: All present versions of the module ``.
 
-*   `@`: The repo with the given [apparent
-    name](overview#apparent-repo-name) in the context of the `--base_module`.
+*   `@`: The repo with the given [apparent name](overview#apparent-repo-name) in the context of the `--base_module`.
 
-*   `@@`: The repo with the given [canonical
-    name](overview#canonical-repo-name).
+*   `@@`: The repo with the given [canonical name](overview#canonical-repo-name).
 
 In a context requiring specifying modules, ``s referring to repos that
 correspond to modules (as opposed to extension-generated repos) can also be
@@ -88,8 +86,7 @@ The following options only affect the subcommands that print graphs (`graph`,
     information about the version resolution of each module. If the module
     version changed during resolution, show either which version replaced it or
     what was the original version, the reason it was replaced, and which modules
-    requested the new version if the reason was [Minimal Version
-    Selection](module#version-selection).
+    requested the new version if the reason was [Minimal Version Selection](module#version-selection).
 
 *   `--include_unused` *default: "false"*: Include in the output graph the
     modules which were originally present in the dependency graph, but became
diff --git a/versions/8.5.1/external/module.mdx b/versions/8.5.1/external/module.mdx
index 4d8e5dcf..b947b7ce 100644
--- a/versions/8.5.1/external/module.mdx
+++ b/versions/8.5.1/external/module.mdx
@@ -122,8 +122,7 @@ serves multiple purposes:
     version, regardless of which versions of the dependency are requested in the
     dependency graph.
 *   With the `registry` attribute, you can force this dependency to come from a
-    specific registry, instead of following the normal [registry
-    selection](/versions/8.5.1/external/registry#selecting_registries) process.
+    specific registry, instead of following the normal [registry selection](/versions/8.5.1/external/registry#selecting_registries) process.
 *   With the `patch*` attributes, you can specify a set of patches to apply to
     the downloaded module.
 
@@ -176,13 +175,11 @@ With `bazel_dep`, you can define repos that represent other Bazel modules.
 Sometimes there is a need to define a repo that does _not_ represent a Bazel
 module; for example, one that contains a plain JSON file to be read as data.
 
-In this case, you could use the [`use_repo_rule`
-directive](/versions/8.5.1/rules/lib/globals/module#use_repo_rule) to directly define a repo
+In this case, you could use the [`use_repo_rule` directive](/versions/8.5.1/rules/lib/globals/module#use_repo_rule) to directly define a repo
 by invoking a repo rule. This repo will only be visible to the module it's
 defined in.
 
-Under the hood, this is implemented using the same mechanism as [module
-extensions](/versions/8.5.1/external/extension), which lets you define repos with more
+Under the hood, this is implemented using the same mechanism as [module extensions](/versions/8.5.1/external/extension), which lets you define repos with more
 flexibility.
 
 ## Repository names and strict deps
diff --git a/versions/8.5.1/external/overview.mdx b/versions/8.5.1/external/overview.mdx
index 6d6ae6ea..e5d486a0 100644
--- a/versions/8.5.1/external/overview.mdx
+++ b/versions/8.5.1/external/overview.mdx
@@ -128,8 +128,7 @@ for all build targets inside the repo.
 
 The syntax of a `REPO.bazel` file is similar to `BUILD` files, except that no
 `load` statements are supported, and only a single function, `repo()`, is
-available. `repo()` takes the same arguments as the [`package()`
-function](/versions/8.5.1/reference/be/functions#package) in `BUILD` files; whereas `package()`
+available. `repo()` takes the same arguments as the [`package()` function](/versions/8.5.1/reference/be/functions#package) in `BUILD` files; whereas `package()`
 specifies common attributes for all build targets inside the package, `repo()`
 analogously does so for all build targets inside the repo.
 
@@ -163,8 +162,7 @@ bazel_dep(name = "protobuf", version = "3.19.0")
 ```
 
 A module must only list its direct dependencies, which Bzlmod looks up in a
-[Bazel registry](/versions/8.5.1/external/registry) — by default, the [Bazel Central
-Registry](https://bcr.bazel.build/). The registry provides the
+[Bazel registry](/versions/8.5.1/external/registry) — by default, the [Bazel Central Registry](https://bcr.bazel.build/). The registry provides the
 dependencies' `MODULE.bazel` files, which allows Bazel to discover the entire
 transitive dependency graph before performing version resolution.
 
@@ -235,5 +233,4 @@ many pain points, including:
         `B` and `C`; `B` and `C` both depend on different versions of `D`).
 
 Due to the shortcomings of WORKSPACE, Bzlmod is going to replace the legacy
-WORKSPACE system in future Bazel releases. Please read the [Bzlmod migration
-guide](/versions/8.5.1/external/migration) on how to migrate to Bzlmod.
+WORKSPACE system in future Bazel releases. Please read the [Bzlmod migration guide](/versions/8.5.1/external/migration) on how to migrate to Bzlmod.
diff --git a/versions/8.5.1/external/registry.mdx b/versions/8.5.1/external/registry.mdx
index 74d55237..8ec76e21 100644
--- a/versions/8.5.1/external/registry.mdx
+++ b/versions/8.5.1/external/registry.mdx
@@ -42,8 +42,7 @@ An index registry must follow the format below:
             project
         *   `versions`: A list of all the versions of this module to be found in
             this registry
-        *   `yanked_versions`: A map of [*yanked*
-            versions](/versions/8.5.1/external/module#yanked_versions) of this module. The keys
+        *   `yanked_versions`: A map of [*yanked* versions](/versions/8.5.1/external/module#yanked_versions) of this module. The keys
             should be versions to yank and the values should be descriptions of
             why the version is yanked, ideally containing a link to more
             information
@@ -56,8 +55,7 @@ An index registry must follow the format below:
             *   `url`: The URL of the source archive
             *   `mirror_urls`: A list of string, the mirror URLs of the source archive.
                 The URLs are tried in order after `url` as backups.
-            *   `integrity`: The [Subresource
-                Integrity](https://w3c.github.io/webappsec-subresource-integrity/#integrity-metadata-description)
+            *   `integrity`: The [Subresource Integrity](https://w3c.github.io/webappsec-subresource-integrity/#integrity-metadata-description)
                 checksum of the archive
             *   `strip_prefix`: A directory prefix to strip when extracting the
                 source archive
@@ -105,8 +103,7 @@ You can browse its contents using the web frontend at
 https://registry.bazel.build/.
 
 The Bazel community maintains the BCR, and contributors are welcome to submit
-pull requests. See the [BCR contribution
-guidelines](https://github.com/bazelbuild/bazel-central-registry/blob/main/docs/README.md).
+pull requests. See the [BCR contribution guidelines](https://github.com/bazelbuild/bazel-central-registry/blob/main/docs/README.md).
 
 In addition to following the format of a normal index registry, the BCR requires
 a `presubmit.yml` file for each module version
diff --git a/versions/8.5.1/external/vendor.mdx b/versions/8.5.1/external/vendor.mdx
index b2f569b2..4ce92ef1 100644
--- a/versions/8.5.1/external/vendor.mdx
+++ b/versions/8.5.1/external/vendor.mdx
@@ -23,9 +23,7 @@ absolute path.
 ## Vendor a specific external repository {#vendor-specific-repository}
 
 You can use the `vendor` command with the `--repo` flag to specify which repo
-to vendor, it accepts both [canonical repo
-name](/versions/8.5.1/external/overview#canonical-repo-name) and [apparent repo
-name](/versions/8.5.1/external/overview#apparent-repo-name).
+to vendor, it accepts both [canonical repo name](/versions/8.5.1/external/overview#canonical-repo-name) and [apparent repo name](/versions/8.5.1/external/overview#apparent-repo-name).
 
 For example, running:
 
diff --git a/versions/8.5.1/help.mdx b/versions/8.5.1/help.mdx
index 4d23265f..4121504a 100644
--- a/versions/8.5.1/help.mdx
+++ b/versions/8.5.1/help.mdx
@@ -46,5 +46,4 @@ what level of support Bazel provides.
 
 ## File a bug {#file-bug}
 
-If you encounter a bug or want to request a feature, file a [GitHub
-Issue](https://github.com/bazelbuild/bazel/issues).
+If you encounter a bug or want to request a feature, file a [GitHub Issue](https://github.com/bazelbuild/bazel/issues).
diff --git a/versions/8.5.1/install/bazelisk.mdx b/versions/8.5.1/install/bazelisk.mdx
index b3bd88a9..d53e96bd 100644
--- a/versions/8.5.1/install/bazelisk.mdx
+++ b/versions/8.5.1/install/bazelisk.mdx
@@ -16,8 +16,7 @@ For more details, see
 ## Updating Bazel
 
 Bazel has a [backward compatibility policy](/versions/8.5.1/release/backward-compatibility)
-(see [guidance for rolling out incompatible
-changes](/versions/8.5.1/contribute/breaking-changes) if you
+(see [guidance for rolling out incompatible changes](/versions/8.5.1/contribute/breaking-changes) if you
 are the author of one). That page summarizes best practices on how to test and
 migrate your project with upcoming incompatible changes and how to provide
 feedback to the incompatible change authors.
diff --git a/versions/8.5.1/install/compile-source.mdx b/versions/8.5.1/install/compile-source.mdx
index c193471f..3943d9af 100644
--- a/versions/8.5.1/install/compile-source.mdx
+++ b/versions/8.5.1/install/compile-source.mdx
@@ -45,8 +45,7 @@ it by typing `bazel` in a terminal.
 
 **Reason**: To build Bazel from a GitHub source tree, you need a pre-existing
 Bazel binary. You can install one from a package manager or download one from
-GitHub. See [Installing Bazel](/versions/8.5.1/install). (Or you can [build from
-scratch (bootstrap)](#bootstrap-bazel).)
+GitHub. See [Installing Bazel](/versions/8.5.1/install). (Or you can [build from scratch (bootstrap)](#bootstrap-bazel).)
 
 **Troubleshooting**:
 
@@ -239,8 +238,7 @@ For instructions for Unix-like systems, see
     ```
 
 *   **The Visual C++ compiler.** Install the Visual C++ compiler either as part
-    of Visual Studio 2015 or newer, or by installing the latest [Build Tools
-    for Visual Studio 2017](https://aka.ms/BuildTools).
+    of Visual Studio 2015 or newer, or by installing the latest [Build Tools for Visual Studio 2017](https://aka.ms/BuildTools).
 
 *   **JDK.** Version 21 is required.
 
diff --git a/versions/8.5.1/install/ide.mdx b/versions/8.5.1/install/ide.mdx
index 561d0e02..c42d95e9 100644
--- a/versions/8.5.1/install/ide.mdx
+++ b/versions/8.5.1/install/ide.mdx
@@ -38,10 +38,8 @@ To install, go to the IDE's plugin browser and search for `Bazel`.
 To manually install older versions, download the zip files from JetBrains'
 Plugin Repository and install the zip file from the IDE's plugin browser:
 
-*  [Android Studio
-   plugin](https://plugins.jetbrains.com/plugin/9185-android-studio-with-bazel)
-*  [IntelliJ
-   plugin](https://plugins.jetbrains.com/plugin/8609-intellij-with-bazel)
+*  [Android Studio plugin](https://plugins.jetbrains.com/plugin/9185-android-studio-with-bazel)
+*  [IntelliJ plugin](https://plugins.jetbrains.com/plugin/8609-intellij-with-bazel)
 *  [CLion plugin](https://plugins.jetbrains.com/plugin/9554-clion-with-bazel)
 
 ### Xcode {#xcode}
@@ -61,8 +59,7 @@ Features:
 * Starlark debugger for `.bzl` files during a build (set breakpoints, step
   through code, inspect variables, and so on)
 
-Find [the plugin on the Visual Studio
-marketplace](https://marketplace.visualstudio.com/items?itemName=BazelBuild.vscode-bazel).
+Find [the plugin on the Visual Studio marketplace](https://marketplace.visualstudio.com/items?itemName=BazelBuild.vscode-bazel).
 The plugin is [open source](https://github.com/bazelbuild/vscode-bazel).
 
 See also: [Autocomplete for Source Code](#autocomplete-for-source-code)
@@ -82,8 +79,7 @@ See also: [Autocomplete for Source Code](#autocomplete-for-source-code)
 
 ### Emacs {#emacs}
 
-See [`bazelbuild/bazel-emacs-mode` on
-GitHub](https://github.com/bazelbuild/emacs-bazel-mode)
+See [`bazelbuild/bazel-emacs-mode` on GitHub](https://github.com/bazelbuild/emacs-bazel-mode)
 
 See also: [Autocomplete for Source Code](#autocomplete-for-source-code)
 
@@ -115,6 +111,5 @@ tool for building Bazel targets when source files change.
 
 ## Building your own IDE plugin {#build-own-plugin}
 
-Read the [**IDE support** blog
-post](https://blog.bazel.build/2016/06/10/ide-support.html) to learn more about
+Read the [**IDE support** blog post](https://blog.bazel.build/2016/06/10/ide-support.html) to learn more about
 the Bazel APIs to use when building an IDE plugin.
diff --git a/versions/8.5.1/install/windows.mdx b/versions/8.5.1/install/windows.mdx
index bff9ff8e..b9d210ba 100644
--- a/versions/8.5.1/install/windows.mdx
+++ b/versions/8.5.1/install/windows.mdx
@@ -31,8 +31,7 @@ To check your Windows version:
 
 Alternatively you can:
 
-*   [Download the Bazel binary (`bazel-version-windows-x86_64.exe`) from
- GitHub](https://github.com/bazelbuild/bazel/releases).
+*   [Download the Bazel binary (`bazel-version-windows-x86_64.exe`) from GitHub](https://github.com/bazelbuild/bazel/releases).
 *   [Install Bazel from Chocolatey](#chocolately)
 *   [Install Bazel from Scoop](#scoop)
 *   [Build Bazel from source](/versions/8.5.1/install/compile-source)
@@ -208,8 +207,7 @@ If that doesn't help:
     its dependencies, such as the MSYS2 shell. This will not install Visual C++
     though.
 
-See [Chocolatey installation and package maintenance
-guide](/versions/8.5.1/contribute/windows-chocolatey-maintenance) for more
+See [Chocolatey installation and package maintenance guide](/versions/8.5.1/contribute/windows-chocolatey-maintenance) for more
 information about the Chocolatey package.
 
 ### Using Scoop {#scoop}
@@ -226,8 +224,7 @@ information about the Chocolatey package.
     scoop install bazel
     ```
 
-See [Scoop installation and package maintenance
-guide](/versions/8.5.1/contribute/windows-scoop-maintenance) for more
+See [Scoop installation and package maintenance guide](/versions/8.5.1/contribute/windows-scoop-maintenance) for more
 information about the Scoop package.
 
 ### Build from source {#build-from-source}
diff --git a/versions/8.5.1/migrate/maven.mdx b/versions/8.5.1/migrate/maven.mdx
index 4f1b4f66..0ce791d4 100644
--- a/versions/8.5.1/migrate/maven.mdx
+++ b/versions/8.5.1/migrate/maven.mdx
@@ -19,8 +19,7 @@ directly run by Bazel since there's no Maven compatibility layer.
 ## Before you begin {#before-you-begin}
 
 *   [Install Bazel](/versions/8.5.1/install) if it's not yet installed.
-*   If you're new to Bazel, go through the tutorial [Introduction to Bazel:
-    Build Java](/versions/8.5.1/start/java) before you start migrating. The tutorial explains
+*   If you're new to Bazel, go through the tutorial [Introduction to Bazel: Build Java](/versions/8.5.1/start/java) before you start migrating. The tutorial explains
     Bazel's concepts, structure, and label syntax.
 
 ## Differences between Maven and Bazel {#dif-maven-bazel}
@@ -44,8 +43,7 @@ The steps below describe how to migrate your project to Bazel:
 3.  [Create more BUILD files](#3-build)
 4.  [Build using Bazel](#4-build)
 
-Examples below come from a migration of the [Guava
-project](https://github.com/google/guava) from Maven to Bazel. The
+Examples below come from a migration of the [Guava project](https://github.com/google/guava) from Maven to Bazel. The
 Guava project used is release `v31.1`. The examples using Guava do not walk
 through each step in the migration, but they do show the files and contents that
 are generated or added manually for the migration.
@@ -63,14 +61,12 @@ has no external dependencies, this file can be empty.
 If your project depends on files or packages that are not in one of the
 project's directories, specify these external dependencies in the MODULE.bazel
 file. You can use `rules_jvm_external` to manage dependencies from Maven. For
-instructions about using this ruleset, see [the
-README](https://github.com/bazelbuild/rules_jvm_external/#rules_jvm_external)
+instructions about using this ruleset, see [the README](https://github.com/bazelbuild/rules_jvm_external/#rules_jvm_external)
 .
 
 #### Guava project example: external dependencies {#guava-1}
 
-You can list the external dependencies of the [Guava
-project](https://github.com/google/guava) with the
+You can list the external dependencies of the [Guava project](https://github.com/google/guava) with the
 [`rules_jvm_external`](https://github.com/bazelbuild/rules_jvm_external)
 ruleset.
 
@@ -164,8 +160,7 @@ your build by adding more `BUILD` files with more granular targets.
             *   `resources`: Use globbing to list all resources in your project.
             *   `deps`: You need to determine which external dependencies your
                 project needs.
-        *   Take a look at the [example below of this top-level BUILD
-            file](#guava-2) from the migration of the Guava project.
+        *   Take a look at the [example below of this top-level BUILD file](#guava-2) from the migration of the Guava project.
 
 3.  Now that you have a `BUILD` file at the root of your project, build your
     project to ensure that it works. On the command line, from your workspace
diff --git a/versions/8.5.1/migrate/xcode.mdx b/versions/8.5.1/migrate/xcode.mdx
index ca2e47e4..af6f40b6 100644
--- a/versions/8.5.1/migrate/xcode.mdx
+++ b/versions/8.5.1/migrate/xcode.mdx
@@ -32,8 +32,7 @@ Before you begin, do the following:
 
 1.  [Install Bazel](/versions/8.5.1/install) if you have not already done so.
 
-2.  If you're not familiar with Bazel and its concepts, complete the [iOS app
-    tutorial](/versions/8.5.1/start/ios-app)). You should understand the Bazel workspace,
+2.  If you're not familiar with Bazel and its concepts, complete the [iOS app tutorial](/versions/8.5.1/start/ios-app)). You should understand the Bazel workspace,
     including the `MODULE.bazel` and `BUILD` files, as well as the concepts of
     targets, build rules, and Bazel packages.
 
@@ -44,8 +43,7 @@ Before you begin, do the following:
 Unlike Xcode, Bazel requires you to explicitly declare all dependencies for
 every target in the `BUILD` file.
 
-For more information on external dependencies, see [Working with external
-dependencies](/versions/8.5.1/docs/external).
+For more information on external dependencies, see [Working with external dependencies](/versions/8.5.1/docs/external).
 
 ## Build or test an Xcode project with Bazel {#build-xcode-project}
 
@@ -84,8 +82,7 @@ Note: Place the project source code within the directory tree containing the
 
 To integrate SwiftPM dependencies into the Bazel workspace with
 [swift_bazel](https://github.com/cgrindel/swift_bazel), you must
-convert them into Bazel packages as described in the [following
-tutorial](https://chuckgrindel.com/swift-packages-in-bazel-using-swift_bazel/)
+convert them into Bazel packages as described in the [following tutorial](https://chuckgrindel.com/swift-packages-in-bazel-using-swift_bazel/)
 .
 
 Note: SwiftPM support is a manual process with many variables. SwiftPM
@@ -103,8 +100,7 @@ initial build of the project as follows:
 *   [Step 3b: (Optional) Add the test target(s)](#step-3b-optional-add-the-test-target-s)
 *   [Step 3c: Add the library target(s)](#step-3c-add-the-library-target-s)
 
-**Tip:** To learn more about packages and other Bazel concepts, see [Workspaces,
-packages, and targets](/versions/8.5.1/concepts/build-ref).
+**Tip:** To learn more about packages and other Bazel concepts, see [Workspaces, packages, and targets](/versions/8.5.1/concepts/build-ref).
 
 #### Step 3a: Add the application target {#add-app-target}
 
@@ -132,8 +128,7 @@ In the target, specify the following at the minimum:
 
 #### Step 3b: (Optional) Add the test target(s) {#add-test-target}
 
-Bazel's [Apple build
-rules](https://github.com/bazelbuild/rules_apple) support running
+Bazel's [Apple build rules](https://github.com/bazelbuild/rules_apple) support running
 unit and UI tests on all Apple platforms. Add test targets as follows:
 
 *   [`macos_unit_test`](https://github.com/bazelbuild/rules_apple/blob/master/doc/rules-macos.md#macos_unit_test)
@@ -181,8 +176,7 @@ all sources and/or headers of a certain type. Use it carefully as it might
 include files you do not want Bazel to build.
 
 You can browse existing examples for various types of applications directly in
-the [rules_apple examples
-directory](https://github.com/bazelbuild/rules_apple/tree/master/examples/). For
+the [rules_apple examples directory](https://github.com/bazelbuild/rules_apple/tree/master/examples/). For
 example:
 
 *   [macOS application targets](https://github.com/bazelbuild/rules_apple/tree/master/examples/macos)
@@ -191,8 +185,7 @@ example:
 
 *   [Multi platform applications (macOS, iOS, watchOS, tvOS)](https://github.com/bazelbuild/rules_apple/tree/master/examples/multi_platform)
 
-For more information on build rules, see [Apple Rules for
-Bazel](https://github.com/bazelbuild/rules_apple).
+For more information on build rules, see [Apple Rules for Bazel](https://github.com/bazelbuild/rules_apple).
 
 At this point, it is a good idea to test the build:
 
diff --git a/versions/8.5.1/query/cquery.mdx b/versions/8.5.1/query/cquery.mdx
index c4721b50..75f8bb8a 100644
--- a/versions/8.5.1/query/cquery.mdx
+++ b/versions/8.5.1/query/cquery.mdx
@@ -6,8 +6,7 @@ title: ' Configurable Query (cquery)'
 [`select()`](/versions/8.5.1/docs/configurable-attributes) and build options' effects on the build
 graph.
 
-It achieves this by running over the results of Bazel's [analysis
-phase](/versions/8.5.1/extending/concepts#evaluation-model),
+It achieves this by running over the results of Bazel's [analysis phase](/versions/8.5.1/extending/concepts#evaluation-model),
 which integrates these effects. `query`, by contrast, runs over the results of
 Bazel's loading phase, before options are evaluated.
 
@@ -137,8 +136,7 @@ $ bazel cquery //foo --universe_scope=//foo,//genrule_with_foo_as_tool
 If you want to precisely declare which instance to query over, use
 the [`config`](#config) function.
 
-See `query`'s [target pattern
-documentation](/versions/8.5.1/query/language#target-patterns) for more information on target patterns.
+See `query`'s [target pattern documentation](/versions/8.5.1/query/language#target-patterns) for more information on target patterns.
 
 ## Functions {#functions}
 
diff --git a/versions/8.5.1/query/language.mdx b/versions/8.5.1/query/language.mdx
index 521b16d7..7243addc 100644
--- a/versions/8.5.1/query/language.mdx
+++ b/versions/8.5.1/query/language.mdx
@@ -1120,8 +1120,7 @@ is being used.
 
 ### On the ordering of results {#results-ordering}
 
-Although query expressions always follow the "[law of
-conservation of graph order](#graph-order)", _presenting_ the results may be done
+Although query expressions always follow the "[law of conservation of graph order](#graph-order)", _presenting_ the results may be done
 in either a dependency-ordered or unordered manner. This does **not**
 influence the targets in the result set or how the query is computed. It only
 affects how the results are printed to stdout. Moreover, nodes that are
@@ -1267,8 +1266,7 @@ and `maxrank` output formats print the labels of each
 target in the resulting graph, but instead of appearing in
 topological order, they appear in rank order, preceded by their
 rank number. These are unaffected by the result ordering
-`--[no]order_results` flag (see [notes on
-the ordering of results](#result-order)).
+`--[no]order_results` flag (see [notes on the ordering of results](#result-order)).
 
 There are two variants of this format: `minrank` ranks
 each node by the length of the shortest path from a root node to it.
diff --git a/versions/8.5.1/reference/be/functions.mdx b/versions/8.5.1/reference/be/functions.mdx
index 58e36d7a..cd1729eb 100644
--- a/versions/8.5.1/reference/be/functions.mdx
+++ b/versions/8.5.1/reference/be/functions.mdx
@@ -262,8 +262,7 @@ There are several important limitations and caveats:
    package called "Foo.java" (which is allowed, though Bazel warns about it),
    then the consumer of the `glob()` will use the "Foo.java" rule
    (its outputs) instead of the "Foo.java" file. See
-   [GitHub
-   issue #10395](https://github.com/bazelbuild/bazel/issues/10395#issuecomment-583714657) for more details.
+   [GitHub issue #10395](https://github.com/bazelbuild/bazel/issues/10395#issuecomment-583714657) for more details.
 3. Globs may match files in subdirectories. And subdirectory names
    may be wildcarded. However...
 4. Labels are not allowed to cross the package boundary and glob does
diff --git a/versions/8.5.1/reference/be/java.mdx b/versions/8.5.1/reference/be/java.mdx
index c545b821..3a0008a3 100644
--- a/versions/8.5.1/reference/be/java.mdx
+++ b/versions/8.5.1/reference/be/java.mdx
@@ -225,8 +225,7 @@ test code. The test runner's main method is invoked instead of the main class be
   [java\_binary](#java_binary) for more details.
 
 See the section on `java_binary()` arguments. This rule also
-supports all [attributes common
-to all test rules (\*\_test)](https://bazel.build/versions/8.5.1/reference/be/common-definitions#common-attributes-tests).
+supports all [attributes common to all test rules (\*\_test)](https://bazel.build/versions/8.5.1/reference/be/common-definitions#common-attributes-tests).
 
 #### Examples
 
diff --git a/versions/8.5.1/reference/be/make-variables.mdx b/versions/8.5.1/reference/be/make-variables.mdx
index a5ae6aba..cc5eea94 100644
--- a/versions/8.5.1/reference/be/make-variables.mdx
+++ b/versions/8.5.1/reference/be/make-variables.mdx
@@ -19,8 +19,7 @@ targets, and *custom* variables, which are defined in dependency targets
 and only available to targets that depend on them.
 
 The reason for the term "Make" is historical: the syntax and semantics of
-these variables were originally intended to match [GNU
-Make](https://www.gnu.org/software/make/manual/html_node/Using-Variables.html).
+these variables were originally intended to match [GNU Make](https://www.gnu.org/software/make/manual/html_node/Using-Variables.html).
 
 ## Use
 
@@ -64,8 +63,7 @@ and look at the top output lines with capital letters.
 **Toolchain option variables**
 
 * `COMPILATION_MODE`:
-  `fastbuild`, `dbg`, or `opt`. ([more
-  details](https://bazel.build/versions/8.5.1/docs/user-manual#flag--compilation_mode))
+  `fastbuild`, `dbg`, or `opt`. ([more details](https://bazel.build/versions/8.5.1/docs/user-manual#flag--compilation_mode))
 
 **Path variables**
 
diff --git a/versions/8.5.1/reference/be/workspace.mdx b/versions/8.5.1/reference/be/workspace.mdx
index 82e93dfa..78b5d809 100644
--- a/versions/8.5.1/reference/be/workspace.mdx
+++ b/versions/8.5.1/reference/be/workspace.mdx
@@ -25,8 +25,7 @@ bind(name, actual, compatible_with, deprecation, distribs, features, licenses, r
 
 *Warning: use of `bind()` is not recommended. See "[Consider removing bind](https://github.com/bazelbuild/bazel/issues/1952)" for a long
 discussion of its issues and alternatives. In particular, consider the use of
-[`repo_mapping`
-repository attributes](https://bazel.build/versions/8.5.1/rules/repository_rules#attributes).*
+[`repo_mapping` repository attributes](https://bazel.build/versions/8.5.1/rules/repository_rules#attributes).*
 
 *Warning: `select()` cannot be used in `bind()`. See the [Configurable Attributes FAQ](/versions/8.5.1/docs/configurable-attributes#bind-select) for
 details.*
@@ -114,8 +113,7 @@ local_repository(name, path, repo_mapping)
 ```
 
 Allows targets from a local directory to be bound. This means that the current repository can
-use targets defined in this other directory. See the [bind
-section](/versions/8.5.1/reference/be/workspace#bind_examples) for more details.
+use targets defined in this other directory. See the [bind section](/versions/8.5.1/reference/be/workspace#bind_examples) for more details.
 
 #### Examples
 
diff --git a/versions/8.5.1/reference/glossary.mdx b/versions/8.5.1/reference/glossary.mdx
index 7fb81c45..0e004520 100644
--- a/versions/8.5.1/reference/glossary.mdx
+++ b/versions/8.5.1/reference/glossary.mdx
@@ -21,8 +21,7 @@ An in-memory graph of [actions](#action) and the [artifacts](#artifact) that
 these actions read and generate. The graph might include artifacts that exist as
 source files (for example, in the file system) as well as generated
 intermediate/final artifacts that are not mentioned in `BUILD` files. Produced
-during the [analysis phase](#analysis-phase) and used during the [execution
-phase](#execution-phase).
+during the [analysis phase](#analysis-phase) and used during the [execution phase](#execution-phase).
 
 ### Action graph query (aquery) {#action-graph-query}
 A [query](#query-concept) tool that can query over build [actions](#action).
@@ -37,8 +36,7 @@ invalidate individual actions deterministically.
 
 ### Analysis phase {#analysis-phase}
 The second phase of a build. Processes the [target graph](#target-graph)
-specified in [`BUILD` files](#build-file) to produce an in-memory [action
-graph](#action-graph) that determines the order of actions to run during the
+specified in [`BUILD` files](#build-file) to produce an in-memory [action graph](#action-graph) that determines the order of actions to run during the
 [execution phase](#execution-phase). This is the phase in which rule
 implementations are evaluated.
 
@@ -81,8 +79,7 @@ target's source files, dependencies, and custom compiler options. The particular
 attributes available for a given target depend on its rule type.
 
 ### .bazelrc {#bazelrc}
-Bazel’s configuration file used to change the default values for [startup
-flags](#startup-flags) and [command flags](#command-flags), and to define common
+Bazel’s configuration file used to change the default values for [startup flags](#startup-flags) and [command flags](#command-flags), and to define common
 groups of options that can then be set together on the Bazel command line using
 a `--config` flag. Bazel can combine settings from multiple bazelrc files
 (systemwide, per-workspace, per-user, or from a custom location), and a
@@ -108,8 +105,7 @@ directory.
 
 ### .bzl File {#bzl-file}
 A file that defines rules, [macros](#macro), and constants written in
-[Starlark](#starlark). These can then be imported into [`BUILD`
-files](#build-file) using the `load()` function.
+[Starlark](#starlark). These can then be imported into [`BUILD` files](#build-file) using the `load()` function.
 
 {/* TODO: ### Build event protocol */}
 
@@ -117,8 +113,7 @@ files](#build-file) using the `load()` function.
 
 ### Build graph {#build-graph}
 The dependency graph that Bazel constructs and traverses to perform a build.
-Includes nodes like [targets](#target), [configured
-targets](#configured-target), [actions](#action), and [artifacts](#artifact). A
+Includes nodes like [targets](#target), [configured targets](#configured-target), [actions](#action), and [artifacts](#artifact). A
 build is considered complete when all [artifacts](#artifact) on which a set of
 requested targets depend are verified as up-to-date.
 
@@ -158,8 +153,7 @@ graphs and restart the [analysis phase](#analysis-phase).
 ### Configuration {#configuration}
 Information outside of [rule](#rule) definitions that impacts how rules generate
 [actions](#action). Every build has at least one configuration specifying the
-target platform, action environment variables, and command-line [build
-flags](#command-flags). [Transitions](#transition) may create additional
+target platform, action environment variables, and command-line [build flags](#command-flags). [Transitions](#transition) may create additional
 configurations, such as for host tools or cross-compilation.
 
 **See also:** [Configurations](/versions/8.5.1/extending/rules#configurations)
@@ -174,8 +168,7 @@ configuration of `//:c` because changing `--javacopt` unnecessarily breaks C++
 build cacheability.
 
 ### Configured query (cquery) {#configured-query}
-A [query](#query-concept) tool that queries over [configured
-targets](#configured-target) (after the [analysis phase](#analysis-phase)
+A [query](#query-concept) tool that queries over [configured targets](#configured-target) (after the [analysis phase](#analysis-phase)
 completes). This means `select()` and [build flags](#command-flags) (such as
 `--platforms`) are accurately reflected in the results.
 
@@ -191,8 +184,7 @@ build, it has two configured targets: `` and ``.
 ### Correctness {#correctness}
 A build is correct when its output faithfully reflects the state of its
 transitive inputs. To achieve correct builds, Bazel strives to be
-[hermetic](#hermeticity), reproducible, and making [build
-analysis](#analysis-phase) and [action execution](#execution-phase)
+[hermetic](#hermeticity), reproducible, and making [build analysis](#analysis-phase) and [action execution](#execution-phase)
 deterministic.
 
 ### Dependency {#dependency}
@@ -234,8 +226,7 @@ compilation). A dynamic execution strategy can provide the best possible
 incremental and clean build times.
 
 ### Execution phase {#execution-phase}
-The third phase of a build. Executes the [actions](#action) in the [action
-graph](#action-graph) created during the [analysis phase](#analysis-phase).
+The third phase of a build. Executes the [actions](#action) in the [action graph](#action-graph) created during the [analysis phase](#analysis-phase).
 These actions invoke executables (compilers, scripts) to read and write
 [artifacts](#artifact). *Spawn strategies* control how these actions are
 executed: locally, remotely, dynamically, sandboxed, docker, and so on.
@@ -285,8 +276,7 @@ syntax may be omitted.
 The first phase of a build where Bazel executes [`BUILD` files](#build-file) to
 create [packages](#package). [Macros](#macro) and certain functions like
 `glob()` are evaluated in this phase. Interleaved with the second phase of the
-build, the [analysis phase](#analysis-phase), to build up a [target
-graph](#target-graph).
+build, the [analysis phase](#analysis-phase), to build up a [target graph](#target-graph).
 
 ### Legacy macro {#legacy-macro}
 A flavor of [macro](#macro) which is declared as an ordinary
@@ -336,8 +326,7 @@ Module metadata is hosted in Bazel registries.
 
 ### Module Extension {#module-extension}
 A piece of logic that can be run to generate [repos](#repository) by reading
-inputs from across the [module](#module) dependency graph and invoking [repo
-rules](#repository-rule). Module extensions have capabilities similar to repo
+inputs from across the [module](#module) dependency graph and invoking [repo rules](#repository-rule). Module extensions have capabilities similar to repo
 rules, allowing them to access the internet, perform file I/O, and so on.
 
 **See also:** [Module extensions](/versions/8.5.1/external/extension)
@@ -350,8 +339,7 @@ example, `native.cc_library` or `native.java_library`). User-defined rules
 
 ### Output base {#output-base}
 A [workspace](#workspace)-specific directory to store Bazel output files. Used
-to separate outputs from the *workspace*'s source tree (the [main
-repo](#repository)). Located in the [output user root](#output-user-root).
+to separate outputs from the *workspace*'s source tree (the [main repo](#repository)). Located in the [output user root](#output-user-root).
 
 ### Output groups {#output-groups}
 A group of files that is expected to be built when Bazel finishes building a
@@ -406,8 +394,7 @@ query variants: [query](#query-command), [cquery](#configured-query), and
 [aquery](#action-graph-query).
 
 ### query (command) {#query-command}
-A [query](#query-concept) tool that operates over the build's post-[loading
-phase](#loading-phase) [target graph](#target-graph). This is relatively fast,
+A [query](#query-concept) tool that operates over the build's post-[loading phase](#loading-phase) [target graph](#target-graph). This is relatively fast,
 but can't analyze the effects of `select()`, [build flags](#command-flags),
 [artifacts](#artifact), or build [actions](#action).
 
@@ -425,8 +412,7 @@ repo; multiple such files can coexist in a directory.
 The *main repo* is the repo in which the current Bazel command is being run.
 
 *External repos* are defined by specifying [modules](#module) in `MODULE.bazel`
-files, or invoking [repo rules](#repository-rule) in [module
-extensions](#module-extension). They can be fetched on demand to a predetermined
+files, or invoking [repo rules](#repository-rule) in [module extensions](#module-extension). They can be fetched on demand to a predetermined
 "magical" location on disk.
 
 Each repo has a unique, constant *canonical* name, and potentially different
@@ -437,8 +423,7 @@ Each repo has a unique, constant *canonical* name, and potentially different
 ### Repository cache {#repo-cache}
 A shared content-addressable cache of files downloaded by Bazel for builds,
 shareable across [workspaces](#workspace). Enables offline builds after the
-initial download. Commonly used to cache files downloaded through [repository
-rules](#repository-rule) like `http_archive` and repository rule APIs like
+initial download. Commonly used to cache files downloaded through [repository rules](#repository-rule) like `http_archive` and repository rule APIs like
 `repository_ctx.download`. Files are cached only if their SHA-256 checksums are
 specified for the download.
 
@@ -472,8 +457,7 @@ Rules are instantiated to produce rule targets in the
 [loading phase](#loading-phase). In the [analysis phase](#analysis-phase) rule
 targets communicate information to their downstream dependencies in the form of
 [providers](#provider), and register [actions](#action) describing how to
-generate their output artifacts. These actions are run in the [execution
-phase](#execution-phase).
+generate their output artifacts. These actions are run in the [execution phase](#execution-phase).
 
 Note: Historically the term "rule" has been used to refer to a rule target.
 This usage was inherited from tools like Make, but causes confusion and should
@@ -517,8 +501,7 @@ support the stamp attribute.
 ### Starlark {#starlark}
 The extension language for writing [rules](/versions/8.5.1/extending/rules) and [macros](#macro). A
 restricted subset of Python (syntactically and grammatically) aimed for the
-purpose of configuration, and for better performance. Uses the [`.bzl`
-file](#bzl-file) extension. [`BUILD` files](#build-file) use an even more
+purpose of configuration, and for better performance. Uses the [`.bzl` file](#bzl-file) extension. [`BUILD` files](#build-file) use an even more
 restricted version of Starlark (such as no `def` function definitions), formerly
 known as Skylark.
 
@@ -549,8 +532,7 @@ An object that is defined in a [`BUILD` file](#build-file) and identified by a
 [label](#label). Targets represent the buildable units of a workspace from
 the perspective of the end user.
 
-A target that is declared by instantiating a [rule](#rule) is called a [rule
-target](#rule-target). Depending on the rule, these may be runnable (like
+A target that is declared by instantiating a [rule](#rule) is called a [rule target](#rule-target). Depending on the rule, these may be runnable (like
 `cc_binary`) or testable (like `cc_test`). Rule targets typically depend on
 other targets via their [attributes](#attribute) (such as `deps`); these
 dependencies form the basis of the [target graph](#target-graph).
@@ -561,14 +543,11 @@ within a `BUILD` file. As a special case, the `BUILD` file of any package is
 always considered a source file target in that package.
 
 Targets are discovered during the [loading phase](#loading-phase). During the
-[analysis phase](#analysis-phase), targets are associated with [build
-configurations](#configuration) to form [configured
-targets](#configured-target).
+[analysis phase](#analysis-phase), targets are associated with [build configurations](#configuration) to form [configured targets](#configured-target).
 
 ### Target graph {#target-graph}
 An in-memory graph of [targets](#target) and their dependencies. Produced during
-the [loading phase](#loading-phase) and used as an input to the [analysis
-phase](#analysis-phase).
+the [loading phase](#loading-phase) and used as an input to the [analysis phase](#analysis-phase).
 
 ### Target pattern {#target-pattern}
 A way to specify a group of [targets](#target) on the command line. Commonly
@@ -581,8 +560,7 @@ packages recursively from the root of the [workspace](#workspace).
 Rule [targets](#target) instantiated from test rules, and therefore contains a
 test executable. A return code of zero from the completion of the executable
 indicates test success. The exact contract between Bazel and tests (such as test
-environment variables, test result collection methods) is specified in the [Test
-Encyclopedia](/versions/8.5.1/reference/test-encyclopedia).
+environment variables, test result collection methods) is specified in the [Test Encyclopedia](/versions/8.5.1/reference/test-encyclopedia).
 
 ### Toolchain {#toolchain}
 A set of tools to build outputs for a language. Typically, a toolchain includes
@@ -596,8 +574,7 @@ A build [target](#target) is top-level if it’s requested on the Bazel command
 line. For example, if `//:foo` depends on `//:bar`, and `bazel build //:foo` is
 called, then for this build, `//:foo` is top-level, and `//:bar` isn’t
 top-level, although both targets will need to be built. An important difference
-between top-level and non-top-level targets is that [command
-flags](#command-flags) set on the Bazel command line (or via
+between top-level and non-top-level targets is that [command flags](#command-flags) set on the Bazel command line (or via
 [.bazelrc](#bazelrc)) will set the [configuration](#configuration) for top-level
 targets, but might be modified by a [transition](#transition) for non-top-level
 targets.
@@ -628,8 +605,7 @@ or `.bzl` file may load a given `.bzl` file. Without context, usually
 **See also:** [Visibility documentation](/versions/8.5.1/concepts/visibility)
 
 ### Workspace {#workspace}
-The environment shared by all Bazel commands run from the same [main
-repository](#repository).
+The environment shared by all Bazel commands run from the same [main repository](#repository).
 
 Note that historically the concepts of "repository" and "workspace" have been
 conflated; the term "workspace" has often been used to refer to the main
diff --git a/versions/8.5.1/release/backward-compatibility.mdx b/versions/8.5.1/release/backward-compatibility.mdx
index eba056ee..7f9a40ed 100644
--- a/versions/8.5.1/release/backward-compatibility.mdx
+++ b/versions/8.5.1/release/backward-compatibility.mdx
@@ -6,11 +6,9 @@ This page provides information about how to handle backward compatibility,
 including migrating from one release to another and how to communicate
 incompatible changes.
 
-Bazel is evolving. Minor versions released as part of an [LTS major
-version](/versions/8.5.1/release#bazel-versioning) are fully backward-compatible. New major LTS
+Bazel is evolving. Minor versions released as part of an [LTS major version](/versions/8.5.1/release#bazel-versioning) are fully backward-compatible. New major LTS
 releases may contain incompatible changes that require some migration effort.
-For more information about Bazel's release model, please check out the [Release
-Model](/versions/8.5.1/release) page.
+For more information about Bazel's release model, please check out the [Release Model](/versions/8.5.1/release) page.
 
 ## Summary {#summary}
 
@@ -59,8 +57,7 @@ available.
 ## Communicating incompatible changes {#communicating-incompatible-changes}
 
 The primary source of information about incompatible changes are GitHub issues
-marked with an ["incompatible-change"
-label](https://github.com/bazelbuild/bazel/issues?q=label%3Aincompatible-change).
+marked with an ["incompatible-change" label](https://github.com/bazelbuild/bazel/issues?q=label%3Aincompatible-change).
 
 For every incompatible change, the issue specifies the following:
 
diff --git a/versions/8.5.1/release/index.mdx b/versions/8.5.1/release/index.mdx
index 49422dec..726a5635 100644
--- a/versions/8.5.1/release/index.mdx
+++ b/versions/8.5.1/release/index.mdx
@@ -2,8 +2,7 @@
 title: 'Release Model'
 ---
 
-As announced in [the original blog
-post](https://blog.bazel.build/2020/11/10/long-term-support-release.html), Bazel
+As announced in [the original blog post](https://blog.bazel.build/2020/11/10/long-term-support-release.html), Bazel
 4.0 and higher versions provides support for two release tracks: rolling
 releases and long term support (LTS) releases. This page covers the latest
 information about Bazel's release model.
@@ -19,8 +18,7 @@ information about Bazel's release model.
 | Bazel 5 | Maintenance | [5.4.1](https://github.com/bazelbuild/bazel/releases/tag/5.4.1) | Jan 2025 |
 | Bazel 4 | Deprecated | [4.2.4](https://github.com/bazelbuild/bazel/releases/tag/4.2.4) | Jan 2024 |
 
-All Bazel LTS releases can be found on the [release
-page](https://github.com/bazelbuild/bazel/releases) on GitHub.
+All Bazel LTS releases can be found on the [release page](https://github.com/bazelbuild/bazel/releases) on GitHub.
 
 Note: Bazel version older than Bazel 5 are no longer supported, Bazel users are
 recommended to upgrade to the latest LTS release or use rolling releases if you
@@ -28,8 +26,7 @@ want to keep up with the latest changes at HEAD.
 
 ## Release versioning {#bazel-versioning}
 
-Bazel uses a _major.minor.patch_ [Semantic
-Versioning](https://semver.org/) scheme.
+Bazel uses a _major.minor.patch_ [Semantic Versioning](https://semver.org/) scheme.
 
 *   A _major release_ contains features that are not backward compatible with
     the previous release. Each major Bazel version is an LTS release.
@@ -72,8 +69,7 @@ Bazel regularly publish releases for two release tracks.
     release.
 *   Rolling releases can ship incompatible changes. Incompatible flags are
     recommended for major breaking changes, rolling out incompatible changes
-    should follow our [backward compatibility
-    policy](/versions/8.5.1/release/backward-compatibility).
+    should follow our [backward compatibility policy](/versions/8.5.1/release/backward-compatibility).
 
 ### LTS releases {#lts-releases}
 
@@ -89,8 +85,7 @@ Bazel regularly publish releases for two release tracks.
 *   A Bazel LTS release enters the Deprecated stage after being in ​​the
     Maintenance stage for 2 years.
 
-For planned releases, please check our [release
-issues](https://github.com/bazelbuild/bazel/issues?q=is%3Aopen+is%3Aissue+label%3Arelease)
+For planned releases, please check our [release issues](https://github.com/bazelbuild/bazel/issues?q=is%3Aopen+is%3Aissue+label%3Arelease)
 on Github.
 
 ## Release procedure & policies {#release-procedure-policies}
@@ -153,8 +148,7 @@ For LTS releases, the procedure and policies below are followed:
 1.  Identify release blockers and fix issues found on the release branch.
     *   The release branch is tested with the same test suite in
         [postsubmit](https://buildkite.com/bazel/bazel-bazel) and
-        [downstream test pipeline]
-        (https://buildkite.com/bazel/bazel-at-head-plus-downstream)
+        [downstream test pipeline](https://buildkite.com/bazel/bazel-at-head-plus-downstream)
         on Bazel CI. The Bazel team monitors testing results of the release
         branch and fixes any regressions found.
 1.  Create a new release candidate from the release branch when all known
@@ -210,5 +204,4 @@ feature.
 ## Rule compatibility {#rule-compatibility}
 
 If you are a rule authors and want to maintain compatibility with different
-Bazel versions, please check out the [Rule
-Compatibility](/versions/8.5.1/release/rule-compatibility) page.
+Bazel versions, please check out the [Rule Compatibility](/versions/8.5.1/release/rule-compatibility) page.
diff --git a/versions/8.5.1/release/rule-compatibility.mdx b/versions/8.5.1/release/rule-compatibility.mdx
index c5082e89..2a511aa2 100644
--- a/versions/8.5.1/release/rule-compatibility.mdx
+++ b/versions/8.5.1/release/rule-compatibility.mdx
@@ -53,18 +53,15 @@ Bazel LTS release.
 As Bazel rules authors, you can ensure a manageable migration process for users
 by following these best practices:
 
-1.  The rule should follow [Semantic
-    Versioning](https://semver.org/): minor versions of the same
+1.  The rule should follow [Semantic Versioning](https://semver.org/): minor versions of the same
     major version are backward compatible.
 1.  The rule at HEAD should be compatible with the latest Bazel LTS release.
 1.  The rule at HEAD should be compatible with Bazel at HEAD. To achieve this,
     you can
     *   Set up your own CI testing with Bazel at HEAD
-    *   Add your project to [Bazel downstream
-        testing](https://github.com/bazelbuild/continuous-integration/blob/master/docs/downstream-testing.md);
+    *   Add your project to [Bazel downstream testing](https://github.com/bazelbuild/continuous-integration/blob/master/docs/downstream-testing.md);
         the Bazel team files issues to your project if breaking changes in Bazel
-        affect your project, and you must follow our [downstream project
-        policies](https://github.com/bazelbuild/continuous-integration/blob/master/docs/downstream-testing.md#downstream-project-policies)
+        affect your project, and you must follow our [downstream project policies](https://github.com/bazelbuild/continuous-integration/blob/master/docs/downstream-testing.md#downstream-project-policies)
         to address issues timely.
 1.  The latest major version of the rule must be compatible with the latest
     Bazel LTS release.
diff --git a/versions/8.5.1/remote/bep-glossary.mdx b/versions/8.5.1/remote/bep-glossary.mdx
index 7ab2a884..416806ea 100644
--- a/versions/8.5.1/remote/bep-glossary.mdx
+++ b/versions/8.5.1/remote/bep-glossary.mdx
@@ -410,5 +410,4 @@ workspace, such as the execution root.
 
 ## WorkspaceStatus {#workspacestatus}
 
-A single `WorkspaceStatus` event contains the result of the [workspace status
-command](/versions/8.5.1/docs/user-manual#workspace-status).
+A single `WorkspaceStatus` event contains the result of the [workspace status command](/versions/8.5.1/docs/user-manual#workspace-status).
diff --git a/versions/8.5.1/remote/bep.mdx b/versions/8.5.1/remote/bep.mdx
index 2f37c08d..ea1a1df5 100644
--- a/versions/8.5.1/remote/bep.mdx
+++ b/versions/8.5.1/remote/bep.mdx
@@ -2,14 +2,12 @@
 title: 'Build Event Protocol'
 ---
 
-The [Build Event
-Protocol](https://github.com/bazelbuild/bazel/blob/master/src/main/java/com/google/devtools/build/lib/buildeventstream/proto/build_event_stream.proto)
+The [Build Event Protocol](https://github.com/bazelbuild/bazel/blob/master/src/main/java/com/google/devtools/build/lib/buildeventstream/proto/build_event_stream.proto)
 (BEP) allows third-party programs to gain insight into a Bazel invocation. For
 example, you could use the BEP to gather information for an IDE
 plugin or a dashboard that displays build results.
 
-The protocol is a set of [protocol
-buffer](https://developers.google.com/protocol-buffers/) messages with some
+The protocol is a set of [protocol buffer](https://developers.google.com/protocol-buffers/) messages with some
 semantics defined on top of it. It includes information about build and test
 results, build progress, the build configuration and much more. The BEP is
 intended to be consumed programmatically and makes parsing Bazel’s
@@ -20,16 +18,13 @@ build event is a protocol buffer message consisting of a build event identifier,
 a set of child event identifiers, and a payload.
 
 *  __Build Event Identifier:__ Depending on the kind of build event, it might be
-an [opaque
-string](https://github.com/bazelbuild/bazel/blob/7.1.0/src/main/java/com/google/devtools/build/lib/buildeventstream/proto/build_event_stream.proto#L131-L140)
-or [structured
-information](https://github.com/bazelbuild/bazel/blob/7.1.0/src/main/java/com/google/devtools/build/lib/buildeventstream/proto/build_event_stream.proto#L194-L205)
+an [opaque string](https://github.com/bazelbuild/bazel/blob/7.1.0/src/main/java/com/google/devtools/build/lib/buildeventstream/proto/build_event_stream.proto#L131-L140)
+or [structured information](https://github.com/bazelbuild/bazel/blob/7.1.0/src/main/java/com/google/devtools/build/lib/buildeventstream/proto/build_event_stream.proto#L194-L205)
 revealing more about the build event. A build event identifier is unique within
 a build.
 
 *  __Children:__ A build event may announce other build events, by including
-their build event identifiers in its [children
-field](https://github.com/bazelbuild/bazel/blob/7.1.0/src/main/java/com/google/devtools/build/lib/buildeventstream/proto/build_event_stream.proto#L1276).
+their build event identifiers in its [children field](https://github.com/bazelbuild/bazel/blob/7.1.0/src/main/java/com/google/devtools/build/lib/buildeventstream/proto/build_event_stream.proto#L1276).
 For example, the `PatternExpanded` build event announces the targets it expands
 to as children. The protocol guarantees that all events, except for the first
 event, are announced by a previous event.
@@ -91,8 +86,7 @@ human-readable formats, such as text and JSON:
 
 ## Build Event Service {#build-event-service}
 
-The [Build Event
-Service](https://github.com/googleapis/googleapis/blob/master/google/devtools/build/v1/publish_build_event.proto)
+The [Build Event Service](https://github.com/googleapis/googleapis/blob/master/google/devtools/build/v1/publish_build_event.proto)
 Protocol is a generic [gRPC](https://www.grpc.io) service for publishing build events. The Build Event
 Service protocol is independent of the BEP and treats BEP events as opaque bytes.
 Bazel ships with a gRPC client implementation of the Build Event Service protocol that
@@ -136,8 +130,7 @@ For a description of each of these flags, see the
 The BEP typically contains many references to log files (test.log, test.xml,
 etc. ) stored on the machine where Bazel is running. A remote BES server
 typically can't access these files as they are on different machines. A way to
-work around this issue is to use Bazel with [remote
-caching](/versions/8.5.1/remote/caching).
+work around this issue is to use Bazel with [remote caching](/versions/8.5.1/remote/caching).
 Bazel will upload all output files to the remote cache (including files
 referenced in the BEP) and the BES server can then fetch the referenced files
 from the cache.
diff --git a/versions/8.5.1/remote/cache-local.mdx b/versions/8.5.1/remote/cache-local.mdx
index add2e191..e02ac2a6 100644
--- a/versions/8.5.1/remote/cache-local.mdx
+++ b/versions/8.5.1/remote/cache-local.mdx
@@ -18,8 +18,7 @@ execution. However, local execution presents some additional challenges.
 ## Checking your cache hit rate {#cache-hits}
 
 Successful remote cache hits will show up in the status line, similar to
-[Cache Hits rate with Remote
-Execution](/versions/8.5.1/remote/cache-remote#check-cache-hits).
+[Cache Hits rate with Remote Execution](/versions/8.5.1/remote/cache-remote#check-cache-hits).
 
 In the standard output of your Bazel run, you will see something like the
 following:
@@ -66,8 +65,7 @@ the steps in this section.
    message you see does not give you enough information, try adding
    `--verbose_failures`.
 
-2. Follow the steps from [Troubleshooting cache hits for remote
-   execution](/versions/8.5.1/remote/cache-remote#troubleshooting_cache_hits) to
+2. Follow the steps from [Troubleshooting cache hits for remote execution](/versions/8.5.1/remote/cache-remote#troubleshooting_cache_hits) to
    ensure that your cache-writing Bazel invocations are able to get cache hits
    on the same machine and across machines.
 
@@ -81,7 +79,6 @@ the steps in this section.
    b. Ensure your cache-reading Bazel invocations build the same targets as the
       cache-writing Bazel invocations.
 
-   c. Follow the same steps as to [ensure caching across
-      machines](/versions/8.5.1/remote/cache-remote#caching-across-machines),
+   c. Follow the same steps as to [ensure caching across machines](/versions/8.5.1/remote/cache-remote#caching-across-machines),
       to ensure caching from your cache-writing Bazel invocation to your
       cache-reading Bazel invocation.
diff --git a/versions/8.5.1/remote/caching.mdx b/versions/8.5.1/remote/caching.mdx
index 3a300a85..3c114f92 100644
--- a/versions/8.5.1/remote/caching.mdx
+++ b/versions/8.5.1/remote/caching.mdx
@@ -308,8 +308,7 @@ or for the age of individual cache entries. Bazel will automatically garbage
 collect the disk cache while idling between builds; the idle timer can be set
 with `--experimental_disk_cache_gc_idle_delay` (defaulting to 5 minutes).
 
-As an alternative to automatic garbage collection, we also provide a [tool](
-https://github.com/bazelbuild/bazel/tree/master/src/tools/diskcache) to run a
+As an alternative to automatic garbage collection, we also provide a [tool](https://github.com/bazelbuild/bazel/tree/master/src/tools/diskcache) to run a
 garbage collection on demand.
 
 ## Known issues {#known-issues}
diff --git a/versions/8.5.1/remote/dynamic.mdx b/versions/8.5.1/remote/dynamic.mdx
index 1effcc66..ffd9503f 100644
--- a/versions/8.5.1/remote/dynamic.mdx
+++ b/versions/8.5.1/remote/dynamic.mdx
@@ -12,8 +12,7 @@ alike.
 This page describes how to enable, tune, and debug dynamic execution. If you
 have both local and remote execution set up and are trying to adjust Bazel
 settings for better performance, this page is for you. If you don't already have
-remote execution set up, go to the Bazel [Remote Execution
-Overview](/versions/8.5.1/remote/rbe) first.
+remote execution set up, go to the Bazel [Remote Execution Overview](/versions/8.5.1/remote/rbe) first.
 
 ## Enabling dynamic execution? {#enabling-dynamic-execution}
 
@@ -44,14 +43,12 @@ are likely. The default value is 1000ms, but should be tuned to being just a bit
 longer than cache hits usually take. The actual time depends both on the remote
 system and on how long a round-trip takes. Usually, the value will be the same
 for all users of a given remote system, unless some of them are far enough away
-to add roundtrip latency. You can use the [Bazel profiling
-features](/versions/8.5.1/rules/performance#performance-profiling) to look at how long typical
+to add roundtrip latency. You can use the [Bazel profiling features](/versions/8.5.1/rules/performance#performance-profiling) to look at how long typical
 cache hits take.
 
 Dynamic execution can be used with local sandboxed strategy as well as with
 [persistent workers](/versions/8.5.1/remote/persistent). Persistent workers will automatically
-run with sandboxing when used with dynamic execution, and cannot use [multiplex
-workers](/versions/8.5.1/remote/multiplex). On Darwin and Windows systems, the sandboxed
+run with sandboxing when used with dynamic execution, and cannot use [multiplex workers](/versions/8.5.1/remote/multiplex). On Darwin and Windows systems, the sandboxed
 strategy can be slow; you can pass `--reuse_sandbox_directories` to reduce
 overhead of creating sandboxes on these systems.
 
@@ -67,8 +64,7 @@ entire action fails. This is an intentional choice to prevent differences
 between local and remote execution from going unnoticed.
 
 For more background on how dynamic execution and its locking works, see Julio
-Merino's excellent [blog
-posts](https://jmmv.dev/series/bazel-dynamic-execution/)
+Merino's excellent [blog posts](https://jmmv.dev/series/bazel-dynamic-execution/)
 
 ## When should I use dynamic execution? {#when-to-use}
 
diff --git a/versions/8.5.1/remote/persistent.mdx b/versions/8.5.1/remote/persistent.mdx
index 00024069..e2282cb5 100644
--- a/versions/8.5.1/remote/persistent.mdx
+++ b/versions/8.5.1/remote/persistent.mdx
@@ -257,7 +257,6 @@ For more information on persistent workers, see:
 *   [Original persistent workers blog post](https://blog.bazel.build/2015/12/10/java-workers.html)
 *   [Haskell implementation description](https://www.tweag.io/blog/2019-09-25-bazel-ghc-persistent-worker-internship/)
 *   [Blog post by Mike Morearty](https://medium.com/@mmorearty/how-to-create-a-persistent-worker-for-bazel-7738bba2cabb)
-*   [Front End Development with Bazel: Angular/TypeScript and Persistent Workers
-    w/ Asana](https://www.youtube.com/watch?v=0pgERydGyqo)
+*   [Front End Development with Bazel: Angular/TypeScript and Persistent Workers w/ Asana](https://www.youtube.com/watch?v=0pgERydGyqo)
 *   [Bazel strategies explained](https://jmmv.dev/2019/12/bazel-strategies.html)
 *   [Informative worker strategy discussion on the bazel-discuss mailing list](https://groups.google.com/forum/#!msg/bazel-discuss/oAEnuhYOPm8/ol7hf4KWJgAJ)
diff --git a/versions/8.5.1/remote/rules.mdx b/versions/8.5.1/remote/rules.mdx
index 239ecfcd..081fd75c 100644
--- a/versions/8.5.1/remote/rules.mdx
+++ b/versions/8.5.1/remote/rules.mdx
@@ -54,8 +54,7 @@ variables that may not be set to equivalent values (or at all) in the remote
 execution environment.
 
 Toolchain rules currently exist for Bazel build and test rules for
-[Scala](https://github.com/bazelbuild/rules_scala/blob/master/scala/scala_toolch
-ain.bzl),
+[Scala](https://github.com/bazelbuild/rules_scala/blob/master/scala/scala_toolch ain.bzl),
 [Rust](https://github.com/bazelbuild/rules_rust/blob/main/rust/toolchain.bzl),
 and [Go](https://github.com/bazelbuild/rules_go/blob/master/go/toolchains.rst),
 and new toolchain rules are under way for other languages and tools such as
diff --git a/versions/8.5.1/remote/workspace.mdx b/versions/8.5.1/remote/workspace.mdx
index ae1d1633..38401b77 100644
--- a/versions/8.5.1/remote/workspace.mdx
+++ b/versions/8.5.1/remote/workspace.mdx
@@ -11,8 +11,7 @@ on the host machine. If your workspace rules access information about the
 host machine for use during execution, your build is likely to break due to
 incompatibilities between the environments.
 
-As part of [adapting Bazel rules for remote
-execution](/versions/8.5.1/remote/rules), you need to find such workspace rules
+As part of [adapting Bazel rules for remote execution](/versions/8.5.1/remote/rules), you need to find such workspace rules
 and fix them. This page describes how to find potentially problematic workspace
 rules using the workspace log.
 
diff --git a/versions/8.5.1/rules/language.mdx b/versions/8.5.1/rules/language.mdx
index f267ce5d..1d05b185 100644
--- a/versions/8.5.1/rules/language.mdx
+++ b/versions/8.5.1/rules/language.mdx
@@ -93,10 +93,8 @@ values returned by rules are immutable.
 `BUILD` files register targets via making calls to rules. `.bzl` files provide
 definitions for constants, rules, macros, and functions.
 
-[Native functions](/versions/8.5.1/reference/be/functions) and [native rules](
-/reference/be/overview#language-specific-native-rules) are global symbols in
-`BUILD` files. `bzl` files need to load them using the [`native` module](
-/rules/lib/toplevel/native).
+[Native functions](/versions/8.5.1/reference/be/functions) and [native rules](/reference/be/overview#language-specific-native-rules) are global symbols in
+`BUILD` files. `bzl` files need to load them using the [`native` module](/rules/lib/toplevel/native).
 
 There are two syntactic restrictions in `BUILD` files: 1) declaring functions is
 illegal, and 2) `*args` and `**kwargs` arguments are not allowed.
diff --git a/versions/8.5.1/rules/legacy-macro-tutorial.mdx b/versions/8.5.1/rules/legacy-macro-tutorial.mdx
index 67e7944f..4e0993d1 100644
--- a/versions/8.5.1/rules/legacy-macro-tutorial.mdx
+++ b/versions/8.5.1/rules/legacy-macro-tutorial.mdx
@@ -3,9 +3,7 @@ title: 'Creating a Legacy Macro'
 ---
 
 IMPORTANT: This tutorial is for [*legacy macros*](/versions/8.5.1/extending/legacy-macros). If
-you only need to support Bazel 8 or newer, we recommend using [symbolic
-macros](/versions/8.5.1/extending/macros) instead; take a look at [Creating a Symbolic
-Macro](../macro-tutorial).
+you only need to support Bazel 8 or newer, we recommend using [symbolic macros](/versions/8.5.1/extending/macros) instead; take a look at [Creating a Symbolic Macro](../macro-tutorial).
 
 Imagine that you need to run a tool as part of your build. For example, you
 may want to generate or preprocess a source file, or compress a binary. In this
diff --git a/versions/8.5.1/rules/verbs-tutorial.mdx b/versions/8.5.1/rules/verbs-tutorial.mdx
index d10c8b69..d64dadb8 100644
--- a/versions/8.5.1/rules/verbs-tutorial.mdx
+++ b/versions/8.5.1/rules/verbs-tutorial.mdx
@@ -49,8 +49,7 @@ This pattern can also be seen in the Angular project. The
 produces two targets. The first is a standard `nodejs_test` target which compares
 some generated output against a "golden" file (that is, a file containing the
 expected output). This can be built and run with a normal `bazel
-test` invocation. In `angular-cli`, you can run [one such
-target](https://github.com/angular/angular-cli/blob/e1269cb520871ee29b1a4eec6e6c0e4a94f0b5fc/etc/api/BUILD)
+test` invocation. In `angular-cli`, you can run [one such target](https://github.com/angular/angular-cli/blob/e1269cb520871ee29b1a4eec6e6c0e4a94f0b5fc/etc/api/BUILD)
 with `bazel test //etc/api:angular_devkit_core_api`.
 
 Over time, this golden file may need to be updated for legitimate reasons.
diff --git a/versions/8.5.1/run/build.mdx b/versions/8.5.1/run/build.mdx
index ae6772ba..90af109a 100644
--- a/versions/8.5.1/run/build.mdx
+++ b/versions/8.5.1/run/build.mdx
@@ -633,8 +633,7 @@ Note: Hermeticity means that the action only uses its declared input
 files and no other files in the filesystem, and it only produces its declared
 output files. See [Hermeticity](/versions/8.5.1/basics/hermeticity) for more details.
 
-On some platforms such as [Google Kubernetes
-Engine](https://cloud.google.com/kubernetes-engine/) cluster nodes or Debian,
+On some platforms such as [Google Kubernetes Engine](https://cloud.google.com/kubernetes-engine/) cluster nodes or Debian,
 user namespaces are deactivated by default due to security
 concerns. This can be checked by looking at the file
 `/proc/sys/kernel/unprivileged_userns_clone`: if it exists and contains a 0,
diff --git a/versions/8.5.1/start/android-app.mdx b/versions/8.5.1/start/android-app.mdx
index 36dee1df..a1d32858 100644
--- a/versions/8.5.1/start/android-app.mdx
+++ b/versions/8.5.1/start/android-app.mdx
@@ -36,8 +36,7 @@ In this tutorial you learn how to:
 Before you begin the tutorial, install the following software:
 
 * **Bazel.** To install, follow the [installation instructions](/versions/8.5.1/install).
-* **Android Studio.** To install, follow the steps to [download Android
-  Studio](https://developer.android.com/sdk/index.html).
+* **Android Studio.** To install, follow the steps to [download Android Studio](https://developer.android.com/sdk/index.html).
   Execute the setup wizard to download the SDK and configure your environment.
 * (Optional) **Git.** Use `git` to download the Android app project.
 
@@ -52,8 +51,7 @@ This app has a single button that prints a greeting when clicked:
 
 **Figure 1.** Android app button greeting.
 
-Clone the repository with `git` (or [download the ZIP file
-directly](https://github.com/bazelbuild/examples/archive/master.zip)):
+Clone the repository with `git` (or [download the ZIP file directly](https://github.com/bazelbuild/examples/archive/master.zip)):
 
 ```posix-terminal
 git clone https://github.com/bazelbuild/examples
@@ -103,8 +101,7 @@ A [workspace](/versions/8.5.1/concepts/build-ref#workspace) is a directory that
 source files for one or more software projects, and has a `MODULE.bazel` file at
 its root.
 
-The `MODULE.bazel` file may be empty or may contain references to [external
-dependencies](/versions/8.5.1/external/overview) required to build your project.
+The `MODULE.bazel` file may be empty or may contain references to [external dependencies](/versions/8.5.1/external/overview) required to build your project.
 
 First, run the following command to create an empty `MODULE.bazel` file:
 
@@ -147,8 +144,7 @@ environment variable, and automatically detect the highest API level and the
 latest version of build tools installed within that location.
 
 You can set the `ANDROID_HOME` variable to the location of the Android SDK. Find
-the path to the installed SDK using Android Studio's [SDK
-Manager](https://developer.android.com/studio/intro/update#sdk-manager).
+the path to the installed SDK using Android Studio's [SDK Manager](https://developer.android.com/studio/intro/update#sdk-manager).
 Assuming the SDK is installed to default locations, you can use the following
 commands to set the `ANDROID_HOME` variable:
 
@@ -170,16 +166,14 @@ them permanent, run the following commands:
 | Windows (PowerShell)     | `[System.Environment]::SetEnvironmentVariable('ANDROID_HOME', "$env:LOCALAPPDATA\Android\Sdk", [System.EnvironmentVariableTarget]::User)` |
 
 **Optional:** If you want to compile native code into your Android app, you
-also need to download the [Android
-NDK](https://developer.android.com/ndk/downloads/index.html)
+also need to download the [Android NDK](https://developer.android.com/ndk/downloads/index.html)
 and use `rules_android_ndk` by adding the following line to your `MODULE.bazel` file:
 
 ```python
 bazel_dep(name = "rules_android_ndk", version = "0.1.2")
 ```
 
-For more information, read [Using the Android Native Development Kit with
-Bazel](/versions/8.5.1/docs/android-ndk).
+For more information, read [Using the Android Native Development Kit with Bazel](/versions/8.5.1/docs/android-ndk).
 
 It's not necessary to set the API levels to the same value for the SDK and NDK.
 [This page](https://developer.android.com/ndk/guides/stable_apis.html)
@@ -221,8 +215,7 @@ files or other dependencies. Bazel provides two build rules,
 build an Android app.
 
 For this tutorial, you'll first use the
-`android_library` rule to tell Bazel to build an [Android library
-module](http://developer.android.com/tools/projects/index.html#LibraryProjects)
+`android_library` rule to tell Bazel to build an [Android library module](http://developer.android.com/tools/projects/index.html#LibraryProjects)
 from the app source code and resource files. You'll then use the
 `android_binary` rule to tell Bazel how to build the Android application package.
 
@@ -337,11 +330,9 @@ file:
 ### Run the app
 
 You can now deploy the app to a connected Android device or emulator from the
-command line using the [`bazel
-mobile-install`](/versions/8.5.1/docs/user-manual#mobile-install) command. This command uses
+command line using the [`bazel mobile-install`](/versions/8.5.1/docs/user-manual#mobile-install) command. This command uses
 the Android Debug Bridge (`adb`) to communicate with the device. You must set up
-your device to use `adb` following the instructions in [Android Debug
-Bridge](http://developer.android.com/tools/help/adb.html) before deployment. You
+your device to use `adb` following the instructions in [Android Debug Bridge](http://developer.android.com/tools/help/adb.html) before deployment. You
 can also choose to install the app on the Android emulator included in Android
 Studio. Make sure the emulator is running before executing the command below.
 
diff --git a/versions/8.5.1/start/cpp.mdx b/versions/8.5.1/start/cpp.mdx
index 0a0cdd01..c94ddb33 100644
--- a/versions/8.5.1/start/cpp.mdx
+++ b/versions/8.5.1/start/cpp.mdx
@@ -19,8 +19,7 @@ Estimated completion time: 30 minutes.
 ### Prerequisites {#prerequisites}
 
 Start by [installing Bazel](https://bazel.build/versions/8.5.1/install), if you haven't
-already. This tutorial uses Git for source control, so for best results [install
-Git](https://git-scm.com/book/en/v2/Getting-Started-Installing-Git) as well.
+already. This tutorial uses Git for source control, so for best results [install Git](https://git-scm.com/book/en/v2/Getting-Started-Installing-Git) as well.
 
 Next, retrieve the sample project from Bazel's GitHub repository by running the
 following in your command-line tool of choice:
@@ -63,9 +62,7 @@ examples
 ```
 
 There are three sets of files, each set representing a stage in this tutorial.
-In the first stage, you will build a single [target]
-(https://bazel.build/reference/glossary#target) residing in a single [package]
-(https://bazel.build/reference/glossary#package). In the second stage, you will
+In the first stage, you will build a single [target](https://bazel.build/reference/glossary#target) residing in a single [package](https://bazel.build/reference/glossary#package). In the second stage, you will
 build both a binary and a library from a single package. In the third and final
 stage, you will build a project with multiple packages and build it with
 multiple targets.
@@ -86,8 +83,7 @@ It also contains these significant files:
 *   The `MODULE.bazel` file, which identifies the directory and its contents as
     a Bazel workspace and lives at the root of the project's directory
     structure. It's also where you specify your external dependencies.
-*   One or more [`BUILD`
-    files](https://bazel.build/reference/glossary#build-file), which tell Bazel
+*   One or more [`BUILD` files](https://bazel.build/reference/glossary#build-file), which tell Bazel
     how to build different parts of the project. A directory within the
     workspace that contains a `BUILD` file is a
     [package](https://bazel.build/versions/8.5.1/reference/glossary#package). (More on packages
@@ -182,9 +178,7 @@ This results in a printed "`Hello world`" message.
 
 Here's the dependency graph of Stage 1:
 
-![Dependency graph for hello-world displays a single target with a single source
-file.](/versions/8.5.1/docs/images/cpp-tutorial-stage1.png "Dependency graph for hello-world
-displays a single target with a single source file.")
+![Dependency graph for hello-world displays a single target with a single source file.](/versions/8.5.1/docs/images/cpp-tutorial-stage1.png "Dependency graph for hello-world displays a single target with a single source file.")
 
 ### Summary: stage 1 {#summary-stage-1}
 
@@ -231,8 +225,7 @@ cc_binary(
 ```
 
 With this `BUILD` file, Bazel first builds the `hello-greet` library (using
-Bazel's built-in [`cc_library`
-rule](https://bazel.build/reference/be/c-cpp#cc_library)), then the
+Bazel's built-in [`cc_library` rule](https://bazel.build/reference/be/c-cpp#cc_library)), then the
 `hello-world` binary. The `deps` attribute in the `hello-world` target tells
 Bazel that the `hello-greet` library is required to build the `hello-world`
 binary.
@@ -272,10 +265,7 @@ recompiles that file.
 Looking at the dependency graph, you can see that `hello-world` depends on an
 extra input named `hello-greet`:
 
-![Dependency graph for `hello-world` displays dependency changes after
-modification to the file.](/versions/8.5.1/docs/images/cpp-tutorial-stage2.png "Dependency
-graph for `hello-world` displays dependency changes after modification to the
-file.")
+![Dependency graph for `hello-world` displays dependency changes after modification to the file.](/versions/8.5.1/docs/images/cpp-tutorial-stage2.png "Dependency graph for `hello-world` displays dependency changes after modification to the file.")
 
 ### Summary: stage 2 {#summary-stage-2}
 
@@ -343,11 +333,7 @@ in the `lib` package (hence the target label `//lib:hello-time`) - Bazel knows
 this through the `deps` attribute. You can see this reflected in the dependency
 graph:
 
-![Dependency graph for `hello-world` displays how the target in the main package
-depends on the target in the `lib`
-package.](/versions/8.5.1/docs/images/cpp-tutorial-stage3.png "Dependency graph for
-`hello-world` displays how the target in the main package depends on the target
-in the `lib` package.")
+![Dependency graph for `hello-world` displays how the target in the main package depends on the target in the `lib` package.](/versions/8.5.1/docs/images/cpp-tutorial-stage3.png "Dependency graph for `hello-world` displays how the target in the main package depends on the target in the `lib` package.")
 
 For the build to succeed, you make the `//lib:hello-time` target in `lib/BUILD`
 explicitly visible to targets in `main/BUILD` using the visibility attribute.
@@ -395,15 +381,11 @@ Bazel journey.
 You've now completed your first basic build with Bazel, but this is just the
 start. Here are some more resources to continue learning with Bazel:
 
-*   To keep focusing on C++, read about common [C++ build use
-    cases](https://bazel.build/tutorials/cpp-use-cases).
+*   To keep focusing on C++, read about common [C++ build use cases](https://bazel.build/tutorials/cpp-use-cases).
 *   To get started with building other applications with Bazel, see the
-    tutorials for [Java](https://bazel.build/versions/8.5.1/start/java), [Android
-    application](https://bazel.build/start/android-app), or [iOS
-    application](https://bazel.build/start/ios-app).
+    tutorials for [Java](https://bazel.build/versions/8.5.1/start/java), [Android application](https://bazel.build/start/android-app), or [iOS application](https://bazel.build/start/ios-app).
 *   To learn more about working with local and remote repositories, read about
     [external dependencies](https://bazel.build/versions/8.5.1/docs/external).
-*   To learn more about Bazel's other rules, see this [reference
-    guide](https://bazel.build/rules).
+*   To learn more about Bazel's other rules, see this [reference guide](https://bazel.build/rules).
 
 Happy building!
\ No newline at end of file
diff --git a/versions/8.5.1/start/java.mdx b/versions/8.5.1/start/java.mdx
index 7799fd56..bf68cdd2 100644
--- a/versions/8.5.1/start/java.mdx
+++ b/versions/8.5.1/start/java.mdx
@@ -241,8 +241,7 @@ recompiles that file.
 Looking at the dependency graph, you can see that `ProjectRunner` depends on the
 same inputs as it did before, but the structure of the build is different:
 
-![Dependency graph of the target 'ProjectRunner' after adding a dependency](
-/docs/images/tutorial_java_02.svg)
+![Dependency graph of the target 'ProjectRunner' after adding a dependency](/docs/images/tutorial_java_02.svg)
 
 You've now built the project with two targets. The `ProjectRunner` target builds
 one source files and depends on one other target (`:greeter`), which builds
diff --git a/versions/8.5.1/tutorials/ccp-toolchain-config.mdx b/versions/8.5.1/tutorials/ccp-toolchain-config.mdx
index d5a25f6a..fbc6c01e 100644
--- a/versions/8.5.1/tutorials/ccp-toolchain-config.mdx
+++ b/versions/8.5.1/tutorials/ccp-toolchain-config.mdx
@@ -29,8 +29,7 @@ uses `clang version 16`, which you can install on your system.
 
 Set up your build environment as follows:
 
-1.  If you have not already done so, [download and install Bazel
-    7.0.2](https://bazel.build/install) or later.
+1.  If you have not already done so, [download and install Bazel 7.0.2](https://bazel.build/install) or later.
 
 2.  Add an empty `MODULE.bazel` file at the root folder.
 
@@ -450,8 +449,7 @@ The key takeaways are:
 
 -   You need to specify a matching `platforms` flag in the command line for
     Bazel to resolve to the toolchain for the same constraint values on the
-    platform. The documentation holds more [information about language specific
-    configuration flags](/versions/8.5.1/concepts/platforms).
+    platform. The documentation holds more [information about language specific configuration flags](/versions/8.5.1/concepts/platforms).
 -   You have to let the toolchain know where the tools live. In this tutorial
     there is a simplified version where you access the tools from the system. If
     you are interested in a more self-contained approach, you can read about
@@ -464,5 +462,4 @@ The key takeaways are:
 
 ## Further reading {#further-reading}
 
-For more details, see [C++ toolchain
-configuration](/versions/8.5.1/docs/cc-toolchain-config-reference)
\ No newline at end of file
+For more details, see [C++ toolchain configuration](/versions/8.5.1/docs/cc-toolchain-config-reference)
\ No newline at end of file
diff --git a/versions/8.6.0/about/roadmap.mdx b/versions/8.6.0/about/roadmap.mdx
index eca79ea8..ab827814 100644
--- a/versions/8.6.0/about/roadmap.mdx
+++ b/versions/8.6.0/about/roadmap.mdx
@@ -13,8 +13,7 @@ projects.
 
 ## Bazel 8.0 Release
 
-We plan to bring Bazel 8.0 [long term support
-(LTS)](https://bazel.build/versions/8.6.0/release/versioning) to you in late 2024.
+We plan to bring Bazel 8.0 [long term support (LTS)](https://bazel.build/versions/8.6.0/release/versioning) to you in late 2024.
 The following features are planned to be implemented.
 
 ### Bzlmod: external dependency management system
@@ -29,8 +28,7 @@ support will be removed. Starting with Bazel 7.1, you can set
 `--noenable_workspace` to opt into the new behavior.
 
 Bazel 8.0 will contain a number of enhancements to
-[Bazel's external dependency management]
-(https://docs.google.com/document/d/1moQfNcEIttsk6vYanNKIy3ZuK53hQUFq1b1r0rmsYVg/edit#heading=h.lgyp7ubwxmjc)
+[Bazel's external dependency management](https://docs.google.com/document/d/1moQfNcEIttsk6vYanNKIy3ZuK53hQUFq1b1r0rmsYVg/edit#heading=h.lgyp7ubwxmjc)
 functionality, including:
 
 *   The new flag `--enable_workspace` can be set to `false` to completely
diff --git a/versions/8.6.0/basics/dependencies.mdx b/versions/8.6.0/basics/dependencies.mdx
index f8468dc5..f5c12ee0 100644
--- a/versions/8.6.0/basics/dependencies.mdx
+++ b/versions/8.6.0/basics/dependencies.mdx
@@ -65,8 +65,7 @@ targets, we’ve made some strides in mitigating the downside by investing in
 tooling to automatically manage `BUILD` files to avoid burdening developers.
 
 Some of these tools, such as `buildifier` and `buildozer`, are available with
-Bazel in the [`buildtools`
-directory](https://github.com/bazelbuild/buildtools).
+Bazel in the [`buildtools` directory](https://github.com/bazelbuild/buildtools).
 
 ## Minimizing Module Visibility
 
@@ -106,8 +105,7 @@ transitive dependencies (Figure 1). Suppose target A depends on target B, which
 depends on a common library target C. Should target A be able to use classes
 defined in target C?
 
-[![Transitive
-dependencies](/versions/8.6.0/images/transitive-dependencies.png)](/versions/8.6.0/images/transitive-dependencies.png)
+[![Transitive dependencies](/versions/8.6.0/images/transitive-dependencies.png)](/versions/8.6.0/images/transitive-dependencies.png)
 
 **Figure 1**. Transitive dependencies
 
@@ -141,9 +139,7 @@ dependencies and adding them to a `BUILD` files without any developer
 intervention. But even without such tools, we’ve found the trade-off to be well
 worth it as the codebase scales: explicitly adding a dependency to `BUILD` file
 is a one-time cost, but dealing with implicit transitive dependencies can cause
-ongoing problems as long as the build target exists. Bazel [enforces strict
-transitive
-dependencies](https://blog.bazel.build/2017/06/28/sjd-unused_deps.html)
+ongoing problems as long as the build target exists. Bazel [enforces strict transitive dependencies](https://blog.bazel.build/2017/06/28/sjd-unused_deps.html)
 on Java code by default.
 
 ### External dependencies
@@ -192,8 +188,7 @@ so in theory there’s no reason that different versions of the same external
 dependency couldn’t both be declared in the build system under different names.
 That way, each target could choose which version of the dependency it wanted to
 use. This causes a lot of problems in practice, so Google enforces a strict
-[One-Version
-Rule](https://opensource.google/docs/thirdparty/oneversion/) for
+[One-Version Rule](https://opensource.google/docs/thirdparty/oneversion/) for
 all third-party dependencies in our codebase.
 
 The biggest problem with allowing multiple versions is the diamond dependency
@@ -232,8 +227,7 @@ Bazel did not use to automatically download transitive dependencies. It used to
 employ a `WORKSPACE` file that required all transitive dependencies to be
 listed, which led to a lot of pain when managing external dependencies. Bazel
 has since added support for automatic transitive external dependency management
-in the form of the `MODULE.bazel` file. See [external dependency
-overview](/versions/8.6.0/external/overview) for more details.
+in the form of the `MODULE.bazel` file. See [external dependency overview](/versions/8.6.0/external/overview) for more details.
 
 Yet again, the choice here is one between convenience and scalability. Small
 projects might prefer not having to worry about managing transitive dependencies
diff --git a/versions/8.6.0/community/roadmaps-configurability.mdx b/versions/8.6.0/community/roadmaps-configurability.mdx
index 9f44bdce..9b59928b 100644
--- a/versions/8.6.0/community/roadmaps-configurability.mdx
+++ b/versions/8.6.0/community/roadmaps-configurability.mdx
@@ -24,8 +24,7 @@ title: 'Bazel Configurability 2021 Roadmap'
 * Builds scale well, particularly w.r.t graph size and action caching.
 
 We also support
-[`cquery`](https://bazel.build/versions/8.6.0/query/cquery), [`Starlark
-configuration`](https://bazel.build/versions/8.6.0/extending/config),
+[`cquery`](https://bazel.build/versions/8.6.0/query/cquery), [`Starlark configuration`](https://bazel.build/versions/8.6.0/extending/config),
 and
 [`select()`](https://bazel.build/versions/8.6.0/docs/configurable-attributes).
 
@@ -39,15 +38,13 @@ interest of accurate expectations.
 ### Platforms
 
 

-Q3 2021**Android rules use the new [platforms
-API](https://bazel.build/versions/8.6.0/concepts/platforms)**
+Q3 2021**Android rules use the new [platforms API](https://bazel.build/versions/8.6.0/concepts/platforms)**
 IN PROGRESS ([#11749](https://github.com/bazelbuild/bazel/issues/11749))
 
 * This is our main priority for the beginning of 2021.
 
 

-Q3 2021**Builds support [multiple execution
-platforms](https://docs.google.com/document/d/1U9HzdDmtRnm244CaRM6JV-q2408mbNODAMewcGjnnbM/)**
+Q3 2021**Builds support [multiple execution platforms](https://docs.google.com/document/d/1U9HzdDmtRnm244CaRM6JV-q2408mbNODAMewcGjnnbM/)**
 IN PROGRESS ([#11748](https://github.com/bazelbuild/bazel/issues/11748))
 
 

diff --git a/versions/8.6.0/community/sig.mdx b/versions/8.6.0/community/sig.mdx
index a0750f8c..1665204d 100644
--- a/versions/8.6.0/community/sig.mdx
+++ b/versions/8.6.0/community/sig.mdx
@@ -3,8 +3,7 @@ title: 'Bazel Special Interest Groups'
 ---
 
 Bazel hosts Special Interest Groups (SIGs) to focus collaboration on particular
-areas and to support communication and coordination between [Bazel owners,
-maintainers, and contributors](/versions/8.6.0/contribute/policy). This policy
+areas and to support communication and coordination between [Bazel owners, maintainers, and contributors](/versions/8.6.0/contribute/policy). This policy
 applies to [`bazelbuild`](http://github.com/bazelbuild).
 
 SIGs do their work in public. The ideal scope for a SIG covers a well-defined
diff --git a/versions/8.6.0/community/users.mdx b/versions/8.6.0/community/users.mdx
index c8477097..fa45a7f5 100644
--- a/versions/8.6.0/community/users.mdx
+++ b/versions/8.6.0/community/users.mdx
@@ -304,11 +304,9 @@ safety systems_.
 Pigweed is an open-source solution for sustained, robust, and rapid embedded
 product development for large teams. Pigweed has shipped in millions of
 devices, including Google's suite of Pixel devices, Nest thermostats,
-[satellites](https://www.spinlaunch.com/), and [autonomous aerial
-drones](https://www.flyzipline.com/).
+[satellites](https://www.spinlaunch.com/), and [autonomous aerial drones](https://www.flyzipline.com/).
 
-Pigweed [uses Bazel as its primary build
-system](https://pigweed.dev/seed/0111-build-systems.html). The [Bazel for
+Pigweed [uses Bazel as its primary build system](https://pigweed.dev/seed/0111-build-systems.html). The [Bazel for
 Embedded][pw-bazel-great] blog post discusses why we think it's a great build
 system for embedded projects!
 
diff --git a/versions/8.6.0/concepts/build-files.mdx b/versions/8.6.0/concepts/build-files.mdx
index 08b5904a..09f8ae87 100644
--- a/versions/8.6.0/concepts/build-files.mdx
+++ b/versions/8.6.0/concepts/build-files.mdx
@@ -132,18 +132,3 @@ for anyone to create new rules.
     programming language. Libraries can depend on other libraries,
     and binaries and tests can depend on libraries, with the expected
     separate-compilation behavior.
-
-
-  
-    
-    
-  
-

-      
-        Labels
-      
-    
-      
-        Dependencies
-      
-    

diff --git a/versions/8.6.0/concepts/build-ref.mdx b/versions/8.6.0/concepts/build-ref.mdx
index 3bdee30b..07f25559 100644
--- a/versions/8.6.0/concepts/build-ref.mdx
+++ b/versions/8.6.0/concepts/build-ref.mdx
@@ -17,8 +17,7 @@ its root; such a boundary marker file could be `MODULE.bazel`, `REPO.bazel`, or
 in legacy contexts, `WORKSPACE` or `WORKSPACE.bazel`.
 
 The repo in which the current Bazel command is being run is called the _main
-repo_. Other, (external) repos are defined by _repo rules_; see [external
-dependencies overview](/versions/8.6.0/external/overview) for more information.
+repo_. Other, (external) repos are defined by _repo rules_; see [external dependencies overview](/versions/8.6.0/external/overview) for more information.
 
 ## Workspace
 
@@ -95,9 +94,4 @@ have three properties: the list of packages they contain, their name, and other
 package groups they include. The only allowed ways to refer to them are from the
 `visibility` attribute of rules or from the `default_visibility` attribute of
 the `package` function; they do not generate or consume files. For more
-information, refer to the [`package_group`
-documentation](/versions/8.6.0/reference/be/functions#package_group).
-
-
-  Labels
-
\ No newline at end of file
+information, refer to the [`package_group` documentation](/versions/8.6.0/reference/be/functions#package_group).
diff --git a/versions/8.6.0/concepts/dependencies.mdx b/versions/8.6.0/concepts/dependencies.mdx
index b1d14626..adc54f0d 100644
--- a/versions/8.6.0/concepts/dependencies.mdx
+++ b/versions/8.6.0/concepts/dependencies.mdx
@@ -366,19 +366,3 @@ filegroup(
 ```
 
 You can then reference the label `my_data` as the data dependency in your test.
-
-
-  
-    
-    
-  
-

-      
-        BUILD files
-      
-    
-      
-        Visibility
-      
-    

-
diff --git a/versions/8.6.0/concepts/labels.mdx b/versions/8.6.0/concepts/labels.mdx
index 87dfe0cd..baf3b322 100644
--- a/versions/8.6.0/concepts/labels.mdx
+++ b/versions/8.6.0/concepts/labels.mdx
@@ -10,8 +10,7 @@ form looks like:
 ```
 
 The first part of the label is the repository name, `@@myrepo`. The double-`@`
-syntax signifies that this is a [*canonical* repo
-name](/versions/8.6.0/external/overview#canonical-repo-name), which is unique within
+syntax signifies that this is a [*canonical* repo name](/versions/8.6.0/external/overview#canonical-repo-name), which is unique within
 the workspace. Labels with canonical repo names unambiguously identify a target
 no matter which context they appear in.
 
@@ -239,18 +238,3 @@ the build.
 This directed acyclic graph over targets is called the _target graph_ or
 _build dependency graph_, and is the domain over which the
 [Bazel Query tool](/versions/8.6.0/query/guide) operates.
-
-
-  
-    
-    
-  
-

-      
-        Targets
-      
-    
-      
-        BUILD files
-      
-    

diff --git a/versions/8.6.0/concepts/platforms.mdx b/versions/8.6.0/concepts/platforms.mdx
index d5dff662..5b417e96 100644
--- a/versions/8.6.0/concepts/platforms.mdx
+++ b/versions/8.6.0/concepts/platforms.mdx
@@ -77,8 +77,7 @@ To test your Android project with platforms, see
 for support.
 
 You can still use platform APIs with Apple builds (for example, when building
-with a mixture of Apple rules and pure C++) with [platform
-mappings](#platform-mappings).
+with a mixture of Apple rules and pure C++) with [platform mappings](#platform-mappings).
 
 ### Other languages
 
@@ -241,8 +240,7 @@ sets `--cpu`, `--crossstool_top`, or other legacy flags, rules that read
 
 When migrating your project to platforms, you must either convert changes like
 `return { "//command_line_option:cpu": "arm" }` to `return {
-"//command_line_option:platforms": "//:my_arm_platform" }` or use [platform
-mappings](#platform-mappings) to support both styles during migration.
+"//command_line_option:platforms": "//:my_arm_platform" }` or use [platform mappings](#platform-mappings) to support both styles during migration.
 window.
 
 ## Migrating your rule set
@@ -361,10 +359,8 @@ attributes declare a language's tools (like `compiler =
 this information to rules that need to build with these tools.
 
 Toolchains declare the `constraint_value`s of machines they can
-[target][target_compatible_with Attribute]
-(`target_compatible_with = ["@platforms//os:linux"]`) and machines their tools can
-[run on][exec_compatible_with Attribute]
-(`exec_compatible_with = ["@platforms//os:mac"]`).
+[target][target_compatible_with Attribute](`target_compatible_with = ["@platforms//os:linux"]`) and machines their tools can
+[run on][exec_compatible_with Attribute](`exec_compatible_with = ["@platforms//os:mac"]`).
 
 When building `$ bazel build //:myproject --platforms=//:myplatform`, Bazel
 automatically selects a toolchain that can run on the build machine and
diff --git a/versions/8.6.0/configure/attributes.mdx b/versions/8.6.0/configure/attributes.mdx
index 3d7793f0..16188682 100644
--- a/versions/8.6.0/configure/attributes.mdx
+++ b/versions/8.6.0/configure/attributes.mdx
@@ -2,8 +2,7 @@
 title: 'Configurable Build Attributes'
 ---
 
-**_Configurable attributes_**, commonly known as [`select()`](
-/reference/be/functions#select), is a Bazel feature that lets users toggle the values
+**_Configurable attributes_**, commonly known as [`select()`](/reference/be/functions#select), is a Bazel feature that lets users toggle the values
 of build rule attributes at the command line.
 
 This can be used, for example, for a multiplatform library that automatically
@@ -407,8 +406,7 @@ sh_library(
 )
 ```
 
-If you need a `select` to match when multiple conditions match, consider [AND
-chaining](#and-chaining).
+If you need a `select` to match when multiple conditions match, consider [AND chaining](#and-chaining).
 
 ## OR chaining
 
diff --git a/versions/8.6.0/configure/integrate-cpp.mdx b/versions/8.6.0/configure/integrate-cpp.mdx
index e623e085..2b4a6a71 100644
--- a/versions/8.6.0/configure/integrate-cpp.mdx
+++ b/versions/8.6.0/configure/integrate-cpp.mdx
@@ -33,8 +33,7 @@ This is because when writing our own actions, they must behave
 consistently with the C++ toolchain - for example, passing C++ command line
 flags to a tool that invokes the C++ compiler behind the scenes.
 
-C++ rules use a special way of constructing command lines based on [feature
-configuration](/versions/8.6.0/docs/cc-toolchain-config-reference). To construct a command line,
+C++ rules use a special way of constructing command lines based on [feature configuration](/versions/8.6.0/docs/cc-toolchain-config-reference). To construct a command line,
 you need the following:
 
 * `features` and `action_configs` - these come from the `CcToolchainConfigInfo`
diff --git a/versions/8.6.0/configure/windows.mdx b/versions/8.6.0/configure/windows.mdx
index 8de464a8..2658dc77 100644
--- a/versions/8.6.0/configure/windows.mdx
+++ b/versions/8.6.0/configure/windows.mdx
@@ -166,8 +166,7 @@ To build C++ targets with MSVC, you need:
         set BAZEL_VC=C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC
         ```
 
-*   The [Windows
-    SDK](https://developer.microsoft.com/en-us/windows/downloads/windows-10-sdk).
+*   The [Windows SDK](https://developer.microsoft.com/en-us/windows/downloads/windows-10-sdk).
 
     The Windows SDK contains header files and libraries you need when building
     Windows applications, including Bazel itself. By default, the latest Windows SDK installed will
@@ -186,8 +185,7 @@ To build C++ targets with MSVC, you need:
 
 If everything is set up, you can build a C++ target now!
 
-Try building a target from one of our [sample
-projects](https://github.com/bazelbuild/bazel/tree/master/examples):
+Try building a target from one of our [sample projects](https://github.com/bazelbuild/bazel/tree/master/examples):
 
 
 
 
-To build and use Dynamically Linked Libraries (DLL files), see [this
-example](https://github.com/bazelbuild/bazel/tree/master/examples/windows/dll).
+To build and use Dynamically Linked Libraries (DLL files), see [this example](https://github.com/bazelbuild/bazel/tree/master/examples/windows/dll).
 
 **Command Line Length Limit**: To prevent the
 [Windows command line length limit issue](https://github.com/bazelbuild/bazel/issues/5163),
@@ -292,8 +289,7 @@ On Windows, Bazel builds two output files for `java_binary` rules:
 *   a `.jar` file
 *   a `.exe` file that can set up the environment for the JVM and run the binary
 
-Try building a target from one of our [sample
-projects](https://github.com/bazelbuild/bazel/tree/master/examples):
+Try building a target from one of our [sample projects](https://github.com/bazelbuild/bazel/tree/master/examples):
 
 
   bazel build //examples/java-native/src/main/java/com/example/ myproject :hello-world
@@ -315,8 +311,7 @@ On Windows, Bazel builds two output files for `py_binary` rules:
 You can either run the executable file (it has a `.exe` extension) or you can run
 Python with the self-extracting zip file as the argument.
 
-Try building a target from one of our [sample
-projects](https://github.com/bazelbuild/bazel/tree/master/examples):
+Try building a target from one of our [sample projects](https://github.com/bazelbuild/bazel/tree/master/examples):
 
 
   
 
 If you are interested in details about how Bazel builds Python targets on
-Windows, check out this [design
-doc](https://github.com/bazelbuild/bazel-website/blob/master/designs/_posts/2016-09-05-build-python-on-windows.md).
+Windows, check out this [design doc](https://github.com/bazelbuild/bazel-website/blob/master/designs/_posts/2016-09-05-build-python-on-windows.md).
diff --git a/versions/8.6.0/contribute/codebase.mdx b/versions/8.6.0/contribute/codebase.mdx
index 7e53f654..1ca571eb 100644
--- a/versions/8.6.0/contribute/codebase.mdx
+++ b/versions/8.6.0/contribute/codebase.mdx
@@ -227,8 +227,7 @@ repository", the others are called "external repositories".
 A repository is marked by a repo boundary file (`MODULE.bazel`, `REPO.bazel`, or
 in legacy contexts, `WORKSPACE` or `WORKSPACE.bazel`) in its root directory. The
 main repo is the source tree where you're invoking Bazel from. External repos
-are defined in various ways; see [external dependencies
-overview](/versions/8.6.0/external/overview) for more information.
+are defined in various ways; see [external dependencies overview](/versions/8.6.0/external/overview) for more information.
 
 Code of external repositories is symlinked or downloaded under
 `$OUTPUT_BASE/external`.
diff --git a/versions/8.6.0/contribute/design-documents.mdx b/versions/8.6.0/contribute/design-documents.mdx
index 49f8687a..89f58251 100644
--- a/versions/8.6.0/contribute/design-documents.mdx
+++ b/versions/8.6.0/contribute/design-documents.mdx
@@ -137,8 +137,7 @@ A lead reviewer should be a domain expert who is:
 *   Objective and capable of providing constructive feedback
 *   Available for the entire review period to lead the process
 
-Consider checking the contacts for various [team
-labels](/versions/8.6.0/contribute/maintainers-guide#team-labels).
+Consider checking the contacts for various [team labels](/versions/8.6.0/contribute/maintainers-guide#team-labels).
 
 ## Markdown vs Google Docs
 
@@ -168,12 +167,10 @@ Markdown for posterity.
 
 ### Using Google Docs
 
-For consistency, use the [Bazel design doc template](
-https://docs.google.com/document/d/1cE5zrjrR40RXNg64XtRFewSv6FrLV6slGkkqxBumS1w/edit).
+For consistency, use the [Bazel design doc template](https://docs.google.com/document/d/1cE5zrjrR40RXNg64XtRFewSv6FrLV6slGkkqxBumS1w/edit).
 It includes the necessary header and creates visual
 consistency with other Bazel related documents. To do that, click on **File** >
-**Make a copy** or click this link to [make a copy of the design doc
-template](https://docs.google.com/document/d/1cE5zrjrR40RXNg64XtRFewSv6FrLV6slGkkqxBumS1w/copy).
+**Make a copy** or click this link to [make a copy of the design doc template](https://docs.google.com/document/d/1cE5zrjrR40RXNg64XtRFewSv6FrLV6slGkkqxBumS1w/copy).
 
 To make your document readable to the world, click on
 **Share** > **Advanced** > **Change…**, and
diff --git a/versions/8.6.0/contribute/index.mdx b/versions/8.6.0/contribute/index.mdx
index ddb05621..45c2b05c 100644
--- a/versions/8.6.0/contribute/index.mdx
+++ b/versions/8.6.0/contribute/index.mdx
@@ -10,8 +10,7 @@ As you use Bazel, you may find things that can be improved.
 You can help by [reporting issues](http://github.com/bazelbuild/bazel/issues)
 when:
 
-   - Bazel crashes or you encounter a bug that can [only be resolved using `bazel
-     clean`](/versions/8.6.0/run/build#correct-incremental-rebuilds).
+   - Bazel crashes or you encounter a bug that can [only be resolved using `bazel clean`](/versions/8.6.0/run/build#correct-incremental-rebuilds).
    - The documentation is incomplete or unclear. You can also report issues
      from the page you are viewing by using the "Create issue"
      link at the top right corner of the page.
@@ -21,11 +20,9 @@ when:
 
 You can engage with the Bazel community by:
 
-   - Answering questions [on Stack Overflow](
-     https://stackoverflow.com/questions/tagged/bazel).
+   - Answering questions [on Stack Overflow](https://stackoverflow.com/questions/tagged/bazel).
    - Helping other users [on Slack](https://slack.bazel.build).
-   - Improving documentation or [contributing examples](
-     https://github.com/bazelbuild/examples).
+   - Improving documentation or [contributing examples](https://github.com/bazelbuild/examples).
    - Sharing your experience or your tips, for example, on a blog or social media.
 
 ## Contribute code
@@ -40,8 +37,7 @@ You can contribute to the Bazel ecosystem by:
    - Contributing to Bazel-related tools, for example, migration tools.
    - Improving Bazel integration with other IDEs and tools.
 
-Before making a change, [create a GitHub
-issue](http://github.com/bazelbuild/bazel/issues)
+Before making a change, [create a GitHub issue](http://github.com/bazelbuild/bazel/issues)
 or email [bazel-discuss@](mailto:bazel-discuss@googlegroups.com).
 
 The most helpful contributions fix bugs or add features (as opposed
diff --git a/versions/8.6.0/contribute/maintainers-guide.mdx b/versions/8.6.0/contribute/maintainers-guide.mdx
index 88ddab31..067262e8 100644
--- a/versions/8.6.0/contribute/maintainers-guide.mdx
+++ b/versions/8.6.0/contribute/maintainers-guide.mdx
@@ -4,8 +4,7 @@ title: 'Guide for Bazel Maintainers'
 
 This is a guide for the maintainers of the Bazel open source project.
 
-If you are looking to contribute to Bazel, please read [Contributing to
-Bazel](/versions/8.6.0/contribute) instead.
+If you are looking to contribute to Bazel, please read [Contributing to Bazel](/versions/8.6.0/contribute) instead.
 
 The objectives of this page are to:
 
@@ -37,8 +36,7 @@ repository.
 
 1. A user creates an issue by choosing one of the
 [issue templates](https://github.com/bazelbuild/bazel/issues/new/choose)
-   and it enters the pool of [unreviewed open
-   issues](https://github.com/bazelbuild/bazel/issues?utf8=%E2%9C%93&q=is%3Aissue+is%3Aopen+-label%3Auntriaged+-label%3Ap2+-label%3Ap1+-label%3Ap3+-label%3Ap4+-label%3Ateam-Starlark+-label%3Ateam-Rules-CPP+-label%3Ateam-Rules-Java+-label%3Ateam-XProduct+-label%3Ateam-Android+-label%3Ateam-Apple+-label%3Ateam-Configurability++-label%3Ateam-Performance+-label%3Ateam-Rules-Server+-label%3Ateam-Core+-label%3Ateam-Rules-Python+-label%3Ateam-Remote-Exec+-label%3Ateam-Local-Exec+-label%3Ateam-Bazel).
+   and it enters the pool of [unreviewed open issues](https://github.com/bazelbuild/bazel/issues?utf8=%E2%9C%93&q=is%3Aissue+is%3Aopen+-label%3Auntriaged+-label%3Ap2+-label%3Ap1+-label%3Ap3+-label%3Ap4+-label%3Ateam-Starlark+-label%3Ateam-Rules-CPP+-label%3Ateam-Rules-Java+-label%3Ateam-XProduct+-label%3Ateam-Android+-label%3Ateam-Apple+-label%3Ateam-Configurability++-label%3Ateam-Performance+-label%3Ateam-Rules-Server+-label%3Ateam-Core+-label%3Ateam-Rules-Python+-label%3Ateam-Remote-Exec+-label%3Ateam-Local-Exec+-label%3Ateam-Bazel).
 1. A member on the Developer Experience (DevEx) subteam rotation reviews the
    issue.
    1. If the issue is **not a bug** or a **feature request**, the DevEx member
@@ -58,21 +56,18 @@ repository.
 1. After reviewing the issue, the DevEx member decides if the issue requires
    immediate attention. If it does, they will assign the **P0**
    [priority](#priority) label and an owner from the list of team leads.
-1. The DevEx member assigns the `untriaged` label and exactly one [team
-   label](#team-labels) for routing.
+1. The DevEx member assigns the `untriaged` label and exactly one [team label](#team-labels) for routing.
 1. The DevEx member also assigns exactly one `type:` label, such as `type: bug`
    or `type: feature request`, according to the type of the issue.
 1. For platform-specific issues, the DevEx member assigns one `platform:` label,
    such as `platform:apple` for Mac-specific issues.
 1. If the issue is low priority and can be worked on by a new community
    contributor, the DevEx member assigns the `good first issue` label.
-At this stage, the issue enters the pool of [untriaged open
-issues](https://github.com/bazelbuild/bazel/issues?q=is%3Aissue+is%3Aopen+label%3Auntriaged).
+At this stage, the issue enters the pool of [untriaged open issues](https://github.com/bazelbuild/bazel/issues?q=is%3Aissue+is%3Aopen+label%3Auntriaged).
 
 Each Bazel subteam will triage all issues under labels they own, preferably on a
 weekly basis. The subteam will review and evaluate the issue and provide a
-resolution, if possible. If you are an owner of a team label, see [this section
-](#label-own) for more information.
+resolution, if possible. If you are an owner of a team label, see [this section](#label-own) for more information.
 
 When an issue is resolved, it can be closed.
 
@@ -111,8 +106,7 @@ preferably on a weekly basis.
      issue is either P0 or P1 we assume that is actively worked on.
 1. Remove the `untriaged` label.
 
-Note that you need to be in the [bazelbuild
-organization](https://github.com/bazelbuild) to be able to add or remove labels.
+Note that you need to be in the [bazelbuild organization](https://github.com/bazelbuild) to be able to add or remove labels.
 
 ### Pull Requests
 
@@ -138,8 +132,7 @@ issues.
   unusable, or a downed service that severely impacts development of the Bazel
   project. This includes regressions introduced in a new release that blocks a
   significant number of users, or an incompatible breaking change that was not
-  compliant to the [Breaking
-  Change](https://docs.google.com/document/d/1q5GGRxKrF_mnwtaPKI487P8OdDRh2nN7jX6U-FXnHL0/edit?pli=1#heading=h.ceof6vpkb3ik)
+  compliant to the [Breaking Change](https://docs.google.com/document/d/1q5GGRxKrF_mnwtaPKI487P8OdDRh2nN7jX6U-FXnHL0/edit?pli=1#heading=h.ceof6vpkb3ik)
   policy. No practical workaround exists.
 * [**P1**](https://github.com/bazelbuild/bazel/labels/P1) - Critical defect or
   feature which should be addressed in the next release, or a serious issue that
diff --git a/versions/8.6.0/contribute/naming.mdx b/versions/8.6.0/contribute/naming.mdx
index 33fe009a..f658ea83 100644
--- a/versions/8.6.0/contribute/naming.mdx
+++ b/versions/8.6.0/contribute/naming.mdx
@@ -4,8 +4,7 @@ title: 'Naming a Bazel related project'
 
 First, thank you for contributing to the Bazel ecosystem! Please reach out to
 the Bazel community on the
-[bazel-discuss mailing list](https://groups.google.com/forum/#!forum/bazel-discuss
-) to share your project and its suggested name.
+[bazel-discuss mailing list](https://groups.google.com/forum/#!forum/bazel-discuss) to share your project and its suggested name.
 
 If you are building a Bazel related tool or sharing your Skylark rules,
 we recommend following these guidelines for the name of your project:
diff --git a/versions/8.6.0/contribute/patch-acceptance.mdx b/versions/8.6.0/contribute/patch-acceptance.mdx
index 5cc10911..7055d86a 100644
--- a/versions/8.6.0/contribute/patch-acceptance.mdx
+++ b/versions/8.6.0/contribute/patch-acceptance.mdx
@@ -11,29 +11,24 @@ code base.
    need a corresponding issue for tracking.
 1. If you're proposing significant changes, write a
    [design document](/versions/8.6.0/contribute/design-documents).
-1. Ensure you've signed a [Contributor License
-   Agreement](https://cla.developers.google.com).
+1. Ensure you've signed a [Contributor License Agreement](https://cla.developers.google.com).
 1. Prepare a git commit that implements the feature. Don't forget to add tests
    and update the documentation. If your change has user-visible effects, please
    [add release notes](/versions/8.6.0/contribute/release-notes). If it is an incompatible change,
    read the [guide for rolling out breaking changes](/versions/8.6.0/contribute/breaking-changes).
 1. Create a pull request on
    [GitHub](https://github.com/bazelbuild/bazel/pulls). If you're new to GitHub,
-   read [about pull
-   requests](https://help.github.com/articles/about-pull-requests/). Note that
+   read [about pull requests](https://help.github.com/articles/about-pull-requests/). Note that
    we restrict permissions to create branches on the main Bazel repository, so
-   you will need to push your commit to [your own fork of the
-   repository](https://help.github.com/articles/working-with-forks/).
+   you will need to push your commit to [your own fork of the repository](https://help.github.com/articles/working-with-forks/).
 1. A Bazel maintainer should assign you a reviewer within two business days
    (excluding holidays in the USA and Germany). If you aren't assigned a
    reviewer in that time, you can request one by emailing
-   [bazel-discuss@googlegroups.com]
-   (mailto:bazel-discuss@googlegroups.com).
+   [bazel-discuss@googlegroups.com](mailto:bazel-discuss@googlegroups.com).
 1. Work with the reviewer to complete a code review. For each change, create a
    new commit and push it to make changes to your pull request. If the review
    takes too long (for instance, if the reviewer is unresponsive), send an email to
-   [bazel-discuss@googlegroups.com]
-   (mailto:bazel-discuss@googlegroups.com).
+   [bazel-discuss@googlegroups.com](mailto:bazel-discuss@googlegroups.com).
 1. After your review is complete, a Bazel maintainer applies your patch to
    Google's internal version control system.
 
diff --git a/versions/8.6.0/contribute/release-notes.mdx b/versions/8.6.0/contribute/release-notes.mdx
index 9b362325..f9cc9536 100644
--- a/versions/8.6.0/contribute/release-notes.mdx
+++ b/versions/8.6.0/contribute/release-notes.mdx
@@ -16,8 +16,7 @@ the release announcement.
 * If the change adds / removes / changes Bazel in a user-visible way, then it
   may be advantageous to mention it.
 
-If the change is significant, follow the [design document
-policy](/versions/8.6.0/contribute/design-documents) first.
+If the change is significant, follow the [design document policy](/versions/8.6.0/contribute/design-documents) first.
 
 ## Guidelines
 
@@ -60,10 +59,8 @@ change is about.
 
 ## Process
 
-As part of the [release
-process](https://github.com/bazelbuild/continuous-integration/blob/master/docs/release-playbook.md),
-we collect the `RELNOTES` tags of every commit. We copy everything in a [Google
-Doc](https://docs.google.com/document/d/1wDvulLlj4NAlPZamdlEVFORks3YXJonCjyuQMUQEmB0/edit)
+As part of the [release process](https://github.com/bazelbuild/continuous-integration/blob/master/docs/release-playbook.md),
+we collect the `RELNOTES` tags of every commit. We copy everything in a [Google Doc](https://docs.google.com/document/d/1wDvulLlj4NAlPZamdlEVFORks3YXJonCjyuQMUQEmB0/edit)
 where we review, edit, and organize the notes.
 
 The release manager sends an email to the
@@ -71,6 +68,4 @@ The release manager sends an email to the
 Bazel contributors are invited to contribute to the document and make sure
 their changes are correctly reflected in the announcement.
 
-Later, the announcement will be submitted to the [Bazel
-blog](https://blog.bazel.build/), using the [bazel-blog
-repository](https://github.com/bazelbuild/bazel-blog/tree/master/_posts).
+Later, the announcement will be submitted to the [Bazel blog](https://blog.bazel.build/), using the [bazel-blog repository](https://github.com/bazelbuild/bazel-blog/tree/master/_posts).
diff --git a/versions/8.6.0/contribute/statemachine-guide.mdx b/versions/8.6.0/contribute/statemachine-guide.mdx
index 2d44221a..b574e584 100644
--- a/versions/8.6.0/contribute/statemachine-guide.mdx
+++ b/versions/8.6.0/contribute/statemachine-guide.mdx
@@ -172,8 +172,7 @@ instead, batches[^4] as many lookups as possible before doing so. The value
 might not be immediately available, for example, requiring a Skyframe restart,
 so the caller specifies what to do with the resulting value using a callback.
 
-The `StateMachine` processor ([`Driver`s and bridging to
-SkyFrame](#drivers-and-bridging)) guarantees that the value is available before
+The `StateMachine` processor ([`Driver`s and bridging to SkyFrame](#drivers-and-bridging)) guarantees that the value is available before
 the next state begins. An example follows.
 
 ```
@@ -284,8 +283,7 @@ and solutions to certain control flow problems.
 ### Sequential states
 
 This is the most common and straightforward control flow pattern. An example of
-this is shown in [Stateful computations inside
-`SkyKeyComputeState`](#stateful-computations).
+this is shown in [Stateful computations inside `SkyKeyComputeState`](#stateful-computations).
 
 ### Branching
 
@@ -545,8 +543,7 @@ section describes the propagation of data values.
 
 ### Implementing `Tasks.lookUp` callbacks
 
-There’s an example of implementing a `Tasks.lookUp` callback in [SkyValue
-lookups](#skyvalue-lookups). This section provides rationale and suggests
+There’s an example of implementing a `Tasks.lookUp` callback in [SkyValue lookups](#skyvalue-lookups). This section provides rationale and suggests
 approaches for handling multiple SkyValues.
 
 #### `Tasks.lookUp` callbacks
@@ -710,8 +707,7 @@ class BarProducer implements StateMachine {
 Tip: It would be tempting to use the more concise signature void `accept(Bar
 value)` rather than the stuttery `void acceptBarValue(Bar value)` above.
 However, `Consumer` is a common overload of `void accept(Bar value)`,
-so doing this often leads to violations of the [Overloads: never
-split](https://google.github.io/styleguide/javaguide.html#s3.4.2-ordering-class-contents)
+so doing this often leads to violations of the [Overloads: never split](https://google.github.io/styleguide/javaguide.html#s3.4.2-ordering-class-contents)
 style-guide rule.
 
 Tip: Using a custom `ResultSink` type instead of a generic one from
@@ -774,14 +770,11 @@ pattern after accepting output from either a subtask or SkyValue lookup.
 Note that the implementation of `acceptBarError` eagerly forwards the result to
 the `Caller.ResultSink`, as required by [Error bubbling](#error-bubbling).
 
-Alternatives for top-level `StateMachine`s are described in [`Driver`s and
-bridging to SkyFunctions](#drivers-and-bridging).
+Alternatives for top-level `StateMachine`s are described in [`Driver`s and bridging to SkyFunctions](#drivers-and-bridging).
 
 ### Error handling
 
-There's a couple of examples of error handling already in [`Tasks.lookUp`
-callbacks](#tasks-lookup-callbacks) and [Propagating values between
-`StateMachines`](#propagating-values). Exceptions, other than
+There's a couple of examples of error handling already in [`Tasks.lookUp` callbacks](#tasks-lookup-callbacks) and [Propagating values between `StateMachines`](#propagating-values). Exceptions, other than
 `InterruptedException` are not thrown, but instead passed around through
 callbacks as values. Such callbacks often have exclusive-or semantics, with
 exactly one of a value or error being passed.
@@ -1184,8 +1177,7 @@ states. Where it is possible, local stack `step` variables are young generation
 variables and efficiently GC'd.
 
 For `StateMachine` variables, breaking things down into subtasks and following
-the recommended pattern for [Propagating values between
-`StateMachine`s](#propagating-values) is also helpful. Observe that when
+the recommended pattern for [Propagating values between `StateMachine`s](#propagating-values) is also helpful. Observe that when
 following the pattern, only child `StateMachine`s have references to parent
 `StateMachine`s and not vice versa. This means that as children complete and
 update the parents using result callbacks, the children naturally fall out of
@@ -1207,8 +1199,7 @@ potentially reflecting local behavior.
 
 ### Concurrency tree diagram
 
-The following is an alternative view of the diagram in [Structured
-concurrency](#structured-concurrency) that better depicts the tree structure.
+The following is an alternative view of the diagram in [Structured concurrency](#structured-concurrency) that better depicts the tree structure.
 The blocks form a small tree.
 
 ![Structured Concurrency 3D](/versions/8.6.0/contribute/images/structured-concurrency-3d.svg)
diff --git a/versions/8.6.0/docs/android-instrumentation-test.mdx b/versions/8.6.0/docs/android-instrumentation-test.mdx
index 520cbdf5..37adc455 100644
--- a/versions/8.6.0/docs/android-instrumentation-test.mdx
+++ b/versions/8.6.0/docs/android-instrumentation-test.mdx
@@ -2,8 +2,7 @@
 title: 'Android Instrumentation Tests'
 ---
 
-_If you're new to Bazel, start with the [Building Android with
-Bazel](/versions/8.6.0/start/android-app ) tutorial._
+_If you're new to Bazel, start with the [Building Android with Bazel](/versions/8.6.0/start/android-app) tutorial._
 
 ![Running Android instrumentation tests in parallel](/versions/8.6.0/docs/images/android_test.gif "Android instrumentation test")
 
@@ -18,9 +17,7 @@ emulators in a sandbox, ensuring that tests always run from a clean state. Each
 test gets an isolated emulator instance, allowing tests to run in parallel
 without passing states between them.
 
-For more information on Android instrumentation tests, check out the [Android
-developer
-documentation](https://developer.android.com/training/testing/unit-testing/instrumented-unit-tests.html).
+For more information on Android instrumentation tests, check out the [Android developer documentation](https://developer.android.com/training/testing/unit-testing/instrumented-unit-tests.html).
 
 Please file issues in the [GitHub issue tracker](https://github.com/bazelbuild/bazel/issues).
 
@@ -58,8 +55,7 @@ This results in output similar to the following:
 release 4.1.0
 ```
 
-- **KVM**. Bazel requires emulators to have [hardware
-  acceleration](https://developer.android.com/studio/run/emulator-acceleration.html#accel-check)
+- **KVM**. Bazel requires emulators to have [hardware acceleration](https://developer.android.com/studio/run/emulator-acceleration.html#accel-check)
   with KVM on Linux. You can follow these
   [installation instructions](https://help.ubuntu.com/community/KVM/Installation)
   for Ubuntu.
@@ -173,11 +169,9 @@ The main attributes of the rule `android_instrumentation_test` are:
 
 - `target_device`: An `android_device` target. This target describes the
   specifications of the Android emulator which Bazel uses to create, launch and
-  run the tests. See the [section on choosing an Android
-  device](#android-device-target) for more information.
+  run the tests. See the [section on choosing an Android device](#android-device-target) for more information.
 
-The test app's `AndroidManifest.xml` must include [an ``
-tag](https://developer.android.com/studio/test/#configure_instrumentation_manifest_settings).
+The test app's `AndroidManifest.xml` must include [an `` tag](https://developer.android.com/studio/test/#configure_instrumentation_manifest_settings).
 This tag must specify the attributes for the **package of the target app** and
 the **fully qualified class name of the instrumentation test runner**,
 `androidx.test.runner.AndroidJUnitRunner`.
@@ -214,8 +208,7 @@ repositories:
 - `@androidsdk`: The Android SDK. Download this through Android Studio.
 
 - `@android_test_support`: Hosts the test runner, emulator launcher, and
-  `android_device` targets. You can find the [latest release
-  here](https://github.com/android/android-test/releases).
+  `android_device` targets. You can find the [latest release here](https://github.com/android/android-test/releases).
 
 Enable these dependencies by adding the following lines to your `WORKSPACE`
 file:
@@ -240,8 +233,7 @@ android_test_repositories()
 
 ## Maven dependencies
 
-For managing dependencies on Maven artifacts from repositories, such as [Google
-Maven](https://maven.google.com) or [Maven Central](https://central.maven.org),
+For managing dependencies on Maven artifacts from repositories, such as [Google Maven](https://maven.google.com) or [Maven Central](https://central.maven.org),
 you should use a Maven resolver, such as
 [`rules_jvm_external`](https://github.com/bazelbuild/rules_jvm_external).
 
@@ -370,8 +362,7 @@ the device/emulator listed in `adb devices`.
 
 ## Sample projects
 
-If you are looking for canonical project samples, see the [Android testing
-samples](https://github.com/googlesamples/android-testing#experimental-bazel-support)
+If you are looking for canonical project samples, see the [Android testing samples](https://github.com/googlesamples/android-testing#experimental-bazel-support)
 for projects using Espresso and UIAutomator.
 
 ## Espresso setup
@@ -560,8 +551,7 @@ API_LEVELS = [
 
 ## Known issues
 
-- [Forked adb server processes are not terminated after
-  tests](https://github.com/bazelbuild/bazel/issues/4853)
+- [Forked adb server processes are not terminated after tests](https://github.com/bazelbuild/bazel/issues/4853)
 - While APK building works on all platforms (Linux, macOS, Windows), testing
   only works on Linux.
 - Even with `--config=local_adb`, users still need to specify
diff --git a/versions/8.6.0/docs/android-ndk.mdx b/versions/8.6.0/docs/android-ndk.mdx
index c628dc9a..f1b572a3 100644
--- a/versions/8.6.0/docs/android-ndk.mdx
+++ b/versions/8.6.0/docs/android-ndk.mdx
@@ -2,8 +2,7 @@
 title: 'Using the Android Native Development Kit with Bazel'
 ---
 
-_If you're new to Bazel, please start with the [Building Android with
-Bazel](/versions/8.6.0/start/android-app ) tutorial._
+_If you're new to Bazel, please start with the [Building Android with Bazel](/versions/8.6.0/start/android-app) tutorial._
 
 ## Overview
 
@@ -31,8 +30,7 @@ android_ndk_repository(
 )
 ```
 
-For more information about the `android_ndk_repository` rule, see the [Build
-Encyclopedia entry](/versions/8.6.0/reference/be/android#android_ndk_repository).
+For more information about the `android_ndk_repository` rule, see the [Build Encyclopedia entry](/versions/8.6.0/reference/be/android#android_ndk_repository).
 
 If you're using a recent version of the Android NDK (r22 and beyond), use the
 Starlark implementation of `android_ndk_repository`.
@@ -101,13 +99,11 @@ META-INF/MANIFEST.MF
 
 Bazel compiles all of the cc_libraries into a single shared object (`.so`) file,
 targeted for the `armeabi-v7a` ABI by default. To change this or build for
-multiple ABIs at the same time, see the section on [configuring the target
-ABI](#configuring-target-abi).
+multiple ABIs at the same time, see the section on [configuring the target ABI](#configuring-target-abi).
 
 ## Example setup
 
-This example is available in the [Bazel examples
-repository](https://github.com/bazelbuild/examples/tree/master/android/ndk).
+This example is available in the [Bazel examples repository](https://github.com/bazelbuild/examples/tree/master/android/ndk).
 
 In the `BUILD.bazel` file, three targets are defined with the `android_binary`,
 `android_library`, and `cc_library` rules.
diff --git a/versions/8.6.0/docs/configurable-attributes.mdx b/versions/8.6.0/docs/configurable-attributes.mdx
index a93dc87b..0f890110 100644
--- a/versions/8.6.0/docs/configurable-attributes.mdx
+++ b/versions/8.6.0/docs/configurable-attributes.mdx
@@ -2,8 +2,7 @@
 title: 'Configurable Build Attributes'
 ---
 
-**_Configurable attributes_**, commonly known as [`select()`](
-/reference/be/functions#select), is a Bazel feature that lets users toggle the values
+**_Configurable attributes_**, commonly known as [`select()`](/reference/be/functions#select), is a Bazel feature that lets users toggle the values
 of build rule attributes at the command line.
 
 This can be used, for example, for a multiplatform library that automatically
@@ -407,8 +406,7 @@ sh_library(
 )
 ```
 
-If you need a `select` to match when multiple conditions match, consider [AND
-chaining](#and-chaining).
+If you need a `select` to match when multiple conditions match, consider [AND chaining](#and-chaining).
 
 ## OR chaining
 
diff --git a/versions/8.6.0/extending/auto-exec-groups.mdx b/versions/8.6.0/extending/auto-exec-groups.mdx
index c6a8c624..bab0282a 100644
--- a/versions/8.6.0/extending/auto-exec-groups.mdx
+++ b/versions/8.6.0/extending/auto-exec-groups.mdx
@@ -27,9 +27,7 @@ doesn't detect that ([the error](#first-error-message) is raised), you can set
 
 If you need to use multiple toolchains on a single execution platform (an action
 uses executable or tools from two or more toolchains), you need to manually
-define [exec_groups][exec_groups] (check
-[When should I use a custom exec_group?][multiple_toolchains_exec_groups]
-section).
+define [exec_groups][exec_groups](check [When should I use a custom exec_group?][multiple_toolchains_exec_groups] section).
 
 ## History
 
@@ -42,8 +40,7 @@ my_rule = rule(
 )
 ```
 
-Rule `my_rule` registers two toolchain types. This means that the [Toolchain
-Resolution](https://bazel.build/versions/8.6.0/extending/toolchains#toolchain-resolution) used
+Rule `my_rule` registers two toolchain types. This means that the [Toolchain Resolution](https://bazel.build/versions/8.6.0/extending/toolchains#toolchain-resolution) used
 to find an execution platform which supports both toolchain types. The selected
 execution platform was used for each registered action inside the rule, unless
 specified differently with [exec_groups][exec_groups].
diff --git a/versions/8.6.0/extending/concepts.mdx b/versions/8.6.0/extending/concepts.mdx
index 9e26ff48..63c02194 100644
--- a/versions/8.6.0/extending/concepts.mdx
+++ b/versions/8.6.0/extending/concepts.mdx
@@ -21,16 +21,14 @@ Before learning the more advanced concepts, first:
 ## Macros and rules
 
 A macro is a function that instantiates rules. Macros come in two flavors:
-[symbolic macros](/versions/8.6.0/extending/macros) (new in Bazel 8) and [legacy
-macros](/versions/8.6.0/extending/legacy-macros). The two flavors of macros are defined
+[symbolic macros](/versions/8.6.0/extending/macros) (new in Bazel 8) and [legacy macros](/versions/8.6.0/extending/legacy-macros). The two flavors of macros are defined
 differently, but behave almost the same from the point of view of a user. A
 macro is useful when a `BUILD` file is getting too repetitive or too complex, as
 it lets you reuse some code. The function is evaluated as soon as the `BUILD`
 file is read. After the evaluation of the `BUILD` file, Bazel has little
 information about macros. If your macro generates a `genrule`, Bazel will
 behave *almost* as if you declared that `genrule` in the `BUILD` file. (The one
-exception is that targets declared in a symbolic macro have [special visibility
-semantics](/versions/8.6.0/extending/macros#visibility): a symbolic macro can hide its internal
+exception is that targets declared in a symbolic macro have [special visibility semantics](/versions/8.6.0/extending/macros#visibility): a symbolic macro can hide its internal
 targets from the rest of the package.)
 
 A [rule](/versions/8.6.0/extending/rules) is more powerful than a macro. It can access Bazel
@@ -77,8 +75,7 @@ they will not be executed.
 ## Creating extensions
 
 * [Create your first macro](/versions/8.6.0/rules/macro-tutorial) in order to reuse some code.
-  Then [learn more about macros](/versions/8.6.0/extending/macros) and [using them to create
-  "custom verbs"](/versions/8.6.0/rules/verbs-tutorial).
+  Then [learn more about macros](/versions/8.6.0/extending/macros) and [using them to create "custom verbs"](/versions/8.6.0/rules/verbs-tutorial).
 
 * [Follow the rules tutorial](/versions/8.6.0/rules/rules-tutorial) to get started with rules.
   Next, you can read more about the [rules concepts](/versions/8.6.0/extending/rules).
@@ -93,8 +90,7 @@ them within reach:
 ## Going further
 
 In addition to [macros](/versions/8.6.0/extending/macros) and [rules](/versions/8.6.0/extending/rules), you
-may want to write [aspects](/versions/8.6.0/extending/aspects) and [repository
-rules](/versions/8.6.0/extending/repo).
+may want to write [aspects](/versions/8.6.0/extending/aspects) and [repository rules](/versions/8.6.0/extending/repo).
 
 * Use [Buildifier](https://github.com/bazelbuild/buildtools)
   consistently to format and lint your code.
diff --git a/versions/8.6.0/extending/depsets.mdx b/versions/8.6.0/extending/depsets.mdx
index 43d9b038..82a37e7c 100644
--- a/versions/8.6.0/extending/depsets.mdx
+++ b/versions/8.6.0/extending/depsets.mdx
@@ -111,8 +111,7 @@ need to ensure that if `B` depends on `A`, then `A.o` comes before `B.o` on the
 linker’s command line. Other tools might have the opposite requirement.
 
 Three traversal orders are supported: `postorder`, `preorder`, and
-`topological`. The first two work exactly like [tree
-traversals](https://en.wikipedia.org/wiki/Tree_traversal#Depth-first_search)
+`topological`. The first two work exactly like [tree traversals](https://en.wikipedia.org/wiki/Tree_traversal#Depth-first_search)
 except that they operate on DAGs and skip already visited nodes. The third order
 works as a topological sort from root to leaves, essentially the same as
 preorder except that shared children are listed only after all of their parents.
diff --git a/versions/8.6.0/extending/exec-groups.mdx b/versions/8.6.0/extending/exec-groups.mdx
index 42e5524d..86764857 100644
--- a/versions/8.6.0/extending/exec-groups.mdx
+++ b/versions/8.6.0/extending/exec-groups.mdx
@@ -63,8 +63,7 @@ test rules.
 
 In the rule implementation, you can declare that actions should be run on the
 execution platform of an execution group. You can do this by using the `exec_group`
-param of action generating methods, specifically [`ctx.actions.run`]
-(/rules/lib/builtins/actions#run) and
+param of action generating methods, specifically [`ctx.actions.run`](/rules/lib/builtins/actions#run) and
 [`ctx.actions.run_shell`](/versions/8.6.0/rules/lib/builtins/actions#run_shell).
 
 ```python
diff --git a/versions/8.6.0/extending/macros.mdx b/versions/8.6.0/extending/macros.mdx
index 636889f2..5d7b6f59 100644
--- a/versions/8.6.0/extending/macros.mdx
+++ b/versions/8.6.0/extending/macros.mdx
@@ -31,8 +31,7 @@ two required parameters: `attrs` and `implementation`.
 
 ### Attributes
 
-`attrs` accepts a dictionary of attribute name to [attribute
-types](https://bazel.build/versions/8.6.0/rules/lib/toplevel/attr#members), which represents
+`attrs` accepts a dictionary of attribute name to [attribute types](https://bazel.build/versions/8.6.0/rules/lib/toplevel/attr#members), which represents
 the arguments to the macro. Two common attributes – `name` and `visibility` –
 are implicitly added to all macros and are not included in the dictionary passed
 to `attrs`.
@@ -66,9 +65,7 @@ To support this pattern, a macro can *inherit attributes* from a rule or another
 macro by passing the [rule](https://bazel.build/versions/8.6.0/rules/lib/builtins/rule) or
 [macro symbol](https://bazel.build/versions/8.6.0/rules/lib/builtins/macro) to `macro()`'s
 `inherit_attrs` argument. (You can also use the special string `"common"`
-instead of a rule or macro symbol to inherit the [common attributes defined for
-all Starlark build
-rules](https://bazel.build/versions/8.6.0/reference/be/common-definitions#common-attributes).)
+instead of a rule or macro symbol to inherit the [common attributes defined for all Starlark build rules](https://bazel.build/versions/8.6.0/reference/be/common-definitions#common-attributes).)
 Only public attributes get inherited, and the attributes in the macro's own
 `attrs` dictionary override inherited attributes with the same name. You can
 also *remove* inherited attributes by using `None` as a value in the `attrs`
diff --git a/versions/8.6.0/extending/platforms.mdx b/versions/8.6.0/extending/platforms.mdx
index 5970f174..d40b9fc2 100644
--- a/versions/8.6.0/extending/platforms.mdx
+++ b/versions/8.6.0/extending/platforms.mdx
@@ -245,8 +245,7 @@ cc_library(
 
 You can use the
 [`IncompatiblePlatformProvider`](/versions/8.6.0/rules/lib/providers/IncompatiblePlatformProvider)
-in `bazel cquery`'s [Starlark output
-format](/versions/8.6.0/query/cquery#output-format-definition) to distinguish
+in `bazel cquery`'s [Starlark output format](/versions/8.6.0/query/cquery#output-format-definition) to distinguish
 incompatible targets from compatible ones.
 
 This can be used to filter out incompatible targets. The example below will
@@ -266,5 +265,4 @@ $ bazel cquery //... --output=starlark --starlark:file=example.cquery
 
 ### Known Issues
 
-Incompatible targets [ignore visibility
-restrictions](https://github.com/bazelbuild/bazel/issues/16044).
+Incompatible targets [ignore visibility restrictions](https://github.com/bazelbuild/bazel/issues/16044).
diff --git a/versions/8.6.0/extending/repo.mdx b/versions/8.6.0/extending/repo.mdx
index 0ffa048e..608fb816 100644
--- a/versions/8.6.0/extending/repo.mdx
+++ b/versions/8.6.0/extending/repo.mdx
@@ -74,8 +74,7 @@ specified.
 
 The input parameter `repository_ctx` can be used to access attribute values, and
 non-hermetic functions (finding a binary, executing a binary, creating a file in
-the repository or downloading a file from the Internet). See [the API
-docs](/versions/8.6.0/rules/lib/builtins/repository_ctx) for more context. Example:
+the repository or downloading a file from the Internet). See [the API docs](/versions/8.6.0/rules/lib/builtins/repository_ctx) for more context. Example:
 
 ```python
 def _impl(repository_ctx):
@@ -144,8 +143,7 @@ definition has the `configure` attribute set, use `bazel fetch --force
 
 ## Examples
 
--   [C++ auto-configured
-    toolchain](https://cs.opensource.google/bazel/bazel/+/master:tools/cpp/cc_configure.bzl;drc=644b7d41748e09eff9e47cbab2be2263bb71f29a;l=176):
+-   [C++ auto-configured toolchain](https://cs.opensource.google/bazel/bazel/+/master:tools/cpp/cc_configure.bzl;drc=644b7d41748e09eff9e47cbab2be2263bb71f29a;l=176):
     it uses a repo rule to automatically create the C++ configuration files for
     Bazel by looking for the local C++ compiler, the environment and the flags
     the C++ compiler supports.
diff --git a/versions/8.6.0/extending/rules.mdx b/versions/8.6.0/extending/rules.mdx
index 1ab25d37..c83bd4a2 100644
--- a/versions/8.6.0/extending/rules.mdx
+++ b/versions/8.6.0/extending/rules.mdx
@@ -449,8 +449,7 @@ def _example_library_impl(ctx):
 
 If `DefaultInfo` is not returned by a rule implementation or the `files`
 parameter is not specified, `DefaultInfo.files` defaults to all
-*predeclared outputs* (generally, those created by [output
-attributes](#output_attributes)).
+*predeclared outputs* (generally, those created by [output attributes](#output_attributes)).
 
 Rules that perform actions should provide default outputs, even if those outputs
 are not expected to be directly used. Actions that are not in the graph of the
@@ -995,8 +994,7 @@ By using `configuration_field`, the dependency on the Java LCOV merger tool can
 be avoided as long as coverage is not requested.
 
 When the test is run, it should emit coverage information in the form of one or
-more [LCOV files]
-(https://manpages.debian.org/unstable/lcov/geninfo.1.en.html#TRACEFILE_FORMAT)
+more [LCOV files](https://manpages.debian.org/unstable/lcov/geninfo.1.en.html#TRACEFILE_FORMAT)
 with unique names into the directory specified by the `COVERAGE_DIR` environment
 variable. Bazel will then merge these files into a single LCOV file using the
 `_lcov_merger` tool. If present, it will also collect C/C++ coverage using the
diff --git a/versions/8.6.0/extending/toolchains.mdx b/versions/8.6.0/extending/toolchains.mdx
index 3ba5fb83..3bc96e5b 100644
--- a/versions/8.6.0/extending/toolchains.mdx
+++ b/versions/8.6.0/extending/toolchains.mdx
@@ -523,8 +523,7 @@ The set of available toolchains, in priority order, is created from
   4. Toolchains registered in the "WORKSPACE suffix"; this is only used by
      certain native rules bundled with the Bazel installation.
 
-**NOTE:** [Pseudo-targets like `:all`, `:*`, and
-`/...`](/versions/8.6.0/run/build#specifying-build-targets) are ordered by Bazel's package
+**NOTE:** [Pseudo-targets like `:all`, `:*`, and `/...`](/versions/8.6.0/run/build#specifying-build-targets) are ordered by Bazel's package
 loading mechanism, which uses a lexicographic ordering.
 
 The resolution steps are as follows.
diff --git a/versions/8.6.0/external/advanced.mdx b/versions/8.6.0/external/advanced.mdx
index 66b4d2f5..d7166333 100644
--- a/versions/8.6.0/external/advanced.mdx
+++ b/versions/8.6.0/external/advanced.mdx
@@ -4,10 +4,8 @@ title: 'Advanced topics on external dependencies'
 
 ## Shadowing dependencies in WORKSPACE
 
-Note: This section applies to the [WORKSPACE
-system](/versions/8.6.0/external/overview#workspace-system) only. For
-[Bzlmod](/versions/8.6.0/external/overview#bzlmod), use a [multiple-version
-override](/versions/8.6.0/external/module#multiple-version_override).
+Note: This section applies to the [WORKSPACE system](/versions/8.6.0/external/overview#workspace-system) only. For
+[Bzlmod](/versions/8.6.0/external/overview#bzlmod), use a [multiple-version override](/versions/8.6.0/external/module#multiple-version_override).
 
 Whenever possible, have a single version policy in your project, which is
 required for dependencies that you compile against and end up in your final
@@ -128,29 +126,24 @@ preferring IPv4 if enabled. In some situations, for example when the IPv4
 network cannot resolve/reach external addresses, this can cause `Network
 unreachable` exceptions and build failures. In these cases, you can override
 Bazel's behavior to prefer IPv6 by using the
-[`java.net.preferIPv6Addresses=true` system
-property](https://docs.oracle.com/javase/8/docs/api/java/net/doc-files/net-properties.html).
+[`java.net.preferIPv6Addresses=true` system property](https://docs.oracle.com/javase/8/docs/api/java/net/doc-files/net-properties.html).
 Specifically:
 
-*   Use `--host_jvm_args=-Djava.net.preferIPv6Addresses=true` [startup
-    option](/versions/8.6.0/docs/user-manual#startup-options), for example by adding the
+*   Use `--host_jvm_args=-Djava.net.preferIPv6Addresses=true` [startup option](/versions/8.6.0/docs/user-manual#startup-options), for example by adding the
     following line in your [`.bazelrc` file](/versions/8.6.0/run/bazelrc):
 
     `startup --host_jvm_args=-Djava.net.preferIPv6Addresses=true`
 
 *   When running Java build targets that need to connect to the internet (such
     as for integration tests), use the
-    `--jvmopt=-Djava.net.preferIPv6Addresses=true` [tool
-    flag](/versions/8.6.0/docs/user-manual#jvmopt). For example, include in your [`.bazelrc`
-    file](/versions/8.6.0/run/bazelrc):
+    `--jvmopt=-Djava.net.preferIPv6Addresses=true` [tool flag](/versions/8.6.0/docs/user-manual#jvmopt). For example, include in your [`.bazelrc` file](/versions/8.6.0/run/bazelrc):
 
     `build --jvmopt=-Djava.net.preferIPv6Addresses`
 
 *   If you are using [`rules_jvm_external`](https://github.com/bazelbuild/rules_jvm_external)
     for dependency version resolution, also add
     `-Djava.net.preferIPv6Addresses=true` to the `COURSIER_OPTS` environment
-    variable to [provide JVM options for
-    Coursier](https://github.com/bazelbuild/rules_jvm_external#provide-jvm-options-for-coursier-with-coursier_opts).
+    variable to [provide JVM options for Coursier](https://github.com/bazelbuild/rules_jvm_external#provide-jvm-options-for-coursier-with-coursier_opts).
 
 ## Offline builds
 
@@ -167,15 +160,12 @@ fetch a file with [`ctx.download`](/versions/8.6.0/rules/lib/builtins/repository
 providing a hash sum of the file needed, Bazel looks for a file matching the
 basename of the first URL, and uses the local copy if the hash matches.
 
-Bazel itself uses this technique to bootstrap offline from the [distribution
-artifact](https://github.com/bazelbuild/bazel-website/blob/master/designs/_posts/2016-10-11-distribution-artifact.md).
-It does so by [collecting all the needed external
-dependencies](https://github.com/bazelbuild/bazel/blob/5cfa0303d6ac3b5bd031ff60272ce80a704af8c2/WORKSPACE#L116)
+Bazel itself uses this technique to bootstrap offline from the [distribution artifact](https://github.com/bazelbuild/bazel-website/blob/master/designs/_posts/2016-10-11-distribution-artifact.md).
+It does so by [collecting all the needed external dependencies](https://github.com/bazelbuild/bazel/blob/5cfa0303d6ac3b5bd031ff60272ce80a704af8c2/WORKSPACE#L116)
 in an internal
 [`distdir_tar`](https://github.com/bazelbuild/bazel/blob/5cfa0303d6ac3b5bd031ff60272ce80a704af8c2/distdir.bzl#L44).
 
 Bazel allows execution of arbitrary commands in repository rules without knowing
 if they call out to the network, and so cannot enforce fully offline builds. To
 test if a build works correctly offline, manually block off the network (as
-Bazel does in its [bootstrap
-test](https://cs.opensource.google/bazel/bazel/+/master:src/test/shell/bazel/BUILD;l=1073;drc=88c426e73cc0eb0a41c0d7995e36acd94e7c9a48)).
\ No newline at end of file
+Bazel does in its [bootstrap test](https://cs.opensource.google/bazel/bazel/+/master:src/test/shell/bazel/BUILD;l=1073;drc=88c426e73cc0eb0a41c0d7995e36acd94e7c9a48)).
\ No newline at end of file
diff --git a/versions/8.6.0/external/migration.mdx b/versions/8.6.0/external/migration.mdx
index 030c4f0f..dc775214 100644
--- a/versions/8.6.0/external/migration.mdx
+++ b/versions/8.6.0/external/migration.mdx
@@ -4,8 +4,7 @@ keywords: bzlmod
 title: 'Bzlmod Migration Guide'
 ---
 
-Due to the [shortcomings of
-WORKSPACE](/versions/8.6.0/external/overview#workspace-shortcomings), Bzlmod is going to
+Due to the [shortcomings of WORKSPACE](/versions/8.6.0/external/overview#workspace-shortcomings), Bzlmod is going to
 replace the legacy WORKSPACE system. The WORKSPACE file will be disabled by
 default in Bazel 8 (late 2024) and will be removed in Bazel 9 (late 2025).
 This guide helps you migrate your project to Bzlmod and drop WORKSPACE for
@@ -119,9 +118,7 @@ Bazel module when it also adopts Bzlmod.
 
 *   **Bzlmod**
 
-    With Bzlmod, as long as the your dependency is available in [Bazel Central
-    Registry](https://registry.bazel.build) or your custom [Bazel
-    registry](/versions/8.6.0/external/registry), you can simply depend on it with a
+    With Bzlmod, as long as the your dependency is available in [Bazel Central Registry](https://registry.bazel.build) or your custom [Bazel registry](/versions/8.6.0/external/registry), you can simply depend on it with a
     [`bazel_dep`](/versions/8.6.0/rules/lib/globals/module#bazel_dep) directive.
 
     ```python
@@ -152,8 +149,7 @@ repository.
 
 If your dependency is not a Bazel project or not yet available in any Bazel
 registry, you can introduce it using
-[`use_repo_rule`](/versions/8.6.0/external/module#use_repo_rule) or [module
-extensions](/versions/8.6.0/external/extension).
+[`use_repo_rule`](/versions/8.6.0/external/module#use_repo_rule) or [module extensions](/versions/8.6.0/external/extension).
 
 *   **WORKSPACE**
 
@@ -606,8 +602,7 @@ macros.
 Fortunately, the flag
 [`--experimental_repository_resolved_file`][resolved_file_flag]
 can help. This flag essentially generates a "lock file" of all fetched external
-dependencies in your last Bazel command. You can find more details in this [blog
-post](https://blog.bazel.build/2018/07/09/bazel-sync-and-resolved-file.html).
+dependencies in your last Bazel command. You can find more details in this [blog post](https://blog.bazel.build/2018/07/09/bazel-sync-and-resolved-file.html).
 
 [resolved_file_flag]: /reference/command-line-reference#flag--experimental_repository_resolved_file
 
@@ -648,11 +643,9 @@ You may also know `bazel query` can be used for inspecting repository rules with
 bazel query --output=build //external:
 ```
 
-While it is more convenient and much faster, [bazel query can lie about
-external dependency version](https://github.com/bazelbuild/bazel/issues/12947),
+While it is more convenient and much faster, [bazel query can lie about external dependency version](https://github.com/bazelbuild/bazel/issues/12947),
 so be careful using it! Querying and inspecting external
-dependencies with Bzlmod is going to achieved by a [new
-subcommand](https://github.com/bazelbuild/bazel/issues/15365).
+dependencies with Bzlmod is going to achieved by a [new subcommand](https://github.com/bazelbuild/bazel/issues/15365).
 
 #### Built-in default dependencies
 
@@ -699,8 +692,7 @@ Using the WORKSPACE.bzlmod file can make the migration easier because:
 #### Repository visibility
 
 Bzlmod is able to control which other repositories are visible from a given
-repository, check [repository names and strict
-deps](/versions/8.6.0/external/module#repository_names_and_strict_deps) for more details.
+repository, check [repository names and strict deps](/versions/8.6.0/external/module#repository_names_and_strict_deps) for more details.
 
 Here is a summary of repository visibilities from different types of
 repositories when also taking WORKSPACE into consideration.
@@ -713,8 +705,7 @@ repositories when also taking WORKSPACE into consideration.
 | WORKSPACE Repos | All visible | Not visible | Not visible | All visible |
 
 Note: For the root module, if a repository `@foo` is defined in WORKSPACE and
-`@foo` is also used as an [apparent repository
-name](/versions/8.6.0/external/overview#apparent-repo-name) in MODULE.bazel, then `@foo`
+`@foo` is also used as an [apparent repository name](/versions/8.6.0/external/overview#apparent-repo-name) in MODULE.bazel, then `@foo`
 refers to the one introduced in MODULE.bazel.
 
 Note: For a module extension generated repository `@bar`, if `@foo` is used as
@@ -789,9 +780,7 @@ the project. Take note of a few things when creating the source archive:
     GitHub isn't going to guarantee the checksum of source archives generated on
     demand. In short, URLs in the form of
     `https://github.com///releases/download/...` is considered stable
-    while `https://github.com///archive/...` is not. Check [GitHub
-    Archive Checksum
-    Outage](https://blog.bazel.build/2023/02/15/github-archive-checksum.html)
+    while `https://github.com///archive/...` is not. Check [GitHub Archive Checksum Outage](https://blog.bazel.build/2023/02/15/github-archive-checksum.html)
     for more context.
 
 *   **Make sure the source tree follows the layout of the original repository.**
@@ -820,8 +809,7 @@ Pull Request.
 
 [bcr_contrib_guide]: https://github.com/bazelbuild/bazel-central-registry/tree/main/docs#contribute-a-bazel-module
 
-It is **highly recommended** to set up the [Publish to
-BCR](https://github.com/bazel-contrib/publish-to-bcr) GitHub App for your
+It is **highly recommended** to set up the [Publish to BCR](https://github.com/bazel-contrib/publish-to-bcr) GitHub App for your
 repository to automate the process of submitting your module to the BCR.
 
 ## Best practices
diff --git a/versions/8.6.0/external/mod-command.mdx b/versions/8.6.0/external/mod-command.mdx
index 0effacfc..7cb1f916 100644
--- a/versions/8.6.0/external/mod-command.mdx
+++ b/versions/8.6.0/external/mod-command.mdx
@@ -64,11 +64,9 @@ The available subcommands and their respective required arguments are:
 
 *   ``: All present versions of the module ``.
 
-*   `@`: The repo with the given [apparent
-    name](overview#apparent-repo-name) in the context of the `--base_module`.
+*   `@`: The repo with the given [apparent name](overview#apparent-repo-name) in the context of the `--base_module`.
 
-*   `@@`: The repo with the given [canonical
-    name](overview#canonical-repo-name).
+*   `@@`: The repo with the given [canonical name](overview#canonical-repo-name).
 
 In a context requiring specifying modules, ``s referring to repos that
 correspond to modules (as opposed to extension-generated repos) can also be
@@ -92,8 +90,7 @@ The following options only affect the subcommands that print graphs (`graph`,
     information about the version resolution of each module. If the module
     version changed during resolution, show either which version replaced it or
     what was the original version, the reason it was replaced, and which modules
-    requested the new version if the reason was [Minimal Version
-    Selection](module#version-selection).
+    requested the new version if the reason was [Minimal Version Selection](module#version-selection).
 
 *   `--include_unused` *default: "false"*: Include in the output graph the
     modules which were originally present in the dependency graph, but became
@@ -168,16 +165,13 @@ The following options only affect the subcommands that print graphs (`graph`,
     *   `text` *(default)*: Display repository definitions in Starlark.
 
     *   `streamed_proto`: Prints a
-        [length-delimited](https://protobuf.dev/programming-guides/encoding/#siz
-        e-limit)
+        [length-delimited](https://protobuf.dev/programming-guides/encoding/#siz e-limit)
         stream of
-        [`Repository`](https://github.com/bazelbuild/bazel/blob/master/src/main/
-        protobuf/build.proto)
+        [`Repository`](https://github.com/bazelbuild/bazel/blob/master/src/main/ protobuf/build.proto)
         protocol buffers.
 
     *   `streamed_jsonproto`: Similar to `--output streamed_proto`, prints a
-        stream of [`Repository`](https://github.com/bazelbuild/bazel/blob/master
-        /src/main/protobuf/build.proto)
+        stream of [`Repository`](https://github.com/bazelbuild/bazel/blob/master /src/main/protobuf/build.proto)
         protocol buffers but in [NDJSON](https://github.com/ndjson/ndjson-spec)
         format.
 
diff --git a/versions/8.6.0/external/module.mdx b/versions/8.6.0/external/module.mdx
index 2466763e..ef6c6c57 100644
--- a/versions/8.6.0/external/module.mdx
+++ b/versions/8.6.0/external/module.mdx
@@ -105,8 +105,7 @@ serves multiple purposes:
     version, regardless of which versions of the dependency are requested in the
     dependency graph.
 *   With the `registry` attribute, you can force this dependency to come from a
-    specific registry, instead of following the normal [registry
-    selection](/versions/8.6.0/external/registry#selecting_registries) process.
+    specific registry, instead of following the normal [registry selection](/versions/8.6.0/external/registry#selecting_registries) process.
 *   With the `patch*` attributes, you can specify a set of patches to apply to
     the downloaded module.
 
@@ -151,13 +150,11 @@ With `bazel_dep`, you can define repos that represent other Bazel modules.
 Sometimes there is a need to define a repo that does _not_ represent a Bazel
 module; for example, one that contains a plain JSON file to be read as data.
 
-In this case, you could use the [`use_repo_rule`
-directive](/versions/8.6.0/rules/lib/globals/module#use_repo_rule) to directly define a repo
+In this case, you could use the [`use_repo_rule` directive](/versions/8.6.0/rules/lib/globals/module#use_repo_rule) to directly define a repo
 by invoking a repo rule. This repo will only be visible to the module it's
 defined in.
 
-Under the hood, this is implemented using the same mechanism as [module
-extensions](/versions/8.6.0/external/extension), which lets you define repos with more
+Under the hood, this is implemented using the same mechanism as [module extensions](/versions/8.6.0/external/extension), which lets you define repos with more
 flexibility.
 
 ## Repository names and strict deps
diff --git a/versions/8.6.0/external/overview.mdx b/versions/8.6.0/external/overview.mdx
index 2ef7a821..d6b1f241 100644
--- a/versions/8.6.0/external/overview.mdx
+++ b/versions/8.6.0/external/overview.mdx
@@ -128,8 +128,7 @@ for all build targets inside the repo.
 
 The syntax of a `REPO.bazel` file is similar to `BUILD` files, except that no
 `load` statements are supported, and only a single function, `repo()`, is
-available. `repo()` takes the same arguments as the [`package()`
-function](/versions/8.6.0/reference/be/functions#package) in `BUILD` files; whereas `package()`
+available. `repo()` takes the same arguments as the [`package()` function](/versions/8.6.0/reference/be/functions#package) in `BUILD` files; whereas `package()`
 specifies common attributes for all build targets inside the package, `repo()`
 analogously does so for all build targets inside the repo.
 
@@ -163,8 +162,7 @@ bazel_dep(name = "protobuf", version = "3.19.0")
 ```
 
 A module must only list its direct dependencies, which Bzlmod looks up in a
-[Bazel registry](/versions/8.6.0/external/registry) — by default, the [Bazel Central
-Registry](https://bcr.bazel.build/). The registry provides the
+[Bazel registry](/versions/8.6.0/external/registry) — by default, the [Bazel Central Registry](https://bcr.bazel.build/). The registry provides the
 dependencies' `MODULE.bazel` files, which allows Bazel to discover the entire
 transitive dependency graph before performing version resolution.
 
@@ -235,5 +233,4 @@ many pain points, including:
         `B` and `C`; `B` and `C` both depend on different versions of `D`).
 
 Due to the shortcomings of WORKSPACE, Bzlmod is going to replace the legacy
-WORKSPACE system in future Bazel releases. Please read the [Bzlmod migration
-guide](/versions/8.6.0/external/migration) on how to migrate to Bzlmod.
+WORKSPACE system in future Bazel releases. Please read the [Bzlmod migration guide](/versions/8.6.0/external/migration) on how to migrate to Bzlmod.
diff --git a/versions/8.6.0/external/registry.mdx b/versions/8.6.0/external/registry.mdx
index d31b2f8d..811146e1 100644
--- a/versions/8.6.0/external/registry.mdx
+++ b/versions/8.6.0/external/registry.mdx
@@ -42,8 +42,7 @@ An index registry must follow the format below:
             project
         *   `versions`: A list of all the versions of this module to be found in
             this registry
-        *   `yanked_versions`: A map of [*yanked*
-            versions](/versions/8.6.0/external/module#yanked_versions) of this module. The keys
+        *   `yanked_versions`: A map of [*yanked* versions](/versions/8.6.0/external/module#yanked_versions) of this module. The keys
             should be versions to yank and the values should be descriptions of
             why the version is yanked, ideally containing a link to more
             information
@@ -56,8 +55,7 @@ An index registry must follow the format below:
             *   `url`: The URL of the source archive
             *   `mirror_urls`: A list of string, the mirror URLs of the source archive.
                 The URLs are tried in order after `url` as backups.
-            *   `integrity`: The [Subresource
-                Integrity](https://w3c.github.io/webappsec-subresource-integrity/#integrity-metadata-description)
+            *   `integrity`: The [Subresource Integrity](https://w3c.github.io/webappsec-subresource-integrity/#integrity-metadata-description)
                 checksum of the archive
             *   `strip_prefix`: A directory prefix to strip when extracting the
                 source archive
@@ -105,8 +103,7 @@ You can browse its contents using the web frontend at
 ``.
 
 The Bazel community maintains the BCR, and contributors are welcome to submit
-pull requests. See the [BCR contribution
-guidelines](https://github.com/bazelbuild/bazel-central-registry/blob/main/docs/README.md).
+pull requests. See the [BCR contribution guidelines](https://github.com/bazelbuild/bazel-central-registry/blob/main/docs/README.md).
 
 In addition to following the format of a normal index registry, the BCR requires
 a `presubmit.yml` file for each module version
diff --git a/versions/8.6.0/external/vendor.mdx b/versions/8.6.0/external/vendor.mdx
index 00a54a81..2f5a1c52 100644
--- a/versions/8.6.0/external/vendor.mdx
+++ b/versions/8.6.0/external/vendor.mdx
@@ -23,9 +23,7 @@ absolute path.
 ## Vendor a specific external repository
 
 You can use the `vendor` command with the `--repo` flag to specify which repo
-to vendor, it accepts both [canonical repo
-name](/versions/8.6.0/external/overview#canonical-repo-name) and [apparent repo
-name](/versions/8.6.0/external/overview#apparent-repo-name).
+to vendor, it accepts both [canonical repo name](/versions/8.6.0/external/overview#canonical-repo-name) and [apparent repo name](/versions/8.6.0/external/overview#apparent-repo-name).
 
 For example, running:
 
diff --git a/versions/8.6.0/help.mdx b/versions/8.6.0/help.mdx
index 59095ff1..1a49798f 100644
--- a/versions/8.6.0/help.mdx
+++ b/versions/8.6.0/help.mdx
@@ -46,5 +46,4 @@ what level of support Bazel provides.
 
 ## File a bug
 
-If you encounter a bug or want to request a feature, file a [GitHub
-Issue](https://github.com/bazelbuild/bazel/issues).
+If you encounter a bug or want to request a feature, file a [GitHub Issue](https://github.com/bazelbuild/bazel/issues).
diff --git a/versions/8.6.0/install/bazelisk.mdx b/versions/8.6.0/install/bazelisk.mdx
index 551992ba..0adb4419 100644
--- a/versions/8.6.0/install/bazelisk.mdx
+++ b/versions/8.6.0/install/bazelisk.mdx
@@ -16,8 +16,7 @@ For more details, see
 ## Updating Bazel
 
 Bazel has a [backward compatibility policy](/versions/8.6.0/release/backward-compatibility)
-(see [guidance for rolling out incompatible
-changes](/versions/8.6.0/contribute/breaking-changes) if you
+(see [guidance for rolling out incompatible changes](/versions/8.6.0/contribute/breaking-changes) if you
 are the author of one). That page summarizes best practices on how to test and
 migrate your project with upcoming incompatible changes and how to provide
 feedback to the incompatible change authors.
diff --git a/versions/8.6.0/install/compile-source.mdx b/versions/8.6.0/install/compile-source.mdx
index c634a2ae..dbfc76db 100644
--- a/versions/8.6.0/install/compile-source.mdx
+++ b/versions/8.6.0/install/compile-source.mdx
@@ -45,8 +45,7 @@ it by typing `bazel` in a terminal.
 
 **Reason**: To build Bazel from a GitHub source tree, you need a pre-existing
 Bazel binary. You can install one from a package manager or download one from
-GitHub. See [Installing Bazel](/versions/8.6.0/install). (Or you can [build from
-scratch (bootstrap)](#bootstrap-bazel).)
+GitHub. See [Installing Bazel](/versions/8.6.0/install). (Or you can [build from scratch (bootstrap)](#bootstrap-bazel).)
 
 **Troubleshooting**:
 
@@ -239,8 +238,7 @@ For instructions for Unix-like systems, see
     ```
 
 *   **The Visual C++ compiler.** Install the Visual C++ compiler either as part
-    of Visual Studio 2015 or newer, or by installing the latest [Build Tools
-    for Visual Studio 2017](https://aka.ms/BuildTools).
+    of Visual Studio 2015 or newer, or by installing the latest [Build Tools for Visual Studio 2017](https://aka.ms/BuildTools).
 
 *   **JDK.** Version 21 is required.
 
diff --git a/versions/8.6.0/install/ide.mdx b/versions/8.6.0/install/ide.mdx
index b86f351c..bd456354 100644
--- a/versions/8.6.0/install/ide.mdx
+++ b/versions/8.6.0/install/ide.mdx
@@ -38,10 +38,8 @@ To install, go to the IDE's plugin browser and search for `Bazel`.
 To manually install older versions, download the zip files from JetBrains'
 Plugin Repository and install the zip file from the IDE's plugin browser:
 
-*  [Android Studio
-   plugin](https://plugins.jetbrains.com/plugin/9185-android-studio-with-bazel)
-*  [IntelliJ
-   plugin](https://plugins.jetbrains.com/plugin/8609-intellij-with-bazel)
+*  [Android Studio plugin](https://plugins.jetbrains.com/plugin/9185-android-studio-with-bazel)
+*  [IntelliJ plugin](https://plugins.jetbrains.com/plugin/8609-intellij-with-bazel)
 *  [CLion plugin](https://plugins.jetbrains.com/plugin/9554-clion-with-bazel)
 
 ### Xcode
@@ -61,8 +59,7 @@ Features:
 * Starlark debugger for `.bzl` files during a build (set breakpoints, step
   through code, inspect variables, and so on)
 
-Find [the plugin on the Visual Studio
-marketplace](https://marketplace.visualstudio.com/items?itemName=BazelBuild.vscode-bazel).
+Find [the plugin on the Visual Studio marketplace](https://marketplace.visualstudio.com/items?itemName=BazelBuild.vscode-bazel).
 The plugin is [open source](https://github.com/bazelbuild/vscode-bazel).
 
 See also: [Autocomplete for Source Code](#autocomplete-for-source-code)
@@ -82,8 +79,7 @@ See also: [Autocomplete for Source Code](#autocomplete-for-source-code)
 
 ### Emacs
 
-See [`bazelbuild/bazel-emacs-mode` on
-GitHub](https://github.com/bazelbuild/emacs-bazel-mode)
+See [`bazelbuild/bazel-emacs-mode` on GitHub](https://github.com/bazelbuild/emacs-bazel-mode)
 
 See also: [Autocomplete for Source Code](#autocomplete-for-source-code)
 
@@ -115,6 +111,5 @@ tool for building Bazel targets when source files change.
 
 ## Building your own IDE plugin
 
-Read the [**IDE support** blog
-post](https://blog.bazel.build/2016/06/10/ide-support.html) to learn more about
+Read the [**IDE support** blog post](https://blog.bazel.build/2016/06/10/ide-support.html) to learn more about
 the Bazel APIs to use when building an IDE plugin.
diff --git a/versions/8.6.0/install/windows.mdx b/versions/8.6.0/install/windows.mdx
index e5b015b1..2e981621 100644
--- a/versions/8.6.0/install/windows.mdx
+++ b/versions/8.6.0/install/windows.mdx
@@ -31,8 +31,7 @@ To check your Windows version:
 
 Alternatively you can:
 
-*   [Download the Bazel binary (`bazel-version-windows-x86_64.exe`) from
- GitHub](https://github.com/bazelbuild/bazel/releases).
+*   [Download the Bazel binary (`bazel-version-windows-x86_64.exe`) from GitHub](https://github.com/bazelbuild/bazel/releases).
 *   [Install Bazel from Chocolatey](#chocolately)
 *   [Install Bazel from Scoop](#scoop)
 *   [Build Bazel from source](/versions/8.6.0/install/compile-source)
@@ -208,8 +207,7 @@ If that doesn't help:
     its dependencies, such as the MSYS2 shell. This will not install Visual C++
     though.
 
-See [Chocolatey installation and package maintenance
-guide](/versions/8.6.0/contribute/windows-chocolatey-maintenance) for more
+See [Chocolatey installation and package maintenance guide](/versions/8.6.0/contribute/windows-chocolatey-maintenance) for more
 information about the Chocolatey package.
 
 ### Using Scoop
@@ -226,8 +224,7 @@ information about the Chocolatey package.
     scoop install bazel
     ```
 
-See [Scoop installation and package maintenance
-guide](/versions/8.6.0/contribute/windows-scoop-maintenance) for more
+See [Scoop installation and package maintenance guide](/versions/8.6.0/contribute/windows-scoop-maintenance) for more
 information about the Scoop package.
 
 ### Build from source
diff --git a/versions/8.6.0/migrate/maven.mdx b/versions/8.6.0/migrate/maven.mdx
index a150c589..4c7fb5fa 100644
--- a/versions/8.6.0/migrate/maven.mdx
+++ b/versions/8.6.0/migrate/maven.mdx
@@ -19,8 +19,7 @@ directly run by Bazel since there's no Maven compatibility layer.
 ## Before you begin
 
 *   [Install Bazel](/versions/8.6.0/install) if it's not yet installed.
-*   If you're new to Bazel, go through the tutorial [Introduction to Bazel:
-    Build Java](/versions/8.6.0/start/java) before you start migrating. The tutorial explains
+*   If you're new to Bazel, go through the tutorial [Introduction to Bazel: Build Java](/versions/8.6.0/start/java) before you start migrating. The tutorial explains
     Bazel's concepts, structure, and label syntax.
 
 ## Differences between Maven and Bazel
@@ -44,8 +43,7 @@ The steps below describe how to migrate your project to Bazel:
 3.  [Create more BUILD files](#3-build)
 4.  [Build using Bazel](#4-build)
 
-Examples below come from a migration of the [Guava
-project](https://github.com/google/guava) from Maven to Bazel. The
+Examples below come from a migration of the [Guava project](https://github.com/google/guava) from Maven to Bazel. The
 Guava project used is release `v31.1`. The examples using Guava do not walk
 through each step in the migration, but they do show the files and contents that
 are generated or added manually for the migration.
@@ -63,14 +61,12 @@ has no external dependencies, this file can be empty.
 If your project depends on files or packages that are not in one of the
 project's directories, specify these external dependencies in the MODULE.bazel
 file. You can use `rules_jvm_external` to manage dependencies from Maven. For
-instructions about using this ruleset, see [the
-README](https://github.com/bazelbuild/rules_jvm_external/#rules_jvm_external)
+instructions about using this ruleset, see [the README](https://github.com/bazelbuild/rules_jvm_external/#rules_jvm_external)
 .
 
 #### Guava project example: external dependencies
 
-You can list the external dependencies of the [Guava
-project](https://github.com/google/guava) with the
+You can list the external dependencies of the [Guava project](https://github.com/google/guava) with the
 [`rules_jvm_external`](https://github.com/bazelbuild/rules_jvm_external)
 ruleset.
 
@@ -164,8 +160,7 @@ your build by adding more `BUILD` files with more granular targets.
             *   `resources`: Use globbing to list all resources in your project.
             *   `deps`: You need to determine which external dependencies your
                 project needs.
-        *   Take a look at the [example below of this top-level BUILD
-            file](#guava-2) from the migration of the Guava project.
+        *   Take a look at the [example below of this top-level BUILD file](#guava-2) from the migration of the Guava project.
 
 3.  Now that you have a `BUILD` file at the root of your project, build your
     project to ensure that it works. On the command line, from your workspace
diff --git a/versions/8.6.0/migrate/xcode.mdx b/versions/8.6.0/migrate/xcode.mdx
index e5cc29b0..d5107586 100644
--- a/versions/8.6.0/migrate/xcode.mdx
+++ b/versions/8.6.0/migrate/xcode.mdx
@@ -32,8 +32,7 @@ Before you begin, do the following:
 
 1.  [Install Bazel](/versions/8.6.0/install) if you have not already done so.
 
-2.  If you're not familiar with Bazel and its concepts, complete the [iOS app
-    tutorial](/versions/8.6.0/start/ios-app)). You should understand the Bazel workspace,
+2.  If you're not familiar with Bazel and its concepts, complete the [iOS app tutorial](/versions/8.6.0/start/ios-app)). You should understand the Bazel workspace,
     including the `MODULE.bazel` and `BUILD` files, as well as the concepts of
     targets, build rules, and Bazel packages.
 
@@ -44,8 +43,7 @@ Before you begin, do the following:
 Unlike Xcode, Bazel requires you to explicitly declare all dependencies for
 every target in the `BUILD` file.
 
-For more information on external dependencies, see [Working with external
-dependencies](/versions/8.6.0/docs/external).
+For more information on external dependencies, see [Working with external dependencies](/versions/8.6.0/docs/external).
 
 ## Build or test an Xcode project with Bazel
 
@@ -84,8 +82,7 @@ Note: Place the project source code within the directory tree containing the
 
 To integrate SwiftPM dependencies into the Bazel workspace with
 [swift_bazel](https://github.com/cgrindel/swift_bazel), you must
-convert them into Bazel packages as described in the [following
-tutorial](https://chuckgrindel.com/swift-packages-in-bazel-using-swift_bazel/)
+convert them into Bazel packages as described in the [following tutorial](https://chuckgrindel.com/swift-packages-in-bazel-using-swift_bazel/)
 .
 
 Note: SwiftPM support is a manual process with many variables. SwiftPM
@@ -103,8 +100,7 @@ initial build of the project as follows:
 *   [Step 3b: (Optional) Add the test target(s)](#step-3b-optional-add-the-test-target-s)
 *   [Step 3c: Add the library target(s)](#step-3c-add-the-library-target-s)
 
-**Tip:** To learn more about packages and other Bazel concepts, see [Workspaces,
-packages, and targets](/versions/8.6.0/concepts/build-ref).
+**Tip:** To learn more about packages and other Bazel concepts, see [Workspaces, packages, and targets](/versions/8.6.0/concepts/build-ref).
 
 #### Step 3a: Add the application target
 
@@ -132,8 +128,7 @@ In the target, specify the following at the minimum:
 
 #### Step 3b: (Optional) Add the test target(s)
 
-Bazel's [Apple build
-rules](https://github.com/bazelbuild/rules_apple) support running
+Bazel's [Apple build rules](https://github.com/bazelbuild/rules_apple) support running
 unit and UI tests on all Apple platforms. Add test targets as follows:
 
 *   [`macos_unit_test`](https://github.com/bazelbuild/rules_apple/blob/master/doc/rules-macos.md#macos_unit_test)
@@ -181,8 +176,7 @@ all sources and/or headers of a certain type. Use it carefully as it might
 include files you do not want Bazel to build.
 
 You can browse existing examples for various types of applications directly in
-the [rules_apple examples
-directory](https://github.com/bazelbuild/rules_apple/tree/master/examples/). For
+the [rules_apple examples directory](https://github.com/bazelbuild/rules_apple/tree/master/examples/). For
 example:
 
 *   [macOS application targets](https://github.com/bazelbuild/rules_apple/tree/master/examples/macos)
@@ -191,8 +185,7 @@ example:
 
 *   [Multi platform applications (macOS, iOS, watchOS, tvOS)](https://github.com/bazelbuild/rules_apple/tree/master/examples/multi_platform)
 
-For more information on build rules, see [Apple Rules for
-Bazel](https://github.com/bazelbuild/rules_apple).
+For more information on build rules, see [Apple Rules for Bazel](https://github.com/bazelbuild/rules_apple).
 
 At this point, it is a good idea to test the build:
 
diff --git a/versions/8.6.0/query/cquery.mdx b/versions/8.6.0/query/cquery.mdx
index 9585a1e0..166ba199 100644
--- a/versions/8.6.0/query/cquery.mdx
+++ b/versions/8.6.0/query/cquery.mdx
@@ -6,8 +6,7 @@ title: ' Configurable Query (cquery)'
 [`select()`](/versions/8.6.0/docs/configurable-attributes) and build options' effects on the build
 graph.
 
-It achieves this by running over the results of Bazel's [analysis
-phase](/versions/8.6.0/extending/concepts#evaluation-model),
+It achieves this by running over the results of Bazel's [analysis phase](/versions/8.6.0/extending/concepts#evaluation-model),
 which integrates these effects. `query`, by contrast, runs over the results of
 Bazel's loading phase, before options are evaluated.
 
@@ -137,8 +136,7 @@ $ bazel cquery //foo --universe_scope=//foo,//genrule_with_foo_as_tool
 If you want to precisely declare which instance to query over, use
 the [`config`](#config) function.
 
-See `query`'s [target pattern
-documentation](/versions/8.6.0/query/language#target-patterns) for more information on target patterns.
+See `query`'s [target pattern documentation](/versions/8.6.0/query/language#target-patterns) for more information on target patterns.
 
 ## Functions
 
diff --git a/versions/8.6.0/query/language.mdx b/versions/8.6.0/query/language.mdx
index 80321497..e2cc1482 100644
--- a/versions/8.6.0/query/language.mdx
+++ b/versions/8.6.0/query/language.mdx
@@ -1120,8 +1120,7 @@ is being used.
 
 ### On the ordering of results
 
-Although query expressions always follow the "[law of
-conservation of graph order](#graph-order)", _presenting_ the results may be done
+Although query expressions always follow the "[law of conservation of graph order](#graph-order)", _presenting_ the results may be done
 in either a dependency-ordered or unordered manner. This does **not**
 influence the targets in the result set or how the query is computed. It only
 affects how the results are printed to stdout. Moreover, nodes that are
@@ -1267,8 +1266,7 @@ and `maxrank` output formats print the labels of each
 target in the resulting graph, but instead of appearing in
 topological order, they appear in rank order, preceded by their
 rank number. These are unaffected by the result ordering
-`--[no]order_results` flag (see [notes on
-the ordering of results](#result-order)).
+`--[no]order_results` flag (see [notes on the ordering of results](#result-order)).
 
 There are two variants of this format: `minrank` ranks
 each node by the length of the shortest path from a root node to it.
diff --git a/versions/8.6.0/reference/be/functions.mdx b/versions/8.6.0/reference/be/functions.mdx
index e7c75155..b2590dd1 100644
--- a/versions/8.6.0/reference/be/functions.mdx
+++ b/versions/8.6.0/reference/be/functions.mdx
@@ -262,8 +262,7 @@ There are several important limitations and caveats:
    package called "Foo.java" (which is allowed, though Bazel warns about it),
    then the consumer of the `glob()` will use the "Foo.java" rule
    (its outputs) instead of the "Foo.java" file. See
-   [GitHub
-   issue #10395](https://github.com/bazelbuild/bazel/issues/10395#issuecomment-583714657) for more details.
+   [GitHub issue #10395](https://github.com/bazelbuild/bazel/issues/10395#issuecomment-583714657) for more details.
 3. Globs may match files in subdirectories. And subdirectory names
    may be wildcarded. However...
 4. Labels are not allowed to cross the package boundary and glob does
diff --git a/versions/8.6.0/reference/be/java.mdx b/versions/8.6.0/reference/be/java.mdx
index 9fe6ef85..3c3ce995 100644
--- a/versions/8.6.0/reference/be/java.mdx
+++ b/versions/8.6.0/reference/be/java.mdx
@@ -225,8 +225,7 @@ test code. The test runner's main method is invoked instead of the main class be
   [java_binary](#java_binary) for more details.
 
 See the section on `java_binary()` arguments. This rule also
-supports all [attributes common
-to all test rules (\*\_test)](https://bazel.build/reference/be/common-definitions#common-attributes-tests).
+supports all [attributes common to all test rules (\*\_test)](https://bazel.build/reference/be/common-definitions#common-attributes-tests).
 
 #### Examples
 
diff --git a/versions/8.6.0/reference/be/make-variables.mdx b/versions/8.6.0/reference/be/make-variables.mdx
index b527affb..db63d1b8 100644
--- a/versions/8.6.0/reference/be/make-variables.mdx
+++ b/versions/8.6.0/reference/be/make-variables.mdx
@@ -19,8 +19,7 @@ targets, and *custom* variables, which are defined in dependency targets
 and only available to targets that depend on them.
 
 The reason for the term "Make" is historical: the syntax and semantics of
-these variables were originally intended to match [GNU
-Make](https://www.gnu.org/software/make/manual/html_node/Using-Variables.html).
+these variables were originally intended to match [GNU Make](https://www.gnu.org/software/make/manual/html_node/Using-Variables.html).
 
 ## Use
 
@@ -64,8 +63,7 @@ and look at the top output lines with capital letters.
 **Toolchain option variables**
 
 * `COMPILATION_MODE`:
-  `fastbuild`, `dbg`, or `opt`. ([more
-  details](https://bazel.build/docs/user-manual#flag--compilation_mode))
+  `fastbuild`, `dbg`, or `opt`. ([more details](https://bazel.build/docs/user-manual#flag--compilation_mode))
 
 **Path variables**
 
diff --git a/versions/8.6.0/reference/be/workspace.mdx b/versions/8.6.0/reference/be/workspace.mdx
index 6fa7eec2..769eacb5 100644
--- a/versions/8.6.0/reference/be/workspace.mdx
+++ b/versions/8.6.0/reference/be/workspace.mdx
@@ -25,8 +25,7 @@ bind(name, actual, compatible_with, deprecation, distribs, features, licenses, r
 
 *Warning: use of `bind()` is not recommended. See "[Consider removing bind](https://github.com/bazelbuild/bazel/issues/1952)" for a long
 discussion of its issues and alternatives. In particular, consider the use of
-[`repo_mapping`
-repository attributes](https://bazel.build/rules/repository_rules#attributes).*
+[`repo_mapping` repository attributes](https://bazel.build/rules/repository_rules#attributes).*
 
 *Warning: `select()` cannot be used in `bind()`. See the [Configurable Attributes FAQ](/docs/configurable-attributes#bind-select) for
 details.*
@@ -114,8 +113,7 @@ local_repository(name, path, repo_mapping)
 ```
 
 Allows targets from a local directory to be bound. This means that the current repository can
-use targets defined in this other directory. See the [bind
-section](/reference/be/workspace#bind_examples) for more details.
+use targets defined in this other directory. See the [bind section](/reference/be/workspace#bind_examples) for more details.
 
 #### Examples
 
diff --git a/versions/8.6.0/reference/glossary.mdx b/versions/8.6.0/reference/glossary.mdx
index d3b310af..1f86ce03 100644
--- a/versions/8.6.0/reference/glossary.mdx
+++ b/versions/8.6.0/reference/glossary.mdx
@@ -24,8 +24,7 @@ An in-memory graph of [actions](#action) and the [artifacts](#artifact) that
 these actions read and generate. The graph might include artifacts that exist as
 source files (for example, in the file system) as well as generated
 intermediate/final artifacts that are not mentioned in `BUILD` files. Produced
-during the [analysis phase](#analysis-phase) and used during the [execution
-phase](#execution-phase).
+during the [analysis phase](#analysis-phase) and used during the [execution phase](#execution-phase).
 
 ### Action graph query (aquery)
 
@@ -43,8 +42,7 @@ invalidate individual actions deterministically.
 ### Analysis phase
 
 The second phase of a build. Processes the [target graph](#target-graph)
-specified in [`BUILD` files](#build-file) to produce an in-memory [action
-graph](#action-graph) that determines the order of actions to run during the
+specified in [`BUILD` files](#build-file) to produce an in-memory [action graph](#action-graph) that determines the order of actions to run during the
 [execution phase](#execution-phase). This is the phase in which rule
 implementations are evaluated.
 
@@ -92,8 +90,7 @@ attributes available for a given target depend on its rule type.
 
 ### .bazelrc
 
-Bazel’s configuration file used to change the default values for [startup
-flags](#startup-flags) and [command flags](#command-flags), and to define common
+Bazel’s configuration file used to change the default values for [startup flags](#startup-flags) and [command flags](#command-flags), and to define common
 groups of options that can then be set together on the Bazel command line using
 a `--config` flag. Bazel can combine settings from multiple bazelrc files
 (systemwide, per-workspace, per-user, or from a custom location), and a
@@ -123,8 +120,7 @@ directory.
 ### .bzl File
 
 A file that defines rules, [macros](#macro), and constants written in
-[Starlark](#starlark). These can then be imported into [`BUILD`
-files](#build-file) using the `load()` function.
+[Starlark](#starlark). These can then be imported into [`BUILD` files](#build-file) using the `load()` function.
 
 {/* TODO: ### Build event protocol */}
 
@@ -133,8 +129,7 @@ files](#build-file) using the `load()` function.
 ### Build graph
 
 The dependency graph that Bazel constructs and traverses to perform a build.
-Includes nodes like [targets](#target), [configured
-targets](#configured-target), [actions](#action), and [artifacts](#artifact). A
+Includes nodes like [targets](#target), [configured targets](#configured-target), [actions](#action), and [artifacts](#artifact). A
 build is considered complete when all [artifacts](#artifact) on which a set of
 requested targets depend are verified as up-to-date.
 
@@ -180,8 +175,7 @@ graphs and restart the [analysis phase](#analysis-phase).
 
 Information outside of [rule](#rule) definitions that impacts how rules generate
 [actions](#action). Every build has at least one configuration specifying the
-target platform, action environment variables, and command-line [build
-flags](#command-flags). [Transitions](#transition) may create additional
+target platform, action environment variables, and command-line [build flags](#command-flags). [Transitions](#transition) may create additional
 configurations, such as for host tools or cross-compilation.
 
 **See also:** [Configurations](/versions/8.6.0/extending/rules#configurations)
@@ -198,8 +192,7 @@ build cacheability.
 
 ### Configured query (cquery)
 
-A [query](#query-concept) tool that queries over [configured
-targets](#configured-target) (after the [analysis phase](#analysis-phase)
+A [query](#query-concept) tool that queries over [configured targets](#configured-target) (after the [analysis phase](#analysis-phase)
 completes). This means `select()` and [build flags](#command-flags) (such as
 `--platforms`) are accurately reflected in the results.
 
@@ -217,8 +210,7 @@ build, it has two configured targets: `` and ``.
 
 A build is correct when its output faithfully reflects the state of its
 transitive inputs. To achieve correct builds, Bazel strives to be
-[hermetic](#hermeticity), reproducible, and making [build
-analysis](#analysis-phase) and [action execution](#execution-phase)
+[hermetic](#hermeticity), reproducible, and making [build analysis](#analysis-phase) and [action execution](#execution-phase)
 deterministic.
 
 ### Dependency
@@ -266,8 +258,7 @@ incremental and clean build times.
 
 ### Execution phase
 
-The third phase of a build. Executes the [actions](#action) in the [action
-graph](#action-graph) created during the [analysis phase](#analysis-phase).
+The third phase of a build. Executes the [actions](#action) in the [action graph](#action-graph) created during the [analysis phase](#analysis-phase).
 These actions invoke executables (compilers, scripts) to read and write
 [artifacts](#artifact). *Spawn strategies* control how these actions are
 executed: locally, remotely, dynamically, sandboxed, docker, and so on.
@@ -323,8 +314,7 @@ syntax may be omitted.
 The first phase of a build where Bazel executes [`BUILD` files](#build-file) to
 create [packages](#package). [Macros](#macro) and certain functions like
 `glob()` are evaluated in this phase. Interleaved with the second phase of the
-build, the [analysis phase](#analysis-phase), to build up a [target
-graph](#target-graph).
+build, the [analysis phase](#analysis-phase), to build up a [target graph](#target-graph).
 
 ### Legacy macro
 
@@ -379,8 +369,7 @@ Module metadata is hosted in Bazel registries.
 ### Module Extension
 
 A piece of logic that can be run to generate [repos](#repository) by reading
-inputs from across the [module](#module) dependency graph and invoking [repo
-rules](#repository-rule). Module extensions have capabilities similar to repo
+inputs from across the [module](#module) dependency graph and invoking [repo rules](#repository-rule). Module extensions have capabilities similar to repo
 rules, allowing them to access the internet, perform file I/O, and so on.
 
 **See also:** [Module extensions](/versions/8.6.0/external/extension)
@@ -395,8 +384,7 @@ example, `native.cc_library` or `native.java_library`). User-defined rules
 ### Output base
 
 A [workspace](#workspace)-specific directory to store Bazel output files. Used
-to separate outputs from the *workspace*'s source tree (the [main
-repo](#repository)). Located in the [output user root](#output-user-root).
+to separate outputs from the *workspace*'s source tree (the [main repo](#repository)). Located in the [output user root](#output-user-root).
 
 ### Output groups
 
@@ -459,8 +447,7 @@ query variants: [query](#query-command), [cquery](#configured-query), and
 
 ### query (command)
 
-A [query](#query-concept) tool that operates over the build's post-[loading
-phase](#loading-phase) [target graph](#target-graph). This is relatively fast,
+A [query](#query-concept) tool that operates over the build's post-[loading phase](#loading-phase) [target graph](#target-graph). This is relatively fast,
 but can't analyze the effects of `select()`, [build flags](#command-flags),
 [artifacts](#artifact), or build [actions](#action).
 
@@ -479,8 +466,7 @@ repo; multiple such files can coexist in a directory.
 The *main repo* is the repo in which the current Bazel command is being run.
 
 *External repos* are defined by specifying [modules](#module) in `MODULE.bazel`
-files, or invoking [repo rules](#repository-rule) in [module
-extensions](#module-extension). They can be fetched on demand to a predetermined
+files, or invoking [repo rules](#repository-rule) in [module extensions](#module-extension). They can be fetched on demand to a predetermined
 "magical" location on disk.
 
 Each repo has a unique, constant *canonical* name, and potentially different
@@ -492,8 +478,7 @@ Each repo has a unique, constant *canonical* name, and potentially different
 
 A shared content-addressable cache of files downloaded by Bazel for builds,
 shareable across [workspaces](#workspace). Enables offline builds after the
-initial download. Commonly used to cache files downloaded through [repository
-rules](#repository-rule) like `http_archive` and repository rule APIs like
+initial download. Commonly used to cache files downloaded through [repository rules](#repository-rule) like `http_archive` and repository rule APIs like
 `repository_ctx.download`. Files are cached only if their SHA-256 checksums are
 specified for the download.
 
@@ -530,8 +515,7 @@ Rules are instantiated to produce rule targets in the
 [loading phase](#loading-phase). In the [analysis phase](#analysis-phase) rule
 targets communicate information to their downstream dependencies in the form of
 [providers](#provider), and register [actions](#action) describing how to
-generate their output artifacts. These actions are run in the [execution
-phase](#execution-phase).
+generate their output artifacts. These actions are run in the [execution phase](#execution-phase).
 
 Note: Historically the term "rule" has been used to refer to a rule target.
 This usage was inherited from tools like Make, but causes confusion and should
@@ -581,8 +565,7 @@ support the stamp attribute.
 
 The extension language for writing [rules](/versions/8.6.0/extending/rules) and [macros](#macro). A
 restricted subset of Python (syntactically and grammatically) aimed for the
-purpose of configuration, and for better performance. Uses the [`.bzl`
-file](#bzl-file) extension. [`BUILD` files](#build-file) use an even more
+purpose of configuration, and for better performance. Uses the [`.bzl` file](#bzl-file) extension. [`BUILD` files](#build-file) use an even more
 restricted version of Starlark (such as no `def` function definitions), formerly
 known as Skylark.
 
@@ -616,8 +599,7 @@ An object that is defined in a [`BUILD` file](#build-file) and identified by a
 [label](#label). Targets represent the buildable units of a workspace from
 the perspective of the end user.
 
-A target that is declared by instantiating a [rule](#rule) is called a [rule
-target](#rule-target). Depending on the rule, these may be runnable (like
+A target that is declared by instantiating a [rule](#rule) is called a [rule target](#rule-target). Depending on the rule, these may be runnable (like
 `cc_binary`) or testable (like `cc_test`). Rule targets typically depend on
 other targets via their [attributes](#attribute) (such as `deps`); these
 dependencies form the basis of the [target graph](#target-graph).
@@ -628,15 +610,12 @@ within a `BUILD` file. As a special case, the `BUILD` file of any package is
 always considered a source file target in that package.
 
 Targets are discovered during the [loading phase](#loading-phase). During the
-[analysis phase](#analysis-phase), targets are associated with [build
-configurations](#configuration) to form [configured
-targets](#configured-target).
+[analysis phase](#analysis-phase), targets are associated with [build configurations](#configuration) to form [configured targets](#configured-target).
 
 ### Target graph
 
 An in-memory graph of [targets](#target) and their dependencies. Produced during
-the [loading phase](#loading-phase) and used as an input to the [analysis
-phase](#analysis-phase).
+the [loading phase](#loading-phase) and used as an input to the [analysis phase](#analysis-phase).
 
 ### Target pattern
 
@@ -651,8 +630,7 @@ packages recursively from the root of the [workspace](#workspace).
 Rule [targets](#target) instantiated from test rules, and therefore contains a
 test executable. A return code of zero from the completion of the executable
 indicates test success. The exact contract between Bazel and tests (such as test
-environment variables, test result collection methods) is specified in the [Test
-Encyclopedia](/versions/8.6.0/reference/test-encyclopedia).
+environment variables, test result collection methods) is specified in the [Test Encyclopedia](/versions/8.6.0/reference/test-encyclopedia).
 
 ### Toolchain
 
@@ -668,8 +646,7 @@ A build [target](#target) is top-level if it’s requested on the Bazel command
 line. For example, if `//:foo` depends on `//:bar`, and `bazel build //:foo` is
 called, then for this build, `//:foo` is top-level, and `//:bar` isn’t
 top-level, although both targets will need to be built. An important difference
-between top-level and non-top-level targets is that [command
-flags](#command-flags) set on the Bazel command line (or via
+between top-level and non-top-level targets is that [command flags](#command-flags) set on the Bazel command line (or via
 [.bazelrc](#bazelrc)) will set the [configuration](#configuration) for top-level
 targets, but might be modified by a [transition](#transition) for non-top-level
 targets.
@@ -704,8 +681,7 @@ or `.bzl` file may load a given `.bzl` file. Without context, usually
 
 ### Workspace
 
-The environment shared by all Bazel commands run from the same [main
-repository](#repository).
+The environment shared by all Bazel commands run from the same [main repository](#repository).
 
 Note that historically the concepts of "repository" and "workspace" have been
 conflated; the term "workspace" has often been used to refer to the main
diff --git a/versions/8.6.0/release/backward-compatibility.mdx b/versions/8.6.0/release/backward-compatibility.mdx
index cc4467bb..fe6c3456 100644
--- a/versions/8.6.0/release/backward-compatibility.mdx
+++ b/versions/8.6.0/release/backward-compatibility.mdx
@@ -6,11 +6,9 @@ This page provides information about how to handle backward compatibility,
 including migrating from one release to another and how to communicate
 incompatible changes.
 
-Bazel is evolving. Minor versions released as part of an [LTS major
-version](/versions/8.6.0/release#bazel-versioning) are fully backward-compatible. New major LTS
+Bazel is evolving. Minor versions released as part of an [LTS major version](/versions/8.6.0/release#bazel-versioning) are fully backward-compatible. New major LTS
 releases may contain incompatible changes that require some migration effort.
-For more information about Bazel's release model, please check out the [Release
-Model](/versions/8.6.0/release) page.
+For more information about Bazel's release model, please check out the [Release Model](/versions/8.6.0/release) page.
 
 ## Summary
 
@@ -59,8 +57,7 @@ available.
 ## Communicating incompatible changes
 
 The primary source of information about incompatible changes are GitHub issues
-marked with an ["incompatible-change"
-label](https://github.com/bazelbuild/bazel/issues?q=label%3Aincompatible-change).
+marked with an ["incompatible-change" label](https://github.com/bazelbuild/bazel/issues?q=label%3Aincompatible-change).
 
 For every incompatible change, the issue specifies the following:
 
diff --git a/versions/8.6.0/release/index.mdx b/versions/8.6.0/release/index.mdx
index 4611db17..3bb90d98 100644
--- a/versions/8.6.0/release/index.mdx
+++ b/versions/8.6.0/release/index.mdx
@@ -2,8 +2,7 @@
 title: 'Release Model'
 ---
 
-As announced in [the original blog
-post](https://blog.bazel.build/2020/11/10/long-term-support-release.html), Bazel
+As announced in [the original blog post](https://blog.bazel.build/2020/11/10/long-term-support-release.html), Bazel
 4.0 and higher versions provides support for two release tracks: rolling
 releases and long term support (LTS) releases. This page covers the latest
 information about Bazel's release model.
@@ -19,8 +18,7 @@ information about Bazel's release model.
 | Bazel 5 | Maintenance | [5.4.1](https://github.com/bazelbuild/bazel/releases/tag/5.4.1) | Jan 2025 |
 | Bazel 4 | Deprecated | [4.2.4](https://github.com/bazelbuild/bazel/releases/tag/4.2.4) | Jan 2024 |
 
-All Bazel LTS releases can be found on the [release
-page](https://github.com/bazelbuild/bazel/releases) on GitHub.
+All Bazel LTS releases can be found on the [release page](https://github.com/bazelbuild/bazel/releases) on GitHub.
 
 Note: Bazel version older than Bazel 5 are no longer supported, Bazel users are
 recommended to upgrade to the latest LTS release or use rolling releases if you
@@ -28,8 +26,7 @@ want to keep up with the latest changes at HEAD.
 
 ## Release versioning
 
-Bazel uses a _major.minor.patch_ [Semantic
-Versioning](https://semver.org/) scheme.
+Bazel uses a _major.minor.patch_ [Semantic Versioning](https://semver.org/) scheme.
 
 *   A _major release_ contains features that are not backward compatible with
     the previous release. Each major Bazel version is an LTS release.
@@ -72,8 +69,7 @@ Bazel regularly publish releases for two release tracks.
     release.
 *   Rolling releases can ship incompatible changes. Incompatible flags are
     recommended for major breaking changes, rolling out incompatible changes
-    should follow our [backward compatibility
-    policy](/versions/8.6.0/release/backward-compatibility).
+    should follow our [backward compatibility policy](/versions/8.6.0/release/backward-compatibility).
 
 ### LTS releases
 
@@ -89,8 +85,7 @@ Bazel regularly publish releases for two release tracks.
 *   A Bazel LTS release enters the Deprecated stage after being in ​​the
     Maintenance stage for 2 years.
 
-For planned releases, please check our [release
-issues](https://github.com/bazelbuild/bazel/issues?q=is%3Aopen+is%3Aissue+label%3Arelease)
+For planned releases, please check our [release issues](https://github.com/bazelbuild/bazel/issues?q=is%3Aopen+is%3Aissue+label%3Arelease)
 on Github.
 
 ## Release procedure & policies
@@ -153,8 +148,7 @@ For LTS releases, the procedure and policies below are followed:
 1.  Identify release blockers and fix issues found on the release branch.
     *   The release branch is tested with the same test suite in
         [postsubmit](https://buildkite.com/bazel/bazel-bazel) and
-        [downstream test pipeline]
-        (https://buildkite.com/bazel/bazel-at-head-plus-downstream)
+        [downstream test pipeline](https://buildkite.com/bazel/bazel-at-head-plus-downstream)
         on Bazel CI. The Bazel team monitors testing results of the release
         branch and fixes any regressions found.
 1.  Create a new release candidate from the release branch when all known
@@ -210,5 +204,4 @@ feature.
 ## Rule compatibility
 
 If you are a rule authors and want to maintain compatibility with different
-Bazel versions, please check out the [Rule
-Compatibility](/versions/8.6.0/release/rule-compatibility) page.
+Bazel versions, please check out the [Rule Compatibility](/versions/8.6.0/release/rule-compatibility) page.
diff --git a/versions/8.6.0/release/rule-compatibility.mdx b/versions/8.6.0/release/rule-compatibility.mdx
index 419803cc..91f2d050 100644
--- a/versions/8.6.0/release/rule-compatibility.mdx
+++ b/versions/8.6.0/release/rule-compatibility.mdx
@@ -53,18 +53,15 @@ Bazel LTS release.
 As Bazel rules authors, you can ensure a manageable migration process for users
 by following these best practices:
 
-1.  The rule should follow [Semantic
-    Versioning](https://semver.org/): minor versions of the same
+1.  The rule should follow [Semantic Versioning](https://semver.org/): minor versions of the same
     major version are backward compatible.
 1.  The rule at HEAD should be compatible with the latest Bazel LTS release.
 1.  The rule at HEAD should be compatible with Bazel at HEAD. To achieve this,
     you can
     *   Set up your own CI testing with Bazel at HEAD
-    *   Add your project to [Bazel downstream
-        testing](https://github.com/bazelbuild/continuous-integration/blob/master/docs/downstream-testing.md);
+    *   Add your project to [Bazel downstream testing](https://github.com/bazelbuild/continuous-integration/blob/master/docs/downstream-testing.md);
         the Bazel team files issues to your project if breaking changes in Bazel
-        affect your project, and you must follow our [downstream project
-        policies](https://github.com/bazelbuild/continuous-integration/blob/master/docs/downstream-testing.md#downstream-project-policies)
+        affect your project, and you must follow our [downstream project policies](https://github.com/bazelbuild/continuous-integration/blob/master/docs/downstream-testing.md#downstream-project-policies)
         to address issues timely.
 1.  The latest major version of the rule must be compatible with the latest
     Bazel LTS release.
diff --git a/versions/8.6.0/remote/bep-glossary.mdx b/versions/8.6.0/remote/bep-glossary.mdx
index d38b4a05..4355e333 100644
--- a/versions/8.6.0/remote/bep-glossary.mdx
+++ b/versions/8.6.0/remote/bep-glossary.mdx
@@ -410,5 +410,4 @@ workspace, such as the execution root.
 
 ## WorkspaceStatus
 
-A single `WorkspaceStatus` event contains the result of the [workspace status
-command](/versions/8.6.0/docs/user-manual#workspace-status).
+A single `WorkspaceStatus` event contains the result of the [workspace status command](/versions/8.6.0/docs/user-manual#workspace-status).
diff --git a/versions/8.6.0/remote/bep.mdx b/versions/8.6.0/remote/bep.mdx
index 32b7611e..3b5a7413 100644
--- a/versions/8.6.0/remote/bep.mdx
+++ b/versions/8.6.0/remote/bep.mdx
@@ -2,14 +2,12 @@
 title: 'Build Event Protocol'
 ---
 
-The [Build Event
-Protocol](https://github.com/bazelbuild/bazel/blob/master/src/main/java/com/google/devtools/build/lib/buildeventstream/proto/build_event_stream.proto)
+The [Build Event Protocol](https://github.com/bazelbuild/bazel/blob/master/src/main/java/com/google/devtools/build/lib/buildeventstream/proto/build_event_stream.proto)
 (BEP) allows third-party programs to gain insight into a Bazel invocation. For
 example, you could use the BEP to gather information for an IDE
 plugin or a dashboard that displays build results.
 
-The protocol is a set of [protocol
-buffer](https://developers.google.com/protocol-buffers/) messages with some
+The protocol is a set of [protocol buffer](https://developers.google.com/protocol-buffers/) messages with some
 semantics defined on top of it. It includes information about build and test
 results, build progress, the build configuration and much more. The BEP is
 intended to be consumed programmatically and makes parsing Bazel’s
@@ -20,16 +18,13 @@ build event is a protocol buffer message consisting of a build event identifier,
 a set of child event identifiers, and a payload.
 
 *  __Build Event Identifier:__ Depending on the kind of build event, it might be
-an [opaque
-string](https://github.com/bazelbuild/bazel/blob/7.1.0/src/main/java/com/google/devtools/build/lib/buildeventstream/proto/build_event_stream.proto#L131-L140)
-or [structured
-information](https://github.com/bazelbuild/bazel/blob/7.1.0/src/main/java/com/google/devtools/build/lib/buildeventstream/proto/build_event_stream.proto#L194-L205)
+an [opaque string](https://github.com/bazelbuild/bazel/blob/7.1.0/src/main/java/com/google/devtools/build/lib/buildeventstream/proto/build_event_stream.proto#L131-L140)
+or [structured information](https://github.com/bazelbuild/bazel/blob/7.1.0/src/main/java/com/google/devtools/build/lib/buildeventstream/proto/build_event_stream.proto#L194-L205)
 revealing more about the build event. A build event identifier is unique within
 a build.
 
 *  __Children:__ A build event may announce other build events, by including
-their build event identifiers in its [children
-field](https://github.com/bazelbuild/bazel/blob/7.1.0/src/main/java/com/google/devtools/build/lib/buildeventstream/proto/build_event_stream.proto#L1276).
+their build event identifiers in its [children field](https://github.com/bazelbuild/bazel/blob/7.1.0/src/main/java/com/google/devtools/build/lib/buildeventstream/proto/build_event_stream.proto#L1276).
 For example, the `PatternExpanded` build event announces the targets it expands
 to as children. The protocol guarantees that all events, except for the first
 event, are announced by a previous event.
@@ -91,8 +86,7 @@ human-readable formats, such as text and JSON:
 
 ## Build Event Service
 
-The [Build Event
-Service](https://github.com/googleapis/googleapis/blob/master/google/devtools/build/v1/publish_build_event.proto)
+The [Build Event Service](https://github.com/googleapis/googleapis/blob/master/google/devtools/build/v1/publish_build_event.proto)
 Protocol is a generic [gRPC](https://www.grpc.io) service for publishing build events. The Build Event
 Service protocol is independent of the BEP and treats BEP events as opaque bytes.
 Bazel ships with a gRPC client implementation of the Build Event Service protocol that
@@ -136,8 +130,7 @@ For a description of each of these flags, see the
 The BEP typically contains many references to log files (test.log, test.xml,
 etc. ) stored on the machine where Bazel is running. A remote BES server
 typically can't access these files as they are on different machines. A way to
-work around this issue is to use Bazel with [remote
-caching](/versions/8.6.0/remote/caching).
+work around this issue is to use Bazel with [remote caching](/versions/8.6.0/remote/caching).
 Bazel will upload all output files to the remote cache (including files
 referenced in the BEP) and the BES server can then fetch the referenced files
 from the cache.
diff --git a/versions/8.6.0/remote/cache-local.mdx b/versions/8.6.0/remote/cache-local.mdx
index e073bc31..28300aaf 100644
--- a/versions/8.6.0/remote/cache-local.mdx
+++ b/versions/8.6.0/remote/cache-local.mdx
@@ -18,8 +18,7 @@ execution. However, local execution presents some additional challenges.
 ## Checking your cache hit rate
 
 Successful remote cache hits will show up in the status line, similar to
-[Cache Hits rate with Remote
-Execution](/versions/8.6.0/remote/cache-remote#check-cache-hits).
+[Cache Hits rate with Remote Execution](/versions/8.6.0/remote/cache-remote#check-cache-hits).
 
 In the standard output of your Bazel run, you will see something like the
 following:
@@ -66,8 +65,7 @@ the steps in this section.
    message you see does not give you enough information, try adding
    `--verbose_failures`.
 
-2. Follow the steps from [Troubleshooting cache hits for remote
-   execution](/versions/8.6.0/remote/cache-remote#troubleshooting_cache_hits) to
+2. Follow the steps from [Troubleshooting cache hits for remote execution](/versions/8.6.0/remote/cache-remote#troubleshooting_cache_hits) to
    ensure that your cache-writing Bazel invocations are able to get cache hits
    on the same machine and across machines.
 
@@ -81,7 +79,6 @@ the steps in this section.
    b. Ensure your cache-reading Bazel invocations build the same targets as the
       cache-writing Bazel invocations.
 
-   c. Follow the same steps as to [ensure caching across
-      machines](/versions/8.6.0/remote/cache-remote#caching-across-machines),
+   c. Follow the same steps as to [ensure caching across machines](/versions/8.6.0/remote/cache-remote#caching-across-machines),
       to ensure caching from your cache-writing Bazel invocation to your
       cache-reading Bazel invocation.
diff --git a/versions/8.6.0/remote/caching.mdx b/versions/8.6.0/remote/caching.mdx
index 9f744a2d..e9680f11 100644
--- a/versions/8.6.0/remote/caching.mdx
+++ b/versions/8.6.0/remote/caching.mdx
@@ -308,8 +308,7 @@ or for the age of individual cache entries. Bazel will automatically garbage
 collect the disk cache while idling between builds; the idle timer can be set
 with `--experimental_disk_cache_gc_idle_delay` (defaulting to 5 minutes).
 
-As an alternative to automatic garbage collection, we also provide a [tool](
-https://github.com/bazelbuild/bazel/tree/master/src/tools/diskcache) to run a
+As an alternative to automatic garbage collection, we also provide a [tool](https://github.com/bazelbuild/bazel/tree/master/src/tools/diskcache) to run a
 garbage collection on demand.
 
 ## Known issues
diff --git a/versions/8.6.0/remote/dynamic.mdx b/versions/8.6.0/remote/dynamic.mdx
index f585b03d..6c09c7fc 100644
--- a/versions/8.6.0/remote/dynamic.mdx
+++ b/versions/8.6.0/remote/dynamic.mdx
@@ -12,8 +12,7 @@ alike.
 This page describes how to enable, tune, and debug dynamic execution. If you
 have both local and remote execution set up and are trying to adjust Bazel
 settings for better performance, this page is for you. If you don't already have
-remote execution set up, go to the Bazel [Remote Execution
-Overview](/versions/8.6.0/remote/rbe) first.
+remote execution set up, go to the Bazel [Remote Execution Overview](/versions/8.6.0/remote/rbe) first.
 
 ## Enabling dynamic execution?
 
@@ -44,14 +43,12 @@ are likely. The default value is 1000ms, but should be tuned to being just a bit
 longer than cache hits usually take. The actual time depends both on the remote
 system and on how long a round-trip takes. Usually, the value will be the same
 for all users of a given remote system, unless some of them are far enough away
-to add roundtrip latency. You can use the [Bazel profiling
-features](/versions/8.6.0/rules/performance#performance-profiling) to look at how long typical
+to add roundtrip latency. You can use the [Bazel profiling features](/versions/8.6.0/rules/performance#performance-profiling) to look at how long typical
 cache hits take.
 
 Dynamic execution can be used with local sandboxed strategy as well as with
 [persistent workers](/versions/8.6.0/remote/persistent). Persistent workers will automatically
-run with sandboxing when used with dynamic execution, and cannot use [multiplex
-workers](/versions/8.6.0/remote/multiplex). On Darwin and Windows systems, the sandboxed
+run with sandboxing when used with dynamic execution, and cannot use [multiplex workers](/versions/8.6.0/remote/multiplex). On Darwin and Windows systems, the sandboxed
 strategy can be slow; you can pass `--reuse_sandbox_directories` to reduce
 overhead of creating sandboxes on these systems.
 
@@ -67,8 +64,7 @@ entire action fails. This is an intentional choice to prevent differences
 between local and remote execution from going unnoticed.
 
 For more background on how dynamic execution and its locking works, see Julio
-Merino's excellent [blog
-posts](https://jmmv.dev/series/bazel-dynamic-execution/)
+Merino's excellent [blog posts](https://jmmv.dev/series/bazel-dynamic-execution/)
 
 ## When should I use dynamic execution?
 
diff --git a/versions/8.6.0/remote/persistent.mdx b/versions/8.6.0/remote/persistent.mdx
index a1b539bc..7795e1b3 100644
--- a/versions/8.6.0/remote/persistent.mdx
+++ b/versions/8.6.0/remote/persistent.mdx
@@ -257,7 +257,6 @@ For more information on persistent workers, see:
 *   [Original persistent workers blog post](https://blog.bazel.build/2015/12/10/java-workers.html)
 *   [Haskell implementation description](https://www.tweag.io/blog/2019-09-25-bazel-ghc-persistent-worker-internship/)
 *   [Blog post by Mike Morearty](https://medium.com/@mmorearty/how-to-create-a-persistent-worker-for-bazel-7738bba2cabb)
-*   [Front End Development with Bazel: Angular/TypeScript and Persistent Workers
-    w/ Asana](https://www.youtube.com/watch?v=0pgERydGyqo)
+*   [Front End Development with Bazel: Angular/TypeScript and Persistent Workers w/ Asana](https://www.youtube.com/watch?v=0pgERydGyqo)
 *   [Bazel strategies explained](https://jmmv.dev/2019/12/bazel-strategies.html)
 *   [Informative worker strategy discussion on the bazel-discuss mailing list](https://groups.google.com/forum/#!msg/bazel-discuss/oAEnuhYOPm8/ol7hf4KWJgAJ)
diff --git a/versions/8.6.0/remote/rules.mdx b/versions/8.6.0/remote/rules.mdx
index 7740aecf..f25bd058 100644
--- a/versions/8.6.0/remote/rules.mdx
+++ b/versions/8.6.0/remote/rules.mdx
@@ -54,8 +54,7 @@ variables that may not be set to equivalent values (or at all) in the remote
 execution environment.
 
 Toolchain rules currently exist for Bazel build and test rules for
-[Scala](https://github.com/bazelbuild/rules_scala/blob/master/scala/scala_toolch
-ain.bzl),
+[Scala](https://github.com/bazelbuild/rules_scala/blob/master/scala/scala_toolch ain.bzl),
 [Rust](https://github.com/bazelbuild/rules_rust/blob/main/rust/toolchain.bzl),
 and [Go](https://github.com/bazelbuild/rules_go/blob/master/go/toolchains.rst),
 and new toolchain rules are under way for other languages and tools such as
diff --git a/versions/8.6.0/remote/workspace.mdx b/versions/8.6.0/remote/workspace.mdx
index 73908871..dca5bce1 100644
--- a/versions/8.6.0/remote/workspace.mdx
+++ b/versions/8.6.0/remote/workspace.mdx
@@ -11,8 +11,7 @@ on the host machine. If your workspace rules access information about the
 host machine for use during execution, your build is likely to break due to
 incompatibilities between the environments.
 
-As part of [adapting Bazel rules for remote
-execution](/versions/8.6.0/remote/rules), you need to find such workspace rules
+As part of [adapting Bazel rules for remote execution](/versions/8.6.0/remote/rules), you need to find such workspace rules
 and fix them. This page describes how to find potentially problematic workspace
 rules using the workspace log.
 
diff --git a/versions/8.6.0/rules/language.mdx b/versions/8.6.0/rules/language.mdx
index 3cf2942f..1a75922c 100644
--- a/versions/8.6.0/rules/language.mdx
+++ b/versions/8.6.0/rules/language.mdx
@@ -94,10 +94,8 @@ values returned by rules are immutable.
 `BUILD` files register targets via making calls to rules. `.bzl` files provide
 definitions for constants, rules, macros, and functions.
 
-[Native functions](/versions/8.6.0/reference/be/functions) and [native rules](
-/reference/be/overview#language-specific-native-rules) are global symbols in
-`BUILD` files. `bzl` files need to load them using the [`native` module](
-/rules/lib/toplevel/native).
+[Native functions](/versions/8.6.0/reference/be/functions) and [native rules](/reference/be/overview#language-specific-native-rules) are global symbols in
+`BUILD` files. `bzl` files need to load them using the [`native` module](/rules/lib/toplevel/native).
 
 There are two syntactic restrictions in `BUILD` files: 1) declaring functions is
 illegal, and 2) `*args` and `**kwargs` arguments are not allowed.
diff --git a/versions/8.6.0/rules/legacy-macro-tutorial.mdx b/versions/8.6.0/rules/legacy-macro-tutorial.mdx
index c2d9bd57..27f6e923 100644
--- a/versions/8.6.0/rules/legacy-macro-tutorial.mdx
+++ b/versions/8.6.0/rules/legacy-macro-tutorial.mdx
@@ -3,9 +3,7 @@ title: 'Creating a Legacy Macro'
 ---
 
 IMPORTANT: This tutorial is for [*legacy macros*](/versions/8.6.0/extending/legacy-macros). If
-you only need to support Bazel 8 or newer, we recommend using [symbolic
-macros](/versions/8.6.0/extending/macros) instead; take a look at [Creating a Symbolic
-Macro](../macro-tutorial).
+you only need to support Bazel 8 or newer, we recommend using [symbolic macros](/versions/8.6.0/extending/macros) instead; take a look at [Creating a Symbolic Macro](../macro-tutorial).
 
 Imagine that you need to run a tool as part of your build. For example, you
 may want to generate or preprocess a source file, or compress a binary. In this
diff --git a/versions/8.6.0/rules/verbs-tutorial.mdx b/versions/8.6.0/rules/verbs-tutorial.mdx
index 7deffbe3..2df6d2e2 100644
--- a/versions/8.6.0/rules/verbs-tutorial.mdx
+++ b/versions/8.6.0/rules/verbs-tutorial.mdx
@@ -49,8 +49,7 @@ This pattern can also be seen in the Angular project. The
 produces two targets. The first is a standard `nodejs_test` target which compares
 some generated output against a "golden" file (that is, a file containing the
 expected output). This can be built and run with a normal `bazel
-test` invocation. In `angular-cli`, you can run [one such
-target](https://github.com/angular/angular-cli/blob/e1269cb520871ee29b1a4eec6e6c0e4a94f0b5fc/etc/api/BUILD)
+test` invocation. In `angular-cli`, you can run [one such target](https://github.com/angular/angular-cli/blob/e1269cb520871ee29b1a4eec6e6c0e4a94f0b5fc/etc/api/BUILD)
 with `bazel test //etc/api:angular_devkit_core_api`.
 
 Over time, this golden file may need to be updated for legitimate reasons.
diff --git a/versions/8.6.0/run/build.mdx b/versions/8.6.0/run/build.mdx
index c3d6a7c9..ddb1586a 100644
--- a/versions/8.6.0/run/build.mdx
+++ b/versions/8.6.0/run/build.mdx
@@ -633,8 +633,7 @@ Note: Hermeticity means that the action only uses its declared input
 files and no other files in the filesystem, and it only produces its declared
 output files. See [Hermeticity](/versions/8.6.0/basics/hermeticity) for more details.
 
-On some platforms such as [Google Kubernetes
-Engine](https://cloud.google.com/kubernetes-engine/) cluster nodes or Debian,
+On some platforms such as [Google Kubernetes Engine](https://cloud.google.com/kubernetes-engine/) cluster nodes or Debian,
 user namespaces are deactivated by default due to security
 concerns. This can be checked by looking at the file
 `/proc/sys/kernel/unprivileged_userns_clone`: if it exists and contains a 0,
diff --git a/versions/8.6.0/start/android-app.mdx b/versions/8.6.0/start/android-app.mdx
index 08e09bf0..636ee60a 100644
--- a/versions/8.6.0/start/android-app.mdx
+++ b/versions/8.6.0/start/android-app.mdx
@@ -36,8 +36,7 @@ In this tutorial you learn how to:
 Before you begin the tutorial, install the following software:
 
 * **Bazel.** To install, follow the [installation instructions](/versions/8.6.0/install).
-* **Android Studio.** To install, follow the steps to [download Android
-  Studio](https://developer.android.com/sdk/index.html).
+* **Android Studio.** To install, follow the steps to [download Android Studio](https://developer.android.com/sdk/index.html).
   Execute the setup wizard to download the SDK and configure your environment.
 * (Optional) **Git.** Use `git` to download the Android app project.
 
@@ -52,8 +51,7 @@ This app has a single button that prints a greeting when clicked:
 
 **Figure 1.** Android app button greeting.
 
-Clone the repository with `git` (or [download the ZIP file
-directly](https://github.com/bazelbuild/examples/archive/master.zip)):
+Clone the repository with `git` (or [download the ZIP file directly](https://github.com/bazelbuild/examples/archive/master.zip)):
 
 ```posix-terminal
 git clone https://github.com/bazelbuild/examples
@@ -103,8 +101,7 @@ A [workspace](/versions/8.6.0/concepts/build-ref#workspace) is a directory that
 source files for one or more software projects, and has a `MODULE.bazel` file at
 its root.
 
-The `MODULE.bazel` file may be empty or may contain references to [external
-dependencies](/versions/8.6.0/external/overview) required to build your project.
+The `MODULE.bazel` file may be empty or may contain references to [external dependencies](/versions/8.6.0/external/overview) required to build your project.
 
 First, run the following command to create an empty `MODULE.bazel` file:
 
@@ -147,8 +144,7 @@ environment variable, and automatically detect the highest API level and the
 latest version of build tools installed within that location.
 
 You can set the `ANDROID_HOME` variable to the location of the Android SDK. Find
-the path to the installed SDK using Android Studio's [SDK
-Manager](https://developer.android.com/studio/intro/update#sdk-manager).
+the path to the installed SDK using Android Studio's [SDK Manager](https://developer.android.com/studio/intro/update#sdk-manager).
 Assuming the SDK is installed to default locations, you can use the following
 commands to set the `ANDROID_HOME` variable:
 
@@ -170,16 +166,14 @@ them permanent, run the following commands:
 | Windows (PowerShell)     | `[System.Environment]::SetEnvironmentVariable('ANDROID_HOME', "$env:LOCALAPPDATA\Android\Sdk", [System.EnvironmentVariableTarget]::User)` |
 
 **Optional:** If you want to compile native code into your Android app, you
-also need to download the [Android
-NDK](https://developer.android.com/ndk/downloads/index.html)
+also need to download the [Android NDK](https://developer.android.com/ndk/downloads/index.html)
 and use `rules_android_ndk` by adding the following line to your `MODULE.bazel` file:
 
 ```python
 bazel_dep(name = "rules_android_ndk", version = "0.1.2")
 ```
 
-For more information, read [Using the Android Native Development Kit with
-Bazel](/versions/8.6.0/docs/android-ndk).
+For more information, read [Using the Android Native Development Kit with Bazel](/versions/8.6.0/docs/android-ndk).
 
 It's not necessary to set the API levels to the same value for the SDK and NDK.
 [This page](https://developer.android.com/ndk/guides/stable_apis.html)
@@ -221,8 +215,7 @@ files or other dependencies. Bazel provides two build rules,
 build an Android app.
 
 For this tutorial, you'll first use the
-`android_library` rule to tell Bazel to build an [Android library
-module](http://developer.android.com/tools/projects/index.html#LibraryProjects)
+`android_library` rule to tell Bazel to build an [Android library module](http://developer.android.com/tools/projects/index.html#LibraryProjects)
 from the app source code and resource files. You'll then use the
 `android_binary` rule to tell Bazel how to build the Android application package.
 
@@ -337,11 +330,9 @@ file:
 ### Run the app
 
 You can now deploy the app to a connected Android device or emulator from the
-command line using the [`bazel
-mobile-install`](/versions/8.6.0/docs/user-manual#mobile-install) command. This command uses
+command line using the [`bazel mobile-install`](/versions/8.6.0/docs/user-manual#mobile-install) command. This command uses
 the Android Debug Bridge (`adb`) to communicate with the device. You must set up
-your device to use `adb` following the instructions in [Android Debug
-Bridge](http://developer.android.com/tools/help/adb.html) before deployment. You
+your device to use `adb` following the instructions in [Android Debug Bridge](http://developer.android.com/tools/help/adb.html) before deployment. You
 can also choose to install the app on the Android emulator included in Android
 Studio. Make sure the emulator is running before executing the command below.
 
diff --git a/versions/8.6.0/start/cpp.mdx b/versions/8.6.0/start/cpp.mdx
index c586a1ac..1d9683c5 100644
--- a/versions/8.6.0/start/cpp.mdx
+++ b/versions/8.6.0/start/cpp.mdx
@@ -19,8 +19,7 @@ Estimated completion time: 30 minutes.
 ### Prerequisites
 
 Start by [installing Bazel](https://bazel.build/versions/8.6.0/install), if you haven't
-already. This tutorial uses Git for source control, so for best results [install
-Git](https://git-scm.com/book/en/v2/Getting-Started-Installing-Git) as well.
+already. This tutorial uses Git for source control, so for best results [install Git](https://git-scm.com/book/en/v2/Getting-Started-Installing-Git) as well.
 
 Next, retrieve the sample project from Bazel's GitHub repository by running the
 following in your command-line tool of choice:
@@ -63,9 +62,7 @@ examples
 ```
 
 There are three sets of files, each set representing a stage in this tutorial.
-In the first stage, you will build a single [target]
-(https://bazel.build/versions/8.6.0/reference/glossary#target) residing in a single [package]
-(https://bazel.build/versions/8.6.0/reference/glossary#package). In the second stage, you will
+In the first stage, you will build a single [target](https://bazel.build/versions/8.6.0/reference/glossary#target) residing in a single [package](https://bazel.build/versions/8.6.0/reference/glossary#package). In the second stage, you will
 build both a binary and a library from a single package. In the third and final
 stage, you will build a project with multiple packages and build it with
 multiple targets.
@@ -86,8 +83,7 @@ It also contains these significant files:
 *   The `MODULE.bazel` file, which identifies the directory and its contents as
     a Bazel workspace and lives at the root of the project's directory
     structure. It's also where you specify your external dependencies.
-*   One or more [`BUILD`
-    files](https://bazel.build/versions/8.6.0/reference/glossary#build-file), which tell Bazel
+*   One or more [`BUILD` files](https://bazel.build/versions/8.6.0/reference/glossary#build-file), which tell Bazel
     how to build different parts of the project. A directory within the
     workspace that contains a `BUILD` file is a
     [package](https://bazel.build/versions/8.6.0/reference/glossary#package). (More on packages
@@ -182,9 +178,7 @@ This results in a printed "`Hello world`" message.
 
 Here's the dependency graph of Stage 1:
 
-![Dependency graph for hello-world displays a single target with a single source
-file.](/versions/8.6.0/docs/images/cpp-tutorial-stage1.png "Dependency graph for hello-world
-displays a single target with a single source file.")
+![Dependency graph for hello-world displays a single target with a single source file.](/versions/8.6.0/docs/images/cpp-tutorial-stage1.png "Dependency graph for hello-world displays a single target with a single source file.")
 
 ### Summary: stage 1
 
@@ -231,8 +225,7 @@ cc_binary(
 ```
 
 With this `BUILD` file, Bazel first builds the `hello-greet` library (using
-Bazel's built-in [`cc_library`
-rule](https://bazel.build/versions/8.6.0/reference/be/c-cpp#cc_library)), then the
+Bazel's built-in [`cc_library` rule](https://bazel.build/versions/8.6.0/reference/be/c-cpp#cc_library)), then the
 `hello-world` binary. The `deps` attribute in the `hello-world` target tells
 Bazel that the `hello-greet` library is required to build the `hello-world`
 binary.
@@ -272,10 +265,7 @@ recompiles that file.
 Looking at the dependency graph, you can see that `hello-world` depends on an
 extra input named `hello-greet`:
 
-![Dependency graph for `hello-world` displays dependency changes after
-modification to the file.](/versions/8.6.0/docs/images/cpp-tutorial-stage2.png "Dependency
-graph for `hello-world` displays dependency changes after modification to the
-file.")
+![Dependency graph for `hello-world` displays dependency changes after modification to the file.](/versions/8.6.0/docs/images/cpp-tutorial-stage2.png "Dependency graph for `hello-world` displays dependency changes after modification to the file.")
 
 ### Summary: stage 2
 
@@ -343,11 +333,7 @@ in the `lib` package (hence the target label `//lib:hello-time`) - Bazel knows
 this through the `deps` attribute. You can see this reflected in the dependency
 graph:
 
-![Dependency graph for `hello-world` displays how the target in the main package
-depends on the target in the `lib`
-package.](/versions/8.6.0/docs/images/cpp-tutorial-stage3.png "Dependency graph for
-`hello-world` displays how the target in the main package depends on the target
-in the `lib` package.")
+![Dependency graph for `hello-world` displays how the target in the main package depends on the target in the `lib` package.](/versions/8.6.0/docs/images/cpp-tutorial-stage3.png "Dependency graph for `hello-world` displays how the target in the main package depends on the target in the `lib` package.")
 
 For the build to succeed, you make the `//lib:hello-time` target in `lib/BUILD`
 explicitly visible to targets in `main/BUILD` using the visibility attribute.
@@ -395,15 +381,11 @@ Bazel journey.
 You've now completed your first basic build with Bazel, but this is just the
 start. Here are some more resources to continue learning with Bazel:
 
-*   To keep focusing on C++, read about common [C++ build use
-    cases](https://bazel.build/versions/8.6.0/tutorials/cpp-use-cases).
+*   To keep focusing on C++, read about common [C++ build use cases](https://bazel.build/versions/8.6.0/tutorials/cpp-use-cases).
 *   To get started with building other applications with Bazel, see the
-    tutorials for [Java](https://bazel.build/versions/8.6.0/start/java), [Android
-    application](https://bazel.build/versions/8.6.0/start/android-app), or [iOS
-    application](https://bazel.build/versions/8.6.0/start/ios-app).
+    tutorials for [Java](https://bazel.build/versions/8.6.0/start/java), [Android application](https://bazel.build/versions/8.6.0/start/android-app), or [iOS application](https://bazel.build/versions/8.6.0/start/ios-app).
 *   To learn more about working with local and remote repositories, read about
     [external dependencies](https://bazel.build/versions/8.6.0/docs/external).
-*   To learn more about Bazel's other rules, see this [reference
-    guide](https://bazel.build/versions/8.6.0/rules).
+*   To learn more about Bazel's other rules, see this [reference guide](https://bazel.build/versions/8.6.0/rules).
 
 Happy building!
\ No newline at end of file
diff --git a/versions/8.6.0/start/java.mdx b/versions/8.6.0/start/java.mdx
index 74ca8c8b..aa2e3bbb 100644
--- a/versions/8.6.0/start/java.mdx
+++ b/versions/8.6.0/start/java.mdx
@@ -241,8 +241,7 @@ recompiles that file.
 Looking at the dependency graph, you can see that `ProjectRunner` depends on the
 same inputs as it did before, but the structure of the build is different:
 
-![Dependency graph of the target 'ProjectRunner' after adding a dependency](
-/docs/images/tutorial_java_02.svg)
+![Dependency graph of the target 'ProjectRunner' after adding a dependency](/docs/images/tutorial_java_02.svg)
 
 You've now built the project with two targets. The `ProjectRunner` target builds
 one source files and depends on one other target (`:greeter`), which builds
diff --git a/versions/8.6.0/tutorials/ccp-toolchain-config.mdx b/versions/8.6.0/tutorials/ccp-toolchain-config.mdx
index 7895860d..5c5e0885 100644
--- a/versions/8.6.0/tutorials/ccp-toolchain-config.mdx
+++ b/versions/8.6.0/tutorials/ccp-toolchain-config.mdx
@@ -29,8 +29,7 @@ uses `clang version 16`, which you can install on your system.
 
 Set up your build environment as follows:
 
-1.  If you have not already done so, [download and install Bazel
-    7.0.2](https://bazel.build/versions/8.6.0/install) or later.
+1.  If you have not already done so, [download and install Bazel 7.0.2](https://bazel.build/versions/8.6.0/install) or later.
 
 2.  Add an empty `MODULE.bazel` file at the root folder.
 
@@ -450,8 +449,7 @@ The key takeaways are:
 
 -   You need to specify a matching `platforms` flag in the command line for
     Bazel to resolve to the toolchain for the same constraint values on the
-    platform. The documentation holds more [information about language specific
-    configuration flags](/versions/8.6.0/concepts/platforms).
+    platform. The documentation holds more [information about language specific configuration flags](/versions/8.6.0/concepts/platforms).
 -   You have to let the toolchain know where the tools live. In this tutorial
     there is a simplified version where you access the tools from the system. If
     you are interested in a more self-contained approach, you can read about
@@ -464,5 +462,4 @@ The key takeaways are:
 
 ## Further reading
 
-For more details, see [C++ toolchain
-configuration](/versions/8.6.0/docs/cc-toolchain-config-reference)
\ No newline at end of file
+For more details, see [C++ toolchain configuration](/versions/8.6.0/docs/cc-toolchain-config-reference)
\ No newline at end of file
diff --git a/versions/9.0.0/basics/dependencies.mdx b/versions/9.0.0/basics/dependencies.mdx
index d762c4f3..83787edd 100644
--- a/versions/9.0.0/basics/dependencies.mdx
+++ b/versions/9.0.0/basics/dependencies.mdx
@@ -65,8 +65,7 @@ targets, we’ve made some strides in mitigating the downside by investing in
 tooling to automatically manage `BUILD` files to avoid burdening developers.
 
 Some of these tools, such as `buildifier` and `buildozer`, are available with
-Bazel in the [`buildtools`
-directory](https://github.com/bazelbuild/buildtools).
+Bazel in the [`buildtools` directory](https://github.com/bazelbuild/buildtools).
 
 ## Minimizing Module Visibility
 
@@ -106,8 +105,7 @@ transitive dependencies (Figure 1). Suppose target A depends on target B, which
 depends on a common library target C. Should target A be able to use classes
 defined in target C?
 
-[![Transitive
-dependencies](/versions/9.0.0/images/transitive-dependencies.png)](/versions/9.0.0/images/transitive-dependencies.png)
+[![Transitive dependencies](/versions/9.0.0/images/transitive-dependencies.png)](/versions/9.0.0/images/transitive-dependencies.png)
 
 **Figure 1**. Transitive dependencies
 
@@ -141,9 +139,7 @@ dependencies and adding them to a `BUILD` files without any developer
 intervention. But even without such tools, we’ve found the trade-off to be well
 worth it as the codebase scales: explicitly adding a dependency to `BUILD` file
 is a one-time cost, but dealing with implicit transitive dependencies can cause
-ongoing problems as long as the build target exists. Bazel [enforces strict
-transitive
-dependencies](https://blog.bazel.build/2017/06/28/sjd-unused_deps.html)
+ongoing problems as long as the build target exists. Bazel [enforces strict transitive dependencies](https://blog.bazel.build/2017/06/28/sjd-unused_deps.html)
 on Java code by default.
 
 ### External dependencies
@@ -192,8 +188,7 @@ so in theory there’s no reason that different versions of the same external
 dependency couldn’t both be declared in the build system under different names.
 That way, each target could choose which version of the dependency it wanted to
 use. This causes a lot of problems in practice, so Google enforces a strict
-[One-Version
-Rule](https://opensource.google/docs/thirdparty/oneversion/) for
+[One-Version Rule](https://opensource.google/docs/thirdparty/oneversion/) for
 all third-party dependencies in our codebase.
 
 The biggest problem with allowing multiple versions is the diamond dependency
@@ -232,8 +227,7 @@ Bazel did not use to automatically download transitive dependencies. It used to
 employ a `WORKSPACE` file that required all transitive dependencies to be
 listed, which led to a lot of pain when managing external dependencies. Bazel
 has since added support for automatic transitive external dependency management
-in the form of the `MODULE.bazel` file. See [external dependency
-overview](/versions/9.0.0/external/overview) for more details.
+in the form of the `MODULE.bazel` file. See [external dependency overview](/versions/9.0.0/external/overview) for more details.
 
 Yet again, the choice here is one between convenience and scalability. Small
 projects might prefer not having to worry about managing transitive dependencies
diff --git a/versions/9.0.0/community/sig.mdx b/versions/9.0.0/community/sig.mdx
index 314ac7bf..786eaf38 100644
--- a/versions/9.0.0/community/sig.mdx
+++ b/versions/9.0.0/community/sig.mdx
@@ -3,8 +3,7 @@ title: 'Bazel Special Interest Groups'
 ---
 
 Bazel hosts Special Interest Groups (SIGs) to focus collaboration on particular
-areas and to support communication and coordination between [Bazel owners,
-maintainers, and contributors](/versions/9.0.0/contribute/policy). This policy
+areas and to support communication and coordination between [Bazel owners, maintainers, and contributors](/versions/9.0.0/contribute/policy). This policy
 applies to [`bazelbuild`](http://github.com/bazelbuild).
 
 SIGs do their work in public. The ideal scope for a SIG covers a well-defined
diff --git a/versions/9.0.0/community/users.mdx b/versions/9.0.0/community/users.mdx
index 948b0892..f19117a2 100644
--- a/versions/9.0.0/community/users.mdx
+++ b/versions/9.0.0/community/users.mdx
@@ -304,11 +304,9 @@ safety systems_.
 Pigweed is an open-source solution for sustained, robust, and rapid embedded
 product development for large teams. Pigweed has shipped in millions of
 devices, including Google's suite of Pixel devices, Nest thermostats,
-[satellites](https://www.spinlaunch.com/), and [autonomous aerial
-drones](https://www.flyzipline.com/).
+[satellites](https://www.spinlaunch.com/), and [autonomous aerial drones](https://www.flyzipline.com/).
 
-Pigweed [uses Bazel as its primary build
-system](https://pigweed.dev/seed/0111-build-systems.html). The [Bazel for
+Pigweed [uses Bazel as its primary build system](https://pigweed.dev/seed/0111-build-systems.html). The [Bazel for
 Embedded][pw-bazel-great] blog post discusses why we think it's a great build
 system for embedded projects!
 
diff --git a/versions/9.0.0/concepts/build-files.mdx b/versions/9.0.0/concepts/build-files.mdx
index 42e7b901..164a1b78 100644
--- a/versions/9.0.0/concepts/build-files.mdx
+++ b/versions/9.0.0/concepts/build-files.mdx
@@ -130,13 +130,6 @@ for anyone to create new rules.
     and binaries and tests can depend on libraries, with the expected
     separate-compilation behavior.
 
-
-  
-    
-    
-  
-
LabelsDependencies

-
 ## File encoding
 
 `BUILD` and `.bzl` files should be encoded in UTF-8, of which ASCII is a valid
diff --git a/versions/9.0.0/concepts/build-ref.mdx b/versions/9.0.0/concepts/build-ref.mdx
index 6c0f7d78..b9cb0c85 100644
--- a/versions/9.0.0/concepts/build-ref.mdx
+++ b/versions/9.0.0/concepts/build-ref.mdx
@@ -17,8 +17,7 @@ its root; such a boundary marker file could be `MODULE.bazel`, `REPO.bazel`, or
 in legacy contexts, `WORKSPACE` or `WORKSPACE.bazel`.
 
 The repo in which the current Bazel command is being run is called the _main
-repo_. Other, (external) repos are defined by _repo rules_; see [external
-dependencies overview](/versions/9.0.0/external/overview) for more information.
+repo_. Other, (external) repos are defined by _repo rules_; see [external dependencies overview](/versions/9.0.0/external/overview) for more information.
 
 ## Workspace {#workspace}
 
@@ -95,9 +94,4 @@ have three properties: the list of packages they contain, their name, and other
 package groups they include. The only allowed ways to refer to them are from the
 `visibility` attribute of rules or from the `default_visibility` attribute of
 the `package` function; they do not generate or consume files. For more
-information, refer to the [`package_group`
-documentation](/versions/9.0.0/reference/be/functions#package_group).
-
-
-  Labels
-
\ No newline at end of file
+information, refer to the [`package_group` documentation](/versions/9.0.0/reference/be/functions#package_group).
diff --git a/versions/9.0.0/concepts/dependencies.mdx b/versions/9.0.0/concepts/dependencies.mdx
index 218b243c..169b0f81 100644
--- a/versions/9.0.0/concepts/dependencies.mdx
+++ b/versions/9.0.0/concepts/dependencies.mdx
@@ -352,11 +352,3 @@ filegroup(
 ```
 
 You can then reference the label `my_data` as the data dependency in your test.
-
-
-  
-    
-    
-  
-
BUILD filesVisibility

-
diff --git a/versions/9.0.0/concepts/labels.mdx b/versions/9.0.0/concepts/labels.mdx
index 38059f37..6b3215b8 100644
--- a/versions/9.0.0/concepts/labels.mdx
+++ b/versions/9.0.0/concepts/labels.mdx
@@ -10,8 +10,7 @@ form looks like:
 ```
 
 The first part of the label is the repository name, `@@myrepo`. The double-`@`
-syntax signifies that this is a [*canonical* repo
-name](/versions/9.0.0/external/overview#canonical-repo-name), which is unique within
+syntax signifies that this is a [*canonical* repo name](/versions/9.0.0/external/overview#canonical-repo-name), which is unique within
 the workspace. Labels with canonical repo names unambiguously identify a target
 no matter which context they appear in.
 
@@ -238,10 +237,3 @@ the build.
 This directed acyclic graph over targets is called the _target graph_ or
 _build dependency graph_, and is the domain over which the
 [Bazel Query tool](/versions/9.0.0/query/guide) operates.
-
-
-  
-    
-    
-  
-
TargetsBUILD files

diff --git a/versions/9.0.0/concepts/platforms.mdx b/versions/9.0.0/concepts/platforms.mdx
index 7b8488ee..9ec48e28 100644
--- a/versions/9.0.0/concepts/platforms.mdx
+++ b/versions/9.0.0/concepts/platforms.mdx
@@ -77,8 +77,7 @@ To test your Android project with platforms, see
 for support.
 
 You can still use platform APIs with Apple builds (for example, when building
-with a mixture of Apple rules and pure C++) with [platform
-mappings](#platform-mappings).
+with a mixture of Apple rules and pure C++) with [platform mappings](#platform-mappings).
 
 ### Other languages {#other-languages}
 
@@ -241,8 +240,7 @@ sets `--cpu`, `--crossstool_top`, or other legacy flags, rules that read
 
 When migrating your project to platforms, you must either convert changes like
 `return { "//command_line_option:cpu": "arm" }` to `return {
-"//command_line_option:platforms": "//:my_arm_platform" }` or use [platform
-mappings](#platform-mappings) to support both styles during migration.
+"//command_line_option:platforms": "//:my_arm_platform" }` or use [platform mappings](#platform-mappings) to support both styles during migration.
 window.
 
 ## Migrating your rule set {#migrating-your-rule-set}
@@ -361,10 +359,8 @@ attributes declare a language's tools (like `compiler =
 this information to rules that need to build with these tools.
 
 Toolchains declare the `constraint_value`s of machines they can
-[target][target_compatible_with Attribute]
-(`target_compatible_with = ["@platforms//os:linux"]`) and machines their tools can
-[run on][exec_compatible_with Attribute]
-(`exec_compatible_with = ["@platforms//os:mac"]`).
+[target][target_compatible_with Attribute](`target_compatible_with = ["@platforms//os:linux"]`) and machines their tools can
+[run on][exec_compatible_with Attribute](`exec_compatible_with = ["@platforms//os:mac"]`).
 
 When building `$ bazel build //:myproject --platforms=//:myplatform`, Bazel
 automatically selects a toolchain that can run on the build machine and
diff --git a/versions/9.0.0/configure/attributes.mdx b/versions/9.0.0/configure/attributes.mdx
index 7827c192..8ae0f413 100644
--- a/versions/9.0.0/configure/attributes.mdx
+++ b/versions/9.0.0/configure/attributes.mdx
@@ -2,8 +2,7 @@
 title: 'Configurable Build Attributes'
 ---
 
-**_Configurable attributes_**, commonly known as [`select()`](
-/reference/be/functions#select), is a Bazel feature that lets users toggle the values
+**_Configurable attributes_**, commonly known as [`select()`](/reference/be/functions#select), is a Bazel feature that lets users toggle the values
 of build rule attributes at the command line.
 
 This can be used, for example, for a multiplatform library that automatically
@@ -407,8 +406,7 @@ sh_library(
 )
 ```
 
-If you need a `select` to match when multiple conditions match, consider [AND
-chaining](#and-chaining).
+If you need a `select` to match when multiple conditions match, consider [AND chaining](#and-chaining).
 
 ## OR chaining {#or-chaining}
 
diff --git a/versions/9.0.0/configure/integrate-cpp.mdx b/versions/9.0.0/configure/integrate-cpp.mdx
index cb104c7d..78a5c11a 100644
--- a/versions/9.0.0/configure/integrate-cpp.mdx
+++ b/versions/9.0.0/configure/integrate-cpp.mdx
@@ -14,8 +14,7 @@ To depend on a C++ toolchain in your rule, set the `toolchains` parameter to
 `use_cc_toolchain()`. Then, in the rule implementation, use
 `find_cpp_toolchain(ctx)` to get the
 [`CcToolchainInfo`](/versions/9.0.0/rules/lib/providers/CcToolchainInfo). A complete working
-example can be found [in the rules_cc
-examples](https://github.com/bazelbuild/rules_cc/blob/main/examples/write_cc_toolchain_cpu/write_cc_toolchain_cpu.bzl).
+example can be found [in the rules_cc examples](https://github.com/bazelbuild/rules_cc/blob/main/examples/write_cc_toolchain_cpu/write_cc_toolchain_cpu.bzl).
 
 ## Generating command lines and environment variables using the C++ toolchain {#generate-command-lines-toolchain}
 
@@ -25,8 +24,7 @@ This is because when writing our own actions, they must behave
 consistently with the C++ toolchain - for example, passing C++ command line
 flags to a tool that invokes the C++ compiler behind the scenes.
 
-C++ rules use a special way of constructing command lines based on [feature
-configuration](/versions/9.0.0/docs/cc-toolchain-config-reference). To construct a command line,
+C++ rules use a special way of constructing command lines based on [feature configuration](/versions/9.0.0/docs/cc-toolchain-config-reference). To construct a command line,
 you need the following:
 
 * `features` and `action_configs` - these come from the `CcToolchainConfigInfo`
diff --git a/versions/9.0.0/configure/windows.mdx b/versions/9.0.0/configure/windows.mdx
index 2a1da390..34e2516d 100644
--- a/versions/9.0.0/configure/windows.mdx
+++ b/versions/9.0.0/configure/windows.mdx
@@ -160,8 +160,7 @@ To build C++ targets with MSVC, you need:
         set BAZEL_VC=C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC
         ```
 
-*   The [Windows
-    SDK](https://developer.microsoft.com/en-us/windows/downloads/windows-10-sdk).
+*   The [Windows SDK](https://developer.microsoft.com/en-us/windows/downloads/windows-10-sdk).
 
     The Windows SDK contains header files and libraries you need when building
     Windows applications, including Bazel itself. By default, the latest Windows SDK installed will
@@ -180,8 +179,7 @@ To build C++ targets with MSVC, you need:
 
 If everything is set up, you can build a C++ target now!
 
-Try building a target from one of our [sample
-projects](https://github.com/bazelbuild/bazel/tree/master/examples):
+Try building a target from one of our [sample projects](https://github.com/bazelbuild/bazel/tree/master/examples):
 
 
 
   
   
 
 If you are interested in details about how Bazel builds Python targets on
-Windows, check out this [design
-doc](https://github.com/bazelbuild/bazel-website/blob/master/designs/_posts/2016-09-05-build-python-on-windows.md).
+Windows, check out this [design doc](https://github.com/bazelbuild/bazel-website/blob/master/designs/_posts/2016-09-05-build-python-on-windows.md).
diff --git a/versions/9.0.0/contribute/codebase.mdx b/versions/9.0.0/contribute/codebase.mdx
index 7d05f598..8042618f 100644
--- a/versions/9.0.0/contribute/codebase.mdx
+++ b/versions/9.0.0/contribute/codebase.mdx
@@ -237,8 +237,7 @@ repository", the others are called "external repositories".
 A repository is marked by a repo boundary file (`MODULE.bazel`, `REPO.bazel`, or
 in legacy contexts, `WORKSPACE` or `WORKSPACE.bazel`) in its root directory. The
 main repo is the source tree where you're invoking Bazel from. External repos
-are defined in various ways; see [external dependencies
-overview](/versions/9.0.0/external/overview) for more information.
+are defined in various ways; see [external dependencies overview](/versions/9.0.0/external/overview) for more information.
 
 Code of external repositories is symlinked or downloaded under
 `$OUTPUT_BASE/external`.
diff --git a/versions/9.0.0/contribute/design-documents.mdx b/versions/9.0.0/contribute/design-documents.mdx
index b56dbd73..babc758e 100644
--- a/versions/9.0.0/contribute/design-documents.mdx
+++ b/versions/9.0.0/contribute/design-documents.mdx
@@ -137,8 +137,7 @@ A lead reviewer should be a domain expert who is:
 *   Objective and capable of providing constructive feedback
 *   Available for the entire review period to lead the process
 
-Consider checking the contacts for various [team
-labels](/versions/9.0.0/contribute/maintainers-guide#team-labels).
+Consider checking the contacts for various [team labels](/versions/9.0.0/contribute/maintainers-guide#team-labels).
 
 ## Markdown vs Google Docs {#markdown-versus-gdocs}
 
@@ -168,12 +167,10 @@ Markdown for posterity.
 
 ### Using Google Docs {#gdocs}
 
-For consistency, use the [Bazel design doc template](
-https://docs.google.com/document/d/1cE5zrjrR40RXNg64XtRFewSv6FrLV6slGkkqxBumS1w/edit).
+For consistency, use the [Bazel design doc template](https://docs.google.com/document/d/1cE5zrjrR40RXNg64XtRFewSv6FrLV6slGkkqxBumS1w/edit).
 It includes the necessary header and creates visual
 consistency with other Bazel related documents. To do that, click on **File** >
-**Make a copy** or click this link to [make a copy of the design doc
-template](https://docs.google.com/document/d/1cE5zrjrR40RXNg64XtRFewSv6FrLV6slGkkqxBumS1w/copy).
+**Make a copy** or click this link to [make a copy of the design doc template](https://docs.google.com/document/d/1cE5zrjrR40RXNg64XtRFewSv6FrLV6slGkkqxBumS1w/copy).
 
 To make your document readable to the world, click on
 **Share** > **Advanced** > **Change…**, and
diff --git a/versions/9.0.0/contribute/index.mdx b/versions/9.0.0/contribute/index.mdx
index 8c0fc403..a18cbc0f 100644
--- a/versions/9.0.0/contribute/index.mdx
+++ b/versions/9.0.0/contribute/index.mdx
@@ -10,8 +10,7 @@ As you use Bazel, you may find things that can be improved.
 You can help by [reporting issues](http://github.com/bazelbuild/bazel/issues)
 when:
 
-   - Bazel crashes or you encounter a bug that can [only be resolved using `bazel
-     clean`](/versions/9.0.0/run/build#correct-incremental-rebuilds).
+   - Bazel crashes or you encounter a bug that can [only be resolved using `bazel clean`](/versions/9.0.0/run/build#correct-incremental-rebuilds).
    - The documentation is incomplete or unclear. You can also report issues
      from the page you are viewing by using the "Create issue"
      link at the top right corner of the page.
@@ -21,11 +20,9 @@ when:
 
 You can engage with the Bazel community by:
 
-   - Answering questions [on Stack Overflow](
-     https://stackoverflow.com/questions/tagged/bazel).
+   - Answering questions [on Stack Overflow](https://stackoverflow.com/questions/tagged/bazel).
    - Helping other users [on Slack](https://slack.bazel.build).
-   - Improving documentation or [contributing examples](
-     https://github.com/bazelbuild/examples).
+   - Improving documentation or [contributing examples](https://github.com/bazelbuild/examples).
    - Sharing your experience or your tips, for example, on a blog or social media.
 
 ## Contribute code {#contribute-code}
@@ -40,8 +37,7 @@ You can contribute to the Bazel ecosystem by:
    - Contributing to Bazel-related tools, for example, migration tools.
    - Improving Bazel integration with other IDEs and tools.
 
-Before making a change, [create a GitHub
-issue](http://github.com/bazelbuild/bazel/issues)
+Before making a change, [create a GitHub issue](http://github.com/bazelbuild/bazel/issues)
 or email [bazel-discuss@](mailto:bazel-discuss@googlegroups.com).
 
 The most helpful contributions fix bugs or add features (as opposed
diff --git a/versions/9.0.0/contribute/maintainers-guide.mdx b/versions/9.0.0/contribute/maintainers-guide.mdx
index d2208c86..9734e378 100644
--- a/versions/9.0.0/contribute/maintainers-guide.mdx
+++ b/versions/9.0.0/contribute/maintainers-guide.mdx
@@ -4,8 +4,7 @@ title: 'Guide for Bazel Maintainers'
 
 This is a guide for the maintainers of the Bazel open source project.
 
-If you are looking to contribute to Bazel, please read [Contributing to
-Bazel](/versions/9.0.0/contribute) instead.
+If you are looking to contribute to Bazel, please read [Contributing to Bazel](/versions/9.0.0/contribute) instead.
 
 The objectives of this page are to:
 
@@ -37,8 +36,7 @@ repository.
 
 1. A user creates an issue by choosing one of the
 [issue templates](https://github.com/bazelbuild/bazel/issues/new/choose)
-   and it enters the pool of [unreviewed open
-   issues](https://github.com/bazelbuild/bazel/issues?utf8=%E2%9C%93&q=is%3Aissue+is%3Aopen+-label%3Auntriaged+-label%3Ap2+-label%3Ap1+-label%3Ap3+-label%3Ap4+-label%3Ateam-Starlark+-label%3Ateam-Rules-CPP+-label%3Ateam-Rules-Java+-label%3Ateam-XProduct+-label%3Ateam-Android+-label%3Ateam-Apple+-label%3Ateam-Configurability++-label%3Ateam-Performance+-label%3Ateam-Rules-Server+-label%3Ateam-Core+-label%3Ateam-Rules-Python+-label%3Ateam-Remote-Exec+-label%3Ateam-Local-Exec+-label%3Ateam-Bazel).
+   and it enters the pool of [unreviewed open issues](https://github.com/bazelbuild/bazel/issues?utf8=%E2%9C%93&q=is%3Aissue+is%3Aopen+-label%3Auntriaged+-label%3Ap2+-label%3Ap1+-label%3Ap3+-label%3Ap4+-label%3Ateam-Starlark+-label%3Ateam-Rules-CPP+-label%3Ateam-Rules-Java+-label%3Ateam-XProduct+-label%3Ateam-Android+-label%3Ateam-Apple+-label%3Ateam-Configurability++-label%3Ateam-Performance+-label%3Ateam-Rules-Server+-label%3Ateam-Core+-label%3Ateam-Rules-Python+-label%3Ateam-Remote-Exec+-label%3Ateam-Local-Exec+-label%3Ateam-Bazel).
 1. A member on the Developer Experience (DevEx) subteam rotation reviews the
    issue.
    1. If the issue is **not a bug** or a **feature request**, the DevEx member
@@ -58,21 +56,18 @@ repository.
 1. After reviewing the issue, the DevEx member decides if the issue requires
    immediate attention. If it does, they will assign the **P0**
    [priority](#priority) label and an owner from the list of team leads.
-1. The DevEx member assigns the `untriaged` label and exactly one [team
-   label](#team-labels) for routing.
+1. The DevEx member assigns the `untriaged` label and exactly one [team label](#team-labels) for routing.
 1. The DevEx member also assigns exactly one `type:` label, such as `type: bug`
    or `type: feature request`, according to the type of the issue.
 1. For platform-specific issues, the DevEx member assigns one `platform:` label,
    such as `platform:apple` for Mac-specific issues.
 1. If the issue is low priority and can be worked on by a new community
    contributor, the DevEx member assigns the `good first issue` label.
-At this stage, the issue enters the pool of [untriaged open
-issues](https://github.com/bazelbuild/bazel/issues?q=is%3Aissue+is%3Aopen+label%3Auntriaged).
+At this stage, the issue enters the pool of [untriaged open issues](https://github.com/bazelbuild/bazel/issues?q=is%3Aissue+is%3Aopen+label%3Auntriaged).
 
 Each Bazel subteam will triage all issues under labels they own, preferably on a
 weekly basis. The subteam will review and evaluate the issue and provide a
-resolution, if possible. If you are an owner of a team label, see [this section
-](#label-own) for more information.
+resolution, if possible. If you are an owner of a team label, see [this section](#label-own) for more information.
 
 When an issue is resolved, it can be closed.
 
@@ -111,8 +106,7 @@ preferably on a weekly basis.
      issue is either P0 or P1 we assume that is actively worked on.
 1. Remove the `untriaged` label.
 
-Note that you need to be in the [bazelbuild
-organization](https://github.com/bazelbuild) to be able to add or remove labels.
+Note that you need to be in the [bazelbuild organization](https://github.com/bazelbuild) to be able to add or remove labels.
 
 ### Pull Requests {#pull-requests}
 
@@ -138,8 +132,7 @@ issues.
   unusable, or a downed service that severely impacts development of the Bazel
   project. This includes regressions introduced in a new release that blocks a
   significant number of users, or an incompatible breaking change that was not
-  compliant to the [Breaking
-  Change](https://docs.google.com/document/d/1q5GGRxKrF_mnwtaPKI487P8OdDRh2nN7jX6U-FXnHL0/edit?pli=1#heading=h.ceof6vpkb3ik)
+  compliant to the [Breaking Change](https://docs.google.com/document/d/1q5GGRxKrF_mnwtaPKI487P8OdDRh2nN7jX6U-FXnHL0/edit?pli=1#heading=h.ceof6vpkb3ik)
   policy. No practical workaround exists.
 * [**P1**](https://github.com/bazelbuild/bazel/labels/P1) - Critical defect or
   feature which should be addressed in the next release, or a serious issue that
diff --git a/versions/9.0.0/contribute/naming.mdx b/versions/9.0.0/contribute/naming.mdx
index 41c92fc5..d579ea4a 100644
--- a/versions/9.0.0/contribute/naming.mdx
+++ b/versions/9.0.0/contribute/naming.mdx
@@ -4,8 +4,7 @@ title: 'Naming a Bazel related project'
 
 First, thank you for contributing to the Bazel ecosystem! Please reach out to
 the Bazel community on the
-[bazel-discuss mailing list](https://groups.google.com/forum/#!forum/bazel-discuss
-) to share your project and its suggested name.
+[bazel-discuss mailing list](https://groups.google.com/forum/#!forum/bazel-discuss) to share your project and its suggested name.
 
 If you are building a Bazel related tool or sharing your Skylark rules,
 we recommend following these guidelines for the name of your project:
diff --git a/versions/9.0.0/contribute/patch-acceptance.mdx b/versions/9.0.0/contribute/patch-acceptance.mdx
index 58c5a4fd..1603c24f 100644
--- a/versions/9.0.0/contribute/patch-acceptance.mdx
+++ b/versions/9.0.0/contribute/patch-acceptance.mdx
@@ -11,29 +11,24 @@ code base.
    need a corresponding issue for tracking.
 1. If you're proposing significant changes, write a
    [design document](/versions/9.0.0/contribute/design-documents).
-1. Ensure you've signed a [Contributor License
-   Agreement](https://cla.developers.google.com).
+1. Ensure you've signed a [Contributor License Agreement](https://cla.developers.google.com).
 1. Prepare a git commit that implements the feature. Don't forget to add tests
    and update the documentation. If your change has user-visible effects, please
    [add release notes](/versions/9.0.0/contribute/release-notes). If it is an incompatible change,
    read the [guide for rolling out breaking changes](/versions/9.0.0/contribute/breaking-changes).
 1. Create a pull request on
    [GitHub](https://github.com/bazelbuild/bazel/pulls). If you're new to GitHub,
-   read [about pull
-   requests](https://help.github.com/articles/about-pull-requests/). Note that
+   read [about pull requests](https://help.github.com/articles/about-pull-requests/). Note that
    we restrict permissions to create branches on the main Bazel repository, so
-   you will need to push your commit to [your own fork of the
-   repository](https://help.github.com/articles/working-with-forks/).
+   you will need to push your commit to [your own fork of the repository](https://help.github.com/articles/working-with-forks/).
 1. A Bazel maintainer should assign you a reviewer within two business days
    (excluding holidays in the USA and Germany). If you aren't assigned a
    reviewer in that time, you can request one by emailing
-   [bazel-discuss@googlegroups.com]
-   (mailto:bazel-discuss@googlegroups.com).
+   [bazel-discuss@googlegroups.com](mailto:bazel-discuss@googlegroups.com).
 1. Work with the reviewer to complete a code review. For each change, create a
    new commit and push it to make changes to your pull request. If the review
    takes too long (for instance, if the reviewer is unresponsive), send an email to
-   [bazel-discuss@googlegroups.com]
-   (mailto:bazel-discuss@googlegroups.com).
+   [bazel-discuss@googlegroups.com](mailto:bazel-discuss@googlegroups.com).
 1. After your review is complete, a Bazel maintainer applies your patch to
    Google's internal version control system.
 
diff --git a/versions/9.0.0/contribute/release-notes.mdx b/versions/9.0.0/contribute/release-notes.mdx
index f423378d..b15e8fc0 100644
--- a/versions/9.0.0/contribute/release-notes.mdx
+++ b/versions/9.0.0/contribute/release-notes.mdx
@@ -16,8 +16,7 @@ the release announcement.
 * If the change adds / removes / changes Bazel in a user-visible way, then it
   may be advantageous to mention it.
 
-If the change is significant, follow the [design document
-policy](/versions/9.0.0/contribute/design-documents) first.
+If the change is significant, follow the [design document policy](/versions/9.0.0/contribute/design-documents) first.
 
 ## Guidelines {#guidelines}
 
@@ -60,10 +59,8 @@ change is about.
 
 ## Process {#process}
 
-As part of the [release
-process](https://github.com/bazelbuild/continuous-integration/blob/master/docs/release-playbook.md),
-we collect the `RELNOTES` tags of every commit. We copy everything in a [Google
-Doc](https://docs.google.com/document/d/1wDvulLlj4NAlPZamdlEVFORks3YXJonCjyuQMUQEmB0/edit)
+As part of the [release process](https://github.com/bazelbuild/continuous-integration/blob/master/docs/release-playbook.md),
+we collect the `RELNOTES` tags of every commit. We copy everything in a [Google Doc](https://docs.google.com/document/d/1wDvulLlj4NAlPZamdlEVFORks3YXJonCjyuQMUQEmB0/edit)
 where we review, edit, and organize the notes.
 
 The release manager sends an email to the
@@ -71,6 +68,4 @@ The release manager sends an email to the
 Bazel contributors are invited to contribute to the document and make sure
 their changes are correctly reflected in the announcement.
 
-Later, the announcement will be submitted to the [Bazel
-blog](https://blog.bazel.build/), using the [bazel-blog
-repository](https://github.com/bazelbuild/bazel-blog/tree/master/_posts).
+Later, the announcement will be submitted to the [Bazel blog](https://blog.bazel.build/), using the [bazel-blog repository](https://github.com/bazelbuild/bazel-blog/tree/master/_posts).
diff --git a/versions/9.0.0/contribute/statemachine-guide.mdx b/versions/9.0.0/contribute/statemachine-guide.mdx
index e4fdbe31..068f0242 100644
--- a/versions/9.0.0/contribute/statemachine-guide.mdx
+++ b/versions/9.0.0/contribute/statemachine-guide.mdx
@@ -172,8 +172,7 @@ instead, batches[^4] as many lookups as possible before doing so. The value
 might not be immediately available, for example, requiring a Skyframe restart,
 so the caller specifies what to do with the resulting value using a callback.
 
-The `StateMachine` processor ([`Driver`s and bridging to
-SkyFrame](#drivers-and-bridging)) guarantees that the value is available before
+The `StateMachine` processor ([`Driver`s and bridging to SkyFrame](#drivers-and-bridging)) guarantees that the value is available before
 the next state begins. An example follows.
 
 ```
@@ -284,8 +283,7 @@ and solutions to certain control flow problems.
 ### Sequential states
 
 This is the most common and straightforward control flow pattern. An example of
-this is shown in [Stateful computations inside
-`SkyKeyComputeState`](#stateful-computations).
+this is shown in [Stateful computations inside `SkyKeyComputeState`](#stateful-computations).
 
 ### Branching
 
@@ -545,8 +543,7 @@ section describes the propagation of data values.
 
 ### Implementing `Tasks.lookUp` callbacks
 
-There’s an example of implementing a `Tasks.lookUp` callback in [SkyValue
-lookups](#skyvalue-lookups). This section provides rationale and suggests
+There’s an example of implementing a `Tasks.lookUp` callback in [SkyValue lookups](#skyvalue-lookups). This section provides rationale and suggests
 approaches for handling multiple SkyValues.
 
 #### `Tasks.lookUp` callbacks {#tasks-lookup-callbacks}
@@ -710,8 +707,7 @@ class BarProducer implements StateMachine {
 Tip: It would be tempting to use the more concise signature void `accept(Bar
 value)` rather than the stuttery `void acceptBarValue(Bar value)` above.
 However, `Consumer` is a common overload of `void accept(Bar value)`,
-so doing this often leads to violations of the [Overloads: never
-split](https://google.github.io/styleguide/javaguide.html#s3.4.2-ordering-class-contents)
+so doing this often leads to violations of the [Overloads: never split](https://google.github.io/styleguide/javaguide.html#s3.4.2-ordering-class-contents)
 style-guide rule.
 
 Tip: Using a custom `ResultSink` type instead of a generic one from
@@ -774,14 +770,11 @@ pattern after accepting output from either a subtask or SkyValue lookup.
 Note that the implementation of `acceptBarError` eagerly forwards the result to
 the `Caller.ResultSink`, as required by [Error bubbling](#error-bubbling).
 
-Alternatives for top-level `StateMachine`s are described in [`Driver`s and
-bridging to SkyFunctions](#drivers-and-bridging).
+Alternatives for top-level `StateMachine`s are described in [`Driver`s and bridging to SkyFunctions](#drivers-and-bridging).
 
 ### Error handling {#error-handling}
 
-There's a couple of examples of error handling already in [`Tasks.lookUp`
-callbacks](#tasks-lookup-callbacks) and [Propagating values between
-`StateMachines`](#propagating-values). Exceptions, other than
+There's a couple of examples of error handling already in [`Tasks.lookUp` callbacks](#tasks-lookup-callbacks) and [Propagating values between `StateMachines`](#propagating-values). Exceptions, other than
 `InterruptedException` are not thrown, but instead passed around through
 callbacks as values. Such callbacks often have exclusive-or semantics, with
 exactly one of a value or error being passed.
@@ -1184,8 +1177,7 @@ states. Where it is possible, local stack `step` variables are young generation
 variables and efficiently GC'd.
 
 For `StateMachine` variables, breaking things down into subtasks and following
-the recommended pattern for [Propagating values between
-`StateMachine`s](#propagating-values) is also helpful. Observe that when
+the recommended pattern for [Propagating values between `StateMachine`s](#propagating-values) is also helpful. Observe that when
 following the pattern, only child `StateMachine`s have references to parent
 `StateMachine`s and not vice versa. This means that as children complete and
 update the parents using result callbacks, the children naturally fall out of
@@ -1207,8 +1199,7 @@ potentially reflecting local behavior.
 
 ### Concurrency tree diagram {#concurrency-tree-diagram}
 
-The following is an alternative view of the diagram in [Structured
-concurrency](#structured-concurrency) that better depicts the tree structure.
+The following is an alternative view of the diagram in [Structured concurrency](#structured-concurrency) that better depicts the tree structure.
 The blocks form a small tree.
 
 ![Structured Concurrency 3D](/versions/9.0.0/contribute/images/structured-concurrency-3d.svg)
diff --git a/versions/9.0.0/docs/android-instrumentation-test.mdx b/versions/9.0.0/docs/android-instrumentation-test.mdx
index fa25a42b..78aa17a2 100644
--- a/versions/9.0.0/docs/android-instrumentation-test.mdx
+++ b/versions/9.0.0/docs/android-instrumentation-test.mdx
@@ -2,8 +2,7 @@
 title: 'Android Instrumentation Tests'
 ---
 
-_If you're new to Bazel, start with the [Building Android with
-Bazel](/versions/9.0.0/start/android-app ) tutorial._
+_If you're new to Bazel, start with the [Building Android with Bazel](/versions/9.0.0/start/android-app) tutorial._
 
 ![Running Android instrumentation tests in parallel](/versions/9.0.0/docs/images/android_test.gif "Android instrumentation test")
 
@@ -18,9 +17,7 @@ emulators in a sandbox, ensuring that tests always run from a clean state. Each
 test gets an isolated emulator instance, allowing tests to run in parallel
 without passing states between them.
 
-For more information on Android instrumentation tests, check out the [Android
-developer
-documentation](https://developer.android.com/training/testing/unit-testing/instrumented-unit-tests.html).
+For more information on Android instrumentation tests, check out the [Android developer documentation](https://developer.android.com/training/testing/unit-testing/instrumented-unit-tests.html).
 
 Please file issues in the [GitHub issue tracker](https://github.com/bazelbuild/bazel/issues).
 
@@ -58,8 +55,7 @@ This results in output similar to the following:
 release 4.1.0
 ```
 
-- **KVM**. Bazel requires emulators to have [hardware
-  acceleration](https://developer.android.com/studio/run/emulator-acceleration.html#accel-check)
+- **KVM**. Bazel requires emulators to have [hardware acceleration](https://developer.android.com/studio/run/emulator-acceleration.html#accel-check)
   with KVM on Linux. You can follow these
   [installation instructions](https://help.ubuntu.com/community/KVM/Installation)
   for Ubuntu.
@@ -173,11 +169,9 @@ The main attributes of the rule `android_instrumentation_test` are:
 
 - `target_device`: An `android_device` target. This target describes the
   specifications of the Android emulator which Bazel uses to create, launch and
-  run the tests. See the [section on choosing an Android
-  device](#android-device-target) for more information.
+  run the tests. See the [section on choosing an Android device](#android-device-target) for more information.
 
-The test app's `AndroidManifest.xml` must include [an ``
-tag](https://developer.android.com/studio/test/#configure_instrumentation_manifest_settings).
+The test app's `AndroidManifest.xml` must include [an `` tag](https://developer.android.com/studio/test/#configure_instrumentation_manifest_settings).
 This tag must specify the attributes for the **package of the target app** and
 the **fully qualified class name of the instrumentation test runner**,
 `androidx.test.runner.AndroidJUnitRunner`.
@@ -214,8 +208,7 @@ repositories:
 - `@androidsdk`: The Android SDK. Download this through Android Studio.
 
 - `@android_test_support`: Hosts the test runner, emulator launcher, and
-  `android_device` targets. You can find the [latest release
-  here](https://github.com/android/android-test/releases).
+  `android_device` targets. You can find the [latest release here](https://github.com/android/android-test/releases).
 
 Enable these dependencies by adding the following lines to your `WORKSPACE`
 file:
@@ -240,8 +233,7 @@ android_test_repositories()
 
 ## Maven dependencies {#maven-dependencies}
 
-For managing dependencies on Maven artifacts from repositories, such as [Google
-Maven](https://maven.google.com) or [Maven Central](https://central.maven.org),
+For managing dependencies on Maven artifacts from repositories, such as [Google Maven](https://maven.google.com) or [Maven Central](https://central.maven.org),
 you should use a Maven resolver, such as
 [`rules_jvm_external`](https://github.com/bazelbuild/rules_jvm_external).
 
@@ -370,8 +362,7 @@ the device/emulator listed in `adb devices`.
 
 ## Sample projects {#sample-projects}
 
-If you are looking for canonical project samples, see the [Android testing
-samples](https://github.com/googlesamples/android-testing#experimental-bazel-support)
+If you are looking for canonical project samples, see the [Android testing samples](https://github.com/googlesamples/android-testing#experimental-bazel-support)
 for projects using Espresso and UIAutomator.
 
 ## Espresso setup {#espresso-setup}
@@ -560,8 +551,7 @@ API_LEVELS = [
 
 ## Known issues {#known-issues}
 
-- [Forked adb server processes are not terminated after
-  tests](https://github.com/bazelbuild/bazel/issues/4853)
+- [Forked adb server processes are not terminated after tests](https://github.com/bazelbuild/bazel/issues/4853)
 - While APK building works on all platforms (Linux, macOS, Windows), testing
   only works on Linux.
 - Even with `--config=local_adb`, users still need to specify
diff --git a/versions/9.0.0/docs/android-ndk.mdx b/versions/9.0.0/docs/android-ndk.mdx
index cbf846c7..4f0b1f43 100644
--- a/versions/9.0.0/docs/android-ndk.mdx
+++ b/versions/9.0.0/docs/android-ndk.mdx
@@ -2,8 +2,7 @@
 title: 'Using the Android Native Development Kit with Bazel'
 ---
 
-_If you're new to Bazel, please start with the [Building Android with
-Bazel](/versions/9.0.0/start/android-app ) tutorial._
+_If you're new to Bazel, please start with the [Building Android with Bazel](/versions/9.0.0/start/android-app) tutorial._
 
 ## Overview {#overview}
 
@@ -155,8 +154,7 @@ more details.
 
 ## Example setup {#example-setup}
 
-This example is available in the [Bazel examples
-repository](https://github.com/bazelbuild/examples/tree/master/android/ndk).
+This example is available in the [Bazel examples repository](https://github.com/bazelbuild/examples/tree/master/android/ndk).
 
 In the `BUILD.bazel` file, three targets are defined with the `android_binary`,
 `android_library`, and `cc_library` rules.
diff --git a/versions/9.0.0/docs/configurable-attributes.mdx b/versions/9.0.0/docs/configurable-attributes.mdx
index 42b009f6..c96d435d 100644
--- a/versions/9.0.0/docs/configurable-attributes.mdx
+++ b/versions/9.0.0/docs/configurable-attributes.mdx
@@ -2,8 +2,7 @@
 title: 'Configurable Build Attributes'
 ---
 
-**_Configurable attributes_**, commonly known as [`select()`](
-/reference/be/functions#select), is a Bazel feature that lets users toggle the values
+**_Configurable attributes_**, commonly known as [`select()`](/reference/be/functions#select), is a Bazel feature that lets users toggle the values
 of build rule attributes at the command line.
 
 This can be used, for example, for a multiplatform library that automatically
@@ -408,8 +407,7 @@ sh_library(
 )
 ```
 
-If you need a `select` to match when multiple conditions match, consider [AND
-chaining](#and-chaining).
+If you need a `select` to match when multiple conditions match, consider [AND chaining](#and-chaining).
 
 ## OR chaining {#or-chaining}
 
diff --git a/versions/9.0.0/docs/user-manual.mdx b/versions/9.0.0/docs/user-manual.mdx
index ff599f90..fb0295e5 100644
--- a/versions/9.0.0/docs/user-manual.mdx
+++ b/versions/9.0.0/docs/user-manual.mdx
@@ -1147,10 +1147,7 @@ This option causes Bazel's execution phase to print the full command line
 for each command prior to executing it.
 
 
-  >>>>> # //examples/cpp:hello-world [action 'Linking examples/cpp/hello-world']
-  (cd /home/johndoe/.cache/bazel/_bazel_johndoe/4c084335afceb392cfbe7c31afee3a9f/bazel && \
-    exec env - \
-    /usr/bin/gcc -o bazel-out/local-fastbuild/bin/examples/cpp/hello-world -B/usr/bin/ -Wl,-z,relro,-z,now -no-canonical-prefixes -pass-exit-codes -Wl,-S -Wl,@bazel-out/local_linux-fastbuild/bin/examples/cpp/hello-world-2.params)
+  >>>>> # //examples/cpp:hello-world [action 'Linking examples/cpp/hello-world'](cd /home/johndoe/.cache/bazel/_bazel_johndoe/4c084335afceb392cfbe7c31afee3a9f/bazel && \ exec env - \ /usr/bin/gcc -o bazel-out/local-fastbuild/bin/examples/cpp/hello-world -B/usr/bin/ -Wl,-z,relro,-z,now -no-canonical-prefixes -pass-exit-codes -Wl,-S -Wl,@bazel-out/local_linux-fastbuild/bin/examples/cpp/hello-world-2.params)
 

 
 Where possible, commands are printed in a Bourne shell compatible syntax,
diff --git a/versions/9.0.0/extending/auto-exec-groups.mdx b/versions/9.0.0/extending/auto-exec-groups.mdx
index e3b23c54..8453e0b9 100644
--- a/versions/9.0.0/extending/auto-exec-groups.mdx
+++ b/versions/9.0.0/extending/auto-exec-groups.mdx
@@ -27,9 +27,7 @@ doesn't detect that ([the error](#first-error-message) is raised), you can set
 
 If you need to use multiple toolchains on a single execution platform (an action
 uses executable or tools from two or more toolchains), you need to manually
-define [exec_groups][exec_groups] (check
-[When should I use a custom exec_group?][multiple_toolchains_exec_groups]
-section).
+define [exec_groups][exec_groups](check [When should I use a custom exec_group?][multiple_toolchains_exec_groups] section).
 
 ## History {#history}
 
@@ -42,8 +40,7 @@ my_rule = rule(
 )
 ```
 
-Rule `my_rule` registers two toolchain types. This means that the [Toolchain
-Resolution](https://bazel.build/extending/toolchains#toolchain-resolution) used
+Rule `my_rule` registers two toolchain types. This means that the [Toolchain Resolution](https://bazel.build/extending/toolchains#toolchain-resolution) used
 to find an execution platform which supports both toolchain types. The selected
 execution platform was used for each registered action inside the rule, unless
 specified differently with [exec_groups][exec_groups].
diff --git a/versions/9.0.0/extending/concepts.mdx b/versions/9.0.0/extending/concepts.mdx
index 56dcdc1d..b5be9a11 100644
--- a/versions/9.0.0/extending/concepts.mdx
+++ b/versions/9.0.0/extending/concepts.mdx
@@ -20,16 +20,14 @@ Before learning the more advanced concepts, first:
 ## Macros and rules {#macros-and-rules}
 
 A macro is a function that instantiates rules. Macros come in two flavors:
-[symbolic macros](/versions/9.0.0/extending/macros) (new in Bazel 8) and [legacy
-macros](/versions/9.0.0/extending/legacy-macros). The two flavors of macros are defined
+[symbolic macros](/versions/9.0.0/extending/macros) (new in Bazel 8) and [legacy macros](/versions/9.0.0/extending/legacy-macros). The two flavors of macros are defined
 differently, but behave almost the same from the point of view of a user. A
 macro is useful when a `BUILD` file is getting too repetitive or too complex, as
 it lets you reuse some code. The function is evaluated as soon as the `BUILD`
 file is read. After the evaluation of the `BUILD` file, Bazel has little
 information about macros. If your macro generates a `genrule`, Bazel will
 behave *almost* as if you declared that `genrule` in the `BUILD` file. (The one
-exception is that targets declared in a symbolic macro have [special visibility
-semantics](/versions/9.0.0/extending/macros#visibility): a symbolic macro can hide its internal
+exception is that targets declared in a symbolic macro have [special visibility semantics](/versions/9.0.0/extending/macros#visibility): a symbolic macro can hide its internal
 targets from the rest of the package.)
 
 A [rule](/versions/9.0.0/extending/rules) is more powerful than a macro. It can access Bazel
@@ -76,8 +74,7 @@ they will not be executed.
 ## Creating extensions
 
 * [Create your first macro](/versions/9.0.0/rules/macro-tutorial) in order to reuse some code.
-  Then [learn more about macros](/versions/9.0.0/extending/macros) and [using them to create
-  "custom verbs"](/versions/9.0.0/rules/verbs-tutorial).
+  Then [learn more about macros](/versions/9.0.0/extending/macros) and [using them to create "custom verbs"](/versions/9.0.0/rules/verbs-tutorial).
 
 * [Follow the rules tutorial](/versions/9.0.0/rules/rules-tutorial) to get started with rules.
   Next, you can read more about the [rules concepts](/versions/9.0.0/extending/rules).
@@ -92,8 +89,7 @@ them within reach:
 ## Going further
 
 In addition to [macros](/versions/9.0.0/extending/macros) and [rules](/versions/9.0.0/extending/rules), you
-may want to write [aspects](/versions/9.0.0/extending/aspects) and [repository
-rules](/versions/9.0.0/external/repo).
+may want to write [aspects](/versions/9.0.0/extending/aspects) and [repository rules](/versions/9.0.0/external/repo).
 
 * Use [Buildifier](https://github.com/bazelbuild/buildtools)
   consistently to format and lint your code.
diff --git a/versions/9.0.0/extending/depsets.mdx b/versions/9.0.0/extending/depsets.mdx
index 7326a9d5..0da23426 100644
--- a/versions/9.0.0/extending/depsets.mdx
+++ b/versions/9.0.0/extending/depsets.mdx
@@ -111,8 +111,7 @@ need to ensure that if `B` depends on `A`, then `A.o` comes before `B.o` on the
 linker’s command line. Other tools might have the opposite requirement.
 
 Three traversal orders are supported: `postorder`, `preorder`, and
-`topological`. The first two work exactly like [tree
-traversals](https://en.wikipedia.org/wiki/Tree_traversal#Depth-first_search)
+`topological`. The first two work exactly like [tree traversals](https://en.wikipedia.org/wiki/Tree_traversal#Depth-first_search)
 except that they operate on DAGs and skip already visited nodes. The third order
 works as a topological sort from root to leaves, essentially the same as
 preorder except that shared children are listed only after all of their parents.
diff --git a/versions/9.0.0/extending/exec-groups.mdx b/versions/9.0.0/extending/exec-groups.mdx
index 9c1b6b22..0881d383 100644
--- a/versions/9.0.0/extending/exec-groups.mdx
+++ b/versions/9.0.0/extending/exec-groups.mdx
@@ -70,8 +70,7 @@ test rules.
 
 In the rule implementation, you can declare that actions should be run on the
 execution platform of an execution group. You can do this by using the `exec_group`
-param of action generating methods, specifically [`ctx.actions.run`]
-(/rules/lib/builtins/actions#run) and
+param of action generating methods, specifically [`ctx.actions.run`](/rules/lib/builtins/actions#run) and
 [`ctx.actions.run_shell`](/versions/9.0.0/rules/lib/builtins/actions#run_shell).
 
 ```python
diff --git a/versions/9.0.0/extending/macros.mdx b/versions/9.0.0/extending/macros.mdx
index 66e06a43..d1529bd1 100644
--- a/versions/9.0.0/extending/macros.mdx
+++ b/versions/9.0.0/extending/macros.mdx
@@ -31,8 +31,7 @@ two required parameters: `attrs` and `implementation`.
 
 ### Attributes {#attributes}
 
-`attrs` accepts a dictionary of attribute name to [attribute
-types](https://bazel.build/rules/lib/toplevel/attr#members), which represents
+`attrs` accepts a dictionary of attribute name to [attribute types](https://bazel.build/rules/lib/toplevel/attr#members), which represents
 the arguments to the macro. Two common attributes – `name` and `visibility` –
 are implicitly added to all macros and are not included in the dictionary passed
 to `attrs`.
@@ -66,9 +65,7 @@ To support this pattern, a macro can *inherit attributes* from a rule or another
 macro by passing the [rule](https://bazel.build/versions/9.0.0/rules/lib/builtins/rule) or
 [macro symbol](https://bazel.build/versions/9.0.0/rules/lib/builtins/macro) to `macro()`'s
 `inherit_attrs` argument. (You can also use the special string `"common"`
-instead of a rule or macro symbol to inherit the [common attributes defined for
-all Starlark build
-rules](https://bazel.build/reference/be/common-definitions#common-attributes).)
+instead of a rule or macro symbol to inherit the [common attributes defined for all Starlark build rules](https://bazel.build/reference/be/common-definitions#common-attributes).)
 Only public attributes get inherited, and the attributes in the macro's own
 `attrs` dictionary override inherited attributes with the same name. You can
 also *remove* inherited attributes by using `None` as a value in the `attrs`
diff --git a/versions/9.0.0/extending/platforms.mdx b/versions/9.0.0/extending/platforms.mdx
index 27b2d6ee..09b850e2 100644
--- a/versions/9.0.0/extending/platforms.mdx
+++ b/versions/9.0.0/extending/platforms.mdx
@@ -254,8 +254,7 @@ cc_library(
 
 You can use the
 [`IncompatiblePlatformProvider`](/versions/9.0.0/rules/lib/providers/IncompatiblePlatformProvider)
-in `bazel cquery`'s [Starlark output
-format](/versions/9.0.0/query/cquery#output-format-definition) to distinguish
+in `bazel cquery`'s [Starlark output format](/versions/9.0.0/query/cquery#output-format-definition) to distinguish
 incompatible targets from compatible ones.
 
 This can be used to filter out incompatible targets. The example below will
@@ -275,5 +274,4 @@ $ bazel cquery //... --output=starlark --starlark:file=example.cquery
 
 ### Known Issues
 
-Incompatible targets [ignore visibility
-restrictions](https://github.com/bazelbuild/bazel/issues/16044).
+Incompatible targets [ignore visibility restrictions](https://github.com/bazelbuild/bazel/issues/16044).
diff --git a/versions/9.0.0/extending/rules.mdx b/versions/9.0.0/extending/rules.mdx
index 8a56e6e1..57d4aeed 100644
--- a/versions/9.0.0/extending/rules.mdx
+++ b/versions/9.0.0/extending/rules.mdx
@@ -449,8 +449,7 @@ def _example_library_impl(ctx):
 
 If `DefaultInfo` is not returned by a rule implementation or the `files`
 parameter is not specified, `DefaultInfo.files` defaults to all
-*predeclared outputs* (generally, those created by [output
-attributes](#output_attributes)).
+*predeclared outputs* (generally, those created by [output attributes](#output_attributes)).
 
 Rules that perform actions should provide default outputs, even if those outputs
 are not expected to be directly used. Actions that are not in the graph of the
@@ -993,8 +992,7 @@ By using `configuration_field`, the dependency on the Java LCOV merger tool can
 be avoided as long as coverage is not requested.
 
 When the test is run, it should emit coverage information in the form of one or
-more [LCOV files]
-(https://manpages.debian.org/unstable/lcov/geninfo.1.en.html#TRACEFILE_FORMAT)
+more [LCOV files](https://manpages.debian.org/unstable/lcov/geninfo.1.en.html#TRACEFILE_FORMAT)
 with unique names into the directory specified by the `COVERAGE_DIR` environment
 variable. Bazel will then merge these files into a single LCOV file using the
 `_lcov_merger` tool. If present, it will also collect C/C++ coverage using the
diff --git a/versions/9.0.0/extending/toolchains.mdx b/versions/9.0.0/extending/toolchains.mdx
index 6d8e88c6..20dc4ab8 100644
--- a/versions/9.0.0/extending/toolchains.mdx
+++ b/versions/9.0.0/extending/toolchains.mdx
@@ -581,8 +581,7 @@ The set of available toolchains, in priority order, is created from
   4. Toolchains registered in the "WORKSPACE suffix"; this is only used by
      certain native rules bundled with the Bazel installation.
 
-**NOTE:** [Pseudo-targets like `:all`, `:*`, and
-`/...`](/versions/9.0.0/run/build#specifying-build-targets) are ordered by Bazel's package
+**NOTE:** [Pseudo-targets like `:all`, `:*`, and `/...`](/versions/9.0.0/run/build#specifying-build-targets) are ordered by Bazel's package
 loading mechanism, which uses a lexicographic ordering.
 
 The resolution steps are as follows.
diff --git a/versions/9.0.0/external/extension.mdx b/versions/9.0.0/external/extension.mdx
index 0334020a..037eea94 100644
--- a/versions/9.0.0/external/extension.mdx
+++ b/versions/9.0.0/external/extension.mdx
@@ -4,8 +4,7 @@ title: 'Module extensions'
 
 Module extensions allow users to extend the module system by reading input data
 from modules across the dependency graph, performing necessary logic to resolve
-dependencies, and finally creating repos by calling [repo
-rules](/versions/9.0.0/external/repo). These extensions have capabilities similar to repo
+dependencies, and finally creating repos by calling [repo rules](/versions/9.0.0/external/repo). These extensions have capabilities similar to repo
 rules, which enables them to perform file I/O, send network requests, and so on.
 Among other things, they allow Bazel to interact with other package management
 systems while also respecting the dependency graph built out of Bazel modules.
diff --git a/versions/9.0.0/external/faq.mdx b/versions/9.0.0/external/faq.mdx
index eaa160e3..9270751e 100644
--- a/versions/9.0.0/external/faq.mdx
+++ b/versions/9.0.0/external/faq.mdx
@@ -112,16 +112,14 @@ Bazel instead uses [Minimal Version Selection](module#version-selection) like
 Go, which in contrast makes the output easy to predict and guarantees
 reproducibility. This is a tradeoff that matches Bazel's design goals.
 
-Furthermore, Bazel module versions are [a superset of
-SemVer](module#version-format), so what makes sense in a strict SemVer
+Furthermore, Bazel module versions are [a superset of SemVer](module#version-format), so what makes sense in a strict SemVer
 environment doesn't always carry over to Bazel module versions.
 
 ### Can I automatically get the latest version for a `bazel_dep`? {#can-i-automatically-get-the-latest-version-for-a-bazel-dep}
 
 Some users occasionally ask for the ability to specify `bazel_dep(name = "foo",
 version = "latest")` to automatically get the latest version of a dep. This is
-similar to [the question about SemVer
-ranges](#can-i-specify-a-semver-range-for-a-bazel-dep), and the answer is also
+similar to [the question about SemVer ranges](#can-i-specify-a-semver-range-for-a-bazel-dep), and the answer is also
 no.
 
 The recommended solution here is to have automation take care of this. For
@@ -179,8 +177,7 @@ wonder which system is consulted first. The short answer is that MODULE.bazel
 
 The long answer is that "which evaluates first" is not the right question to
 ask; rather, the right question to ask is: in the context of the repo with
-[canonical name](overview#canonical-repo-name) `@@foo`, what does the [apparent
-repo name](overview#apparent-repo-name) `@bar` resolve to? Alternatively, what
+[canonical name](overview#canonical-repo-name) `@@foo`, what does the [apparent repo name](overview#apparent-repo-name) `@bar` resolve to? Alternatively, what
 is the repo mapping of `@@base`?
 
 Labels with apparent repo names (a single leading `@`) can refer to different
@@ -189,8 +186,7 @@ things based on the context they're resolved from. When you see a label
 what the context repo is: for example, if the label is in a BUILD file located
 in the repo `@@foo`, then the context repo is `@@foo`.
 
-Then, depending on what the context repo is, the ["repository
-visibility" table](migration#repository-visibility) in the migration guide can
+Then, depending on what the context repo is, the ["repository visibility" table](migration#repository-visibility) in the migration guide can
 be used to find out which repo an apparent name actually resolves to.
 
 *   If the context repo is the main repo (`@@`):
@@ -242,8 +238,7 @@ as the context repo.
 
 Use the `bazel fetch` command to prefetch repos. You can use the `--repo` flag
 (like `bazel fetch --repo @foo`) to fetch only the repo `@foo` (resolved in the
-context of the main repo, see [question
-above](#which-is-evaluated-first-module-bazel-or-workspace)), or use a target
+context of the main repo, see [question above](#which-is-evaluated-first-module-bazel-or-workspace)), or use a target
 pattern (like `bazel fetch @foo//:bar`) to fetch all transitive dependencies of
 `@foo//:bar` (this is equivalent to `bazel build --nobuild @foo//:bar`).
 
@@ -267,21 +262,17 @@ preferring IPv4 if enabled. In some situations, for example when the IPv4
 network cannot resolve/reach external addresses, this can cause `Network
 unreachable` exceptions and build failures. In these cases, you can override
 Bazel's behavior to prefer IPv6 by using the
-[`java.net.preferIPv6Addresses=true` system
-property](https://docs.oracle.com/javase/8/docs/api/java/net/doc-files/net-properties.html).
+[`java.net.preferIPv6Addresses=true` system property](https://docs.oracle.com/javase/8/docs/api/java/net/doc-files/net-properties.html).
 Specifically:
 
-*   Use `--host_jvm_args=-Djava.net.preferIPv6Addresses=true` [startup
-    option](/versions/9.0.0/docs/user-manual#startup-options), for example by adding the
+*   Use `--host_jvm_args=-Djava.net.preferIPv6Addresses=true` [startup option](/versions/9.0.0/docs/user-manual#startup-options), for example by adding the
     following line in your [`.bazelrc` file](/versions/9.0.0/run/bazelrc):
 
     `startup --host_jvm_args=-Djava.net.preferIPv6Addresses=true`
 
 *   When running Java build targets that need to connect to the internet (such
     as for integration tests), use the
-    `--jvmopt=-Djava.net.preferIPv6Addresses=true` [tool
-    flag](/versions/9.0.0/docs/user-manual#jvmopt). For example, include in your [`.bazelrc`
-    file](/versions/9.0.0/run/bazelrc):
+    `--jvmopt=-Djava.net.preferIPv6Addresses=true` [tool flag](/versions/9.0.0/docs/user-manual#jvmopt). For example, include in your [`.bazelrc` file](/versions/9.0.0/run/bazelrc):
 
     `build --jvmopt=-Djava.net.preferIPv6Addresses`
 
@@ -289,8 +280,7 @@ Specifically:
     [`rules_jvm_external`](https://github.com/bazelbuild/rules_jvm_external) for
     dependency version resolution, also add
     `-Djava.net.preferIPv6Addresses=true` to the `COURSIER_OPTS` environment
-    variable to [provide JVM options for
-    Coursier](https://github.com/bazelbuild/rules_jvm_external#provide-jvm-options-for-coursier-with-coursier_opts).
+    variable to [provide JVM options for Coursier](https://github.com/bazelbuild/rules_jvm_external#provide-jvm-options-for-coursier-with-coursier_opts).
 
 ### Can repo rules be run remotely with remote execution? {#can-repo-rules-be-run-remotely-with-remote-execution}
 
@@ -315,9 +305,7 @@ build rules, which would naturally allow them to be run remotely, but conversely
 raise new architectural concerns (for example, the `query` commands would
 potentially need to run actions, complicating their design).
 
-For more previous discussion on this topic, see [A way to support repositories
-that need Bazel for being
-fetched](https://github.com/bazelbuild/bazel/discussions/20464).
+For more previous discussion on this topic, see [A way to support repositories that need Bazel for being fetched](https://github.com/bazelbuild/bazel/discussions/20464).
 
 [npm-semver]: https://docs.npmjs.com/about-semantic-versioning
 [cargo-semver]: https://doc.rust-lang.org/cargo/reference/specifying-dependencies.html#version-requirement-syntax
diff --git a/versions/9.0.0/external/migration.mdx b/versions/9.0.0/external/migration.mdx
index bfba0eb3..77c6b80f 100644
--- a/versions/9.0.0/external/migration.mdx
+++ b/versions/9.0.0/external/migration.mdx
@@ -2,8 +2,7 @@
 title: 'Bzlmod Migration Guide'
 ---
 
-Due to the [shortcomings of
-WORKSPACE](/versions/9.0.0/external/overview#workspace-shortcomings), Bzlmod is replacing the
+Due to the [shortcomings of WORKSPACE](/versions/9.0.0/external/overview#workspace-shortcomings), Bzlmod is replacing the
 legacy WORKSPACE system. The WORKSPACE file is already disabled in Bazel 8 (late
 2024) and will be removed in Bazel 9 (late 2025). This guide helps you migrate
 your project to Bzlmod and drop WORKSPACE for managing external dependencies.
@@ -29,8 +28,7 @@ Recommended migration process:
     streamline the migration process as much as possible.
 2.  If there are errors left after using the migration tool, resolve them
     manually. For understanding the main differences between concepts inside
-    `WORKSPACE` and `MODULE.bazel` files, check [WORKSPACE versus
-    Bzlmod](#workspace-vs-bzlmod) section.
+    `WORKSPACE` and `MODULE.bazel` files, check [WORKSPACE versus Bzlmod](#workspace-vs-bzlmod) section.
 
 ## WORKSPACE vs Bzlmod {#workspace-vs-bzlmod}
 
@@ -140,9 +138,7 @@ Bazel module when it also adopts Bzlmod.
 
 *   **Bzlmod**
 
-    With Bzlmod, as long as your dependency is available in [Bazel Central
-    Registry](https://registry.bazel.build) or your custom [Bazel
-    registry](/versions/9.0.0/external/registry), you can simply depend on it with a
+    With Bzlmod, as long as your dependency is available in [Bazel Central Registry](https://registry.bazel.build) or your custom [Bazel registry](/versions/9.0.0/external/registry), you can simply depend on it with a
     [`bazel_dep`](/versions/9.0.0/rules/lib/globals/module#bazel_dep) directive.
 
     ```python
@@ -173,8 +169,7 @@ repository.
 
 If your dependency is not a Bazel project or not yet available in any Bazel
 registry, you can introduce it using
-[`use_repo_rule`](/versions/9.0.0/external/module#use_repo_rule) or [module
-extensions](/versions/9.0.0/external/extension).
+[`use_repo_rule`](/versions/9.0.0/external/module#use_repo_rule) or [module extensions](/versions/9.0.0/external/extension).
 
 *   **WORKSPACE**
 
@@ -615,8 +610,7 @@ flag after fetching all repos needed for a build.
 ## Manual migration {#manual-migration}
 
 This section provides useful information and guidance for your **manual** Bzlmod
-migration process. For more automatized migration process, check [recommended
-migration process](#how-migrate-to-bzlmod) section.
+migration process. For more automatized migration process, check [recommended migration process](#how-migrate-to-bzlmod) section.
 
 ### Know your dependencies in WORKSPACE {#know-deps-in-workspace}
 
@@ -630,8 +624,7 @@ macros.
 Fortunately, the flag
 [`--experimental_repository_resolved_file`][resolved_file_flag]
 can help. This flag essentially generates a "lock file" of all fetched external
-dependencies in your last Bazel command. You can find more details in this [blog
-post](https://blog.bazel.build/2018/07/09/bazel-sync-and-resolved-file.html).
+dependencies in your last Bazel command. You can find more details in this [blog post](https://blog.bazel.build/2018/07/09/bazel-sync-and-resolved-file.html).
 
 [resolved_file_flag]: /reference/command-line-reference#flag--experimental_repository_resolved_file
 
@@ -672,11 +665,9 @@ You may also know `bazel query` can be used for inspecting repository rules with
 bazel query --output=build //external:
 ```
 
-While it is more convenient and much faster, [bazel query can lie about
-external dependency version](https://github.com/bazelbuild/bazel/issues/12947),
+While it is more convenient and much faster, [bazel query can lie about external dependency version](https://github.com/bazelbuild/bazel/issues/12947),
 so be careful using it! Querying and inspecting external
-dependencies with Bzlmod is going to achieved by a [new
-subcommand](https://github.com/bazelbuild/bazel/issues/15365).
+dependencies with Bzlmod is going to achieved by a [new subcommand](https://github.com/bazelbuild/bazel/issues/15365).
 
 #### Built-in default dependencies {#builtin-default-deps}
 
@@ -723,8 +714,7 @@ Using the WORKSPACE.bzlmod file can make the migration easier because:
 #### Repository visibility {#repository-visibility}
 
 Bzlmod is able to control which other repositories are visible from a given
-repository, check [repository names and strict
-deps](/versions/9.0.0/external/module#repository_names_and_strict_deps) for more details.
+repository, check [repository names and strict deps](/versions/9.0.0/external/module#repository_names_and_strict_deps) for more details.
 
 Here is a summary of repository visibilities from different types of
 repositories when also taking WORKSPACE into consideration.
@@ -737,8 +727,7 @@ repositories when also taking WORKSPACE into consideration.
 | WORKSPACE Repos | All visible | Not visible | Not visible | All visible |
 
 Note: For the root module, if a repository `@foo` is defined in WORKSPACE and
-`@foo` is also used as an [apparent repository
-name](/versions/9.0.0/external/overview#apparent-repo-name) in MODULE.bazel, then `@foo`
+`@foo` is also used as an [apparent repository name](/versions/9.0.0/external/overview#apparent-repo-name) in MODULE.bazel, then `@foo`
 refers to the one introduced in MODULE.bazel.
 
 Note: For a module extension generated repository `@bar`, if `@foo` is used as
@@ -783,9 +772,7 @@ the project. Take note of a few things when creating the source archive:
     GitHub isn't going to guarantee the checksum of source archives generated on
     demand. In short, URLs in the form of
     `https://github.com///releases/download/...` is considered stable
-    while `https://github.com///archive/...` is not. Check [GitHub
-    Archive Checksum
-    Outage](https://blog.bazel.build/2023/02/15/github-archive-checksum.html)
+    while `https://github.com///archive/...` is not. Check [GitHub Archive Checksum Outage](https://blog.bazel.build/2023/02/15/github-archive-checksum.html)
     for more context.
 
 *   **Make sure the source tree follows the layout of the original repository.**
@@ -814,8 +801,7 @@ Pull Request.
 
 [bcr_contrib_guide]: https://github.com/bazelbuild/bazel-central-registry/tree/main/docs#contribute-a-bazel-module
 
-It is **highly recommended** to set up the [Publish to
-BCR](https://github.com/bazel-contrib/publish-to-bcr) GitHub App for your
+It is **highly recommended** to set up the [Publish to BCR](https://github.com/bazel-contrib/publish-to-bcr) GitHub App for your
 repository to automate the process of submitting your module to the BCR.
 
 ## Best practices {#best-practices}
diff --git a/versions/9.0.0/external/migration_tool.mdx b/versions/9.0.0/external/migration_tool.mdx
index e2e5dee0..3cdaaf34 100644
--- a/versions/9.0.0/external/migration_tool.mdx
+++ b/versions/9.0.0/external/migration_tool.mdx
@@ -100,8 +100,7 @@ migrate2bzlmod -t <targets>
     script.
 *   `extension_for_XXX` - A file containing a module extension
     definition. The migration tool generates these files for dependencies that
-    are not standard Bazel modules but can be managed using Bzlmod's [module
-    extensions](/versions/9.0.0/external/extension).
+    are not standard Bazel modules but can be managed using Bzlmod's [module extensions](/versions/9.0.0/external/extension).
 
 ### Flags {#migration-script-flags}
 
@@ -298,8 +297,7 @@ def my_custom_macro(name):
 The end goal is to have `MODULE.bazel` file and delete the `WORKSPACE` file,
 without impacting the user experience.
 
-The first step is to follow [How to Use the Migration
-Tool](#migration-tool-how-to-use), which mostly is checking the bazel version
+The first step is to follow [How to Use the Migration Tool](#migration-tool-how-to-use), which mostly is checking the bazel version
 (it must be Bazel 7) and adding an alias to the migration script.
 
 Then, running `migrate2bzlmod -t=//...` outputs:
@@ -632,8 +630,7 @@ may arise during the Bzlmod migration.
 ### Migration Report Generation {#migration-tool-report-generation}
 
 This file is updated with each run of the migration script or it's generated
-from scratch if it's the first run or if the [`--i`
-flag](#migration-script-flags) is used. The report contains:
+from scratch if it's the first run or if the [`--i` flag](#migration-script-flags) is used. The report contains:
 
 *   Command for local testing.
 *   List of direct dependencies (at least the ones which are directly used in
diff --git a/versions/9.0.0/external/mod-command.mdx b/versions/9.0.0/external/mod-command.mdx
index 580533ec..52b5b732 100644
--- a/versions/9.0.0/external/mod-command.mdx
+++ b/versions/9.0.0/external/mod-command.mdx
@@ -61,11 +61,9 @@ The available subcommands and their respective required arguments are:
 
 *   ``: All present versions of the module ``.
 
-*   `@`: The repo with the given [apparent
-    name](overview#apparent-repo-name) in the context of the `--base_module`.
+*   `@`: The repo with the given [apparent name](overview#apparent-repo-name) in the context of the `--base_module`.
 
-*   `@@`: The repo with the given [canonical
-    name](overview#canonical-repo-name).
+*   `@@`: The repo with the given [canonical name](overview#canonical-repo-name).
 
 In a context requiring specifying modules, ``s referring to repos that
 correspond to modules (as opposed to extension-generated repos) can also be
@@ -89,8 +87,7 @@ The following options only affect the subcommands that print graphs (`graph`,
     information about the version resolution of each module. If the module
     version changed during resolution, show either which version replaced it or
     what was the original version, the reason it was replaced, and which modules
-    requested the new version if the reason was [Minimal Version
-    Selection](module#version-selection).
+    requested the new version if the reason was [Minimal Version Selection](module#version-selection).
 
 *   `--include_unused` *default: "false"*: Include in the output graph the
     modules which were originally present in the dependency graph, but became
diff --git a/versions/9.0.0/external/module.mdx b/versions/9.0.0/external/module.mdx
index 233f93ca..cfe5d294 100644
--- a/versions/9.0.0/external/module.mdx
+++ b/versions/9.0.0/external/module.mdx
@@ -55,8 +55,7 @@ Any valid SemVer version is a valid Bazel module version. Additionally, two
 SemVer versions `a` and `b` compare `a < b` if and only if the same holds when
 they're compared as Bazel module versions.
 
-Finally, to learn more about module versioning, [see the `MODULE.bazel`
-FAQ](faq#module-versioning-best-practices).
+Finally, to learn more about module versioning, [see the `MODULE.bazel` FAQ](faq#module-versioning-best-practices).
 
 ## Version selection {#version-selection}
 
@@ -107,8 +106,7 @@ Bazel can throw an error if it detects that versions of the _same module_ with
 _different compatibility levels_ exist in the resolved dependency graph.
 
 Finally, incrementing the compatibility level can be disruptive to the users.
-To learn more about when and how to increment it, [check the `MODULE.bazel`
-FAQ](faq#incrementing-compatibility-level).
+To learn more about when and how to increment it, [check the `MODULE.bazel` FAQ](faq#incrementing-compatibility-level).
 
 ## Overrides
 
@@ -130,8 +128,7 @@ serves multiple purposes:
     version, regardless of which versions of the dependency are requested in the
     dependency graph.
 *   With the `registry` attribute, you can force this dependency to come from a
-    specific registry, instead of following the normal [registry
-    selection](/versions/9.0.0/external/registry#selecting_registries) process.
+    specific registry, instead of following the normal [registry selection](/versions/9.0.0/external/registry#selecting_registries) process.
 *   With the `patch*` attributes, you can specify a set of patches to apply to
     the downloaded module.
 
@@ -180,8 +177,7 @@ Bazel supports the following non-registry overrides:
 
 Note that setting a version value in the source archive `MODULE.bazel` can have
 downsides when the module is being overridden with a non-registry override. To
-learn more about this [see the `MODULE.bazel`
-FAQ](faq#module-versioning-best-practices).
+learn more about this [see the `MODULE.bazel` FAQ](faq#module-versioning-best-practices).
 
 ## Define repos that don't represent Bazel modules {#use_repo_rule}
 
@@ -189,13 +185,11 @@ With `bazel_dep`, you can define repos that represent other Bazel modules.
 Sometimes there is a need to define a repo that does _not_ represent a Bazel
 module; for example, one that contains a plain JSON file to be read as data.
 
-In this case, you could use the [`use_repo_rule`
-directive](/versions/9.0.0/rules/lib/globals/module#use_repo_rule) to directly define a repo
+In this case, you could use the [`use_repo_rule` directive](/versions/9.0.0/rules/lib/globals/module#use_repo_rule) to directly define a repo
 by invoking a repo rule. This repo will only be visible to the module it's
 defined in.
 
-Under the hood, this is implemented using the same mechanism as [module
-extensions](/versions/9.0.0/external/extension), which lets you define repos with more
+Under the hood, this is implemented using the same mechanism as [module extensions](/versions/9.0.0/external/extension), which lets you define repos with more
 flexibility.
 
 ## Repository names and strict deps
diff --git a/versions/9.0.0/external/overview.mdx b/versions/9.0.0/external/overview.mdx
index 67607c30..3697b623 100644
--- a/versions/9.0.0/external/overview.mdx
+++ b/versions/9.0.0/external/overview.mdx
@@ -12,8 +12,7 @@ concepts in more detail.
 
 ## Overview of the system {#overview}
 
-Bazel's external dependency system works on the basis of [*Bazel
-modules*](#module), each of which is a versioned Bazel project, and
+Bazel's external dependency system works on the basis of [*Bazel modules*](#module), each of which is a versioned Bazel project, and
 [*repositories*](#repository) (or repos), which are directory trees containing
 source files.
 
@@ -30,8 +29,7 @@ bazel_dep(name = "platforms", version = "0.0.11")
 ```
 
 From there, Bazel looks up all transitive dependency modules in a
-[*Bazel registry*](registry) — by default, the [Bazel Central
-Registry](https://bcr.bazel.build/). The registry provides the
+[*Bazel registry*](registry) — by default, the [Bazel Central Registry](https://bcr.bazel.build/). The registry provides the
 dependencies' `MODULE.bazel` files, which allows Bazel to discover the entire
 transitive dependency graph before performing version resolution.
 
@@ -103,8 +101,7 @@ Bazel's external dependency system offers a wide range of benefits.
     need to facilitate offline builds.
 -   **[Lockfile](lockfile)**: The lockfile improves build reproducibility and
     accelerates dependency resolution.
--   **(Upcoming) [BCR Provenance
-    Attestations](https://github.com/bazelbuild/bazel-central-registry/discussions/2721)**:
+-   **(Upcoming) [BCR Provenance Attestations](https://github.com/bazelbuild/bazel-central-registry/discussions/2721)**:
     Strengthen supply chain security by ensuring verified provenance of
     dependencies.
 
@@ -228,8 +225,7 @@ contain anything to serve as a repo boundary file; however, it can also be used
 to specify some common attributes for all build targets inside the repo.
 
 The syntax of a `REPO.bazel` file is similar to `BUILD` files, except that no
-`load` statements are supported. The `repo()` function takes the same arguments as the [`package()`
-function](/versions/9.0.0/reference/be/functions#package) in `BUILD` files; whereas `package()`
+`load` statements are supported. The `repo()` function takes the same arguments as the [`package()` function](/versions/9.0.0/reference/be/functions#package) in `BUILD` files; whereas `package()`
 specifies common attributes for all build targets inside the package, `repo()`
 analogously does so for all build targets inside the repo.
 
diff --git a/versions/9.0.0/external/registry.mdx b/versions/9.0.0/external/registry.mdx
index 4068f500..efc00d05 100644
--- a/versions/9.0.0/external/registry.mdx
+++ b/versions/9.0.0/external/registry.mdx
@@ -21,14 +21,12 @@ An index registry must have the following format:
 *   `/modules`: A directory containing a subdirectory for each module in this
     registry
 *   `/modules/$MODULE`: A directory containing a subdirectory for each version
-    of the module named `$MODULE`, as well as the [`metadata.json`
-    file](#metadata-json) containing metadata for this module.
+    of the module named `$MODULE`, as well as the [`metadata.json` file](#metadata-json) containing metadata for this module.
 *   `/modules/$MODULE/$VERSION`: A directory containing the following files:
     *   `MODULE.bazel`: The `MODULE.bazel` file of this module version. Note
         that this is the `MODULE.bazel` file read during Bazel's external
         dependency resolution, _not_ the one from the source archive (unless
-        there's a [non-registry
-        override](/versions/9.0.0/external/module#non-registry_overrides)). Also note that it's
+        there's a [non-registry override](/versions/9.0.0/external/module#non-registry_overrides)). Also note that it's
         best to use this file to set the version of a release and avoid doing so
         in the source archive `MODULE.bazel` file. To learn more about module
         versioning, [see the FAQ](faq.md#module-versioning-best-practices).
@@ -65,8 +63,7 @@ module, with the following fields:
 *   `versions`: An array of strings, each denoting a version of the module
     available in this registry. This array should match the children of the
     module directory.
-*   `yanked_versions`: A JSON object specifying the [*yanked*
-    versions](/versions/9.0.0/external/module#yanked_versions) of this module. The keys
+*   `yanked_versions`: A JSON object specifying the [*yanked* versions](/versions/9.0.0/external/module#yanked_versions) of this module. The keys
     should be versions to yank, and the values should be descriptions of
     why the version is yanked, ideally containing a link to more
     information.
diff --git a/versions/9.0.0/external/repo.mdx b/versions/9.0.0/external/repo.mdx
index 69b9db3d..35bc61a9 100644
--- a/versions/9.0.0/external/repo.mdx
+++ b/versions/9.0.0/external/repo.mdx
@@ -74,8 +74,7 @@ specified.
 
 The input parameter `repository_ctx` can be used to access attribute values, and
 non-hermetic functions (finding a binary, executing a binary, creating a file in
-the repository or downloading a file from the Internet). See [the API
-docs](/versions/9.0.0/rules/lib/builtins/repository_ctx) for more context. Example:
+the repository or downloading a file from the Internet). See [the API docs](/versions/9.0.0/rules/lib/builtins/repository_ctx) for more context. Example:
 
 ```python
 def _impl(repository_ctx):
@@ -144,8 +143,7 @@ definition has the `configure` attribute set, use `bazel fetch --force
 
 ## Examples
 
--   [C++ auto-configured
-    toolchain](https://cs.opensource.google/bazel/bazel/+/master:tools/cpp/cc_configure.bzl;drc=644b7d41748e09eff9e47cbab2be2263bb71f29a;l=176):
+-   [C++ auto-configured toolchain](https://cs.opensource.google/bazel/bazel/+/master:tools/cpp/cc_configure.bzl;drc=644b7d41748e09eff9e47cbab2be2263bb71f29a;l=176):
     it uses a repo rule to automatically create the C++ configuration files for
     Bazel by looking for the local C++ compiler, the environment and the flags
     the C++ compiler supports.
diff --git a/versions/9.0.0/external/vendor.mdx b/versions/9.0.0/external/vendor.mdx
index 24458591..ffbd4cc4 100644
--- a/versions/9.0.0/external/vendor.mdx
+++ b/versions/9.0.0/external/vendor.mdx
@@ -23,9 +23,7 @@ absolute path.
 ## Vendor a specific external repository {#vendor-specific-repository}
 
 You can use the `vendor` command with the `--repo` flag to specify which repo
-to vendor, it accepts both [canonical repo
-name](/versions/9.0.0/external/overview#canonical-repo-name) and [apparent repo
-name](/versions/9.0.0/external/overview#apparent-repo-name).
+to vendor, it accepts both [canonical repo name](/versions/9.0.0/external/overview#canonical-repo-name) and [apparent repo name](/versions/9.0.0/external/overview#apparent-repo-name).
 
 For example, running:
 
diff --git a/versions/9.0.0/help.mdx b/versions/9.0.0/help.mdx
index ff04941b..290b401d 100644
--- a/versions/9.0.0/help.mdx
+++ b/versions/9.0.0/help.mdx
@@ -47,5 +47,4 @@ what level of support Bazel provides.
 
 ## File a bug {#file-bug}
 
-If you encounter a bug or want to request a feature, file a [GitHub
-Issue](https://github.com/bazelbuild/bazel/issues).
+If you encounter a bug or want to request a feature, file a [GitHub Issue](https://github.com/bazelbuild/bazel/issues).
diff --git a/versions/9.0.0/install/bazelisk.mdx b/versions/9.0.0/install/bazelisk.mdx
index 404ab21b..6fb861bb 100644
--- a/versions/9.0.0/install/bazelisk.mdx
+++ b/versions/9.0.0/install/bazelisk.mdx
@@ -16,8 +16,7 @@ For more details, see
 ## Updating Bazel
 
 Bazel has a [backward compatibility policy](/versions/9.0.0/release/backward-compatibility)
-(see [guidance for rolling out incompatible
-changes](/versions/9.0.0/contribute/breaking-changes) if you
+(see [guidance for rolling out incompatible changes](/versions/9.0.0/contribute/breaking-changes) if you
 are the author of one). That page summarizes best practices on how to test and
 migrate your project with upcoming incompatible changes and how to provide
 feedback to the incompatible change authors.
diff --git a/versions/9.0.0/install/compile-source.mdx b/versions/9.0.0/install/compile-source.mdx
index f1624168..f8e84b02 100644
--- a/versions/9.0.0/install/compile-source.mdx
+++ b/versions/9.0.0/install/compile-source.mdx
@@ -45,8 +45,7 @@ it by typing `bazel` in a terminal.
 
 **Reason**: To build Bazel from a GitHub source tree, you need a pre-existing
 Bazel binary. You can install one from a package manager or download one from
-GitHub. See [Installing Bazel](/versions/9.0.0/install). (Or you can [build from
-scratch (bootstrap)](#bootstrap-bazel).)
+GitHub. See [Installing Bazel](/versions/9.0.0/install). (Or you can [build from scratch (bootstrap)](#bootstrap-bazel).)
 
 **Troubleshooting**:
 
@@ -238,8 +237,7 @@ For instructions for Unix-like systems, see
     ```
 
 *   **The Visual C++ compiler.** Install the Visual C++ compiler either as part
-    of Visual Studio 2015 or newer, or by installing the latest [Build Tools
-    for Visual Studio 2017](https://aka.ms/BuildTools).
+    of Visual Studio 2015 or newer, or by installing the latest [Build Tools for Visual Studio 2017](https://aka.ms/BuildTools).
 
 *   **JDK.** Version 21 is required.
 
diff --git a/versions/9.0.0/install/ide.mdx b/versions/9.0.0/install/ide.mdx
index a22ff004..25380854 100644
--- a/versions/9.0.0/install/ide.mdx
+++ b/versions/9.0.0/install/ide.mdx
@@ -38,10 +38,8 @@ To install, go to the IDE's plugin browser and search for `Bazel`.
 To manually install older versions, download the zip files from JetBrains'
 Plugin Repository and install the zip file from the IDE's plugin browser:
 
-*  [Android Studio
-   plugin](https://plugins.jetbrains.com/plugin/9185-android-studio-with-bazel)
-*  [IntelliJ
-   plugin](https://plugins.jetbrains.com/plugin/8609-intellij-with-bazel)
+*  [Android Studio plugin](https://plugins.jetbrains.com/plugin/9185-android-studio-with-bazel)
+*  [IntelliJ plugin](https://plugins.jetbrains.com/plugin/8609-intellij-with-bazel)
 *  [CLion plugin](https://plugins.jetbrains.com/plugin/9554-clion-with-bazel)
 
 ### Xcode {#xcode}
@@ -61,8 +59,7 @@ Features:
 * Starlark debugger for `.bzl` files during a build (set breakpoints, step
   through code, inspect variables, and so on)
 
-Find [the plugin on the Visual Studio
-marketplace](https://marketplace.visualstudio.com/items?itemName=BazelBuild.vscode-bazel)
+Find [the plugin on the Visual Studio marketplace](https://marketplace.visualstudio.com/items?itemName=BazelBuild.vscode-bazel)
 or the [OpenVSX marketplace](https://open-vsx.org/extension/BazelBuild/vscode-bazel).
 The plugin is [open source](https://github.com/bazelbuild/vscode-bazel).
 
@@ -83,8 +80,7 @@ See also: [Autocomplete for Source Code](#autocomplete-for-source-code)
 
 ### Emacs {#emacs}
 
-See [`bazelbuild/bazel-emacs-mode` on
-GitHub](https://github.com/bazelbuild/emacs-bazel-mode)
+See [`bazelbuild/bazel-emacs-mode` on GitHub](https://github.com/bazelbuild/emacs-bazel-mode)
 
 See also: [Autocomplete for Source Code](#autocomplete-for-source-code)
 
@@ -122,6 +118,5 @@ tool for building Bazel targets when source files change.
 
 ## Building your own IDE plugin {#build-own-plugin}
 
-Read the [**IDE support** blog
-post](https://blog.bazel.build/2016/06/10/ide-support.html) to learn more about
+Read the [**IDE support** blog post](https://blog.bazel.build/2016/06/10/ide-support.html) to learn more about
 the Bazel APIs to use when building an IDE plugin.
diff --git a/versions/9.0.0/install/windows.mdx b/versions/9.0.0/install/windows.mdx
index d82f8572..2d111eee 100644
--- a/versions/9.0.0/install/windows.mdx
+++ b/versions/9.0.0/install/windows.mdx
@@ -31,8 +31,7 @@ To check your Windows version:
 
 Alternatively you can:
 
-*   [Download the Bazel binary (`bazel-version-windows-x86_64.exe`) from
- GitHub](https://github.com/bazelbuild/bazel/releases).
+*   [Download the Bazel binary (`bazel-version-windows-x86_64.exe`) from GitHub](https://github.com/bazelbuild/bazel/releases).
 *   [Install Bazel from Chocolatey](#chocolately)
 *   [Install Bazel from Scoop](#scoop)
 *   [Build Bazel from source](/versions/9.0.0/install/compile-source)
@@ -208,8 +207,7 @@ If that doesn't help:
     its dependencies, such as the MSYS2 shell. This will not install Visual C++
     though.
 
-See [Chocolatey installation and package maintenance
-guide](/versions/9.0.0/contribute/windows-chocolatey-maintenance) for more
+See [Chocolatey installation and package maintenance guide](/versions/9.0.0/contribute/windows-chocolatey-maintenance) for more
 information about the Chocolatey package.
 
 ### Using Scoop {#scoop}
@@ -226,8 +224,7 @@ information about the Chocolatey package.
     scoop install bazel
     ```
 
-See [Scoop installation and package maintenance
-guide](/versions/9.0.0/contribute/windows-scoop-maintenance) for more
+See [Scoop installation and package maintenance guide](/versions/9.0.0/contribute/windows-scoop-maintenance) for more
 information about the Scoop package.
 
 ### Build from source {#build-from-source}
diff --git a/versions/9.0.0/migrate/maven.mdx b/versions/9.0.0/migrate/maven.mdx
index aa856ebd..53d05787 100644
--- a/versions/9.0.0/migrate/maven.mdx
+++ b/versions/9.0.0/migrate/maven.mdx
@@ -19,8 +19,7 @@ directly run by Bazel since there's no Maven compatibility layer.
 ## Before you begin {#before-you-begin}
 
 *   [Install Bazel](/versions/9.0.0/install) if it's not yet installed.
-*   If you're new to Bazel, go through the tutorial [Introduction to Bazel:
-    Build Java](/versions/9.0.0/start/java) before you start migrating. The tutorial explains
+*   If you're new to Bazel, go through the tutorial [Introduction to Bazel: Build Java](/versions/9.0.0/start/java) before you start migrating. The tutorial explains
     Bazel's concepts, structure, and label syntax.
 
 ## Differences between Maven and Bazel {#dif-maven-bazel}
@@ -44,8 +43,7 @@ The steps below describe how to migrate your project to Bazel:
 3.  [Create more BUILD files](#3-build)
 4.  [Build using Bazel](#4-build)
 
-Examples below come from a migration of the [Guava
-project](https://github.com/google/guava) from Maven to Bazel. The
+Examples below come from a migration of the [Guava project](https://github.com/google/guava) from Maven to Bazel. The
 Guava project used is release `v31.1`. The examples using Guava do not walk
 through each step in the migration, but they do show the files and contents that
 are generated or added manually for the migration.
@@ -63,14 +61,12 @@ has no external dependencies, this file can be empty.
 If your project depends on files or packages that are not in one of the
 project's directories, specify these external dependencies in the MODULE.bazel
 file. You can use `rules_jvm_external` to manage dependencies from Maven. For
-instructions about using this ruleset, see [the
-README](https://github.com/bazelbuild/rules_jvm_external/#rules_jvm_external)
+instructions about using this ruleset, see [the README](https://github.com/bazelbuild/rules_jvm_external/#rules_jvm_external)
 .
 
 #### Guava project example: external dependencies {#guava-1}
 
-You can list the external dependencies of the [Guava
-project](https://github.com/google/guava) with the
+You can list the external dependencies of the [Guava project](https://github.com/google/guava) with the
 [`rules_jvm_external`](https://github.com/bazelbuild/rules_jvm_external)
 ruleset.
 
@@ -164,8 +160,7 @@ your build by adding more `BUILD` files with more granular targets.
             *   `resources`: Use globbing to list all resources in your project.
             *   `deps`: You need to determine which external dependencies your
                 project needs.
-        *   Take a look at the [example below of this top-level BUILD
-            file](#guava-2) from the migration of the Guava project.
+        *   Take a look at the [example below of this top-level BUILD file](#guava-2) from the migration of the Guava project.
 
 3.  Now that you have a `BUILD` file at the root of your project, build your
     project to ensure that it works. On the command line, from your workspace
diff --git a/versions/9.0.0/migrate/xcode.mdx b/versions/9.0.0/migrate/xcode.mdx
index f5889ec4..53f514b1 100644
--- a/versions/9.0.0/migrate/xcode.mdx
+++ b/versions/9.0.0/migrate/xcode.mdx
@@ -32,8 +32,7 @@ Before you begin, do the following:
 
 1.  [Install Bazel](/versions/9.0.0/install) if you have not already done so.
 
-2.  If you're not familiar with Bazel and its concepts, complete the [iOS app
-    tutorial](/versions/9.0.0/start/ios-app)). You should understand the Bazel workspace,
+2.  If you're not familiar with Bazel and its concepts, complete the [iOS app tutorial](/versions/9.0.0/start/ios-app)). You should understand the Bazel workspace,
     including the `MODULE.bazel` and `BUILD` files, as well as the concepts of
     targets, build rules, and Bazel packages.
 
@@ -44,8 +43,7 @@ Before you begin, do the following:
 Unlike Xcode, Bazel requires you to explicitly declare all dependencies for
 every target in the `BUILD` file.
 
-For more information on external dependencies, see [Working with external
-dependencies](/versions/9.0.0/docs/external).
+For more information on external dependencies, see [Working with external dependencies](/versions/9.0.0/docs/external).
 
 ## Build or test an Xcode project with Bazel {#build-xcode-project}
 
@@ -84,8 +82,7 @@ Note: Place the project source code within the directory tree containing the
 
 To integrate SwiftPM dependencies into the Bazel workspace with
 [swift_bazel](https://github.com/cgrindel/swift_bazel), you must
-convert them into Bazel packages as described in the [following
-tutorial](https://chuckgrindel.com/swift-packages-in-bazel-using-swift_bazel/)
+convert them into Bazel packages as described in the [following tutorial](https://chuckgrindel.com/swift-packages-in-bazel-using-swift_bazel/)
 .
 
 Note: SwiftPM support is a manual process with many variables. SwiftPM
@@ -103,8 +100,7 @@ initial build of the project as follows:
 *   [Step 3b: (Optional) Add the test target(s)](#step-3b-optional-add-the-test-target-s)
 *   [Step 3c: Add the library target(s)](#step-3c-add-the-library-target-s)
 
-**Tip:** To learn more about packages and other Bazel concepts, see [Workspaces,
-packages, and targets](/versions/9.0.0/concepts/build-ref).
+**Tip:** To learn more about packages and other Bazel concepts, see [Workspaces, packages, and targets](/versions/9.0.0/concepts/build-ref).
 
 #### Step 3a: Add the application target {#add-app-target}
 
@@ -132,8 +128,7 @@ In the target, specify the following at the minimum:
 
 #### Step 3b: (Optional) Add the test target(s) {#add-test-target}
 
-Bazel's [Apple build
-rules](https://github.com/bazelbuild/rules_apple) support running
+Bazel's [Apple build rules](https://github.com/bazelbuild/rules_apple) support running
 unit and UI tests on all Apple platforms. Add test targets as follows:
 
 *   [`macos_unit_test`](https://github.com/bazelbuild/rules_apple/blob/master/doc/rules-macos.md#macos_unit_test)
@@ -181,8 +176,7 @@ all sources and/or headers of a certain type. Use it carefully as it might
 include files you do not want Bazel to build.
 
 You can browse existing examples for various types of applications directly in
-the [rules_apple examples
-directory](https://github.com/bazelbuild/rules_apple/tree/master/examples/). For
+the [rules_apple examples directory](https://github.com/bazelbuild/rules_apple/tree/master/examples/). For
 example:
 
 *   [macOS application targets](https://github.com/bazelbuild/rules_apple/tree/master/examples/macos)
@@ -191,8 +185,7 @@ example:
 
 *   [Multi platform applications (macOS, iOS, watchOS, tvOS)](https://github.com/bazelbuild/rules_apple/tree/master/examples/multi_platform)
 
-For more information on build rules, see [Apple Rules for
-Bazel](https://github.com/bazelbuild/rules_apple).
+For more information on build rules, see [Apple Rules for Bazel](https://github.com/bazelbuild/rules_apple).
 
 At this point, it is a good idea to test the build:
 
diff --git a/versions/9.0.0/query/cquery.mdx b/versions/9.0.0/query/cquery.mdx
index 6a9bf682..37597308 100644
--- a/versions/9.0.0/query/cquery.mdx
+++ b/versions/9.0.0/query/cquery.mdx
@@ -6,8 +6,7 @@ title: 'Configurable Query (cquery)'
 [`select()`](/versions/9.0.0/docs/configurable-attributes) and build options' effects on the
 build graph.
 
-It achieves this by running over the results of Bazel's [analysis
-phase](/versions/9.0.0/extending/concepts#evaluation-model),
+It achieves this by running over the results of Bazel's [analysis phase](/versions/9.0.0/extending/concepts#evaluation-model),
 which integrates these effects. `query`, by contrast, runs over the results of
 Bazel's loading phase, before options are evaluated.
 
@@ -137,8 +136,7 @@ $ bazel cquery //foo --universe_scope=//foo,//genrule_with_foo_as_tool
 If you want to precisely declare which instance to query over, use
 the [`config`](#config) function.
 
-See `query`'s [target pattern
-documentation](/versions/9.0.0/query/language#target-patterns) for more information on target
+See `query`'s [target pattern documentation](/versions/9.0.0/query/language#target-patterns) for more information on target
 patterns.
 
 ## Functions {#functions}
@@ -539,8 +537,7 @@ different niches. Consider the following to decide which is right for you:
 It's therefore prone to picking up results from past queries.
 
 For example, `genrule` exerts an exec transition on its `tools` attribute -
-that is, it configures its tools in the [exec configuration]
-(https://bazel.build/rules/rules#configurations).
+that is, it configures its tools in the [exec configuration](https://bazel.build/rules/rules#configurations).
 
 You can see the lingering effects of that transition below.
 
diff --git a/versions/9.0.0/query/language.mdx b/versions/9.0.0/query/language.mdx
index 68c55b0a..8dcb1c01 100644
--- a/versions/9.0.0/query/language.mdx
+++ b/versions/9.0.0/query/language.mdx
@@ -1129,8 +1129,7 @@ is being used.
 
 ### On the ordering of results {#results-ordering}
 
-Although query expressions always follow the "[law of
-conservation of graph order](#graph-order)", _presenting_ the results may be done
+Although query expressions always follow the "[law of conservation of graph order](#graph-order)", _presenting_ the results may be done
 in either a dependency-ordered or unordered manner. This does **not**
 influence the targets in the result set or how the query is computed. It only
 affects how the results are printed to stdout. Moreover, nodes that are
@@ -1276,8 +1275,7 @@ and `maxrank` output formats print the labels of each
 target in the resulting graph, but instead of appearing in
 topological order, they appear in rank order, preceded by their
 rank number. These are unaffected by the result ordering
-`--[no]order_results` flag (see [notes on
-the ordering of results](#result-order)).
+`--[no]order_results` flag (see [notes on the ordering of results](#result-order)).
 
 There are two variants of this format: `minrank` ranks
 each node by the length of the shortest path from a root node to it.
diff --git a/versions/9.0.0/reference/be/functions.mdx b/versions/9.0.0/reference/be/functions.mdx
index 5e3eff6e..f166f30a 100644
--- a/versions/9.0.0/reference/be/functions.mdx
+++ b/versions/9.0.0/reference/be/functions.mdx
@@ -262,8 +262,7 @@ There are several important limitations and caveats:
    package called "Foo.java" (which is allowed, though Bazel warns about it),
    then the consumer of the `glob()` will use the "Foo.java" rule
    (its outputs) instead of the "Foo.java" file. See
-   [GitHub
-   issue #10395](https://github.com/bazelbuild/bazel/issues/10395#issuecomment-583714657) for more details.
+   [GitHub issue #10395](https://github.com/bazelbuild/bazel/issues/10395#issuecomment-583714657) for more details.
 3. Globs may match files in subdirectories. And subdirectory names
    may be wildcarded. However...
 4. Labels are not allowed to cross the package boundary and glob does
diff --git a/versions/9.0.0/reference/be/java.mdx b/versions/9.0.0/reference/be/java.mdx
index 456be8b8..6a444bf1 100644
--- a/versions/9.0.0/reference/be/java.mdx
+++ b/versions/9.0.0/reference/be/java.mdx
@@ -226,8 +226,7 @@ test code. The test runner's main method is invoked instead of the main class be
   [java\_binary](#java_binary) for more details.
 
 See the section on `java_binary()` arguments. This rule also
-supports all [attributes common
-to all test rules (\*\_test)](https://bazel.build/reference/be/common-definitions#common-attributes-tests).
+supports all [attributes common to all test rules (\*\_test)](https://bazel.build/reference/be/common-definitions#common-attributes-tests).
 
 #### Examples
 
diff --git a/versions/9.0.0/reference/be/make-variables.mdx b/versions/9.0.0/reference/be/make-variables.mdx
index fe369f00..10cc0f1f 100644
--- a/versions/9.0.0/reference/be/make-variables.mdx
+++ b/versions/9.0.0/reference/be/make-variables.mdx
@@ -19,8 +19,7 @@ targets, and *custom* variables, which are defined in dependency targets
 and only available to targets that depend on them.
 
 The reason for the term "Make" is historical: the syntax and semantics of
-these variables were originally intended to match [GNU
-Make](https://www.gnu.org/software/make/manual/html_node/Using-Variables.html).
+these variables were originally intended to match [GNU Make](https://www.gnu.org/software/make/manual/html_node/Using-Variables.html).
 
 ## Use
 
@@ -64,8 +63,7 @@ and look at the top output lines with capital letters.
 **Toolchain option variables**
 
 * `COMPILATION_MODE`:
-  `fastbuild`, `dbg`, or `opt`. ([more
-  details](https://bazel.build/docs/user-manual#flag--compilation_mode))
+  `fastbuild`, `dbg`, or `opt`. ([more details](https://bazel.build/docs/user-manual#flag--compilation_mode))
 
 **Path variables**
 
diff --git a/versions/9.0.0/reference/glossary.mdx b/versions/9.0.0/reference/glossary.mdx
index 8493e05e..9a2b51f2 100644
--- a/versions/9.0.0/reference/glossary.mdx
+++ b/versions/9.0.0/reference/glossary.mdx
@@ -21,8 +21,7 @@ An in-memory graph of [actions](#action) and the [artifacts](#artifact) that
 these actions read and generate. The graph might include artifacts that exist as
 source files (for example, in the file system) as well as generated
 intermediate/final artifacts that are not mentioned in `BUILD` files. Produced
-during the [analysis phase](#analysis-phase) and used during the [execution
-phase](#execution-phase).
+during the [analysis phase](#analysis-phase) and used during the [execution phase](#execution-phase).
 
 ### Action graph query (aquery) {#action-graph-query}
 A [query](#query-concept) tool that can query over build [actions](#action).
@@ -37,8 +36,7 @@ invalidate individual actions deterministically.
 
 ### Analysis phase {#analysis-phase}
 The second phase of a build. Processes the [target graph](#target-graph)
-specified in [`BUILD` files](#build-file) to produce an in-memory [action
-graph](#action-graph) that determines the order of actions to run during the
+specified in [`BUILD` files](#build-file) to produce an in-memory [action graph](#action-graph) that determines the order of actions to run during the
 [execution phase](#execution-phase). This is the phase in which rule
 implementations are evaluated.
 
@@ -81,8 +79,7 @@ target's source files, dependencies, and custom compiler options. The particular
 attributes available for a given target depend on its rule type.
 
 ### .bazelrc {#bazelrc}
-Bazel’s configuration file used to change the default values for [startup
-flags](#startup-flags) and [command flags](#command-flags), and to define common
+Bazel’s configuration file used to change the default values for [startup flags](#startup-flags) and [command flags](#command-flags), and to define common
 groups of options that can then be set together on the Bazel command line using
 a `--config` flag. Bazel can combine settings from multiple bazelrc files
 (systemwide, per-workspace, per-user, or from a custom location), and a
@@ -108,8 +105,7 @@ directory.
 
 ### .bzl File {#bzl-file}
 A file that defines rules, [macros](#macro), and constants written in
-[Starlark](#starlark). These can then be imported into [`BUILD`
-files](#build-file) using the `load()` function.
+[Starlark](#starlark). These can then be imported into [`BUILD` files](#build-file) using the `load()` function.
 
 {/* TODO: ### Build event protocol */}
 
@@ -117,8 +113,7 @@ files](#build-file) using the `load()` function.
 
 ### Build graph {#build-graph}
 The dependency graph that Bazel constructs and traverses to perform a build.
-Includes nodes like [targets](#target), [configured
-targets](#configured-target), [actions](#action), and [artifacts](#artifact). A
+Includes nodes like [targets](#target), [configured targets](#configured-target), [actions](#action), and [artifacts](#artifact). A
 build is considered complete when all [artifacts](#artifact) on which a set of
 requested targets depend are verified as up-to-date.
 
@@ -158,8 +153,7 @@ graphs and restart the [analysis phase](#analysis-phase).
 ### Configuration {#configuration}
 Information outside of [rule](#rule) definitions that impacts how rules generate
 [actions](#action). Every build has at least one configuration specifying the
-target platform, action environment variables, and command-line [build
-flags](#command-flags). [Transitions](#transition) may create additional
+target platform, action environment variables, and command-line [build flags](#command-flags). [Transitions](#transition) may create additional
 configurations, such as for host tools or cross-compilation.
 
 **See also:** [Configurations](/versions/9.0.0/extending/rules#configurations)
@@ -174,8 +168,7 @@ configuration of `//:c` because changing `--javacopt` unnecessarily breaks C++
 build cacheability.
 
 ### Configured query (cquery) {#configured-query}
-A [query](#query-concept) tool that queries over [configured
-targets](#configured-target) (after the [analysis phase](#analysis-phase)
+A [query](#query-concept) tool that queries over [configured targets](#configured-target) (after the [analysis phase](#analysis-phase)
 completes). This means `select()` and [build flags](#command-flags) (such as
 `--platforms`) are accurately reflected in the results.
 
@@ -191,8 +184,7 @@ build, it has two configured targets: `` and ``.
 ### Correctness {#correctness}
 A build is correct when its output faithfully reflects the state of its
 transitive inputs. To achieve correct builds, Bazel strives to be
-[hermetic](#hermeticity), reproducible, and making [build
-analysis](#analysis-phase) and [action execution](#execution-phase)
+[hermetic](#hermeticity), reproducible, and making [build analysis](#analysis-phase) and [action execution](#execution-phase)
 deterministic.
 
 ### Dependency {#dependency}
@@ -234,8 +226,7 @@ compilation). A dynamic execution strategy can provide the best possible
 incremental and clean build times.
 
 ### Execution phase {#execution-phase}
-The third phase of a build. Executes the [actions](#action) in the [action
-graph](#action-graph) created during the [analysis phase](#analysis-phase).
+The third phase of a build. Executes the [actions](#action) in the [action graph](#action-graph) created during the [analysis phase](#analysis-phase).
 These actions invoke executables (compilers, scripts) to read and write
 [artifacts](#artifact). *Spawn strategies* control how these actions are
 executed: locally, remotely, dynamically, sandboxed, docker, and so on.
@@ -285,8 +276,7 @@ syntax may be omitted.
 The first phase of a build where Bazel executes [`BUILD` files](#build-file) to
 create [packages](#package). [Macros](#macro) and certain functions like
 `glob()` are evaluated in this phase. Interleaved with the second phase of the
-build, the [analysis phase](#analysis-phase), to build up a [target
-graph](#target-graph).
+build, the [analysis phase](#analysis-phase), to build up a [target graph](#target-graph).
 
 ### Legacy macro {#legacy-macro}
 A flavor of [macro](#macro) which is declared as an ordinary
@@ -336,8 +326,7 @@ Module metadata is hosted in Bazel registries.
 
 ### Module Extension {#module-extension}
 A piece of logic that can be run to generate [repos](#repository) by reading
-inputs from across the [module](#module) dependency graph and invoking [repo
-rules](#repository-rule). Module extensions have capabilities similar to repo
+inputs from across the [module](#module) dependency graph and invoking [repo rules](#repository-rule). Module extensions have capabilities similar to repo
 rules, allowing them to access the internet, perform file I/O, and so on.
 
 **See also:** [Module extensions](/versions/9.0.0/external/extension)
@@ -350,8 +339,7 @@ example, `native.cc_library` or `native.java_library`). User-defined rules
 
 ### Output base {#output-base}
 A [workspace](#workspace)-specific directory to store Bazel output files. Used
-to separate outputs from the *workspace*'s source tree (the [main
-repo](#repository)). Located in the [output user root](#output-user-root).
+to separate outputs from the *workspace*'s source tree (the [main repo](#repository)). Located in the [output user root](#output-user-root).
 
 ### Output groups {#output-groups}
 A group of files that is expected to be built when Bazel finishes building a
@@ -406,8 +394,7 @@ query variants: [query](#query-command), [cquery](#configured-query), and
 [aquery](#action-graph-query).
 
 ### query (command) {#query-command}
-A [query](#query-concept) tool that operates over the build's post-[loading
-phase](#loading-phase) [target graph](#target-graph). This is relatively fast,
+A [query](#query-concept) tool that operates over the build's post-[loading phase](#loading-phase) [target graph](#target-graph). This is relatively fast,
 but can't analyze the effects of `select()`, [build flags](#command-flags),
 [artifacts](#artifact), or build [actions](#action).
 
@@ -425,8 +412,7 @@ repo; multiple such files can coexist in a directory.
 The *main repo* is the repo in which the current Bazel command is being run.
 
 *External repos* are defined by specifying [modules](#module) in `MODULE.bazel`
-files, or invoking [repo rules](#repository-rule) in [module
-extensions](#module-extension). They can be fetched on demand to a predetermined
+files, or invoking [repo rules](#repository-rule) in [module extensions](#module-extension). They can be fetched on demand to a predetermined
 "magical" location on disk.
 
 Each repo has a unique, constant *canonical* name, and potentially different
@@ -437,8 +423,7 @@ Each repo has a unique, constant *canonical* name, and potentially different
 ### Repository cache {#repo-cache}
 A shared content-addressable cache of files downloaded by Bazel for builds,
 shareable across [workspaces](#workspace). Enables offline builds after the
-initial download. Commonly used to cache files downloaded through [repository
-rules](#repository-rule) like `http_archive` and repository rule APIs like
+initial download. Commonly used to cache files downloaded through [repository rules](#repository-rule) like `http_archive` and repository rule APIs like
 `repository_ctx.download`. Files are cached only if their SHA-256 checksums are
 specified for the download.
 
@@ -472,8 +457,7 @@ Rules are instantiated to produce rule targets in the
 [loading phase](#loading-phase). In the [analysis phase](#analysis-phase) rule
 targets communicate information to their downstream dependencies in the form of
 [providers](#provider), and register [actions](#action) describing how to
-generate their output artifacts. These actions are run in the [execution
-phase](#execution-phase).
+generate their output artifacts. These actions are run in the [execution phase](#execution-phase).
 
 Note: Historically the term "rule" has been used to refer to a rule target.
 This usage was inherited from tools like Make, but causes confusion and should
@@ -517,8 +501,7 @@ support the stamp attribute.
 ### Starlark {#starlark}
 The extension language for writing [rules](/versions/9.0.0/extending/rules) and [macros](#macro). A
 restricted subset of Python (syntactically and grammatically) aimed for the
-purpose of configuration, and for better performance. Uses the [`.bzl`
-file](#bzl-file) extension. [`BUILD` files](#build-file) use an even more
+purpose of configuration, and for better performance. Uses the [`.bzl` file](#bzl-file) extension. [`BUILD` files](#build-file) use an even more
 restricted version of Starlark (such as no `def` function definitions), formerly
 known as Skylark.
 
@@ -549,8 +532,7 @@ An object that is defined in a [`BUILD` file](#build-file) and identified by a
 [label](#label). Targets represent the buildable units of a workspace from
 the perspective of the end user.
 
-A target that is declared by instantiating a [rule](#rule) is called a [rule
-target](#rule-target). Depending on the rule, these may be runnable (like
+A target that is declared by instantiating a [rule](#rule) is called a [rule target](#rule-target). Depending on the rule, these may be runnable (like
 `cc_binary`) or testable (like `cc_test`). Rule targets typically depend on
 other targets via their [attributes](#attribute) (such as `deps`); these
 dependencies form the basis of the [target graph](#target-graph).
@@ -561,14 +543,11 @@ within a `BUILD` file. As a special case, the `BUILD` file of any package is
 always considered a source file target in that package.
 
 Targets are discovered during the [loading phase](#loading-phase). During the
-[analysis phase](#analysis-phase), targets are associated with [build
-configurations](#configuration) to form [configured
-targets](#configured-target).
+[analysis phase](#analysis-phase), targets are associated with [build configurations](#configuration) to form [configured targets](#configured-target).
 
 ### Target graph {#target-graph}
 An in-memory graph of [targets](#target) and their dependencies. Produced during
-the [loading phase](#loading-phase) and used as an input to the [analysis
-phase](#analysis-phase).
+the [loading phase](#loading-phase) and used as an input to the [analysis phase](#analysis-phase).
 
 ### Target pattern {#target-pattern}
 A way to specify a group of [targets](#target) on the command line. Commonly
@@ -581,8 +560,7 @@ packages recursively from the root of the [workspace](#workspace).
 Rule [targets](#target) instantiated from test rules, and therefore contains a
 test executable. A return code of zero from the completion of the executable
 indicates test success. The exact contract between Bazel and tests (such as test
-environment variables, test result collection methods) is specified in the [Test
-Encyclopedia](/versions/9.0.0/reference/test-encyclopedia).
+environment variables, test result collection methods) is specified in the [Test Encyclopedia](/versions/9.0.0/reference/test-encyclopedia).
 
 ### Toolchain {#toolchain}
 A set of tools to build outputs for a language. Typically, a toolchain includes
@@ -596,8 +574,7 @@ A build [target](#target) is top-level if it’s requested on the Bazel command
 line. For example, if `//:foo` depends on `//:bar`, and `bazel build //:foo` is
 called, then for this build, `//:foo` is top-level, and `//:bar` isn’t
 top-level, although both targets will need to be built. An important difference
-between top-level and non-top-level targets is that [command
-flags](#command-flags) set on the Bazel command line (or via
+between top-level and non-top-level targets is that [command flags](#command-flags) set on the Bazel command line (or via
 [.bazelrc](#bazelrc)) will set the [configuration](#configuration) for top-level
 targets, but might be modified by a [transition](#transition) for non-top-level
 targets.
@@ -628,8 +605,7 @@ or `.bzl` file may load a given `.bzl` file. Without context, usually
 **See also:** [Visibility documentation](/versions/9.0.0/concepts/visibility)
 
 ### Workspace {#workspace}
-The environment shared by all Bazel commands run from the same [main
-repository](#repository).
+The environment shared by all Bazel commands run from the same [main repository](#repository).
 
 Note that historically the concepts of "repository" and "workspace" have been
 conflated; the term "workspace" has often been used to refer to the main
diff --git a/versions/9.0.0/reference/test-encyclopedia.mdx b/versions/9.0.0/reference/test-encyclopedia.mdx
index f04cd672..1d5c8b83 100644
--- a/versions/9.0.0/reference/test-encyclopedia.mdx
+++ b/versions/9.0.0/reference/test-encyclopedia.mdx
@@ -685,8 +685,7 @@ mark it as having failed.
 ## Execution platform {#execution-platform}
 The [execution platform](/versions/9.0.0/extending/platforms) for a test action is determined
 via [toolchain resolution](/versions/9.0.0/extending/toolchains#toolchain-resolution), just
-like for any other action. Each test rule has an implicitly defined [
-`test` exec group](/versions/9.0.0/extending/exec-groups#exec-groups-for-native-rules) that,
+like for any other action. Each test rule has an implicitly defined [`test` exec group](/versions/9.0.0/extending/exec-groups#exec-groups-for-native-rules) that,
 unless overridden, has a mandatory toolchain requirement on
 `@bazel_tools//tools/test:default_test_toolchain_type`.
 
@@ -726,8 +725,7 @@ a default toolchain for it.
 ## Tag conventions {#tag-conventions}
 Some tags in the test rules have a special meaning.
 See also the
-[Bazel Build Encyclopedia on the `tags` attribute]
-(/reference/be/common-definitions#common.tags).
+[Bazel Build Encyclopedia on the `tags` attribute](/reference/be/common-definitions#common.tags).
 
 
diff --git a/versions/9.0.0/release/backward-compatibility.mdx b/versions/9.0.0/release/backward-compatibility.mdx
index f11f07f2..0562f0d6 100644
--- a/versions/9.0.0/release/backward-compatibility.mdx
+++ b/versions/9.0.0/release/backward-compatibility.mdx
@@ -6,11 +6,9 @@ This page provides information about how to handle backward compatibility,
 including migrating from one release to another and how to communicate
 incompatible changes.
 
-Bazel is evolving. Minor versions released as part of an [LTS major
-version](/versions/9.0.0/release#bazel-versioning) are fully backward-compatible. New major LTS
+Bazel is evolving. Minor versions released as part of an [LTS major version](/versions/9.0.0/release#bazel-versioning) are fully backward-compatible. New major LTS
 releases may contain incompatible changes that require some migration effort.
-For more information about Bazel's release model, please check out the [Release
-Model](/versions/9.0.0/release) page.
+For more information about Bazel's release model, please check out the [Release Model](/versions/9.0.0/release) page.
 
 ## Summary {#summary}
 
@@ -59,8 +57,7 @@ available.
 ## Communicating incompatible changes {#communicating-incompatible-changes}
 
 The primary source of information about incompatible changes are GitHub issues
-marked with an ["incompatible-change"
-label](https://github.com/bazelbuild/bazel/issues?q=label%3Aincompatible-change).
+marked with an ["incompatible-change" label](https://github.com/bazelbuild/bazel/issues?q=label%3Aincompatible-change).
 
 For every incompatible change, the issue specifies the following:
 
diff --git a/versions/9.0.0/release/index.mdx b/versions/9.0.0/release/index.mdx
index 95d58c35..4d6173f1 100644
--- a/versions/9.0.0/release/index.mdx
+++ b/versions/9.0.0/release/index.mdx
@@ -2,8 +2,7 @@
 title: 'Release Model'
 ---
 
-As announced in [the original blog
-post](https://blog.bazel.build/2020/11/10/long-term-support-release.html), Bazel
+As announced in [the original blog post](https://blog.bazel.build/2020/11/10/long-term-support-release.html), Bazel
 4.0 and higher versions provides support for two release tracks: rolling
 releases and long term support (LTS) releases. This page covers the latest
 information about Bazel's release model.
@@ -19,8 +18,7 @@ information about Bazel's release model.
 | Bazel 5 | Deprecated | [5.4.1](https://github.com/bazelbuild/bazel/releases/tag/5.4.1) | Jan 2025 |
 | Bazel 4 | Deprecated | [4.2.4](https://github.com/bazelbuild/bazel/releases/tag/4.2.4) | Jan 2024 |
 
-All Bazel LTS releases can be found on the [release
-page](https://github.com/bazelbuild/bazel/releases) on GitHub.
+All Bazel LTS releases can be found on the [release page](https://github.com/bazelbuild/bazel/releases) on GitHub.
 
 Note: Bazel version older than Bazel 5 are no longer supported, Bazel users are
 recommended to upgrade to the latest LTS release or use rolling releases if you
@@ -28,8 +26,7 @@ want to keep up with the latest changes at HEAD.
 
 ## Release versioning {#bazel-versioning}
 
-Bazel uses a _major.minor.patch_ [Semantic
-Versioning](https://semver.org/) scheme.
+Bazel uses a _major.minor.patch_ [Semantic Versioning](https://semver.org/) scheme.
 
 *   A _major release_ contains features that are not backward compatible with
     the previous release. Each major Bazel version is an LTS release.
@@ -72,8 +69,7 @@ Bazel regularly publish releases for two release tracks.
     release.
 *   Rolling releases can ship incompatible changes. Incompatible flags are
     recommended for major breaking changes, rolling out incompatible changes
-    should follow our [backward compatibility
-    policy](/versions/9.0.0/release/backward-compatibility).
+    should follow our [backward compatibility policy](/versions/9.0.0/release/backward-compatibility).
 
 ### LTS releases {#lts-releases}
 
@@ -89,8 +85,7 @@ Bazel regularly publish releases for two release tracks.
 *   A Bazel LTS release enters the Deprecated stage after being in ​​the
     Maintenance stage for 2 years.
 
-For planned releases, please check our [release
-issues](https://github.com/bazelbuild/bazel/issues?q=is%3Aopen+is%3Aissue+label%3Arelease)
+For planned releases, please check our [release issues](https://github.com/bazelbuild/bazel/issues?q=is%3Aopen+is%3Aissue+label%3Arelease)
 on Github.
 
 ## Release procedure & policies {#release-procedure-policies}
@@ -153,8 +148,7 @@ For LTS releases, the procedure and policies below are followed:
 1.  Identify release blockers and fix issues found on the release branch.
     *   The release branch is tested with the same test suite in
         [postsubmit](https://buildkite.com/bazel/bazel-bazel) and
-        [downstream test pipeline]
-        (https://buildkite.com/bazel/bazel-at-head-plus-downstream)
+        [downstream test pipeline](https://buildkite.com/bazel/bazel-at-head-plus-downstream)
         on Bazel CI. The Bazel team monitors testing results of the release
         branch and fixes any regressions found.
 1.  Create a new release candidate from the release branch when all known
@@ -210,5 +204,4 @@ feature.
 ## Rule compatibility {#rule-compatibility}
 
 If you are a rule authors and want to maintain compatibility with different
-Bazel versions, please check out the [Rule
-Compatibility](/versions/9.0.0/release/rule-compatibility) page.
+Bazel versions, please check out the [Rule Compatibility](/versions/9.0.0/release/rule-compatibility) page.
diff --git a/versions/9.0.0/release/rule-compatibility.mdx b/versions/9.0.0/release/rule-compatibility.mdx
index 140cdfd2..a5be3b0c 100644
--- a/versions/9.0.0/release/rule-compatibility.mdx
+++ b/versions/9.0.0/release/rule-compatibility.mdx
@@ -53,18 +53,15 @@ Bazel LTS release.
 As Bazel rules authors, you can ensure a manageable migration process for users
 by following these best practices:
 
-1.  The rule should follow [Semantic
-    Versioning](https://semver.org/): minor versions of the same
+1.  The rule should follow [Semantic Versioning](https://semver.org/): minor versions of the same
     major version are backward compatible.
 1.  The rule at HEAD should be compatible with the latest Bazel LTS release.
 1.  The rule at HEAD should be compatible with Bazel at HEAD. To achieve this,
     you can
     *   Set up your own CI testing with Bazel at HEAD
-    *   Add your project to [Bazel downstream
-        testing](https://github.com/bazelbuild/continuous-integration/blob/master/docs/downstream-testing.md);
+    *   Add your project to [Bazel downstream testing](https://github.com/bazelbuild/continuous-integration/blob/master/docs/downstream-testing.md);
         the Bazel team files issues to your project if breaking changes in Bazel
-        affect your project, and you must follow our [downstream project
-        policies](https://github.com/bazelbuild/continuous-integration/blob/master/docs/downstream-testing.md#downstream-project-policies)
+        affect your project, and you must follow our [downstream project policies](https://github.com/bazelbuild/continuous-integration/blob/master/docs/downstream-testing.md#downstream-project-policies)
         to address issues timely.
 1.  The latest major version of the rule must be compatible with the latest
     Bazel LTS release.
diff --git a/versions/9.0.0/remote/bep-glossary.mdx b/versions/9.0.0/remote/bep-glossary.mdx
index 026acdc4..a114cbe3 100644
--- a/versions/9.0.0/remote/bep-glossary.mdx
+++ b/versions/9.0.0/remote/bep-glossary.mdx
@@ -410,5 +410,4 @@ workspace, such as the execution root.
 
 ## WorkspaceStatus {#workspacestatus}
 
-A single `WorkspaceStatus` event contains the result of the [workspace status
-command](/versions/9.0.0/docs/user-manual#workspace-status).
+A single `WorkspaceStatus` event contains the result of the [workspace status command](/versions/9.0.0/docs/user-manual#workspace-status).
diff --git a/versions/9.0.0/remote/bep.mdx b/versions/9.0.0/remote/bep.mdx
index 14bb2251..396c26a6 100644
--- a/versions/9.0.0/remote/bep.mdx
+++ b/versions/9.0.0/remote/bep.mdx
@@ -2,14 +2,12 @@
 title: 'Build Event Protocol'
 ---
 
-The [Build Event
-Protocol](https://github.com/bazelbuild/bazel/blob/master/src/main/java/com/google/devtools/build/lib/buildeventstream/proto/build_event_stream.proto)
+The [Build Event Protocol](https://github.com/bazelbuild/bazel/blob/master/src/main/java/com/google/devtools/build/lib/buildeventstream/proto/build_event_stream.proto)
 (BEP) allows third-party programs to gain insight into a Bazel invocation. For
 example, you could use the BEP to gather information for an IDE
 plugin or a dashboard that displays build results.
 
-The protocol is a set of [protocol
-buffer](https://developers.google.com/protocol-buffers/) messages with some
+The protocol is a set of [protocol buffer](https://developers.google.com/protocol-buffers/) messages with some
 semantics defined on top of it. It includes information about build and test
 results, build progress, the build configuration and much more. The BEP is
 intended to be consumed programmatically and makes parsing Bazel’s
@@ -20,16 +18,13 @@ build event is a protocol buffer message consisting of a build event identifier,
 a set of child event identifiers, and a payload.
 
 *  __Build Event Identifier:__ Depending on the kind of build event, it might be
-an [opaque
-string](https://github.com/bazelbuild/bazel/blob/7.1.0/src/main/java/com/google/devtools/build/lib/buildeventstream/proto/build_event_stream.proto#L131-L140)
-or [structured
-information](https://github.com/bazelbuild/bazel/blob/7.1.0/src/main/java/com/google/devtools/build/lib/buildeventstream/proto/build_event_stream.proto#L194-L205)
+an [opaque string](https://github.com/bazelbuild/bazel/blob/7.1.0/src/main/java/com/google/devtools/build/lib/buildeventstream/proto/build_event_stream.proto#L131-L140)
+or [structured information](https://github.com/bazelbuild/bazel/blob/7.1.0/src/main/java/com/google/devtools/build/lib/buildeventstream/proto/build_event_stream.proto#L194-L205)
 revealing more about the build event. A build event identifier is unique within
 a build.
 
 *  __Children:__ A build event may announce other build events, by including
-their build event identifiers in its [children
-field](https://github.com/bazelbuild/bazel/blob/7.1.0/src/main/java/com/google/devtools/build/lib/buildeventstream/proto/build_event_stream.proto#L1276).
+their build event identifiers in its [children field](https://github.com/bazelbuild/bazel/blob/7.1.0/src/main/java/com/google/devtools/build/lib/buildeventstream/proto/build_event_stream.proto#L1276).
 For example, the `PatternExpanded` build event announces the targets it expands
 to as children. The protocol guarantees that all events, except for the first
 event, are announced by a previous event.
@@ -91,8 +86,7 @@ human-readable formats, such as text and JSON:
 
 ## Build Event Service {#build-event-service}
 
-The [Build Event
-Service](https://github.com/googleapis/googleapis/blob/master/google/devtools/build/v1/publish_build_event.proto)
+The [Build Event Service](https://github.com/googleapis/googleapis/blob/master/google/devtools/build/v1/publish_build_event.proto)
 Protocol is a generic [gRPC](https://www.grpc.io) service for publishing build events. The Build Event
 Service protocol is independent of the BEP and treats BEP events as opaque bytes.
 Bazel ships with a gRPC client implementation of the Build Event Service protocol that
@@ -136,8 +130,7 @@ For a description of each of these flags, see the
 The BEP typically contains many references to log files (test.log, test.xml,
 etc. ) stored on the machine where Bazel is running. A remote BES server
 typically can't access these files as they are on different machines. A way to
-work around this issue is to use Bazel with [remote
-caching](/versions/9.0.0/remote/caching).
+work around this issue is to use Bazel with [remote caching](/versions/9.0.0/remote/caching).
 Bazel will upload all output files to the remote cache (including files
 referenced in the BEP) and the BES server can then fetch the referenced files
 from the cache.
diff --git a/versions/9.0.0/remote/cache-local.mdx b/versions/9.0.0/remote/cache-local.mdx
index 2e7adc1d..6046c4ca 100644
--- a/versions/9.0.0/remote/cache-local.mdx
+++ b/versions/9.0.0/remote/cache-local.mdx
@@ -18,8 +18,7 @@ execution. However, local execution presents some additional challenges.
 ## Checking your cache hit rate {#cache-hits}
 
 Successful remote cache hits will show up in the status line, similar to
-[Cache Hits rate with Remote
-Execution](/versions/9.0.0/remote/cache-remote#check-cache-hits).
+[Cache Hits rate with Remote Execution](/versions/9.0.0/remote/cache-remote#check-cache-hits).
 
 In the standard output of your Bazel run, you will see something like the
 following:
@@ -66,8 +65,7 @@ the steps in this section.
    message you see does not give you enough information, try adding
    `--verbose_failures`.
 
-2. Follow the steps from [Troubleshooting cache hits for remote
-   execution](/versions/9.0.0/remote/cache-remote#troubleshooting_cache_hits) to
+2. Follow the steps from [Troubleshooting cache hits for remote execution](/versions/9.0.0/remote/cache-remote#troubleshooting_cache_hits) to
    ensure that your cache-writing Bazel invocations are able to get cache hits
    on the same machine and across machines.
 
@@ -81,7 +79,6 @@ the steps in this section.
    b. Ensure your cache-reading Bazel invocations build the same targets as the
       cache-writing Bazel invocations.
 
-   c. Follow the same steps as to [ensure caching across
-      machines](/versions/9.0.0/remote/cache-remote#caching-across-machines),
+   c. Follow the same steps as to [ensure caching across machines](/versions/9.0.0/remote/cache-remote#caching-across-machines),
       to ensure caching from your cache-writing Bazel invocation to your
       cache-reading Bazel invocation.
diff --git a/versions/9.0.0/remote/caching.mdx b/versions/9.0.0/remote/caching.mdx
index 78784ed6..033063c6 100644
--- a/versions/9.0.0/remote/caching.mdx
+++ b/versions/9.0.0/remote/caching.mdx
@@ -308,8 +308,7 @@ or for the age of individual cache entries. Bazel will automatically garbage
 collect the disk cache while idling between builds; the idle timer can be set
 with `--experimental_disk_cache_gc_idle_delay` (defaulting to 5 minutes).
 
-As an alternative to automatic garbage collection, we also provide a [tool](
-https://github.com/bazelbuild/bazel/tree/master/src/tools/diskcache) to run a
+As an alternative to automatic garbage collection, we also provide a [tool](https://github.com/bazelbuild/bazel/tree/master/src/tools/diskcache) to run a
 garbage collection on demand.
 
 ## Known issues {#known-issues}
diff --git a/versions/9.0.0/remote/dynamic.mdx b/versions/9.0.0/remote/dynamic.mdx
index 4db5dc16..f71ad8ba 100644
--- a/versions/9.0.0/remote/dynamic.mdx
+++ b/versions/9.0.0/remote/dynamic.mdx
@@ -12,8 +12,7 @@ alike.
 This page describes how to enable, tune, and debug dynamic execution. If you
 have both local and remote execution set up and are trying to adjust Bazel
 settings for better performance, this page is for you. If you don't already have
-remote execution set up, go to the Bazel [Remote Execution
-Overview](/versions/9.0.0/remote/rbe) first.
+remote execution set up, go to the Bazel [Remote Execution Overview](/versions/9.0.0/remote/rbe) first.
 
 ## Enabling dynamic execution? {#enabling-dynamic-execution}
 
@@ -44,14 +43,12 @@ are likely. The default value is 1000ms, but should be tuned to being just a bit
 longer than cache hits usually take. The actual time depends both on the remote
 system and on how long a round-trip takes. Usually, the value will be the same
 for all users of a given remote system, unless some of them are far enough away
-to add roundtrip latency. You can use the [Bazel profiling
-features](/versions/9.0.0/rules/performance#performance-profiling) to look at how long typical
+to add roundtrip latency. You can use the [Bazel profiling features](/versions/9.0.0/rules/performance#performance-profiling) to look at how long typical
 cache hits take.
 
 Dynamic execution can be used with local sandboxed strategy as well as with
 [persistent workers](/versions/9.0.0/remote/persistent). Persistent workers will automatically
-run with sandboxing when used with dynamic execution, and cannot use [multiplex
-workers](/versions/9.0.0/remote/multiplex). On Darwin and Windows systems, the sandboxed
+run with sandboxing when used with dynamic execution, and cannot use [multiplex workers](/versions/9.0.0/remote/multiplex). On Darwin and Windows systems, the sandboxed
 strategy can be slow; you can pass `--reuse_sandbox_directories` to reduce
 overhead of creating sandboxes on these systems.
 
@@ -67,8 +64,7 @@ entire action fails. This is an intentional choice to prevent differences
 between local and remote execution from going unnoticed.
 
 For more background on how dynamic execution and its locking works, see Julio
-Merino's excellent [blog
-posts](https://jmmv.dev/series/bazel-dynamic-execution/)
+Merino's excellent [blog posts](https://jmmv.dev/series/bazel-dynamic-execution/)
 
 ## When should I use dynamic execution? {#when-to-use}
 
diff --git a/versions/9.0.0/remote/persistent.mdx b/versions/9.0.0/remote/persistent.mdx
index 562b1abc..b2948364 100644
--- a/versions/9.0.0/remote/persistent.mdx
+++ b/versions/9.0.0/remote/persistent.mdx
@@ -257,7 +257,6 @@ For more information on persistent workers, see:
 *   [Original persistent workers blog post](https://blog.bazel.build/2015/12/10/java-workers.html)
 *   [Haskell implementation description](https://www.tweag.io/blog/2019-09-25-bazel-ghc-persistent-worker-internship/)
 *   [Blog post by Mike Morearty](https://medium.com/@mmorearty/how-to-create-a-persistent-worker-for-bazel-7738bba2cabb)
-*   [Front End Development with Bazel: Angular/TypeScript and Persistent Workers
-    w/ Asana](https://www.youtube.com/watch?v=0pgERydGyqo)
+*   [Front End Development with Bazel: Angular/TypeScript and Persistent Workers w/ Asana](https://www.youtube.com/watch?v=0pgERydGyqo)
 *   [Bazel strategies explained](https://jmmv.dev/2019/12/bazel-strategies.html)
 *   [Informative worker strategy discussion on the bazel-discuss mailing list](https://groups.google.com/forum/#!msg/bazel-discuss/oAEnuhYOPm8/ol7hf4KWJgAJ)
diff --git a/versions/9.0.0/remote/rules.mdx b/versions/9.0.0/remote/rules.mdx
index 98943b15..31e17392 100644
--- a/versions/9.0.0/remote/rules.mdx
+++ b/versions/9.0.0/remote/rules.mdx
@@ -54,8 +54,7 @@ variables that may not be set to equivalent values (or at all) in the remote
 execution environment.
 
 Toolchain rules currently exist for Bazel build and test rules for
-[Scala](https://github.com/bazelbuild/rules_scala/blob/master/scala/scala_toolch
-ain.bzl),
+[Scala](https://github.com/bazelbuild/rules_scala/blob/master/scala/scala_toolch ain.bzl),
 [Rust](https://github.com/bazelbuild/rules_rust/blob/main/rust/toolchain.bzl),
 and [Go](https://github.com/bazelbuild/rules_go/blob/master/go/toolchains.rst),
 and new toolchain rules are under way for other languages and tools such as
diff --git a/versions/9.0.0/remote/workspace.mdx b/versions/9.0.0/remote/workspace.mdx
index 4ecd4222..14caceb9 100644
--- a/versions/9.0.0/remote/workspace.mdx
+++ b/versions/9.0.0/remote/workspace.mdx
@@ -11,8 +11,7 @@ on the host machine. If your workspace rules access information about the
 host machine for use during execution, your build is likely to break due to
 incompatibilities between the environments.
 
-As part of [adapting Bazel rules for remote
-execution](/versions/9.0.0/remote/rules), you need to find such workspace rules
+As part of [adapting Bazel rules for remote execution](/versions/9.0.0/remote/rules), you need to find such workspace rules
 and fix them. This page describes how to find potentially problematic workspace
 rules using the workspace log.
 
diff --git a/versions/9.0.0/rules/language.mdx b/versions/9.0.0/rules/language.mdx
index 87553d18..d9807a28 100644
--- a/versions/9.0.0/rules/language.mdx
+++ b/versions/9.0.0/rules/language.mdx
@@ -107,10 +107,8 @@ values returned by rules are immutable.
 `BUILD` files register targets via making calls to rules. `.bzl` files provide
 definitions for constants, rules, macros, and functions.
 
-[Native functions](/versions/9.0.0/reference/be/functions) and [native rules](
-/reference/be/overview#language-specific-native-rules) are global symbols in
-`BUILD` files. `bzl` files need to load them using the [`native` module](
-/rules/lib/toplevel/native).
+[Native functions](/versions/9.0.0/reference/be/functions) and [native rules](/reference/be/overview#language-specific-native-rules) are global symbols in
+`BUILD` files. `bzl` files need to load them using the [`native` module](/rules/lib/toplevel/native).
 
 There are two syntactic restrictions in `BUILD` files: 1) declaring functions is
 illegal, and 2) `*args` and `**kwargs` arguments are not allowed.
diff --git a/versions/9.0.0/rules/legacy-macro-tutorial.mdx b/versions/9.0.0/rules/legacy-macro-tutorial.mdx
index 9280231d..0d6cba64 100644
--- a/versions/9.0.0/rules/legacy-macro-tutorial.mdx
+++ b/versions/9.0.0/rules/legacy-macro-tutorial.mdx
@@ -3,9 +3,7 @@ title: 'Creating a Legacy Macro'
 ---
 
 IMPORTANT: This tutorial is for [*legacy macros*](/versions/9.0.0/extending/legacy-macros). If
-you only need to support Bazel 8 or newer, we recommend using [symbolic
-macros](/versions/9.0.0/extending/macros) instead; take a look at [Creating a Symbolic
-Macro](macro-tutorial).
+you only need to support Bazel 8 or newer, we recommend using [symbolic macros](/versions/9.0.0/extending/macros) instead; take a look at [Creating a Symbolic Macro](macro-tutorial).
 
 Imagine that you need to run a tool as part of your build. For example, you
 may want to generate or preprocess a source file, or compress a binary. In this
diff --git a/versions/9.0.0/rules/verbs-tutorial.mdx b/versions/9.0.0/rules/verbs-tutorial.mdx
index 2d1f249a..ad10c473 100644
--- a/versions/9.0.0/rules/verbs-tutorial.mdx
+++ b/versions/9.0.0/rules/verbs-tutorial.mdx
@@ -49,8 +49,7 @@ This pattern can also be seen in the Angular project. The
 produces two targets. The first is a standard `nodejs_test` target which compares
 some generated output against a "golden" file (that is, a file containing the
 expected output). This can be built and run with a normal `bazel
-test` invocation. In `angular-cli`, you can run [one such
-target](https://github.com/angular/angular-cli/blob/e1269cb520871ee29b1a4eec6e6c0e4a94f0b5fc/etc/api/BUILD)
+test` invocation. In `angular-cli`, you can run [one such target](https://github.com/angular/angular-cli/blob/e1269cb520871ee29b1a4eec6e6c0e4a94f0b5fc/etc/api/BUILD)
 with `bazel test //etc/api:angular_devkit_core_api`.
 
 Over time, this golden file may need to be updated for legitimate reasons.
diff --git a/versions/9.0.0/run/build.mdx b/versions/9.0.0/run/build.mdx
index 76b4ce41..535cadeb 100644
--- a/versions/9.0.0/run/build.mdx
+++ b/versions/9.0.0/run/build.mdx
@@ -626,8 +626,7 @@ Note: Hermeticity means that the action only uses its declared input
 files and no other files in the filesystem, and it only produces its declared
 output files. See [Hermeticity](/versions/9.0.0/basics/hermeticity) for more details.
 
-On some platforms such as [Google Kubernetes
-Engine](https://cloud.google.com/kubernetes-engine/) cluster nodes or Debian,
+On some platforms such as [Google Kubernetes Engine](https://cloud.google.com/kubernetes-engine/) cluster nodes or Debian,
 user namespaces are deactivated by default due to security
 concerns. This can be checked by looking at the file
 `/proc/sys/kernel/unprivileged_userns_clone`: if it exists and contains a 0,
diff --git a/versions/9.0.0/start/android-app.mdx b/versions/9.0.0/start/android-app.mdx
index 4a2cea88..b1ab1f49 100644
--- a/versions/9.0.0/start/android-app.mdx
+++ b/versions/9.0.0/start/android-app.mdx
@@ -39,8 +39,7 @@ In this tutorial you learn how to:
 Before you begin the tutorial, install the following software:
 
 * **Bazel.** To install, follow the [installation instructions](/versions/9.0.0/install).
-* **Android Studio.** To install, follow the steps to [download Android
-  Studio](https://developer.android.com/sdk/index.html).
+* **Android Studio.** To install, follow the steps to [download Android Studio](https://developer.android.com/sdk/index.html).
   Execute the setup wizard to download the SDK and configure your environment.
 * (Optional) **Git.** Use `git` to download the Android app project.
 
@@ -55,8 +54,7 @@ This app has a single button that prints a greeting when clicked:
 
 **Figure 1.** Android app button greeting.
 
-Clone the repository with `git` (or [download the ZIP file
-directly](https://github.com/bazelbuild/examples/archive/master.zip)):
+Clone the repository with `git` (or [download the ZIP file directly](https://github.com/bazelbuild/examples/archive/master.zip)):
 
 ```posix-terminal
 git clone https://github.com/bazelbuild/examples
@@ -106,8 +104,7 @@ A [workspace](/versions/9.0.0/concepts/build-ref#workspace) is a directory that
 source files for one or more software projects, and has a `MODULE.bazel` file at
 its root.
 
-The `MODULE.bazel` file may be empty or may contain references to [external
-dependencies](/versions/9.0.0/external/overview) required to build your project.
+The `MODULE.bazel` file may be empty or may contain references to [external dependencies](/versions/9.0.0/external/overview) required to build your project.
 
 First, run the following command to create an empty `MODULE.bazel` file:
 
@@ -158,8 +155,7 @@ environment variable, and automatically detect the highest API level and the
 latest version of build tools installed within that location.
 
 You can set the `ANDROID_HOME` variable to the location of the Android SDK. Find
-the path to the installed SDK using Android Studio's [SDK
-Manager](https://developer.android.com/studio/intro/update#sdk-manager).
+the path to the installed SDK using Android Studio's [SDK Manager](https://developer.android.com/studio/intro/update#sdk-manager).
 Assuming the SDK is installed to default locations, you can use the following
 commands to set the `ANDROID_HOME` variable:
 
@@ -181,16 +177,14 @@ them permanent, run the following commands:
 | Windows (PowerShell)     | `[System.Environment]::SetEnvironmentVariable('ANDROID_HOME', "$env:LOCALAPPDATA\Android\Sdk", [System.EnvironmentVariableTarget]::User)` |
 
 **Optional:** If you want to compile native code into your Android app, you
-also need to download the [Android
-NDK](https://developer.android.com/ndk/downloads/index.html)
+also need to download the [Android NDK](https://developer.android.com/ndk/downloads/index.html)
 and use `rules_android_ndk` by adding the following line to your `MODULE.bazel` file:
 
 ```python
 bazel_dep(name = "rules_android_ndk", version = "0.1.3")
 ```
 
-For more information, read [Using the Android Native Development Kit with
-Bazel](/versions/9.0.0/docs/android-ndk).
+For more information, read [Using the Android Native Development Kit with Bazel](/versions/9.0.0/docs/android-ndk).
 
 It's not necessary to set the API levels to the same value for the SDK and NDK.
 [This page](https://developer.android.com/ndk/guides/stable_apis.html)
@@ -232,8 +226,7 @@ files or other dependencies. Bazel provides two build rules,
 build an Android app.
 
 For this tutorial, you'll first use the
-`android_library` rule to tell Bazel to build an [Android library
-module](http://developer.android.com/tools/projects/index.html#LibraryProjects)
+`android_library` rule to tell Bazel to build an [Android library module](http://developer.android.com/tools/projects/index.html#LibraryProjects)
 from the app source code and resource files. You'll then use the
 `android_binary` rule to tell Bazel how to build the Android application package.
 
diff --git a/versions/9.0.0/start/cpp.mdx b/versions/9.0.0/start/cpp.mdx
index 7c0dee96..e6b4e1b0 100644
--- a/versions/9.0.0/start/cpp.mdx
+++ b/versions/9.0.0/start/cpp.mdx
@@ -19,8 +19,7 @@ Estimated completion time: 30 minutes.
 ### Prerequisites {#prerequisites}
 
 Start by [installing Bazel](https://bazel.build/versions/9.0.0/install), if you haven't
-already. This tutorial uses Git for source control, so for best results [install
-Git](https://git-scm.com/book/en/v2/Getting-Started-Installing-Git) as well.
+already. This tutorial uses Git for source control, so for best results [install Git](https://git-scm.com/book/en/v2/Getting-Started-Installing-Git) as well.
 
 Next, retrieve the sample project from Bazel's GitHub repository by running the
 following in your command-line tool of choice:
@@ -63,9 +62,7 @@ examples
 ```
 
 There are three sets of files, each set representing a stage in this tutorial.
-In the first stage, you will build a single [target]
-(https://bazel.build/reference/glossary#target) residing in a single [package]
-(https://bazel.build/reference/glossary#package). In the second stage, you will
+In the first stage, you will build a single [target](https://bazel.build/reference/glossary#target) residing in a single [package](https://bazel.build/reference/glossary#package). In the second stage, you will
 build both a binary and a library from a single package. In the third and final
 stage, you will build a project with multiple packages and build it with
 multiple targets.
@@ -86,8 +83,7 @@ It also contains these significant files:
 *   The `MODULE.bazel` file, which identifies the directory and its contents as
     a Bazel workspace and lives at the root of the project's directory
     structure. It's also where you specify your external dependencies.
-*   One or more [`BUILD`
-    files](https://bazel.build/reference/glossary#build-file), which tell Bazel
+*   One or more [`BUILD` files](https://bazel.build/reference/glossary#build-file), which tell Bazel
     how to build different parts of the project. A directory within the
     workspace that contains a `BUILD` file is a
     [package](https://bazel.build/versions/9.0.0/reference/glossary#package). (More on packages
@@ -182,9 +178,7 @@ This results in a printed "`Hello world`" message.
 
 Here's the dependency graph of Stage 1:
 
-![Dependency graph for hello-world displays a single target with a single source
-file.](/versions/9.0.0/docs/images/cpp-tutorial-stage1.png "Dependency graph for hello-world
-displays a single target with a single source file.")
+![Dependency graph for hello-world displays a single target with a single source file.](/versions/9.0.0/docs/images/cpp-tutorial-stage1.png "Dependency graph for hello-world displays a single target with a single source file.")
 
 ### Summary: stage 1 {#summary-stage-1}
 
@@ -231,8 +225,7 @@ cc_binary(
 ```
 
 With this `BUILD` file, Bazel first builds the `hello-greet` library (using
-Bazel's built-in [`cc_library`
-rule](https://bazel.build/reference/be/c-cpp#cc_library)), then the
+Bazel's built-in [`cc_library` rule](https://bazel.build/reference/be/c-cpp#cc_library)), then the
 `hello-world` binary. The `deps` attribute in the `hello-world` target tells
 Bazel that the `hello-greet` library is required to build the `hello-world`
 binary.
@@ -272,10 +265,7 @@ recompiles that file.
 Looking at the dependency graph, you can see that `hello-world` depends on an
 extra input named `hello-greet`:
 
-![Dependency graph for `hello-world` displays dependency changes after
-modification to the file.](/versions/9.0.0/docs/images/cpp-tutorial-stage2.png "Dependency
-graph for `hello-world` displays dependency changes after modification to the
-file.")
+![Dependency graph for `hello-world` displays dependency changes after modification to the file.](/versions/9.0.0/docs/images/cpp-tutorial-stage2.png "Dependency graph for `hello-world` displays dependency changes after modification to the file.")
 
 ### Summary: stage 2 {#summary-stage-2}
 
@@ -343,11 +333,7 @@ in the `lib` package (hence the target label `//lib:hello-time`) - Bazel knows
 this through the `deps` attribute. You can see this reflected in the dependency
 graph:
 
-![Dependency graph for `hello-world` displays how the target in the main package
-depends on the target in the `lib`
-package.](/versions/9.0.0/docs/images/cpp-tutorial-stage3.png "Dependency graph for
-`hello-world` displays how the target in the main package depends on the target
-in the `lib` package.")
+![Dependency graph for `hello-world` displays how the target in the main package depends on the target in the `lib` package.](/versions/9.0.0/docs/images/cpp-tutorial-stage3.png "Dependency graph for `hello-world` displays how the target in the main package depends on the target in the `lib` package.")
 
 For the build to succeed, you make the `//lib:hello-time` target in `lib/BUILD`
 explicitly visible to targets in `main/BUILD` using the visibility attribute.
@@ -395,15 +381,11 @@ Bazel journey.
 You've now completed your first basic build with Bazel, but this is just the
 start. Here are some more resources to continue learning with Bazel:
 
-*   To keep focusing on C++, read about common [C++ build use
-    cases](https://bazel.build/tutorials/cpp-use-cases).
+*   To keep focusing on C++, read about common [C++ build use cases](https://bazel.build/tutorials/cpp-use-cases).
 *   To get started with building other applications with Bazel, see the
-    tutorials for [Java](https://bazel.build/versions/9.0.0/start/java), [Android
-    application](https://bazel.build/start/android-app), or [iOS
-    application](https://bazel.build/start/ios-app).
+    tutorials for [Java](https://bazel.build/versions/9.0.0/start/java), [Android application](https://bazel.build/start/android-app), or [iOS application](https://bazel.build/start/ios-app).
 *   To learn more about working with local and remote repositories, read about
     [external dependencies](https://bazel.build/versions/9.0.0/docs/external).
-*   To learn more about Bazel's other rules, see this [reference
-    guide](https://bazel.build/rules).
+*   To learn more about Bazel's other rules, see this [reference guide](https://bazel.build/rules).
 
 Happy building!
\ No newline at end of file
diff --git a/versions/9.0.0/start/go.mdx b/versions/9.0.0/start/go.mdx
index 54c9eb72..83f6517d 100644
--- a/versions/9.0.0/start/go.mdx
+++ b/versions/9.0.0/start/go.mdx
@@ -32,8 +32,7 @@ You can check if Go is installed by running `go version` in any directory.
 
 ### Get the sample project {#get-sample}
 
-The Bazel examples are stored in a Git repository, so you'll need to [install
-Git](https://git-scm.com/book/en/v2/Getting-Started-Installing-Git) if you
+The Bazel examples are stored in a Git repository, so you'll need to [install Git](https://git-scm.com/book/en/v2/Getting-Started-Installing-Git) if you
 haven't already. To download the examples repository, run this command:
 
 ```posix-terminal
@@ -171,10 +170,8 @@ rule. Each rule defines [actions](https://bazel.build/versions/9.0.0/reference/g
 Go compile and link actions that produce an executable output file.
 
 Bazel has built-in rules for a few languages like Java and C++. You can find
-their [documentation in the Build
-Encyclopedia](https://bazel.build/reference/be/overview#rules). You can find
-rule sets for many other languages and tools on the [Bazel Central Registry
-(BCR)](https://registry.bazel.build/).
+their [documentation in the Build Encyclopedia](https://bazel.build/reference/be/overview#rules). You can find
+rule sets for many other languages and tools on the [Bazel Central Registry (BCR)](https://registry.bazel.build/).
 
 ## Add a library {#add-library}
 
@@ -448,11 +445,9 @@ learned some core Bazel concepts along the way.
     languages.
 -   For more information on Go, see the
     [rules_go](https://github.com/bazel-contrib/rules_go) module, especially the
-    [Core Go
-    rules](https://github.com/bazel-contrib/rules_go/blob/master/docs/go/core/rules.md)
+    [Core Go rules](https://github.com/bazel-contrib/rules_go/blob/master/docs/go/core/rules.md)
     documentation.
 -   To learn more about working with Bazel modules outside your project, see
     [external dependencies](/versions/9.0.0/docs/external). In particular, for information on
     how to depend on Go modules and toolchains through Bazel's module system,
-    see [Go with
-    bzlmod](https://github.com/bazel-contrib/rules_go/tree/master/docs/go/core/bzlmod.md).
\ No newline at end of file
+    see [Go with bzlmod](https://github.com/bazel-contrib/rules_go/tree/master/docs/go/core/bzlmod.md).
\ No newline at end of file
diff --git a/versions/9.0.0/start/java.mdx b/versions/9.0.0/start/java.mdx
index b5f23c27..d69caf7c 100644
--- a/versions/9.0.0/start/java.mdx
+++ b/versions/9.0.0/start/java.mdx
@@ -241,8 +241,7 @@ recompiles that file.
 Looking at the dependency graph, you can see that `ProjectRunner` depends on the
 same inputs as it did before, but the structure of the build is different:
 
-![Dependency graph of the target 'ProjectRunner' after adding a dependency](
-/docs/images/tutorial_java_02.svg)
+![Dependency graph of the target 'ProjectRunner' after adding a dependency](/docs/images/tutorial_java_02.svg)
 
 You've now built the project with two targets. The `ProjectRunner` target builds
 one source files and depends on one other target (`:greeter`), which builds
diff --git a/versions/9.0.0/tutorials/ccp-toolchain-config.mdx b/versions/9.0.0/tutorials/ccp-toolchain-config.mdx
index 14b05139..ab6af21f 100644
--- a/versions/9.0.0/tutorials/ccp-toolchain-config.mdx
+++ b/versions/9.0.0/tutorials/ccp-toolchain-config.mdx
@@ -29,8 +29,7 @@ uses `clang version 19`, which you can install on your system.
 
 Set up your build environment as follows:
 
-1.  If you have not already done so, [download and install Bazel
-    7.0.2](https://bazel.build/install) or later.
+1.  If you have not already done so, [download and install Bazel 7.0.2](https://bazel.build/install) or later.
 
 2.  Add an empty `MODULE.bazel` file at the root folder.
 
@@ -454,8 +453,7 @@ The key takeaways are:
 
 -   You need to specify a matching `platforms` flag in the command line for
     Bazel to resolve to the toolchain for the same constraint values on the
-    platform. The documentation holds more [information about language specific
-    configuration flags](/versions/9.0.0/concepts/platforms).
+    platform. The documentation holds more [information about language specific configuration flags](/versions/9.0.0/concepts/platforms).
 -   You have to let the toolchain know where the tools live. In this tutorial
     there is a simplified version where you access the tools from the system. If
     you are interested in a more self-contained approach, you can read about
@@ -468,5 +466,4 @@ The key takeaways are:
 
 ## Further reading {#further-reading}
 
-For more details, see [C++ toolchain
-configuration](/versions/9.0.0/docs/cc-toolchain-config-reference)
+For more details, see [C++ toolchain configuration](/versions/9.0.0/docs/cc-toolchain-config-reference)