docs(v2): use explicit heading IDs (#4460)

website/docs/guides/docs/docs-introduction.md

@@ -7,7 +7,7 @@ slug: /docs-introduction
 
 The docs feature provides users with a way to organize Markdown files in a hierarchical format.
 
-## Document ID
+## Document ID {#document-id}
 
 Every document has a unique `id`. By default, a document `id` is the name of the document (without the extension) relative to the root docs directory.
 
@@ -49,7 +49,7 @@ It is possible to use:
 
 :::
 
-## Home page docs
+## Home page docs {#home-page-docs}
 
 If you want a document to be available at the root, and have a path like `https://v2.docusaurus.io/docs/`, you can use the slug frontmatter:
 
@@ -61,7 +61,7 @@ slug: /
 Lorem ipsum
 ```
 
-## Docs-only mode
+## Docs-only mode {#docs-only-mode}
 
 If you only want the documentation feature, you can run your Docusaurus 2 site without a landing page and display your documentation page as the index page instead.
 

website/docs/guides/docs/docs-markdown-features.mdx

@@ -7,11 +7,11 @@ slug: /docs-markdown-features
 
 Docs can use any [Markdown feature](../markdown-features/markdown-features-intro.mdx), and have a few additional Docs-specific markdown features.
 
-## Markdown frontmatter
+## Markdown frontmatter {#markdown-frontmatter}
 
 Markdown docs have their own [Markdown frontmatter](../../api/plugins/plugin-content-docs.md#markdown-frontmatter)
 
-## Referencing other documents
+## Referencing other documents {#referencing-other-documents}
 
 If you want to reference another document file, you could use the name of the document you want to reference. Docusaurus will convert the file path to be the final website path (and remove the `.md`).
 

website/docs/guides/docs/docs-multi-instance.mdx

@@ -13,13 +13,13 @@ This feature is only useful for [versioned documentations](./versioning.md). It
 
 :::
 
-## Use-cases
+## Use-cases {#use-cases}
 
 Sometimes you want a Docusaurus site to host 2 distinct sets of documentation (or more).
 
 These documentations may even have different versioning/release lifecycles.
 
-### Mobile SDKs documentation
+### Mobile SDKs documentation {#mobile-sdks-documentation}
 
 If you build a cross-platform mobile SDK, you may have 2 documentations:
 
@@ -36,7 +36,7 @@ If someone edits the iOS documentation, is it really useful to rebuild everythin
 
 :::
 
-### Versioned and unversioned doc
+### Versioned and unversioned doc {#versioned-and-unversioned-doc}
 
 Sometimes, you want some documents to be versioned, while other documents are more "global", and it feels useless to version them.
 
@@ -45,7 +45,7 @@ We use this pattern on the Docusaurus website itself:
 - The [/docs/\*](/docs) section is versioned
 - The [/community/\*](/community/support) section is unversioned
 
-## Setup
+## Setup {#setup}
 
 Let's consider we 2 documentations:
 
@@ -138,7 +138,7 @@ We consider that the `product` instance is the most important one, and make it t
 
 :::
 
-## Versioned paths
+## Versioned paths {#versioned-paths}
 
 Each instance will store versioned docs in a distinct folder.
 
@@ -162,7 +162,7 @@ The instance paths will be simpler, and retro-compatible with a single-instance
 
 :::
 
-## Tagging new versions
+## Tagging new versions {#tagging-new-versions}
 
 Each plugin instance will have its own cli command to tag a new version. They will be displayed if you run:
 
@@ -182,7 +182,7 @@ To version the non-default/community docs plugin instance:
 npm run docusaurus docs:version:community 1.0.0
 ```
 
-## Docs navbar items
+## Docs navbar items {#docs-navbar-items}
 
 Each docs-related [theme navbar items](../../api/themes/theme-configuration.md#navbar) take an optional `docsPluginId` attribute.
 

website/docs/guides/docs/sidebar.md

@@ -27,7 +27,7 @@ module.exports = {
 };
 ```
 
-## Sidebar object
+## Sidebar object {#sidebar-object}
 
 A sidebar object contains [sidebar items](#understanding-sidebar-items) and it is defined like this:
 
@@ -83,7 +83,7 @@ Shorthand notation relies on the iteration order of JavaScript object keys for t
 
 :::
 
-## Using multiple sidebars
+## Using multiple sidebars {#using-multiple-sidebars}
 
 You can have multiple sidebars for different Markdown files by adding more top-level keys to the exported object.
 
@@ -107,7 +107,7 @@ For example, with the above example, when displaying the `doc2` page, the sideba
 
 For more information about sidebars and how they relate to doc pages, see [Navbar doc link](../../api/themes/theme-configuration.md#navbar-doc-link).
 
-## Understanding sidebar items
+## Understanding sidebar items {#understanding-sidebar-items}
 
 As the name implies, `SidebarItem` is an item defined in a Sidebar. A SidebarItem as a `type` that defines what the item links to.
 
@@ -118,7 +118,7 @@ As the name implies, `SidebarItem` is an item defined in a Sidebar. A SidebarIte
 - [Ref](#creating-a-link-to-page-without-sidebar)
 - [Category](#creating-a-hierarchy)
 
-### Linking to a doc page
+### Linking to a doc page {#linking-to-a-doc-page}
 
 Set `type` to `doc` to link to a documentation page. This is the default type.
 
@@ -163,7 +163,7 @@ module.exports = {
 };
 ```
 
-### Creating a generic link
+### Creating a generic link {#creating-a-generic-link}
 
 Set `type` to `link` to link to a non-documentation page. For example, to create an external link.
 
@@ -185,7 +185,7 @@ Example:
 }
 ```
 
-### Creating a link to page without sidebar
+### Creating a link to page without sidebar {#creating-a-link-to-page-without-sidebar}
 
 Set `type` to `ref` to link to a documentation page without binding it to a sidebar. This means the sidebar disappears when the user displays the linked page.
 
@@ -205,7 +205,7 @@ Example:
 }
 ```
 
-### Creating a hierarchy
+### Creating a hierarchy {#creating-a-hierarchy}
 
 The Sidebar item type that creates a hierarchy in the sidebar. Set `type` to `category`.
 
@@ -260,7 +260,7 @@ module.exports = {
 };
 ```
 
-#### Collapsible categories
+#### Collapsible categories {#collapsible-categories}
 
 For sites with a sizable amount of content, we support the option to expand/collapse a category to toggle the display of its contents. Categories are collapsible by default. If you want them to be always expanded, set `themeConfig.sidebarCollapsible` to `false`:
 
@@ -274,7 +274,7 @@ module.exports = {
 };
 ```
 
-#### Expanded categories by default
+#### Expanded categories by default {#expanded-categories-by-default}
 
 For docs that have collapsible categories, you may want more fine-grain control over certain categories. If you want specific categories to be always expanded, you can set `collapsed` to `false`:
 
@@ -294,7 +294,7 @@ module.exports = {
 };
 ```
 
-## Hideable sidebar
+## Hideable sidebar {#hideable-sidebar}
 
 Using the enabled `themeConfig.hideableSidebar` option, you can make the entire sidebar hidden, allowing you to better focus your users on the content. This is especially useful when content consumption on medium screens (e.g. on tablets).
 
@@ -308,7 +308,7 @@ module.exports = {
 };
 ```
 
-## Passing custom props
+## Passing custom props {#passing-custom-props}
 
 To pass in custom props to a swizzled sidebar item, add the optional `customProps` object to any of the items:
 

website/docs/guides/docs/versioning.md

@@ -16,7 +16,7 @@ Most of the time, you don't need versioning as it will just increase your build
 
 To better understand how versioning works and see if it suits your needs, you can read on below.
 
-## Directory structure
+## Directory structure {#directory-structure}
 
 ```shell
 website
@@ -50,7 +50,7 @@ The table below explains how a versioned file maps to its version and the genera
 | `versioned_docs/version-1.1.0/hello.md` | 1.1.0 (latest) | /docs/hello       |
 | `docs/hello.md`                         | next           | /docs/next/hello  |
 
-### Tagging a new version
+### Tagging a new version {#tagging-a-new-version}
 
 1. First, make sure your content in the `docs` directory is ready to be frozen as a version. A version always should be based from master.
 1. Enter a new version number.
@@ -65,9 +65,9 @@ When tagging a new version, the document versioning mechanism will:
 - Create a versioned sidebars file based from your current [sidebar](docs-introduction.md#sidebar) configuration (if it exists) - saved as `versioned_sidebars/version-<version>-sidebars.json`.
 - Append the new version number to `versions.json`.
 
-## Docs
+## Docs {#docs}
 
-### Creating new docs
+### Creating new docs {#creating-new-docs}
 
 1. Place the new file into the corresponding version folder.
 1. Include the reference for the new file into the corresponding sidebar file, according to version number.
@@ -92,7 +92,7 @@ versioned_docs/version-1.0.0/new.md
 versioned_sidebars/version-1.0.0-sidebars.json
 ```
 
-### Linking docs
+### Linking docs {#linking-docs}
 
 - Remember to include the `.md` extension.
 - Files will be linked to correct corresponding version.
@@ -104,11 +104,11 @@ The [@hello](hello.md#paginate) document is great!
 See the [Tutorial](../getting-started/tutorial.md) for more info.
 ```
 
-## Versions
+## Versions {#versions}
 
 Each directory in `versioned_docs/` will represent a documentation version.
 
-### Updating an existing version
+### Updating an existing version {#updating-an-existing-version}
 
 You can update multiple docs versions at the same time because each directory in `versioned_docs/` represents specific routes when published.
 
@@ -118,7 +118,7 @@ You can update multiple docs versions at the same time because each directory in
 
 Example: When you change any file in `versioned_docs/version-2.6/`, it will only affect the docs for version `2.6`.
 
-### Deleting an existing version
+### Deleting an existing version {#deleting-an-existing-version}
 
 You can delete/remove versions as well.
 
@@ -137,9 +137,9 @@ Example:
 2. Delete the versioned docs directory. Example: `versioned_docs/version-1.8.0`.
 3. Delete the versioned sidebars file. Example: `versioned_sidebars/version-1.8.0-sidebars.json`.
 
-## Recommended practices
+## Recommended practices {#recommended-practices}
 
-### Figure out the behavior for the "current" version
+### Figure out the behavior for the "current" version {#figure-out-the-behavior-for-the-current-version}
 
 The "current" version is the version name for the `./docs` folder.
 
@@ -168,17 +168,17 @@ The docs in `./docs` will be served at `/docs/1.0.0` instead of `/docs/next`, an
 
 See [docs plugin configuration](../../api/plugins/plugin-content-docs.md) for more details.
 
-### Version your documentation only when needed
+### Version your documentation only when needed {#version-your-documentation-only-when-needed}
 
 For example, you are building a documentation for your npm package `foo` and you are currently in version 1.0.0. You then release a patch version for a minor bug fix and it's now 1.0.1.
 
 Should you cut a new documentation version 1.0.1? **You probably shouldn't**. 1.0.1 and 1.0.0 docs shouldn't differ according to semver because there are no new features!. Cutting a new version for it will only just create unnecessary duplicated files.
 
-### Keep the number of versions small
+### Keep the number of versions small {#keep-the-number-of-versions-small}
 
 As a good rule of thumb, try to keep the number of your versions below 10. **It is very likely** that you will have a lot of obsolete versioned documentation that nobody even reads anymore. For example, [Jest](https://jestjs.io/versions) is currently in version `24.9`, and only maintains several latest documentation version with the lowest being `22.X`. Keep it small 😊
 
-### Use absolute import within the docs
+### Use absolute import within the docs {#use-absolute-import-within-the-docs}
 
 Don't use relative paths import within the docs. Because when we cut a version the paths no longer work (the nesting level is different, among other reasons). You can utilize the `@site` alias provided by docusaurus, that points to the `website` directory. Example:
 
@@ -187,7 +187,7 @@ Don't use relative paths import within the docs. Because when we cut a version t
 + import Foo from '@site/src/components/Foo';
 ```
 
-### Global or versioned colocated assets
+### Global or versioned colocated assets {#global-or-versioned-colocated-assets}
 
 You should decide if assets like images and files are per version or shared between versions