docs(website): use .mdx extension for every docs (#8490)

website/docs/advanced/architecture.mdx

@@ -25,4 +25,4 @@ Although you (either plugin authors or site creators) are writing JavaScript all
 
 Plugin code and theme code never directly import each other: they only communicate through protocols (in our case, through JSON temp files and calls to `addRoute`). A useful mental model is to imagine that the plugins are not written in JavaScript, but in another language like Rust. The only way to interact with plugins for the user is through `docusaurus.config.js`, which itself is run in Node (hence you can use `require` and pass callbacks as plugin options).
 
-During bundling, the config file itself is serialized and bundled, allowing the theme to access config options like `themeConfig` or `baseUrl` through [`useDocusaurusContext()`](../docusaurus-core.md#useDocusaurusContext). However, the `siteConfig` object only contains **serializable values** (values that are preserved after `JSON.stringify()`). Functions, regexes, etc. would be lost on the client side. The `themeConfig` is designed to be entirely serializable.
+During bundling, the config file itself is serialized and bundled, allowing the theme to access config options like `themeConfig` or `baseUrl` through [`useDocusaurusContext()`](../docusaurus-core.mdx#useDocusaurusContext). However, the `siteConfig` object only contains **serializable values** (values that are preserved after `JSON.stringify()`). Functions, regexes, etc. would be lost on the client side. The `themeConfig` is designed to be entirely serializable.

website/docs/advanced/client.mdx

@@ -91,9 +91,9 @@ These modules are imported globally before React even renders the initial UI.
 import '@generated/client-modules';
 ```
 
-Plugins and sites can both declare client modules, through [`getClientModules`](../api/plugin-methods/lifecycle-apis.md#getClientModules) and [`siteConfig.clientModules`](../api/docusaurus.config.js.md#clientModules), respectively.
+Plugins and sites can both declare client modules, through [`getClientModules`](../api/plugin-methods/lifecycle-apis.mdx#getClientModules) and [`siteConfig.clientModules`](../api/docusaurus.config.js.mdx#clientModules), respectively.
 
-Client modules are called during server-side rendering as well, so remember to check the [execution environment](./ssg.md#escape-hatches) before accessing client-side globals.
+Client modules are called during server-side rendering as well, so remember to check the [execution environment](./ssg.mdx#escape-hatches) before accessing client-side globals.
 
 ```js title="mySiteGlobalJs.js"
 import ExecutionEnvironment from '@docusaurus/ExecutionEnvironment';
@@ -108,7 +108,7 @@ if (ExecutionEnvironment.canUseDOM) {
 }
 ```
 
-CSS stylesheets imported as client modules are [global](../styling-layout.md#global-styles).
+CSS stylesheets imported as client modules are [global](../styling-layout.mdx#global-styles).
 
 ```css title="mySiteGlobalCss.css"
 /* This stylesheet is global. */
@@ -181,6 +181,6 @@ Both lifecycles will fire on first render, but they will not fire on server-side
 
 :::tip Prefer using React
 
-Client module lifecycles are purely imperative, and you can't use React hooks or access React contexts within them. If your operations are state-driven or involve complicated DOM manipulations, you should consider [swizzling components](../swizzling.md) instead.
+Client module lifecycles are purely imperative, and you can't use React hooks or access React contexts within them. If your operations are state-driven or involve complicated DOM manipulations, you should consider [swizzling components](../swizzling.mdx) instead.
 
 :::

website/docs/advanced/index.mdx

@@ -8,4 +8,4 @@ import DocCardList from '@theme/DocCardList';
 <DocCardList />
 ```
 
-We will assume that you have finished the guides, and know the basics like how to configure plugins, how to write React components, etc. These sections will have plugin authors and code contributors in mind, so we may occasionally refer to [plugin APIs](../api/plugin-methods/README.md) or other architecture details. Don't panic if you don't understand everything😉
+We will assume that you have finished the guides, and know the basics like how to configure plugins, how to write React components, etc. These sections will have plugin authors and code contributors in mind, so we may occasionally refer to [plugin APIs](../api/plugin-methods/README.mdx) or other architecture details. Don't panic if you don't understand everything😉

website/docs/advanced/plugins.mdx

@@ -4,7 +4,7 @@ Plugins are the building blocks of features in a Docusaurus 2 site. Each plugin
 
 ## Creating plugins {#creating-plugins}
 
-A plugin is a function that takes two parameters: `context` and `options`. It returns a plugin instance object (or a promise). You can create plugins as functions or modules. For more information, refer to the [plugin method references section](../api/plugin-methods/README.md).
+A plugin is a function that takes two parameters: `context` and `options`. It returns a plugin instance object (or a promise). You can create plugins as functions or modules. For more information, refer to the [plugin method references section](../api/plugin-methods/README.mdx).
 
 ### Function definition {#function-definition}
 
@@ -86,7 +86,7 @@ Docusaurus' implementation of the plugins system provides us with a convenient w
 
 ### Theme design {#theme-design}
 
-When plugins have loaded their content, the data is made available to the client side through actions like [`createData` + `addRoute`](../api/plugin-methods/lifecycle-apis.md#addRoute) or [`setGlobalData`](../api/plugin-methods/lifecycle-apis.md#setGlobalData). This data has to be _serialized_ to plain strings, because [plugins and themes run in different environments](./architecture.md). Once the data arrives on the client side, the rest becomes familiar to React developers: data is passed along components, components are bundled with Webpack, and rendered to the window through `ReactDOM.render`...
+When plugins have loaded their content, the data is made available to the client side through actions like [`createData` + `addRoute`](../api/plugin-methods/lifecycle-apis.mdx#addRoute) or [`setGlobalData`](../api/plugin-methods/lifecycle-apis.mdx#setGlobalData). This data has to be _serialized_ to plain strings, because [plugins and themes run in different environments](./architecture.mdx). Once the data arrives on the client side, the rest becomes familiar to React developers: data is passed along components, components are bundled with Webpack, and rendered to the window through `ReactDOM.render`...
 
 **Themes provide the set of UI components to render the content.** Most content plugins need to be paired with a theme in order to be actually useful. The UI is a separate layer from the data schema, which makes swapping designs easy.
 
@@ -120,7 +120,7 @@ Now, although the theme receives the same data from the plugin, how the theme ch
 
 While themes share the exact same lifecycle methods with plugins, themes' implementations can look very different from those of plugins based on themes' designed objectives.
 
-Themes are designed to complete the build of your Docusaurus site and supply the components used by your site, plugins, and the themes themselves. A theme still acts like a plugin and exposes some lifecycle methods, but most likely they would not use [`loadContent`](../api/plugin-methods/lifecycle-apis.md#loadContent), since they only receive data from plugins, but don't generate data themselves; themes are typically also accompanied by an `src/theme` directory full of components, which are made known to the core through the [`getThemePath`](../api/plugin-methods/extend-infrastructure.md#getThemePath) lifecycle.
+Themes are designed to complete the build of your Docusaurus site and supply the components used by your site, plugins, and the themes themselves. A theme still acts like a plugin and exposes some lifecycle methods, but most likely they would not use [`loadContent`](../api/plugin-methods/lifecycle-apis.mdx#loadContent), since they only receive data from plugins, but don't generate data themselves; themes are typically also accompanied by an `src/theme` directory full of components, which are made known to the core through the [`getThemePath`](../api/plugin-methods/extend-infrastructure.mdx#getThemePath) lifecycle.
 
 To summarize:
 

website/docs/advanced/routing.mdx

@@ -38,13 +38,13 @@ graph LR;
 
 Any route will be matched against this nested route config until a good match is found. For example, when given a route `/docs/configuration`, Docusaurus first enters the `/docs` branch, and then searches among the subroutes created by the docs plugin.
 
-Changing `routeBasePath` can effectively alter your site's route structure. For example, in [Docs-only mode](../guides/docs/docs-introduction.md#docs-only-mode), we mentioned that configuring `routeBasePath: '/'` for docs means that all routes that the docs plugin create would not have the `/docs` prefix, yet it doesn't prevent you from having more subroutes like `/blog` created by other plugins.
+Changing `routeBasePath` can effectively alter your site's route structure. For example, in [Docs-only mode](../guides/docs/docs-introduction.mdx#docs-only-mode), we mentioned that configuring `routeBasePath: '/'` for docs means that all routes that the docs plugin create would not have the `/docs` prefix, yet it doesn't prevent you from having more subroutes like `/blog` created by other plugins.
 
 Next, let's look at how the three plugins structure their own "boxes of subroutes".
 
 ### Pages routing {#pages-routing}
 
-Pages routing are straightforward: the file paths directly map to URLs, without any other way to customize. See the [pages docs](../guides/creating-pages.md#routing) for more information.
+Pages routing are straightforward: the file paths directly map to URLs, without any other way to customize. See the [pages docs](../guides/creating-pages.mdx#routing) for more information.
 
 The component used for Markdown pages is `@theme/MDXPage`. React pages are directly used as the route's component.
 
@@ -71,7 +71,7 @@ The blog creates the following routes:
 
 ### Docs routing {#docs-routing}
 
-The docs is the only plugin that creates **nested routes**. At the top, it registers [**version paths**](../guides/docs/versioning.md): `/`, `/next`, `/2.0.0-beta.13`... which provide the version context, including the layout and sidebar. This ensures that when switching between individual docs, the sidebar's state is preserved, and that you can switch between versions through the navbar dropdown while staying on the same doc. The component used is `@theme/DocPage`.
+The docs is the only plugin that creates **nested routes**. At the top, it registers [**version paths**](../guides/docs/versioning.mdx): `/`, `/next`, `/2.0.0-beta.13`... which provide the version context, including the layout and sidebar. This ensures that when switching between individual docs, the sidebar's state is preserved, and that you can switch between versions through the navbar dropdown while staying on the same doc. The component used is `@theme/DocPage`.
 
 ```mdx-code-block
 export const URLPath = () => <code>{useLocation().pathname}</code>;
@@ -221,7 +221,7 @@ Localized sites have the locale as part of the base URL as well. For example, `h
 
 ## Generating and accessing routes {#generating-and-accessing-routes}
 
-The `addRoute` lifecycle action is used to generate routes. It registers a piece of route config to the route tree, giving a route, a component, and props that the component needs. The props and the component are both provided as paths for the bundler to `require`, because as explained in the [architecture overview](architecture.md), server and client only communicate through temp files.
+The `addRoute` lifecycle action is used to generate routes. It registers a piece of route config to the route tree, giving a route, a component, and props that the component needs. The props and the component are both provided as paths for the bundler to `require`, because as explained in the [architecture overview](architecture.mdx), server and client only communicate through temp files.
 
 All routes are aggregated in `.docusaurus/routes.js`, which you can view with the debug plugin's [routes panel](/__docusaurus/debug/routes).
 

website/docs/advanced/ssg.mdx

@@ -5,7 +5,7 @@ description: Docusaurus statically renders your React code into HTML, allowing f
 
 # Static site generation (SSG)
 
-In [architecture](architecture.md), we mentioned that the theme is run in Webpack. But beware: that doesn't mean it always has access to browser globals! The theme is built twice:
+In [architecture](architecture.mdx), we mentioned that the theme is run in Webpack. But beware: that doesn't mean it always has access to browser globals! The theme is built twice:
 
 - During **server-side rendering**, the theme is compiled in a sandbox called [React DOM Server](https://reactjs.org/docs/react-dom-server.html). You can see this as a "headless browser", where there is no `window` or `document`, only React. SSR produces static HTML pages.
 - During **client-side rendering**, the theme is compiled to JavaScript that gets eventually executed in the browser, so it has access to browser variables.
@@ -57,7 +57,8 @@ export default function expensiveComp() {
 
 During Webpack build, the `process.env.NODE_ENV` will be replaced with the value, either `'development'` or `'production'`. You will then get different build results after dead code elimination:
 
-import Tabs from '@theme/Tabs'; import TabItem from '@theme/TabItem';
+import Tabs from '@theme/Tabs';
+import TabItem from '@theme/TabItem';
 
 ```mdx-code-block
 <Tabs>
@@ -105,7 +106,7 @@ export default function expensiveComp() {
 
 React is not just a dynamic UI runtime—it's also a templating engine. Because Docusaurus sites mostly contain static contents, it should be able to work without any JavaScript (which React runs in), but only plain HTML/CSS. And that's what server-side rendering offers: statically rendering your React code into HTML, without any dynamic content. An HTML file has no concept of client state (it's purely markup), hence it shouldn't rely on browser APIs.
 
-These HTML files are the first to arrive at the user's browser screen when a URL is visited (see [routing](routing.md)). Afterwards, the browser fetches and runs other JS code to provide the "dynamic" parts of your site—anything implemented with JavaScript. However, before that, the main content of your page is already visible, allowing faster loading.
+These HTML files are the first to arrive at the user's browser screen when a URL is visited (see [routing](routing.mdx)). Afterwards, the browser fetches and runs other JS code to provide the "dynamic" parts of your site—anything implemented with JavaScript. However, before that, the main content of your page is already visible, allowing faster loading.
 
 In CSR-only apps, all DOM elements are generated on client side with React, and the HTML file only ever contains one root element for React to mount DOM to; in SSR, React is already facing a fully built HTML page, and it only needs to correlate the DOM elements with the virtual DOM in its model. This step is called "hydration". After React has hydrated the static markup, the app starts to work as any normal React app.
 
@@ -135,7 +136,7 @@ We provide several more reliable ways to escape SSR.
 
 ### `<BrowserOnly>` {#browseronly}
 
-If you need to render some component in browser only (for example, because the component relies on browser specifics to be functional at all), one common approach is to wrap your component with [`<BrowserOnly>`](../docusaurus-core.md#browseronly) to make sure it's invisible during SSR and only rendered in CSR.
+If you need to render some component in browser only (for example, because the component relies on browser specifics to be functional at all), one common approach is to wrap your component with [`<BrowserOnly>`](../docusaurus-core.mdx#browseronly) to make sure it's invisible during SSR and only rendered in CSR.
 
 ```jsx
 import BrowserOnly from '@docusaurus/BrowserOnly';
@@ -204,7 +205,7 @@ function MyComponent() {
 
 ### `ExecutionEnvironment` {#executionenvironment}
 
-The [`ExecutionEnvironment`](../docusaurus-core.md#executionenvironment) namespace contains several values, and `canUseDOM` is an effective way to detect browser environment.
+The [`ExecutionEnvironment`](../docusaurus-core.mdx#executionenvironment) namespace contains several values, and `canUseDOM` is an effective way to detect browser environment.
 
 Beware that it essentially checked `typeof window !== 'undefined'` under the hood, so you should not use it for rendering-related logic, but only imperative code, like reacting to user input by sending web requests, or dynamically importing libraries, where DOM isn't updated at all.
 

website/docs/api/docusaurus.config.js.mdx

@@ -119,7 +119,7 @@ Refer to the [deployment guide](../deployment.mdx) and [slorber/trailing-slash-g
 
 - Type: `Object`
 
-The i18n configuration object to [localize your site](../i18n/i18n-introduction.md).
+The i18n configuration object to [localize your site](../i18n/i18n-introduction.mdx).
 
 Example:
 
@@ -201,7 +201,7 @@ By default, it prints a warning, to let you know about your broken Markdown link
 
 - Type: `'ignore' | 'log' | 'warn' | 'throw'`
 
-The behavior of Docusaurus when it detects any [duplicate routes](/guides/creating-pages.md#duplicate-routes).
+The behavior of Docusaurus when it detects any [duplicate routes](/guides/creating-pages.mdx#duplicate-routes).
 
 By default, it displays a warning after you run `yarn start` or `yarn build`.
 
@@ -283,7 +283,7 @@ module.exports = {
 
 - Type: `Object`
 
-The [theme configuration](./themes/theme-configuration.md) object to customize your site UI like navbar and footer.
+The [theme configuration](./themes/theme-configuration.mdx) object to customize your site UI like navbar and footer.
 
 Example:
 
@@ -354,7 +354,7 @@ module.exports = {
 type PluginConfig = string | [string, any] | PluginModule | [PluginModule, any];
 ```
 
-See [plugin method references](./plugin-methods/README.md) for the shape of a `PluginModule`.
+See [plugin method references](./plugin-methods/README.mdx) for the shape of a `PluginModule`.
 
 ```js title="docusaurus.config.js"
 module.exports = {
@@ -530,7 +530,7 @@ By default, the `<link>` tags will have `rel="stylesheet"`, but you can explicit
 
 ### `clientModules` {#clientModules}
 
-An array of [client modules](../advanced/client.md#client-modules) to load globally on your site.
+An array of [client modules](../advanced/client.mdx#client-modules) to load globally on your site.
 
 Example:
 

website/docs/api/misc/eslint-plugin/README.mdx

@@ -50,9 +50,9 @@ For more fine-grained control, you can also enable the plugin manually and confi
 
 | Name | Description |  |
 | --- | --- | --- |
-| [`@docusaurus/no-untranslated-text`](./no-untranslated-text.md) | Enforce text labels in JSX to be wrapped by translate calls |  |
-| [`@docusaurus/string-literal-i18n-messages`](./string-literal-i18n-messages.md) | Enforce translate APIs to be called on plain text labels | ✅ |
-| [`@docusaurus/no-html-links`](./no-html-links.md) | Ensures @docusaurus/Link is used instead of `<a>` tags | ✅ |
+| [`@docusaurus/no-untranslated-text`](./no-untranslated-text.mdx) | Enforce text labels in JSX to be wrapped by translate calls |  |
+| [`@docusaurus/string-literal-i18n-messages`](./string-literal-i18n-messages.mdx) | Enforce translate APIs to be called on plain text labels | ✅ |
+| [`@docusaurus/no-html-links`](./no-html-links.mdx) | Ensures @docusaurus/Link is used instead of `<a>` tags | ✅ |
 
 ✅ = recommended
 

website/docs/api/misc/eslint-plugin/no-html-links.mdx

@@ -4,7 +4,7 @@ slug: /api/misc/@docusaurus/eslint-plugin/no-html-links
 
 # no-html-links
 
-Ensure that the Docusaurus [`<Link>`](../../../docusaurus-core.md#link) component is used instead of `<a>` tags.
+Ensure that the Docusaurus [`<Link>`](../../../docusaurus-core.mdx#link) component is used instead of `<a>` tags.
 
 The `<Link>` component has prefetching and preloading built-in. It also does build-time broken link detection, and helps Docusaurus understand your site's structure better.
 

website/docs/api/misc/eslint-plugin/no-untranslated-text.mdx

@@ -8,7 +8,7 @@ import APITable from '@site/src/components/APITable';
 
 Enforce text labels in JSX to be wrapped by translate calls.
 
-When the [i18n feature](../../../i18n/i18n-introduction.md) is used, this rule ensures that all labels appearing on the website are translatable, so no string accidentally slips through untranslated.
+When the [i18n feature](../../../i18n/i18n-introduction.mdx) is used, this rule ensures that all labels appearing on the website are translatable, so no string accidentally slips through untranslated.
 
 ## Rule Details {#details}
 
@@ -46,7 +46,7 @@ Accepted fields:
 
 ## When Not To Use It {#when-not-to-use}
 
-If you're not using the [i18n feature](../../../i18n/i18n-introduction.md), you can disable this rule. You can also disable this rule where the text is not supposed to be translated.
+If you're not using the [i18n feature](../../../i18n/i18n-introduction.mdx), you can disable this rule. You can also disable this rule where the text is not supposed to be translated.
 
 ## Further Reading {#further-reading}
 

website/docs/api/misc/eslint-plugin/string-literal-i18n-messages.mdx

@@ -6,7 +6,7 @@ slug: /api/misc/@docusaurus/eslint-plugin/string-literal-i18n-messages
 
 Enforce translate APIs to be called on plain text labels.
 
-Docusaurus offers the [`docusaurus write-translations`](../../../cli.md#docusaurus-write-translations-sitedir) API, which statically extracts the text labels marked as translatable. Dynamic values used in `<Translate>` or `translate()` calls will fail to be extracted. This rule will ensure that all translate calls are statically extractable.
+Docusaurus offers the [`docusaurus write-translations`](../../../cli.mdx#docusaurus-write-translations-sitedir) API, which statically extracts the text labels marked as translatable. Dynamic values used in `<Translate>` or `translate()` calls will fail to be extracted. This rule will ensure that all translate calls are statically extractable.
 
 ## Rule Details {#details}
 
@@ -42,7 +42,7 @@ translate({message: 'The logo of site {siteName}'}, {siteName: 'Docusaurus'})
 
 ## When Not To Use It {#when-not-to-use}
 
-If you're not using the [i18n feature](../../../i18n/i18n-introduction.md), you can disable this rule.
+If you're not using the [i18n feature](../../../i18n/i18n-introduction.mdx), you can disable this rule.
 
 ## Further Reading {#further-reading}
 

website/docs/api/plugin-methods/README.mdx

@@ -13,7 +13,7 @@ Plugin APIs are shared by themes and plugins—themes are loaded just like plugi
 Every plugin is imported as a module. The module is expected to have the following members:
 
 - A **default export**: the constructor function for the plugin.
-- **Named exports**: the [static methods](./static-methods.md) called before plugins are initialized.
+- **Named exports**: the [static methods](./static-methods.mdx) called before plugins are initialized.
 
 ## Plugin constructor {#plugin-constructor}
 
@@ -35,7 +35,7 @@ type LoadContext = {
 
 ### `options` {#options}
 
-`options` are the [second optional parameter when the plugins are used](../../using-plugins.md#configuring-plugins). `options` are plugin-specific and are specified by users when they use them in `docusaurus.config.js`. If there's a [`validateOptions`](./static-methods.md#validateOptions) function exported, the `options` will be validated and normalized beforehand.
+`options` are the [second optional parameter when the plugins are used](../../using-plugins.mdx#configuring-plugins). `options` are plugin-specific and are specified by users when they use them in `docusaurus.config.js`. If there's a [`validateOptions`](./static-methods.mdx#validateOptions) function exported, the `options` will be validated and normalized beforehand.
 
 Alternatively, if a preset contains the plugin, the preset will then be in charge of passing the correct options into the plugin. It is up to the individual plugin to define what options it takes.
 

website/docs/api/plugin-methods/i18n-lifecycles.mdx

@@ -15,7 +15,7 @@ Returns translation files `{path: string, content: ChromeI18nJSON}`:
 - `path`: relative to the plugin localized folder `i18n/[locale]/[pluginName]`. Extension `.json` should be omitted to remain generic.
 - `content`: using the Chrome i18n JSON format.
 
-These files will be written by the [`write-translations` CLI](../../cli.md#docusaurus-write-translations-sitedir) to the plugin i18n subfolder, and will be read in the appropriate locale before calling [`translateContent()`](#translateContent) and [`translateThemeConfig()`](#translateThemeConfig)
+These files will be written by the [`write-translations` CLI](../../cli.mdx#docusaurus-write-translations-sitedir) to the plugin i18n subfolder, and will be read in the appropriate locale before calling [`translateContent()`](#translateContent) and [`translateThemeConfig()`](#translateThemeConfig)
 
 Example:
 

website/docs/api/plugin-methods/lifecycle-apis.mdx

@@ -111,7 +111,7 @@ export default function friendsPlugin(context, options) {
 
 This function permits one to create some global plugin data that can be read from any page, including the pages created by other plugins, and your theme layout.
 
-This data becomes accessible to your client-side/theme code through the [`useGlobalData`](../../docusaurus-core.md#useGlobalData) and [`usePluginData`](../../docusaurus-core.md#usePluginData) hooks.
+This data becomes accessible to your client-side/theme code through the [`useGlobalData`](../../docusaurus-core.mdx#useGlobalData) and [`usePluginData`](../../docusaurus-core.mdx#usePluginData) hooks.
 
 :::caution
 
@@ -405,7 +405,7 @@ Tags will be added as follows:
 
 ## `getClientModules()` {#getClientModules}
 
-Returns an array of paths to the [client modules](../../advanced/client.md#client-modules) that are to be imported into the client bundle.
+Returns an array of paths to the [client modules](../../advanced/client.mdx#client-modules) that are to be imported into the client bundle.
 
 As an example, to make your theme load a `customCss` or `customJs` file path from `options` passed in by the user:
 

website/docs/api/plugins/overview.mdx

@@ -13,18 +13,18 @@ We provide official Docusaurus plugins.
 
 These plugins are responsible for loading your site's content, and creating pages for your theme to render.
 
-- [@docusaurus/plugin-content-docs](./plugin-content-docs.md)
-- [@docusaurus/plugin-content-blog](./plugin-content-blog.md)
-- [@docusaurus/plugin-content-pages](./plugin-content-pages.md)
+- [@docusaurus/plugin-content-docs](./plugin-content-docs.mdx)
+- [@docusaurus/plugin-content-blog](./plugin-content-blog.mdx)
+- [@docusaurus/plugin-content-pages](./plugin-content-pages.mdx)
 
 ## Behavior plugins {#behavior-plugins}
 
 These plugins will add a useful behavior to your Docusaurus site.
 
-- [@docusaurus/plugin-debug](./plugin-debug.md)
-- [@docusaurus/plugin-sitemap](./plugin-sitemap.md)
-- [@docusaurus/plugin-pwa](./plugin-pwa.md)
-- [@docusaurus/plugin-client-redirects](./plugin-client-redirects.md)
-- [@docusaurus/plugin-ideal-image](./plugin-ideal-image.md)
-- [@docusaurus/plugin-google-analytics](./plugin-google-analytics.md)
-- [@docusaurus/plugin-google-gtag](./plugin-google-gtag.md)
+- [@docusaurus/plugin-debug](./plugin-debug.mdx)
+- [@docusaurus/plugin-sitemap](./plugin-sitemap.mdx)
+- [@docusaurus/plugin-pwa](./plugin-pwa.mdx)
+- [@docusaurus/plugin-client-redirects](./plugin-client-redirects.mdx)
+- [@docusaurus/plugin-ideal-image](./plugin-ideal-image.mdx)
+- [@docusaurus/plugin-google-analytics](./plugin-google-analytics.mdx)
+- [@docusaurus/plugin-google-gtag](./plugin-google-gtag.mdx)

website/docs/api/plugins/plugin-client-redirects.mdx

@@ -52,7 +52,7 @@ Accepted fields:
 
 :::note
 
-This plugin will also read the [`siteConfig.onDuplicateRoutes`](../docusaurus.config.js.md#onDuplicateRoutes) config to adjust its logging level when multiple files will be emitted to the same location.
+This plugin will also read the [`siteConfig.onDuplicateRoutes`](../docusaurus.config.js.mdx#onDuplicateRoutes) config to adjust its logging level when multiple files will be emitted to the same location.
 
 :::
 

website/docs/api/plugins/plugin-content-blog.mdx

@@ -267,13 +267,13 @@ A Markdown blog post
 
 ## i18n {#i18n}
 
-Read the [i18n introduction](../../i18n/i18n-introduction.md) first.
+Read the [i18n introduction](../../i18n/i18n-introduction.mdx) first.
 
 ### Translation files location {#translation-files-location}
 
 - **Base path**: `website/i18n/[locale]/docusaurus-plugin-content-blog`
 - **Multi-instance path**: `website/i18n/[locale]/docusaurus-plugin-content-blog-[pluginId]`
-- **JSON files**: extracted with [`docusaurus write-translations`](../../cli.md#docusaurus-write-translations-sitedir)
+- **JSON files**: extracted with [`docusaurus write-translations`](../../cli.mdx#docusaurus-write-translations-sitedir)
 - **Markdown files**: `website/i18n/[locale]/docusaurus-plugin-content-blog`
 
 ### Example file-system structure {#example-file-system-structure}

website/docs/api/plugins/plugin-content-docs.mdx

@@ -7,7 +7,7 @@ slug: /api/plugins/@docusaurus/plugin-content-docs
 
 import APITable from '@site/src/components/APITable';
 
-Provides the [Docs](../../guides/docs/docs-introduction.md) functionality and is the default docs plugin for Docusaurus.
+Provides the [Docs](../../guides/docs/docs-introduction.mdx) functionality and is the default docs plugin for Docusaurus.
 
 ## Installation {#installation}
 
@@ -278,7 +278,7 @@ Accepted fields:
 | `sidebar_position` | `number` | Default ordering | Controls the position of a doc inside the generated sidebar slice when using `autogenerated` sidebar items. See also [Autogenerated sidebar metadata](/docs/sidebar#autogenerated-sidebar-metadata). |
 | `sidebar_class_name` | `string` | `undefined` | Gives the corresponding sidebar label a special class name when using autogenerated sidebars. |
 | `sidebar_custom_props` | `string` | `undefined` | Assign custom metadata to the sidebar item referencing this doc. |
-| `displayed_sidebar` | `string` | `undefined` | Force the display of a given sidebar when browsing the current document. Read the [multiple sidebars guide](../../guides/docs/sidebar/multiple-sidebars.md) for details. |
+| `displayed_sidebar` | `string` | `undefined` | Force the display of a given sidebar when browsing the current document. Read the [multiple sidebars guide](../../guides/docs/sidebar/multiple-sidebars.mdx) for details. |
 | `hide_title` | `boolean` | `false` | Whether to hide the title at the top of the doc. It only hides a title declared through the front matter, and have no effect on a Markdown title at the top of your document. |
 | `hide_table_of_contents` | `boolean` | `false` | Whether to hide the table of contents to the right. |
 | `toc_min_heading_level` | `number` | `2` | The minimum heading level shown in the table of contents. Must be between 2 and 6 and lower or equal to the max value. |
@@ -338,13 +338,13 @@ My Document Markdown content
 
 ## i18n {#i18n}
 
-Read the [i18n introduction](../../i18n/i18n-introduction.md) first.
+Read the [i18n introduction](../../i18n/i18n-introduction.mdx) first.
 
 ### Translation files location {#translation-files-location}
 
 - **Base path**: `website/i18n/[locale]/docusaurus-plugin-content-docs`
 - **Multi-instance path**: `website/i18n/[locale]/docusaurus-plugin-content-docs-[pluginId]`
-- **JSON files**: extracted with [`docusaurus write-translations`](../../cli.md#docusaurus-write-translations-sitedir)
+- **JSON files**: extracted with [`docusaurus write-translations`](../../cli.mdx#docusaurus-write-translations-sitedir)
 - **Markdown files**: `website/i18n/[locale]/docusaurus-plugin-content-docs/[versionName]`
 
 ### Example file-system structure {#example-file-system-structure}

website/docs/api/plugins/plugin-content-pages.mdx

@@ -7,7 +7,7 @@ slug: /api/plugins/@docusaurus/plugin-content-pages
 
 import APITable from '@site/src/components/APITable';
 
-The default pages plugin for Docusaurus. The classic template ships with this plugin with default configurations. This plugin provides [creating pages](guides/creating-pages.md) functionality.
+The default pages plugin for Docusaurus. The classic template ships with this plugin with default configurations. This plugin provides [creating pages](guides/creating-pages.mdx) functionality.
 
 ## Installation {#installation}
 
@@ -116,13 +116,13 @@ Markdown page content
 
 ## i18n {#i18n}
 
-Read the [i18n introduction](../../i18n/i18n-introduction.md) first.
+Read the [i18n introduction](../../i18n/i18n-introduction.mdx) first.
 
 ### Translation files location {#translation-files-location}
 
 - **Base path**: `website/i18n/[locale]/docusaurus-plugin-content-pages`
 - **Multi-instance path**: `website/i18n/[locale]/docusaurus-plugin-content-pages-[pluginId]`
-- **JSON files**: extracted with [`docusaurus write-translations`](../../cli.md#docusaurus-write-translations-sitedir)
+- **JSON files**: extracted with [`docusaurus write-translations`](../../cli.mdx#docusaurus-write-translations-sitedir)
 - **Markdown files**: `website/i18n/[locale]/docusaurus-plugin-content-pages`
 
 ### Example file-system structure {#example-file-system-structure}

website/docs/api/plugins/plugin-debug.mdx

@@ -72,7 +72,7 @@ Most Docusaurus users configure this plugin through the preset options.
 <TabItem value="preset" label="Preset options">
 ```
 
-If you use a preset, configure this plugin through the [preset options](../../using-plugins.md#docusauruspreset-classic):
+If you use a preset, configure this plugin through the [preset options](../../using-plugins.mdx#docusauruspreset-classic):
 
 ```js title="docusaurus.config.js"
 module.exports = {

website/docs/api/plugins/plugin-google-analytics.mdx

@@ -7,7 +7,7 @@ slug: /api/plugins/@docusaurus/plugin-google-analytics
 
 import APITable from '@site/src/components/APITable';
 
-The default [Google Analytics](https://developers.google.com/analytics/devguides/collection/analyticsjs/) plugin. It is a JavaScript library for measuring how users interact with your website **in the production build**. If you are using Google Analytics 4 you might need to consider using [plugin-google-gtag](./plugin-google-gtag.md) instead.
+The default [Google Analytics](https://developers.google.com/analytics/devguides/collection/analyticsjs/) plugin. It is a JavaScript library for measuring how users interact with your website **in the production build**. If you are using Google Analytics 4 you might need to consider using [plugin-google-gtag](./plugin-google-gtag.mdx) instead.
 
 :::danger Deprecated
 
@@ -15,7 +15,7 @@ This plugin is **deprecated**, and will become useless on July 1, 2023.
 
 Google is [moving away from Universal Analytics](https://blog.google/products/marketingplatform/analytics/prepare-for-future-with-google-analytics-4/).
 
-If you are still using this plugin with a `UA-*` tracking id, you should create a Google Analytics 4 account as soon as possible, and use [`@docusaurus/plugin-google-gtag`](./plugin-google-gtag.md) instead of this plugin. More details [here](https://github.com/facebook/docusaurus/issues/7221).
+If you are still using this plugin with a `UA-*` tracking id, you should create a Google Analytics 4 account as soon as possible, and use [`@docusaurus/plugin-google-gtag`](./plugin-google-gtag.mdx) instead of this plugin. More details [here](https://github.com/facebook/docusaurus/issues/7221).
 
 :::
 

website/docs/api/plugins/plugin-google-tag-manager.mdx

@@ -7,7 +7,7 @@ slug: /api/plugins/@docusaurus/plugin-google-tag-manager
 
 import APITable from '@site/src/components/APITable';
 
-A plugin for adding [Google Tag Manager (gtm.js)](https://developers.google.com/tag-platform/tag-manager) to a Docusaurus site. Use this plugin in conjunction with the standard [gtag plugin](./plugin-google-gtag.md) for in-depth analysis of how users are using your site.
+A plugin for adding [Google Tag Manager (gtm.js)](https://developers.google.com/tag-platform/tag-manager) to a Docusaurus site. Use this plugin in conjunction with the standard [gtag plugin](./plugin-google-gtag.mdx) for in-depth analysis of how users are using your site.
 
 :::tip
 

website/docs/api/plugins/plugin-pwa.mdx

@@ -294,7 +294,7 @@ import CodeBlock from '@theme/CodeBlock';
 
 ## Customizing reload popup {#customizing-reload-popup}
 
-The `@theme/PwaReloadPopup` component is rendered when a new service worker is waiting to be installed, and we suggest a reload to the user. You can [swizzle](../../swizzling.md) this component and implement your own UI. It will receive an `onReload` callback as props, which should be called when the `reload` button is clicked. This will tell the service worker to install the waiting service worker and reload the page.
+The `@theme/PwaReloadPopup` component is rendered when a new service worker is waiting to be installed, and we suggest a reload to the user. You can [swizzle](../../swizzling.mdx) this component and implement your own UI. It will receive an `onReload` callback as props, which should be called when the `reload` button is clicked. This will tell the service worker to install the waiting service worker and reload the page.
 
 The default theme includes an implementation for the reload popup and uses [Infima Alerts](https://infima.dev/docs/components/alert).
 

website/docs/api/plugins/plugin-sitemap.mdx

@@ -52,8 +52,8 @@ Accepted fields:
 
 This plugin also respects some site config:
 
-- [`noIndex`](../docusaurus.config.js.md#noIndex): results in no sitemap generated
-- [`trailingSlash`](../docusaurus.config.js.md#trailingSlash): determines if the URLs in the sitemap have trailing slashes
+- [`noIndex`](../docusaurus.config.js.mdx#noIndex): results in no sitemap generated
+- [`trailingSlash`](../docusaurus.config.js.mdx#trailingSlash): determines if the URLs in the sitemap have trailing slashes
 
 :::
 

website/docs/api/themes/overview.mdx

@@ -11,9 +11,9 @@ We provide official Docusaurus themes.
 
 ## Main themes {#main-themes}
 
-The main themes implement the user interface for the [docs](../plugins/plugin-content-docs.md), [blog](../plugins/plugin-content-blog.md) and [pages](../plugins/plugin-content-pages.md) plugins.
+The main themes implement the user interface for the [docs](../plugins/plugin-content-docs.mdx), [blog](../plugins/plugin-content-blog.mdx) and [pages](../plugins/plugin-content-pages.mdx) plugins.
 
-- [@docusaurus/theme-classic](./theme-classic.md)
+- [@docusaurus/theme-classic](./theme-classic.mdx)
 - 🚧 other themes are planned
 
 :::caution
@@ -30,5 +30,5 @@ We are not there yet: only the classic theme is production ready.
 
 These themes will enhance the existing main themes with additional user-interface related features.
 
-- [@docusaurus/theme-live-codeblock](./theme-live-codeblock.md)
-- [@docusaurus/theme-search-algolia](./theme-search-algolia.md)
+- [@docusaurus/theme-live-codeblock](./theme-live-codeblock.mdx)
+- [@docusaurus/theme-search-algolia](./theme-search-algolia.mdx)

website/docs/api/themes/theme-classic.mdx

@@ -7,7 +7,7 @@ slug: /api/themes/@docusaurus/theme-classic
 
 The classic theme for Docusaurus.
 
-You can refer to the [theme configuration page](theme-configuration.md) for more details on the configuration.
+You can refer to the [theme configuration page](theme-configuration.mdx) for more details on the configuration.
 
 ```bash npm2yarn
 npm install --save @docusaurus/theme-classic
@@ -29,7 +29,7 @@ Accepted fields:
 
 | Option | Type | Default | Description |
 | --- | --- | --- | --- |
-| `customCss` | <code>string[] \| string</code> | `[]` | Stylesheets to be imported globally as [client modules](../../advanced/client.md#client-modules). Relative paths are resolved against the site directory. |
+| `customCss` | <code>string[] \| string</code> | `[]` | Stylesheets to be imported globally as [client modules](../../advanced/client.mdx#client-modules). Relative paths are resolved against the site directory. |
 
 ```mdx-code-block
 </APITable>
@@ -37,7 +37,7 @@ Accepted fields:
 
 :::note
 
-Most configuration for the theme is done in `themeConfig`, which can be found in [theme configuration](./theme-configuration.md).
+Most configuration for the theme is done in `themeConfig`, which can be found in [theme configuration](./theme-configuration.mdx).
 
 :::
 

website/docs/api/themes/theme-configuration.mdx

@@ -9,7 +9,7 @@ toc_max_heading_level: 4
 
 import APITable from '@site/src/components/APITable';
 
-This configuration applies to all [main themes](./overview.md).
+This configuration applies to all [main themes](./overview.mdx).
 
 ## Common {#common}
 
@@ -180,7 +180,7 @@ Accepted fields:
 
 ### Navbar logo {#navbar-logo}
 
-The logo can be placed in [static folder](static-assets.md). Logo URL is set to base URL of your site by default. Although you can specify your own URL for the logo, if it is an external link, it will open in a new tab. In addition, you can override a value for the target attribute of logo link, it can come in handy if you are hosting docs website in a subdirectory of your main website, and in which case you probably do not need a link in the logo to the main website will open in a new tab.
+The logo can be placed in [static folder](static-assets.mdx). Logo URL is set to base URL of your site by default. Although you can specify your own URL for the logo, if it is an external link, it will open in a new tab. In addition, you can override a value for the target attribute of logo link, it can come in handy if you are hosting docs website in a subdirectory of your main website, and in which case you probably do not need a link in the logo to the main website will open in a new tab.
 
 To improve dark mode support, you can also set a different logo for this mode.
 
@@ -600,7 +600,7 @@ module.exports = {
 
 #### Navbar locale dropdown {#navbar-locale-dropdown}
 
-If you use the [i18n feature](../../i18n/i18n-introduction.md), this special navbar item type will render a dropdown with all your site's available locales.
+If you use the [i18n feature](../../i18n/i18n-introduction.mdx), this special navbar item type will render a dropdown with all your site's available locales.
 
 The user will be able to switch from one locale to another, while staying on the same page.
 
@@ -648,7 +648,7 @@ module.exports = {
 
 #### Navbar search {#navbar-search}
 
-If you use the [search](../../search.md), the search bar will be the rightmost element in the navbar.
+If you use the [search](../../search.mdx), the search bar will be the rightmost element in the navbar.
 
 However, with this special navbar item type, you can change the default location.
 
@@ -835,7 +835,7 @@ module.exports = {
 
 ## Footer {#footer-1}
 
-You can add logo and a copyright to the footer via `themeConfig.footer`. Logo can be placed in [static folder](static-assets.md). Logo URL works in the same way of the navbar logo.
+You can add logo and a copyright to the footer via `themeConfig.footer`. Logo can be placed in [static folder](static-assets.mdx). Logo URL works in the same way of the navbar logo.
 
 Accepted fields:
 
@@ -1066,13 +1066,13 @@ function ExamplePage() {
 
 ## i18n {#i18n}
 
-Read the [i18n introduction](../../i18n/i18n-introduction.md) first.
+Read the [i18n introduction](../../i18n/i18n-introduction.mdx) first.
 
 ### Translation files location {#translation-files-location}
 
 - **Base path**: `website/i18n/[locale]/docusaurus-theme-[themeName]`
 - **Multi-instance path**: N/A
-- **JSON files**: extracted with [`docusaurus write-translations`](../../cli.md#docusaurus-write-translations-sitedir)
+- **JSON files**: extracted with [`docusaurus write-translations`](../../cli.mdx#docusaurus-write-translations-sitedir)
 - **Markdown files**: N/A
 
 ### Example file-system structure {#example-file-system-structure}

website/docs/api/themes/theme-search-algolia.mdx

@@ -5,7 +5,7 @@ slug: /api/themes/@docusaurus/theme-search-algolia
 
 # 📦 theme-search-algolia
 
-This theme provides a `@theme/SearchBar` component that integrates with Algolia DocSearch easily. Combined with `@docusaurus/theme-classic`, it provides a very easy search integration. You can read more on [search](../../search.md) documentation.
+This theme provides a `@theme/SearchBar` component that integrates with Algolia DocSearch easily. Combined with `@docusaurus/theme-classic`, it provides a very easy search integration. You can read more on [search](../../search.mdx) documentation.
 
 ```bash npm2yarn
 npm install --save @docusaurus/theme-search-algolia

website/docs/blog.mdx

@@ -11,7 +11,7 @@ The blog feature enables you to deploy a full-featured blog in no time.
 
 :::info
 
-Check the [Blog Plugin API Reference documentation](./api/plugins/plugin-content-blog.md) for an exhaustive list of options.
+Check the [Blog Plugin API Reference documentation](./api/plugins/plugin-content-blog.mdx) for an exhaustive list of options.
 
 :::
 
@@ -70,7 +70,7 @@ This is my first post on Docusaurus 2.
 A whole bunch of exploration to follow.
 ```
 
-The [front matter](./guides/markdown-features/markdown-features-intro.mdx#front-matter) is useful to add more metadata to your blog post, for example, author information, but Docusaurus will be able to infer all necessary metadata without the front matter. For all possible fields, see [the API documentation](api/plugins/plugin-content-blog.md#markdown-front-matter).
+The [front matter](./guides/markdown-features/markdown-features-intro.mdx#front-matter) is useful to add more metadata to your blog post, for example, author information, but Docusaurus will be able to infer all necessary metadata without the front matter. For all possible fields, see [the API documentation](api/plugins/plugin-content-blog.mdx#markdown-front-matter).
 
 ## Blog list {#blog-list}
 
@@ -617,7 +617,7 @@ Don't forget to delete the existing homepage at `./src/pages/index.js` or else t
 
 :::tip
 
-There's also a "Docs-only mode" for those who only want to use the docs. Read [Docs-only mode](./guides/docs/docs-introduction.md) for detailed instructions or a more elaborate explanation of `routeBasePath`.
+There's also a "Docs-only mode" for those who only want to use the docs. Read [Docs-only mode](./guides/docs/docs-introduction.mdx) for detailed instructions or a more elaborate explanation of `routeBasePath`.
 
 :::
 
@@ -627,7 +627,7 @@ By default, the classic theme assumes only one blog per website and hence includ
 
 Set the `routeBasePath` to the URL route that you want your second blog to be accessed on. Note that the `routeBasePath` here has to be different from the first blog or else there could be a collision of paths! Also, set `path` to the path to the directory containing your second blog's entries.
 
-As documented for [multi-instance plugins](./using-plugins.md#multi-instance-plugins-and-plugin-ids), you need to assign a unique ID to the plugins.
+As documented for [multi-instance plugins](./using-plugins.mdx#multi-instance-plugins-and-plugin-ids), you need to assign a unique ID to the plugins.
 
 ```js title="docusaurus.config.js"
 module.exports = {

website/docs/browser-support.mdx

@@ -103,4 +103,4 @@ safari 13.1
 
 ## Read more {#read-more}
 
-You may wish to visit the [browserslist documentation](https://github.com/browserslist/browserslist/blob/main/README.md) for more specifications, especially the accepted [query values](https://github.com/browserslist/browserslist/blob/main/README.md#queries) and [best practices](https://github.com/browserslist/browserslist/blob/main/README.md#best-practices).
+You may wish to visit the [browserslist documentation](https://github.com/browserslist/browserslist/blob/main/README.mdx) for more specifications, especially the accepted [query values](https://github.com/browserslist/browserslist/blob/main/README.mdx#queries) and [best practices](https://github.com/browserslist/browserslist/blob/main/README.mdx#best-practices).

website/docs/cli.mdx

@@ -92,7 +92,7 @@ Compiles your site for production.
 
 :::info
 
-For advanced minification of CSS bundle, we use the [advanced cssnano preset](https://github.com/cssnano/cssnano/tree/master/packages/cssnano-preset-advanced) (along with additional several PostCSS plugins) and [level 2 optimization of clean-css](https://github.com/jakubpawlowicz/clean-css#level-2-optimizations). If as a result of this advanced CSS minification you find broken CSS, build your website with the environment variable `USE_SIMPLE_CSS_MINIFIER=true` to minify CSS with the [default cssnano preset](https://github.com/cssnano/cssnano/tree/master/packages/cssnano-preset-default). **Please [fill out an issue](https://github.com/facebook/docusaurus/issues/new?labels=bug%2C+needs+triage&template=bug.md) if you experience CSS minification bugs.**
+For advanced minification of CSS bundle, we use the [advanced cssnano preset](https://github.com/cssnano/cssnano/tree/master/packages/cssnano-preset-advanced) (along with additional several PostCSS plugins) and [level 2 optimization of clean-css](https://github.com/jakubpawlowicz/clean-css#level-2-optimizations). If as a result of this advanced CSS minification you find broken CSS, build your website with the environment variable `USE_SIMPLE_CSS_MINIFIER=true` to minify CSS with the [default cssnano preset](https://github.com/cssnano/cssnano/tree/master/packages/cssnano-preset-default). **Please [fill out an issue](https://github.com/facebook/docusaurus/issues/new?labels=bug%2C+needs+triage&template=bug.mdx) if you experience CSS minification bugs.**
 
 You can skip the HTML minification with the environment variable `SKIP_HTML_MINIFICATION=true`.
 
@@ -100,7 +100,7 @@ You can skip the HTML minification with the environment variable `SKIP_HTML_MINI
 
 ### `docusaurus swizzle [themeName] [componentName] [siteDir]` {#docusaurus-swizzle}
 
-[Swizzle](./swizzling.md) a theme component to customize it.
+[Swizzle](./swizzling.mdx) a theme component to customize it.
 
 ```bash npm2yarn
 npm run swizzle [themeName] [componentName] [siteDir]
@@ -109,7 +109,7 @@ npm run swizzle [themeName] [componentName] [siteDir]
 npm run swizzle @docusaurus/theme-classic Footer -- --eject
 ```
 
-The swizzle CLI is interactive and will guide you through the whole [swizzle process](./swizzling.md).
+The swizzle CLI is interactive and will guide you through the whole [swizzle process](./swizzling.mdx).
 
 #### Options {#options-swizzle}
 
@@ -118,8 +118,8 @@ The swizzle CLI is interactive and will guide you through the whole [swizzle pro
 | `themeName` | The name of the theme to swizzle from. |
 | `componentName` | The name of the theme component to swizzle. |
 | `--list` | Display components available for swizzling |
-| `--eject` | [Eject](./swizzling.md#ejecting) the theme component |
-| `--wrap` | [Wrap](./swizzling.md#wrapping) the theme component |
+| `--eject` | [Eject](./swizzling.mdx#ejecting) the theme component |
+| `--wrap` | [Wrap](./swizzling.mdx#wrapping) the theme component |
 | `--danger` | Allow immediate swizzling of unsafe components |
 | `--typescript` | Swizzle the TypeScript variant component |
 | `--config` | Path to docusaurus config file, default to `[siteDir]/docusaurus.config.js` |

website/docs/configuration.mdx

@@ -20,7 +20,7 @@ The high-level overview of Docusaurus configuration can be categorized into:
 
 <TOCInline toc={toc} minHeadingLevel={3} maxHeadingLevel={3} />
 
-For exact reference to each of the configurable fields, you may refer to [**`docusaurus.config.js` API reference**](api/docusaurus.config.js.md).
+For exact reference to each of the configurable fields, you may refer to [**`docusaurus.config.js` API reference**](api/docusaurus.config.js.mdx).
 
 ### Site metadata {#site-metadata}
 
@@ -36,7 +36,7 @@ It is recommended to check the [deployment docs](deployment.mdx) for more inform
 
 ### Theme, plugin, and preset configurations {#theme-plugin-and-preset-configurations}
 
-List the [themes](./using-plugins.md#using-themes), [plugins](./using-plugins.md), and [presets](./using-plugins.md#using-presets) for your site in the `themes`, `plugins`, and `presets` fields, respectively. These are typically npm packages:
+List the [themes](./using-plugins.mdx#using-themes), [plugins](./using-plugins.mdx), and [presets](./using-plugins.mdx#using-presets) for your site in the `themes`, `plugins`, and `presets` fields, respectively. These are typically npm packages:
 
 ```js title="docusaurus.config.js"
 module.exports = {
@@ -51,7 +51,7 @@ module.exports = {
 
 :::tip
 
-Docusaurus supports [**module shorthands**](./using-plugins.md#module-shorthands), allowing you to simplify the above configuration as:
+Docusaurus supports [**module shorthands**](./using-plugins.mdx#module-shorthands), allowing you to simplify the above configuration as:
 
 ```js title="docusaurus.config.js"
 module.exports = {
@@ -121,7 +121,7 @@ The `presets: [['classic', {...}]]` shorthand works as well.
 
 :::
 
-For further help configuring themes, plugins, and presets, see [Using Plugins](./using-plugins.md).
+For further help configuring themes, plugins, and presets, see [Using Plugins](./using-plugins.mdx).
 
 ### Custom configurations {#custom-configurations}
 

website/docs/deployment.mdx

@@ -35,7 +35,7 @@ The following parameters are required in `docusaurus.config.js` to optimize rout
 
 ## Testing your Build Locally {#testing-build-locally}
 
-It is important to test your build locally before deploying it for production. Docusaurus provides a [`docusaurus serve`](cli.md#docusaurus-serve-sitedir) command for that:
+It is important to test your build locally before deploying it for production. Docusaurus provides a [`docusaurus serve`](cli.mdx#docusaurus-serve-sitedir) command for that:
 
 ```bash npm2yarn
 npm run serve
@@ -45,7 +45,7 @@ By default, this will load your site at [http://localhost:3000/](http://localhos
 
 ## Trailing slash configuration {#trailing-slashes}
 
-Docusaurus has a [`trailingSlash` config](./api/docusaurus.config.js.md#trailingSlash), to allow customizing URLs/links and emitted filename patterns.
+Docusaurus has a [`trailingSlash` config](./api/docusaurus.config.js.mdx#trailingSlash), to allow customizing URLs/links and emitted filename patterns.
 
 The default value generally works fine. Unfortunately, each static hosting provider has a **different behavior**, and deploying the exact same site to various hosts can lead to distinct results. Depending on your host, it can be useful to change this config.
 
@@ -57,7 +57,7 @@ Use [slorber/trailing-slash-guide](https://github.com/slorber/trailing-slash-gui
 
 ## Using environment variables {#using-environment-variables}
 
-Putting potentially sensitive information in the environment is common practice. However, in a typical Docusaurus website, the `docusaurus.config.js` file is the only interface to the Node.js environment (see [our architecture overview](advanced/architecture.md)), while everything else—MDX pages, React components... are client side and do not have direct access to the `process` global. In this case, you can consider using [`customFields`](api/docusaurus.config.js.md#customFields) to pass environment variables to the client side.
+Putting potentially sensitive information in the environment is common practice. However, in a typical Docusaurus website, the `docusaurus.config.js` file is the only interface to the Node.js environment (see [our architecture overview](advanced/architecture.mdx)), while everything else—MDX pages, React components... are client side and do not have direct access to the `process` global. In this case, you can consider using [`customFields`](api/docusaurus.config.js.mdx#customFields) to pass environment variables to the client side.
 
 ```js title="docusaurus.config.js"
 // If you are using dotenv (https://www.npmjs.com/package/dotenv)
@@ -132,7 +132,7 @@ There isn't a silver bullet. You need to weigh your needs and resources before m
 
 ## Self-Hosting {#self-hosting}
 
-Docusaurus can be self-hosted using [`docusaurus serve`](cli.md#docusaurus-serve-sitedir). Change port using `--port` and `--host` to change host.
+Docusaurus can be self-hosted using [`docusaurus serve`](cli.mdx#docusaurus-serve-sitedir). Change port using `--port` and `--host` to change host.
 
 ```bash npm2yarn
 npm run serve -- --build --port 80 --host 0.0.0.0

website/docs/docusaurus-core.mdx

@@ -271,9 +271,9 @@ export default function VisitMyWebsiteMessage() {
 
 ### `<Translate/>` {#translate}
 
-When [localizing your site](./i18n/i18n-introduction.md), the `<Translate/>` component will allow providing **translation support to React components**, such as your homepage. The `<Translate>` component supports [interpolation](#interpolate).
+When [localizing your site](./i18n/i18n-introduction.mdx), the `<Translate/>` component will allow providing **translation support to React components**, such as your homepage. The `<Translate>` component supports [interpolation](#interpolate).
 
-The translation strings will statically extracted from your code with the [`docusaurus write-translations`](./cli.md#docusaurus-write-translations-sitedir) CLI and a `code.json` translation file will be created in `website/i18n/[locale]`.
+The translation strings will statically extracted from your code with the [`docusaurus write-translations`](./cli.mdx#docusaurus-write-translations-sitedir) CLI and a `code.json` translation file will be created in `website/i18n/[locale]`.
 
 :::note
 
@@ -338,7 +338,7 @@ You can even omit the children prop and specify a translation string in your `co
 
 ### `useDocusaurusContext` {#useDocusaurusContext}
 
-React hook to access Docusaurus Context. The context contains the `siteConfig` object from [docusaurus.config.js](api/docusaurus.config.js.md) and some additional site metadata.
+React hook to access Docusaurus Context. The context contains the `siteConfig` object from [docusaurus.config.js](api/docusaurus.config.js.mdx) and some additional site metadata.
 
 ```ts
 type PluginVersionInformation =

website/docs/guides/creating-pages.mdx

@@ -11,13 +11,13 @@ The `@docusaurus/plugin-content-pages` plugin empowers you to create **one-off s
 
 :::note
 
-Pages do not have sidebars, only [docs](./docs/docs-introduction.md) do.
+Pages do not have sidebars, only [docs](./docs/docs-introduction.mdx) do.
 
 :::
 
 :::info
 
-Check the [Pages Plugin API Reference documentation](./../api/plugins/plugin-content-pages.md) for an exhaustive list of options.
+Check the [Pages Plugin API Reference documentation](./../api/plugins/plugin-content-pages.mdx) for an exhaustive list of options.
 
 :::
 

website/docs/guides/docs/docs-create-doc.mdx

@@ -60,11 +60,11 @@ Read more about [importing partial pages](../markdown-features/markdown-features
 
 ## Doc front matter {#doc-front-matter}
 
-The [front matter](../markdown-features/markdown-features-intro.mdx#front-matter) is used to provide additional metadata for your doc page. Front matter is optional—Docusaurus will be able to infer all necessary metadata without the front matter. For example, the [doc tags](#dog-tags) feature introduced below requires using front matter. For all possible fields, see [the API documentation](../../api/plugins/plugin-content-docs.md#markdown-front-matter).
+The [front matter](../markdown-features/markdown-features-intro.mdx#front-matter) is used to provide additional metadata for your doc page. Front matter is optional—Docusaurus will be able to infer all necessary metadata without the front matter. For example, the [doc tags](#dog-tags) feature introduced below requires using front matter. For all possible fields, see [the API documentation](../../api/plugins/plugin-content-docs.mdx#markdown-front-matter).
 
 ## Doc tags {#doc-tags}
 
-Optionally, you can add tags to your doc pages, which introduces another dimension of categorization in addition to the [docs sidebar](./sidebar/index.md). Tags are passed in the front matter as a list of labels:
+Optionally, you can add tags to your doc pages, which introduces another dimension of categorization in addition to the [docs sidebar](./sidebar/index.mdx). Tags are passed in the front matter as a list of labels:
 
 ```md "your-doc-page.md"
 ---
@@ -137,7 +137,7 @@ slug: /bonjour
 Lorem ipsum
 ```
 
-`slug` will be appended to the doc plugin's `routeBasePath`, which is `/docs` by default. See [Docs-only mode](docs-introduction.md#docs-only-mode) for how to remove the `/docs` part from the URL.
+`slug` will be appended to the doc plugin's `routeBasePath`, which is `/docs` by default. See [Docs-only mode](docs-introduction.mdx#docs-only-mode) for how to remove the `/docs` part from the URL.
 
 :::note
 
@@ -161,6 +161,6 @@ Lorem ipsum
 
 ### Sidebars {#sidebars}
 
-When using [autogenerated sidebars](./sidebar/autogenerated.md), the file structure will determine the sidebar structure.
+When using [autogenerated sidebars](./sidebar/autogenerated.mdx), the file structure will determine the sidebar structure.
 
 Our recommendation for file system organization is: make your file system mirror the sidebar structure (so you don't need to handwrite your `sidebars.js` file), and use the `slug` front matter to customize URLs of each document.

website/docs/guides/docs/docs-introduction.mdx

@@ -10,7 +10,7 @@ The docs feature provides users with a way to organize Markdown files in a hiera
 
 :::info
 
-Check the [Docs Plugin API Reference documentation](./../../api/plugins/plugin-content-docs.md) for an exhaustive list of options.
+Check the [Docs Plugin API Reference documentation](./../../api/plugins/plugin-content-docs.mdx) for an exhaustive list of options.
 
 :::
 
@@ -21,7 +21,7 @@ Your site's documentation is organized by four levels, from lowest to highest:
 3. Versions.
 4. Plugin instances.
 
-The guide will introduce them in that order: starting from [how individual pages can be configured](./docs-create-doc.mdx), to [how to create a sidebar or multiple ones](./sidebar/index.md), to [how to create and manage versions](./versioning.md), to [how to use multiple docs plugin instances](./docs-multi-instance.mdx).
+The guide will introduce them in that order: starting from [how individual pages can be configured](./docs-create-doc.mdx), to [how to create a sidebar or multiple ones](./sidebar/index.mdx), to [how to create and manage versions](./versioning.mdx), to [how to use multiple docs plugin instances](./docs-multi-instance.mdx).
 
 ## Docs-only mode {#docs-only-mode}
 

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

@@ -6,11 +6,11 @@ slug: /docs-multi-instance
 
 # Docs Multi-instance
 
-The `@docusaurus/plugin-content-docs` plugin can support [multi-instance](../../using-plugins.md#multi-instance-plugins-and-plugin-ids).
+The `@docusaurus/plugin-content-docs` plugin can support [multi-instance](../../using-plugins.mdx#multi-instance-plugins-and-plugin-ids).
 
 :::note
 
-This feature is only useful for [versioned documentation](./versioning.md). It is recommended to be familiar with docs versioning before reading this page. If you just want [multiple sidebars](./sidebar/multiple-sidebars.md), you can do so within one plugin.
+This feature is only useful for [versioned documentation](./versioning.mdx). It is recommended to be familiar with docs versioning before reading this page. If you just want [multiple sidebars](./sidebar/multiple-sidebars.mdx), you can do so within one plugin.
 
 :::
 
@@ -185,7 +185,7 @@ npm run docusaurus docs:version:community 1.0.0
 
 ## Docs navbar items {#docs-navbar-items}
 
-Each docs-related [theme navbar items](../../api/themes/theme-configuration.md#navbar) take an optional `docsPluginId` attribute.
+Each docs-related [theme navbar items](../../api/themes/theme-configuration.mdx#navbar) take an optional `docsPluginId` attribute.
 
 For example, if you want to have one version dropdown for each mobile SDK (iOS and Android), you could do:
 

website/docs/guides/docs/sidebar/autogenerated.mdx

@@ -33,7 +33,7 @@ module.exports = {
 };
 ```
 
-An `autogenerated` item is converted by Docusaurus to a **sidebar slice** (also discussed in [category shorthands](items.md#category-shorthand)): a list of items of type `doc` or `category`, so you can splice **multiple `autogenerated` items** from multiple directories, interleaving them with regular sidebar items, in one sidebar level.
+An `autogenerated` item is converted by Docusaurus to a **sidebar slice** (also discussed in [category shorthands](items.mdx#category-shorthand)): a list of items of type `doc` or `category`, so you can splice **multiple `autogenerated` items** from multiple directories, interleaving them with regular sidebar items, in one sidebar level.
 
 <details>
 <summary>A real-world example</summary>
@@ -171,7 +171,7 @@ A category index document is a document following one of those filename conventi
 - Named as `README` (case-insensitive): `docs/Guides/README.mdx`
 - Same name as parent folder: `docs/Guides/Guides.md`
 
-This is equivalent to using a category with a [doc link](items.md#category-doc-link):
+This is equivalent to using a category with a [doc link](items.mdx#category-doc-link):
 
 ```js title="sidebars.js"
 module.exports = {
@@ -370,7 +370,7 @@ customProps:
 
 :::info
 
-If the `link` is explicitly specified, Docusaurus will not apply any [default conventions](items.md#category-index-convention).
+If the `link` is explicitly specified, Docusaurus will not apply any [default conventions](items.mdx#category-index-convention).
 
 The doc links can be specified relatively, e.g. if the category is generated with the `guides` directory, `"link": {"type": "doc", "id": "intro"}` will be resolved to the ID `guides/intro`, only falling back to `intro` if a doc with the former ID doesn't exist.
 
@@ -414,8 +414,8 @@ By default, Docusaurus will **remove the number prefix** from the doc id, title,
 Updating a number prefix can be annoying, as it can require **updating multiple existing Markdown links**:
 
 ```diff title="docs/02-Tutorial Easy/01-First Part.md"
-- Check the [Tutorial End](../04-End.md);
-+ Check the [Tutorial End](../05-End.md);
+- Check the [Tutorial End](../04-End.mdx);
++ Check the [Tutorial End](../05-End.mdx);
 ```
 
 :::

website/docs/guides/docs/sidebar/index.mdx

@@ -41,7 +41,7 @@ import DocCardList from '@theme/DocCardList';
 
 ## Default sidebar {#default-sidebar}
 
-If the `sidebarPath` is unspecified, Docusaurus [automatically generates a sidebar](autogenerated.md) for you, by using the filesystem structure of the `docs` folder:
+If the `sidebarPath` is unspecified, Docusaurus [automatically generates a sidebar](autogenerated.mdx) for you, by using the filesystem structure of the `docs` folder:
 
 ```js title="sidebars.js"
 module.exports = {
@@ -108,7 +108,7 @@ module.exports = {
 
 This is a sidebars file that exports one sidebar, called `mySidebar`. It has three top-level items: two categories and one external link. Within each category, there are a few doc links.
 
-A sidebars file can contain [**multiple sidebar objects**](multiple-sidebars.md), identified by their object keys.
+A sidebars file can contain [**multiple sidebar objects**](multiple-sidebars.mdx), identified by their object keys.
 
 ```ts
 type SidebarsFile = {

website/docs/guides/docs/sidebar/items.mdx

@@ -16,9 +16,9 @@ We have introduced three types of item types in the example in the previous sect
 - **[Doc](#sidebar-item-doc)**: link to a doc page, associating it with the sidebar
 - **[Link](#sidebar-item-link)**: link to any internal or external page
 - **[Category](#sidebar-item-category)**: creates a dropdown of sidebar items
-- **[Autogenerated](autogenerated.md)**: generate a sidebar slice automatically
+- **[Autogenerated](autogenerated.mdx)**: generate a sidebar slice automatically
 - **[HTML](#sidebar-item-html)**: renders pure HTML in the item's position
-- **[\*Ref](multiple-sidebars.md#sidebar-item-ref)**: link to a doc page, without making the item take part in navigation generation
+- **[\*Ref](multiple-sidebars.mdx#sidebar-item-ref)**: link to a doc page, without making the item take part in navigation generation
 
 ## Doc: link to a doc {#sidebar-item-doc}
 
@@ -231,7 +231,7 @@ With category links, clicking on a category can navigate you to another page.
 
 Use category links to introduce a category of documents.
 
-Autogenerated categories can use the [`_category_.yml`](./autogenerated.md#category-item-metadata) file to declare the link.
+Autogenerated categories can use the [`_category_.yml`](./autogenerated.mdx#category-item-metadata) file to declare the link.
 
 :::
 
@@ -288,7 +288,7 @@ module.exports = {
 };
 ```
 
-See it in action on the [i18n introduction page](../../../i18n/i18n-introduction.md).
+See it in action on the [i18n introduction page](../../../i18n/i18n-introduction.mdx).
 
 #### Embedding generated index in doc page {#embedding-generated-index-in-doc-page}
 
@@ -569,7 +569,7 @@ module.exports = {
 };
 ```
 
-Note how the two consecutive category shorthands are compressed into one object with two entries. This syntax generates a **sidebar slice**: you shouldn't see that object as one bulk item—this object is unwrapped, with each entry becoming a separate item, and they spliced together with the rest of the items (in this case, the "Learn more" link) to form the final sidebar level. Sidebar slices are also important when discussing [autogenerated sidebars](autogenerated.md).
+Note how the two consecutive category shorthands are compressed into one object with two entries. This syntax generates a **sidebar slice**: you shouldn't see that object as one bulk item—this object is unwrapped, with each entry becoming a separate item, and they spliced together with the rest of the items (in this case, the "Learn more" link) to form the final sidebar level. Sidebar slices are also important when discussing [autogenerated sidebars](autogenerated.mdx).
 
 Wherever you have an array of items that is reduced to one category shorthand, you can omit that enclosing array as well.
 

website/docs/guides/docs/sidebar/multiple-sidebars.mdx

@@ -10,8 +10,8 @@ You can create a sidebar for each **set of Markdown files** that you want to **g
 
 The Docusaurus site is a good example of using multiple sidebars:
 
-- [Docs](../../../introduction.md)
-- [API](../../../cli.md)
+- [Docs](../../../introduction.mdx)
+- [API](../../../cli.mdx)
 
 :::
 

website/docs/guides/docs/versioning.mdx

@@ -72,10 +72,19 @@ By default, the `current` docs version is labeled as `Next` and hosted under `/d
 Note the terminology we use here.
 
 <dl>
-<dt><b>Current version</b></dt>
-<dd>The version placed in the <code>./docs</code> folder.</dd>
-<dt><b>Latest version / last version</b></dt>
-<dd>The version served by default for docs navbar items. Usually has path <code>/docs</code>.</dd>
+  <dt>
+    <b>Current version</b>
+  </dt>
+  <dd>
+    The version placed in the <code>./docs</code> folder.
+  </dd>
+  <dt>
+    <b>Latest version / last version</b>
+  </dt>
+  <dd>
+    The version served by default for docs navbar items. Usually has path{' '}
+    <code>/docs</code>.
+  </dd>
 </dl>
 
 Current version is defined by the **file system location**, while latest version is defined by the **the navigation behavior**. They may or may not be the same version! (And the default configuration, as shown in the table above, would treat them as different: current version at `/docs/next` and latest at `/docs`.)
@@ -94,7 +103,7 @@ npm run docusaurus docs:version 1.1.0
 When tagging a new version, the document versioning mechanism will:
 
 - Copy the full `docs/` folder contents into a new `versioned_docs/version-[versionName]/` folder.
-- Create a versioned sidebars file based from your current [sidebar](docs-introduction.md#sidebar) configuration (if it exists) - saved as `versioned_sidebars/version-[versionName]-sidebars.json`.
+- Create a versioned sidebars file based from your current [sidebar](docs-introduction.mdx#sidebar) configuration (if it exists) - saved as `versioned_sidebars/version-[versionName]-sidebars.json`.
 - Append the new version number to `versions.json`.
 
 ### Creating new docs {#creating-new-docs}
@@ -211,16 +220,16 @@ We offer these plugin options to customize versioning behavior:
   - `badge`: show a badge with the version name at the top of a doc of that version.
   - `className`: add a custom `className` to the `<html>` element of doc pages of that version.
 
-See [docs plugin configuration](../../api/plugins/plugin-content-docs.md#configuration) for more details.
+See [docs plugin configuration](../../api/plugins/plugin-content-docs.mdx#configuration) for more details.
 
 ## Navbar items {#navbar-items}
 
 We offer several navbar items to help you quickly set up navigation without worrying about versioned routes.
 
-- [`doc`](../../api/themes/theme-configuration.md#navbar-doc-link): a link to a doc.
-- [`docSidebar`](../../api/themes/theme-configuration.md#navbar-doc-sidebar): a link to the first item in a sidebar.
-- [`docsVersion`](../../api/themes/theme-configuration.md#navbar-docs-version): a link to the main doc of the currently viewed version.
-- [`docsVersionDropdown`](../../api/themes/theme-configuration.md#navbar-docs-version-dropdown): a dropdown containing all the versions available.
+- [`doc`](../../api/themes/theme-configuration.mdx#navbar-doc-link): a link to a doc.
+- [`docSidebar`](../../api/themes/theme-configuration.mdx#navbar-doc-sidebar): a link to the first item in a sidebar.
+- [`docsVersion`](../../api/themes/theme-configuration.mdx#navbar-docs-version): a link to the main doc of the currently viewed version.
+- [`docsVersionDropdown`](../../api/themes/theme-configuration.mdx#navbar-docs-version-dropdown): a dropdown containing all the versions available.
 
 These links would all look for an appropriate version to link to, in the following order:
 
@@ -260,9 +269,9 @@ Don't use relative paths import within the docs. Because when we cut a version t
 Refer to other docs by relative file paths with the `.md` extension, so that Docusaurus can rewrite them to actual URL paths during building. Files will be linked to the correct corresponding version.
 
 ```md
-The [@hello](hello.md#paginate) document is great!
+The [@hello](hello.mdx#paginate) document is great!
 
-See the [Tutorial](../getting-started/tutorial.md) for more info.
+See the [Tutorial](../getting-started/tutorial.mdx) for more info.
 ```
 
 ### Global or versioned collocated assets {#global-or-versioned-collocated-assets}

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

@@ -259,7 +259,7 @@ There are two kinds of customizations possible with admonitions: **parsing** and
 
 ### Customizing rendering behavior {#customizing-rendering-behavior}
 
-You can customize how each individual admonition type is rendered through [swizzling](../../swizzling.md). You can often achieve your goal through a simple wrapper. For example, in the follow example, we swap out the icon for `info` admonitions only.
+You can customize how each individual admonition type is rendered through [swizzling](../../swizzling.mdx). You can often achieve your goal through a simple wrapper. For example, in the follow example, we swap out the icon for `info` admonitions only.
 
 ```jsx title="src/theme/Admonition.js"
 import React from 'react';

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

@@ -80,7 +80,7 @@ All of the above result in displaying the image:
 
 :::note
 
-If you are using [@docusaurus/plugin-ideal-image](../../api/plugins/plugin-ideal-image.md), you need to use the dedicated image component, as documented.
+If you are using [@docusaurus/plugin-ideal-image](../../api/plugins/plugin-ideal-image.mdx), you need to use the dedicated image component, as documented.
 
 :::
 
@@ -214,7 +214,7 @@ To toggle the visibility of an image using the path fragment (for GitHub, it's `
 
 ## Static assets {#static-assets}
 
-If a Markdown link or image has an absolute path, the path will be seen as a file path and will be resolved from the static directories. For example, if you have configured [static directories](../../static-assets.md) to be `['public', 'static']`, then for the following image:
+If a Markdown link or image has an absolute path, the path will be seen as a file path and will be resolved from the static directories. For example, if you have configured [static directories](../../static-assets.mdx) to be `['public', 'static']`, then for the following image:
 
 ```md title="my-doc.md"
 ![An image from the static](/img/docusaurus.png)

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

@@ -380,7 +380,7 @@ You can disable the default line highlighting comments with `magicComments: []`.
 
 Every magic comment entry will contain three keys: `className` (required), `line`, which applies to the directly next line, or `block` (containing `start` and `end`), which applies to the entire block enclosed by the two comments.
 
-Using CSS to target the class can already do a lot, but you can unlock the full potential of this feature through [swizzling](../../swizzling.md).
+Using CSS to target the class can already do a lot, but you can unlock the full potential of this feature through [swizzling](../../swizzling.mdx).
 
 ```bash npm2yarn
 npm run swizzle @docusaurus/theme-classic CodeBlock/Line
@@ -751,7 +751,7 @@ Displaying CLI commands in both npm and Yarn is a very common need, for example:
 npm install @docusaurus/remark-plugin-npm2yarn
 ```
 
-Docusaurus provides such a utility out of the box, freeing you from using the `Tabs` component every time. To enable this feature, first install the `@docusaurus/remark-plugin-npm2yarn` package as above, and then in `docusaurus.config.js`, for the plugins where you need this feature (doc, blog, pages, etc.), register it in the `remarkPlugins` option. (See [Docs configuration](../../api/plugins/plugin-content-docs.md#ex-config) for more details on configuration format)
+Docusaurus provides such a utility out of the box, freeing you from using the `Tabs` component every time. To enable this feature, first install the `@docusaurus/remark-plugin-npm2yarn` package as above, and then in `docusaurus.config.js`, for the plugins where you need this feature (doc, blog, pages, etc.), register it in the `remarkPlugins` option. (See [Docs configuration](../../api/plugins/plugin-content-docs.mdx#ex-config) for more details on configuration format)
 
 ```js title="docusaurus.config.js"
 module.exports = {

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

@@ -47,7 +47,7 @@ This `<head>` declaration has been added to the current Markdown doc as a demo.
 
 :::note
 
-This feature is built on top of the Docusaurus [`<Head>`](./../../docusaurus-core.md#head) component. Refer to [react-helmet](https://github.com/nfl/react-helmet) for exhaustive documentation.
+This feature is built on top of the Docusaurus [`<Head>`](./../../docusaurus-core.mdx#head) component. Refer to [react-helmet](https://github.com/nfl/react-helmet) for exhaustive documentation.
 
 :::
 
@@ -59,14 +59,14 @@ Content plugins (e.g. docs and blog) provide front matter options like `descript
 
 ## Markdown page description {#markdown-page-description}
 
-The Markdown pages' description metadata may be used in more places than the head metadata. For example, the docs plugin's [generated category index](../docs/sidebar/items.md#generated-index-page) uses the description metadata for the doc cards.
+The Markdown pages' description metadata may be used in more places than the head metadata. For example, the docs plugin's [generated category index](../docs/sidebar/items.mdx#generated-index-page) uses the description metadata for the doc cards.
 
 By default, the description is the first content-ful line, with some efforts to convert it to plain text. For example, the following file...
 
 ```md
 # Title
 
-Main content... May contain some [links](./file.md) or **emphasis**.
+Main content... May contain some [links](./file.mdx) or **emphasis**.
 ```
 
 ...will have the default description "Main content... May contain some links or emphasis". However, **it's not designed to be fully functional**. Where it fails to produce reasonable descriptions, you can explicitly provide one through front matter:
@@ -78,5 +78,5 @@ description: This description will override the default.
 
 # Title
 
-Main content... May contain some [links](./file.md) or **emphasis**.
+Main content... May contain some [links](./file.mdx) or **emphasis**.
 ```

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

@@ -10,7 +10,7 @@ There are two ways of adding a link to another page: through a **URL path** and
 
 ```md
 - [URL path to another document](./installation)
-- [file path to another document](./installation.md)
+- [file path to another document](./installation.mdx)
 ```
 
 URL paths are unprocessed by Docusaurus, and you can see them as directly rendering to `<a href="./installation">`, i.e. it will be resolved according to the page's URL location, rather than its file-system location.
@@ -20,21 +20,21 @@ If you want to reference another Markdown file **included by the same plugin**,
 For example, if you are in `docs/folder/doc1.md` and you want to reference `docs/folder/doc2.md`, `docs/folder/subfolder/doc3.md` and `docs/otherFolder/doc4.md`:
 
 ```md title="docs/folder/doc1.md"
-I am referencing a [document](doc2.md).
+I am referencing a [document](doc2.mdx).
 
-Reference to another [document in a subfolder](subfolder/doc3.md).
+Reference to another [document in a subfolder](subfolder/doc3.mdx).
 
-[Relative document](../otherFolder/doc4.md) referencing works as well.
+[Relative document](../otherFolder/doc4.mdx) referencing works as well.
 ```
 
-Relative file paths are resolved against the current file's directory. Absolute file paths, on the other hand, are resolved relative to the **content root**, usually `docs/`, `blog/`, or [localized ones](../../i18n/i18n-tutorial.md) like `i18n/zh-Hans/plugin-content-docs/current`.
+Relative file paths are resolved against the current file's directory. Absolute file paths, on the other hand, are resolved relative to the **content root**, usually `docs/`, `blog/`, or [localized ones](../../i18n/i18n-tutorial.mdx) like `i18n/zh-Hans/plugin-content-docs/current`.
 
 Absolute file paths can also be relative to the site directory. However, beware that links that begin with `/docs/` or `/blog/` are **not portable** as you would need to manually update them if you create new doc versions or localize them.
 
 ```md
-You can write [links](/otherFolder/doc4.md) relative to the content root (`/docs/`).
+You can write [links](/otherFolder/doc4.mdx) relative to the content root (`/docs/`).
 
-You can also write [links](/docs/otherFolder/doc4.md) relative to the site directory, but it's not recommended.
+You can also write [links](/docs/otherFolder/doc4.mdx) relative to the site directory, but it's not recommended.
 ```
 
 Using relative _file_ paths (with `.md` extensions) instead of relative _URL_ links provides the following benefits:
@@ -42,8 +42,8 @@ Using relative _file_ paths (with `.md` extensions) instead of relative _URL_ li
 - Links will keep working on the GitHub interface and many Markdown editors
 - You can customize the files' slugs without having to update all the links
 - Moving files around the folders can be tracked by your editor, and some editors may automatically update file links
-- A [versioned doc](../docs/versioning.md) will link to another doc of the exact same version
-- Relative URL links are very likely to break if you update the [`trailingSlash` config](../../api/docusaurus.config.js.md#trailingSlash)
+- A [versioned doc](../docs/versioning.mdx) will link to another doc of the exact same version
+- Relative URL links are very likely to break if you update the [`trailingSlash` config](../../api/docusaurus.config.js.mdx#trailingSlash)
 
 :::warning
 

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

@@ -14,7 +14,7 @@ Sometimes, you may want to extend or tweak your Markdown syntax. For example:
 
 And the answer is: create an MDX plugin! MDX has a built-in [plugin system](https://mdxjs.com/advanced/plugins/) that can be used to customize how the Markdown files will be parsed and transformed to JSX. There are three typical use-cases of MDX plugins:
 
-- Using existing [remark plugins](https://github.com/remarkjs/remark/blob/main/doc/plugins.md#list-of-plugins) or [rehype plugins](https://github.com/rehypejs/rehype/blob/main/doc/plugins.md#list-of-plugins);
+- Using existing [remark plugins](https://github.com/remarkjs/remark/blob/main/doc/plugins.mdx#list-of-plugins) or [rehype plugins](https://github.com/rehypejs/rehype/blob/main/doc/plugins.mdx#list-of-plugins);
 - Creating remark/rehype plugins to transform the elements generated by existing MDX syntax;
 - Creating remark/rehype plugins to introduce new syntaxes to MDX.
 
@@ -121,7 +121,7 @@ If there isn't an existing package that satisfies your customization need, you c
 
 :::note
 
-The writeup below is **not** meant to be a comprehensive guide to creating a plugin, but just an illustration of how to make it work with Docusaurus. Visit the [Remark](https://github.com/remarkjs/remark/blob/main/doc/plugins.md#create-plugins) or [Rehype](https://github.com/remarkjs/remark/blob/main/doc/plugins.md#create-plugins) documentation for a more in-depth explanation of how they work.
+The writeup below is **not** meant to be a comprehensive guide to creating a plugin, but just an illustration of how to make it work with Docusaurus. Visit the [Remark](https://github.com/remarkjs/remark/blob/main/doc/plugins.mdx#create-plugins) or [Rehype](https://github.com/remarkjs/remark/blob/main/doc/plugins.mdx#create-plugins) documentation for a more in-depth explanation of how they work.
 
 :::
 

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

@@ -84,7 +84,7 @@ Since all doc files are parsed using MDX, anything that looks like HTML is actua
 <span style={{backgroundColor: 'red'}}>Foo</span>
 ```
 
-This behavior is different from Docusaurus 1. See also [Migrating from v1 to v2](../../migration/migration-manual.md#convert-style-attributes-to-style-objects-in-mdx).
+This behavior is different from Docusaurus 1. See also [Migrating from v1 to v2](../../migration/migration-manual.mdx#convert-style-attributes-to-style-objects-in-mdx).
 
 In addition, MDX is not [100% compatible with CommonMark](https://github.com/facebook/docusaurus/issues/3018). Use the **[MDX playground](https://mdx-git-renovate-babel-monorepo-mdx.vercel.app/playground)** to ensure that your syntax is valid MDX.
 
@@ -106,7 +106,7 @@ import BrowserWindow from '@site/src/components/BrowserWindow';
 
 :::tip
 
-The `@site` alias points to your website's directory, usually where the `docusaurus.config.js` file is. Using an alias instead of relative paths (`'../../src/components/BrowserWindow'`) saves you from updating import paths when moving files around, or when [versioning docs](../docs/versioning.md) and [translating](../../i18n/i18n-tutorial.md).
+The `@site` alias points to your website's directory, usually where the `docusaurus.config.js` file is. Using an alias instead of relative paths (`'../../src/components/BrowserWindow'`) saves you from updating import paths when moving files around, or when [versioning docs](../docs/versioning.mdx) and [translating](../../i18n/i18n-tutorial.mdx).
 
 :::
 
@@ -159,9 +159,9 @@ It will be compiled to a React component containing `ul`, `li`, `p`, and `highli
 
 In Docusaurus, this MDX component scope is provided by the `@theme/MDXComponents` component. It's not a React component, _per se_, unlike most other exports under the `@theme/` alias: it is a record from tag names like `ul` and `img` to their custom implementations.
 
-If you [swizzle](../../swizzling.md) this component, you will find all tags that have been re-implemented, and you can further customize our implementation by swizzling the respective sub-component, like `@theme/MDXComponents/Head` (which is used to implement the [`<head>`](./markdown-features-head-metadata.mdx) feature).
+If you [swizzle](../../swizzling.mdx) this component, you will find all tags that have been re-implemented, and you can further customize our implementation by swizzling the respective sub-component, like `@theme/MDXComponents/Head` (which is used to implement the [`<head>`](./markdown-features-head-metadata.mdx) feature).
 
-If you want to register extra tag names (like the `<highlight>` tag above), you should consider [wrapping `@theme/MDXComponents`](../../swizzling.md#wrapping), so you don't have to maintain all the existing mappings. Since the swizzle CLI doesn't allow wrapping non-component files yet, you should manually create the wrapper:
+If you want to register extra tag names (like the `<highlight>` tag above), you should consider [wrapping `@theme/MDXComponents`](../../swizzling.mdx#wrapping), so you don't have to maintain all the existing mappings. Since the swizzle CLI doesn't allow wrapping non-component files yet, you should manually create the wrapper:
 
 ```js title="src/theme/MDXComponents.js"
 import React from 'react';

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

@@ -49,7 +49,7 @@ A special Markdown syntax lets you set an **explicit heading id**:
 
 :::tip
 
-Use the **[`write-heading-ids`](../../cli.md#docusaurus-write-heading-ids-sitedir)** CLI command to add explicit IDs to all your Markdown documents.
+Use the **[`write-heading-ids`](../../cli.mdx#docusaurus-write-heading-ids-sitedir)** CLI command to add explicit IDs to all your Markdown documents.
 
 :::
 
@@ -73,7 +73,7 @@ toc_max_heading_level: 5
 ---
 ```
 
-To set the heading level for _all_ pages, use the [`themeConfig.tableOfContents`](../../api/themes/theme-configuration.md#table-of-contents) option.
+To set the heading level for _all_ pages, use the [`themeConfig.tableOfContents`](../../api/themes/theme-configuration.mdx#table-of-contents) option.
 
 ```js title="docusaurus.config.js"
 module.exports = {

website/docs/guides/whats-next.md

@@ -1,21 +0,0 @@
-# What's next?
-
-Congratulations! You have understood most core features of Docusaurus now. You have:
-
-- [Used the pages plugin](./creating-pages.md) to create a standalone React / Markdown page
-- [Used the docs plugin](./docs/docs-introduction.md) to create documentation pages. This includes [configuring the sidebar](./docs/sidebar/index.md), and even [versioning](./docs/versioning.md)
-- [Used the blog plugin](../blog.mdx) to create a fully featured blog
-- Tried your hands on [a range of Markdown features](./markdown-features/markdown-features-intro.mdx), which are useful for all content plugins
-- [Used stylesheets](../styling-layout.md) or [swizzling](../swizzling.md) to customize your site's appearance
-- [Included images and other assets](../static-assets.md) in your pages
-- [Added search](../search.md) to your site
-- Understood how [browser support](../browser-support.md) and [SEO](../seo.md) are done through standard Docusaurus APIs
-- Learned about how [individual plugins](../using-plugins.md) are installed and configured
-- [Deployed](../deployment.mdx) your site to a content host
-- [Internationalized](../i18n/i18n-tutorial.md) your site to include multiple languages
-
-At this point, you probably have a big `docusaurus.config.js` already😄 However, you haven't written much code yet! Most of the features are implemented through calling encapsulated Docusaurus APIs. As you continue your journey, you can take three paths:
-
-- Learn more advanced Docusaurus concepts. This will help you gain a deeper understand of what the APIs do.
-- Read about [all existing APIs](../docusaurus-core.md). Many of them have not been covered in the Guides!
-- Learn to [develop a plugin](../api/plugin-methods/README.md) to extend the functionality of your site.

website/docs/guides/whats-next.mdx

@@ -0,0 +1,21 @@
+# What's next?
+
+Congratulations! You have understood most core features of Docusaurus now. You have:
+
+- [Used the pages plugin](./creating-pages.mdx) to create a standalone React / Markdown page
+- [Used the docs plugin](./docs/docs-introduction.mdx) to create documentation pages. This includes [configuring the sidebar](./docs/sidebar/index.mdx), and even [versioning](./docs/versioning.mdx)
+- [Used the blog plugin](../blog.mdx) to create a fully featured blog
+- Tried your hands on [a range of Markdown features](./markdown-features/markdown-features-intro.mdx), which are useful for all content plugins
+- [Used stylesheets](../styling-layout.mdx) or [swizzling](../swizzling.mdx) to customize your site's appearance
+- [Included images and other assets](../static-assets.mdx) in your pages
+- [Added search](../search.mdx) to your site
+- Understood how [browser support](../browser-support.mdx) and [SEO](../seo.mdx) are done through standard Docusaurus APIs
+- Learned about how [individual plugins](../using-plugins.mdx) are installed and configured
+- [Deployed](../deployment.mdx) your site to a content host
+- [Internationalized](../i18n/i18n-tutorial.mdx) your site to include multiple languages
+
+At this point, you probably have a big `docusaurus.config.js` already😄 However, you haven't written much code yet! Most of the features are implemented through calling encapsulated Docusaurus APIs. As you continue your journey, you can take three paths:
+
+- Learn more advanced Docusaurus concepts. This will help you gain a deeper understand of what the APIs do.
+- Read about [all existing APIs](../docusaurus-core.mdx). Many of them have not been covered in the Guides!
+- Learn to [develop a plugin](../api/plugin-methods/README.mdx) to extend the functionality of your site.

website/docs/i18n/i18n-crowdin.mdx

@@ -44,7 +44,7 @@ Read the **[official documentation](https://support.crowdin.com/)** to know more
 
 ## Crowdin tutorial {#crowdin-tutorial}
 
-This is a walk-through of using Crowdin to translate a newly initialized English Docusaurus website into French, and assume you already followed the [i18n tutorial](./i18n-tutorial.md).
+This is a walk-through of using Crowdin to translate a newly initialized English Docusaurus website into French, and assume you already followed the [i18n tutorial](./i18n-tutorial.mdx).
 
 The end result can be seen at [docusaurus-crowdin-example.netlify.app](https://docusaurus-crowdin-example.netlify.app/) ([repository](https://github.com/slorber/docusaurus-crowdin-example)).
 

website/docs/i18n/i18n-git.mdx

@@ -33,7 +33,7 @@ Refer to the [Docusaurus i18n RFC](https://github.com/facebook/docusaurus/issues
 
 ## Initialization {#initialization}
 
-This is a walk-through of using Git to translate a newly initialized English Docusaurus website into French, and assume you already followed the [i18n tutorial](./i18n-tutorial.md).
+This is a walk-through of using Git to translate a newly initialized English Docusaurus website into French, and assume you already followed the [i18n tutorial](./i18n-tutorial.mdx).
 
 ### Prepare the Docusaurus site {#prepare-the-docusaurus-site}
 
@@ -89,7 +89,7 @@ export default function Home() {
 
 ### Initialize the `i18n` folder {#initialize-the-i18n-folder}
 
-Use the [write-translations](../cli.md#docusaurus-write-translations-sitedir) CLI command to initialize the JSON translation files for the French locale:
+Use the [write-translations](../cli.mdx#docusaurus-write-translations-sitedir) CLI command to initialize the JSON translation files for the French locale:
 
 ```bash npm2yarn
 npm run write-translations -- --locale fr
@@ -158,7 +158,7 @@ To keep your translated sites consistent, when the `website/docs/doc1.md` doc is
 
 ### JSON translations {#json-translations}
 
-To help you maintain the JSON translation files, it is possible to run again the [write-translations](../cli.md#docusaurus-write-translations-sitedir) CLI command:
+To help you maintain the JSON translation files, it is possible to run again the [write-translations](../cli.mdx#docusaurus-write-translations-sitedir) CLI command:
 
 ```bash npm2yarn
 npm run write-translations -- --locale fr

website/docs/i18n/i18n-introduction.mdx

@@ -44,7 +44,7 @@ We don't provide support for:
 
 Overview of the workflow to create a translated Docusaurus website:
 
-1. **Configure**: declare the default locale and alternative locales in [`docusaurus.config.js`](../api/docusaurus.config.js.md#i18n)
+1. **Configure**: declare the default locale and alternative locales in [`docusaurus.config.js`](../api/docusaurus.config.js.mdx#i18n)
 2. **Translate**: put the translation files at the correct filesystem location
 3. **Deploy**: build and deploy your site using a single or multi-domain strategy
 
@@ -127,11 +127,11 @@ website/i18n
         └── navbar.json   # Text labels in your navbar theme config
 ```
 
-The JSON files are initialized with the [`docusaurus write-translations`](../cli.md#docusaurus-write-translations-sitedir) CLI command. Each plugin sources its own translated content under the corresponding folder, while the `code.json` file defines all text labels used in the React code.
+The JSON files are initialized with the [`docusaurus write-translations`](../cli.mdx#docusaurus-write-translations-sitedir) CLI command. Each plugin sources its own translated content under the corresponding folder, while the `code.json` file defines all text labels used in the React code.
 
 Each content plugin or theme is different, and **defines its own translation files location**:
 
-- [Docs i18n](../api/plugins/plugin-content-docs.md#i18n)
-- [Blog i18n](../api/plugins/plugin-content-blog.md#i18n)
-- [Pages i18n](../api/plugins/plugin-content-pages.md#i18n)
-- [Themes i18n](../api/themes/theme-configuration.md#i18n)
+- [Docs i18n](../api/plugins/plugin-content-docs.mdx#i18n)
+- [Blog i18n](../api/plugins/plugin-content-blog.mdx#i18n)
+- [Pages i18n](../api/plugins/plugin-content-pages.mdx#i18n)
+- [Themes i18n](../api/themes/theme-configuration.mdx#i18n)

website/docs/i18n/i18n-tutorial.mdx

@@ -23,7 +23,7 @@ Modify `docusaurus.config.js` to add the i18n support for the French language.
 
 ### Site configuration {#site-configuration}
 
-Use the [site i18n configuration](./../api/docusaurus.config.js.md#i18n) to declare the i18n locales:
+Use the [site i18n configuration](./../api/docusaurus.config.js.mdx#i18n) to declare the i18n locales:
 
 ```js title="docusaurus.config.js"
 module.exports = {
@@ -106,7 +106,7 @@ After copying files around, restart your site with `npm run start -- --locale fr
 
 ### Translate your React code {#translate-your-react-code}
 
-For any React code you've written yourself: React pages, React components, etc., you will use the [**translation APIs**](../docusaurus-core.md#translate).
+For any React code you've written yourself: React pages, React components, etc., you will use the [**translation APIs**](../docusaurus-core.mdx#translate).
 
 Locate all text labels in your React code that will be visible to your users, and mark them with the translation APIs. There are two kinds of APIs:
 
@@ -216,7 +216,7 @@ export default function Home() {
 
 :::info
 
-Docusaurus provides a **very small and lightweight translation runtime** on purpose, and only supports basic [placeholders interpolation](../docusaurus-core.md#interpolate), using a subset of the [ICU Message Format](https://formatjs.io/docs/core-concepts/icu-syntax/).
+Docusaurus provides a **very small and lightweight translation runtime** on purpose, and only supports basic [placeholders interpolation](../docusaurus-core.mdx#interpolate), using a subset of the [ICU Message Format](https://formatjs.io/docs/core-concepts/icu-syntax/).
 
 Most documentation websites are generally **static** and don't need advanced i18n features (**plurals**, **genders**, etc.). Use a library like [react-intl](https://www.npmjs.com/package/react-intl) for more advanced use-cases.
 
@@ -328,7 +328,7 @@ JSON translation files are used for everything that is interspersed in your code
 - Blog sidebar title in plugin options
 - ...
 
-Run the [write-translations](../cli.md#docusaurus-write-translations-sitedir) command:
+Run the [write-translations](../cli.mdx#docusaurus-write-translations-sitedir) command:
 
 ```bash npm2yarn
 npm run write-translations -- --locale fr
@@ -397,7 +397,7 @@ cp -r docs/** i18n/fr/docusaurus-plugin-content-docs/current
 
 :::info
 
-Notice that the `docusaurus-plugin-content-docs` plugin always divides its content by versions. The data in `./docs` folder will be translated in the `current` subfolder and `current.json` file. See [the doc versioning guide](../guides/docs/versioning.md#terminology) for more information about what "current" means.
+Notice that the `docusaurus-plugin-content-docs` plugin always divides its content by versions. The data in `./docs` folder will be translated in the `current` subfolder and `current.json` file. See [the doc versioning guide](../guides/docs/versioning.mdx#terminology) for more information about what "current" means.
 
 :::
 
@@ -514,4 +514,4 @@ It is also possible to deploy each locale as a separate subdomain, assemble the
 
 Docusaurus doesn't care about how you manage your translations: all it needs is that all translation files (JSON, Markdown, or other data files) are available in the file system during building. However, as site creators, you would need to consider how translations are managed so your translation contributors could collaborate well.
 
-We will share two common translation collaboration strategies: [**using git**](./i18n-git.md) and [**using Crowdin**](./i18n-crowdin.mdx).
+We will share two common translation collaboration strategies: [**using git**](./i18n-git.mdx) and [**using Crowdin**](./i18n-crowdin.mdx).

website/docs/installation.mdx

@@ -13,7 +13,7 @@ Docusaurus is essentially a set of npm [packages](https://github.com/facebook/do
 
 :::tip
 
-Use the **[Fast Track](introduction.md#fast-track)** to understand Docusaurus in **5 minutes ⏱**!
+Use the **[Fast Track](introduction.mdx#fast-track)** to understand Docusaurus in **5 minutes ⏱**!
 
 Use **[docusaurus.new](https://docusaurus.new)** to test Docusaurus immediately in your browser!
 
@@ -34,7 +34,7 @@ npx create-docusaurus@latest my-website classic
 
 We recommend the `classic` template so that you can get started quickly, and it contains features found in Docusaurus 1. The `classic` template contains `@docusaurus/preset-classic` which includes standard documentation, a blog, custom pages, and a CSS framework (with dark mode support). You can get up and running extremely quickly with the classic template and customize things later on when you have gained more familiarity with Docusaurus.
 
-You can also use the template's TypeScript variant by passing the `--typescript` flag. See [TypeScript support](./typescript-support.md) for more information.
+You can also use the template's TypeScript variant by passing the `--typescript` flag. See [TypeScript support](./typescript-support.mdx) for more information.
 
 ```bash
 npx create-docusaurus@latest my-website classic --typescript
@@ -89,7 +89,7 @@ pnpm create docusaurus
 
 </details>
 
-Run `npx create-docusaurus@latest --help`, or check out its [API docs](./api/misc/create-docusaurus.md) for more information about all available flags.
+Run `npx create-docusaurus@latest --help`, or check out its [API docs](./api/misc/create-docusaurus.mdx) for more information about all available flags.
 
 ## Project structure {#project-structure}
 
@@ -124,9 +124,9 @@ my-website
 ### Project structure rundown {#project-structure-rundown}
 
 - `/blog/` - Contains the blog Markdown files. You can delete the directory if you've disabled the blog plugin, or you can change its name after setting the `path` option. More details can be found in the [blog guide](blog.mdx)
-- `/docs/` - Contains the Markdown files for the docs. Customize the order of the docs sidebar in `sidebars.js`. You can delete the directory if you've disabled the docs plugin, or you can change its name after setting the `path` option. More details can be found in the [docs guide](./guides/docs/docs-introduction.md)
+- `/docs/` - Contains the Markdown files for the docs. Customize the order of the docs sidebar in `sidebars.js`. You can delete the directory if you've disabled the docs plugin, or you can change its name after setting the `path` option. More details can be found in the [docs guide](./guides/docs/docs-introduction.mdx)
 - `/src/` - Non-documentation files like pages or custom React components. You don't have to strictly put your non-documentation files here, but putting them under a centralized directory makes it easier to specify in case you need to do some sort of linting/processing
-  - `/src/pages` - Any JSX/TSX/MDX file within this directory will be converted into a website page. More details can be found in the [pages guide](guides/creating-pages.md)
+  - `/src/pages` - Any JSX/TSX/MDX file within this directory will be converted into a website page. More details can be found in the [pages guide](guides/creating-pages.mdx)
 - `/static/` - Static directory. Any contents inside here will be copied into the root of the final `build` directory
 - `/docusaurus.config.js` - A config file containing the site configuration. This is the equivalent of `siteConfig.js` in Docusaurus v1
 - `/package.json` - A Docusaurus website is a React app. You can install and use any npm packages you like in them

website/docs/introduction.mdx

@@ -83,7 +83,7 @@ A [lot of users](/showcase) are already using Docusaurus v2 ([trends](https://ww
 - :x: You don't want a single-page application (SPA)
 - :x: You need support for IE11 (...do you? IE [has already reached end-of-life](https://docs.microsoft.com/en-us/lifecycle/products/internet-explorer-11) and is no longer officially supported)
 
-For existing v1 users that are seeking to upgrade to v2, you can follow our [migration guide](./migration/migration-overview.md).
+For existing v1 users that are seeking to upgrade to v2, you can follow our [migration guide](./migration/migration-overview.mdx).
 
 ## Features {#features}
 

website/docs/migration/migration-manual.mdx

@@ -5,7 +5,7 @@ toc_max_heading_level: 4
 
 # Manual migration
 
-This manual migration process should be run after the [automated migration process](./migration-automated.md), to complete the missing parts, or debug issues in the migration CLI output.
+This manual migration process should be run after the [automated migration process](./migration-automated.mdx), to complete the missing parts, or debug issues in the migration CLI output.
 
 ## Project setup {#project-setup}
 
@@ -123,7 +123,7 @@ yarn-error.log*
 
 ### `README` {#readme}
 
-The D1 website may have an existing README file. You can modify it to reflect the D2 changes, or copy the default [Docusaurus v2 README](https://github.com/facebook/docusaurus/blob/main/packages/create-docusaurus/templates/shared/README.md).
+The D1 website may have an existing README file. You can modify it to reflect the D2 changes, or copy the default [Docusaurus v2 README](https://github.com/facebook/docusaurus/blob/main/packages/create-docusaurus/templates/shared/README.mdx).
 
 ## Site configurations {#site-configurations}
 
@@ -211,7 +211,7 @@ Alteratively, use the following tool to generate the different shades for your w
 
 import ColorGenerator from '@site/src/components/ColorGenerator';
 
-<ColorGenerator/>
+<ColorGenerator />
 
 #### `footerIcon`, `copyright`, `ogImage`, `twitterImage`, `docsSideNavCollapsible` {#footericon-copyright-ogimage-twitterimage-docssidenavcollapsible}
 
@@ -455,7 +455,7 @@ If you had `cleanUrl: false` in v1, it's possible that people published links to
 
 For SEO reasons, and avoiding breaking links, you should configure server-side redirect rules on your hosting provider.
 
-As an escape hatch, you could use [@docusaurus/plugin-client-redirects](../api/plugins/plugin-client-redirects.md) to create client-side redirects from `/installation.html` to `/installation`.
+As an escape hatch, you could use [@docusaurus/plugin-client-redirects](../api/plugins/plugin-client-redirects.mdx) to create client-side redirects from `/installation.html` to `/installation`.
 
 ```js
 module.exports = {
@@ -476,7 +476,7 @@ If you want to keep the `.html` extension as the canonical URL of a page, docs c
 
 ### Sidebar {#sidebar}
 
-In previous version, nested sidebar category is not allowed and sidebar category can only contain doc ID. However, v2 allows infinite nested sidebar and we have many types of [Sidebar Item](../guides/docs/sidebar/items.md) other than document.
+In previous version, nested sidebar category is not allowed and sidebar category can only contain doc ID. However, v2 allows infinite nested sidebar and we have many types of [Sidebar Item](../guides/docs/sidebar/items.mdx) other than document.
 
 You'll have to migrate your sidebar if it contains category type. Rename `subcategory` to `category` and `ids` to `items`.
 
@@ -492,7 +492,7 @@ You'll have to migrate your sidebar if it contains category type. Rename `subcat
 
 ### Footer {#footer}
 
-`website/core/Footer.js` is no longer needed. If you want to modify the default footer provided by Docusaurus, [swizzle](../swizzling.md) it:
+`website/core/Footer.js` is no longer needed. If you want to modify the default footer provided by Docusaurus, [swizzle](../swizzling.mdx) it:
 
 ```bash npm2yarn
 npm run swizzle @docusaurus/theme-classic Footer
@@ -518,7 +518,7 @@ module.exports = {
 
 ### Pages {#pages}
 
-Please refer to [creating pages](guides/creating-pages.md) to learn how Docusaurus 2 pages work. After reading that, notice that you have to move `pages/en` files in v1 to `src/pages` instead.
+Please refer to [creating pages](guides/creating-pages.mdx) to learn how Docusaurus 2 pages work. After reading that, notice that you have to move `pages/en` files in v1 to `src/pages` instead.
 
 In Docusaurus v1, pages received the `siteConfig` object as props.
 

website/docs/migration/migration-overview.mdx

@@ -76,7 +76,7 @@ There are multiple things to migrate to obtain a fully functional Docusaurus 2 w
 
 ## Automated migration process {#automated-migration-process}
 
-The [migration CLI](./migration-automated.md) will handle many things of the migration for you.
+The [migration CLI](./migration-automated.mdx) will handle many things of the migration for you.
 
 However, some parts can't easily be automated, and you will have to fallback to the manual process.
 
@@ -90,7 +90,7 @@ We recommend running the migration CLI, and complete the missing parts thanks to
 
 Some parts of the migration can't be automated (particularly the pages), and you will have to migrate them manually.
 
-The [manual migration guide](./migration-manual.md) will give you all the manual steps.
+The [manual migration guide](./migration-manual.mdx) will give you all the manual steps.
 
 ## Support {#support}
 

website/docs/migration/migration-translated-sites.mdx

@@ -79,7 +79,7 @@ This documentation is a best-effort to help you migrate, please help us improve
 Before all, we recommend to:
 
 - Migrate your v1 Docusaurus site to v2 without the translations
-- Get familiar with the [new i18n system of Docusaurus v2](../i18n/i18n-introduction.md) an
+- Get familiar with the [new i18n system of Docusaurus v2](../i18n/i18n-introduction.mdx) an
 - Make Crowdin work for your v2 site, using a new and untranslated Crowdin project and the [Crowdin tutorial](../i18n/i18n-crowdin.mdx)
 
 :::danger

website/docs/migration/migration-versioned-sites.mdx

@@ -8,7 +8,7 @@ Read up https://docusaurus.io/blog/2018/09/11/Towards-Docusaurus-2#versioning fi
 
 :::note
 
-The versioned docs should normally be migrated correctly by the [migration CLI](./migration-automated.md)
+The versioned docs should normally be migrated correctly by the [migration CLI](./migration-automated.mdx)
 
 :::
 

website/docs/search.mdx

@@ -201,7 +201,7 @@ Refer to the relevant [Algolia faceting documentation](https://www.algolia.com/d
 
 By default, DocSearch comes with a fine-tuned theme that was designed for accessibility, making sure that colors and contrasts respect standards.
 
-Still, you can reuse the [Infima CSS variables](styling-layout.md#styling-your-site-with-infima) from Docusaurus to style DocSearch by editing the `/src/css/custom.css` file.
+Still, you can reuse the [Infima CSS variables](styling-layout.mdx#styling-your-site-with-infima) from Docusaurus to style DocSearch by editing the `/src/css/custom.css` file.
 
 ```css title="/src/css/custom.css"
 [data-theme='light'] .DocSearch {
@@ -266,7 +266,7 @@ module.exports = {
 
 ### Editing the Algolia search component {#editing-the-algolia-search-component}
 
-If you prefer to edit the Algolia search React component, [swizzle](swizzling.md) the `SearchBar` component in `@docusaurus/theme-search-algolia`:
+If you prefer to edit the Algolia search React component, [swizzle](swizzling.mdx) the `SearchBar` component in `@docusaurus/theme-search-algolia`:
 
 ```bash npm2yarn
 npm run swizzle @docusaurus/theme-search-algolia SearchBar

website/docs/seo.mdx

@@ -14,7 +14,7 @@ Docusaurus supports search engine optimization in a variety of ways.
 
 ## Global metadata {#global-metadata}
 
-Provide global meta attributes for the entire site through the [site configuration](./configuration.md#site-metadata). The metadata will all be rendered in the HTML `<head>` using the key-value pairs as the prop name and value.
+Provide global meta attributes for the entire site through the [site configuration](./configuration.mdx#site-metadata). The metadata will all be rendered in the HTML `<head>` using the key-value pairs as the prop name and value.
 
 ```js title="docusaurus.config.js"
 module.exports = {
@@ -25,7 +25,7 @@ module.exports = {
 };
 ```
 
-Docusaurus adds some metadata out-of-the-box. For example, if you have configured [i18n](./i18n/i18n-introduction.md), you will get a [`hreflang`](https://developers.google.com/search/docs/advanced/crawling/localized-versions) alternate link.
+Docusaurus adds some metadata out-of-the-box. For example, if you have configured [i18n](./i18n/i18n-introduction.mdx), you will get a [`hreflang`](https://developers.google.com/search/docs/advanced/crawling/localized-versions) alternate link.
 
 To read more about types of meta tags, visit [the MDN docs](https://developer.mozilla.org/en-US/docs/Web/HTML/Element/meta).
 
@@ -62,7 +62,7 @@ Prefer to use front matter for fields like `description` and `keywords`: Docusau
 
 :::
 
-For JSX pages, you can use the Docusaurus [`<Head>`](docusaurus-core.md#head) component.
+For JSX pages, you can use the Docusaurus [`<Head>`](docusaurus-core.mdx#head) component.
 
 ```jsx title="my-react-page.jsx"
 import React from 'react';
@@ -113,7 +113,7 @@ Docusaurus blogs support [rich search results](https://search.google.com/test/ri
 
 ## Robots file {#robots-file}
 
-A `robots.txt` file regulates search engines' behavior about which should be displayed and which shouldn't. You can provide it as [static asset](./static-assets.md). The following would allow access to all sub-pages from all requests:
+A `robots.txt` file regulates search engines' behavior about which should be displayed and which shouldn't. You can provide it as [static asset](./static-assets.mdx). The following would allow access to all sub-pages from all requests:
 
 ```text title="static/robots.txt"
 User-agent: *
@@ -126,7 +126,7 @@ Read more about the robots file in [the Google documentation](https://developers
 
 **Important**: the `robots.txt` file does **not** prevent HTML pages from being indexed.
 
-To prevent your whole Docusaurus site from being indexed, use the [`noIndex`](./api/docusaurus.config.js.md#noIndex) site config. Some [hosting providers](./deployment.mdx) may also let you configure a `X-Robots-Tag: noindex` HTTP header (GitHub Pages does not support this).
+To prevent your whole Docusaurus site from being indexed, use the [`noIndex`](./api/docusaurus.config.js.mdx#noIndex) site config. Some [hosting providers](./deployment.mdx) may also let you configure a `X-Robots-Tag: noindex` HTTP header (GitHub Pages does not support this).
 
 To prevent a single page from being indexed, use `<meta name="robots" content="noindex">` as [page metadata](#single-page-metadata). Read more about the [robots meta tag](https://developers.google.com/search/docs/advanced/robots/robots_meta_tag).
 
@@ -134,7 +134,7 @@ To prevent a single page from being indexed, use `<meta name="robots" content="n
 
 ## Sitemap file {#sitemap-file}
 
-Docusaurus provides the [`@docusaurus/plugin-sitemap`](./api/plugins/plugin-sitemap.md) plugin, which is shipped with `preset-classic` by default. It autogenerates a `sitemap.xml` file which will be available at `https://example.com/[baseUrl]/sitemap.xml` after the production build. This sitemap metadata helps search engine crawlers crawl your site more accurately.
+Docusaurus provides the [`@docusaurus/plugin-sitemap`](./api/plugins/plugin-sitemap.mdx) plugin, which is shipped with `preset-classic` by default. It autogenerates a `sitemap.xml` file which will be available at `https://example.com/[baseUrl]/sitemap.xml` after the production build. This sitemap metadata helps search engine crawlers crawl your site more accurately.
 
 :::tip
 
@@ -152,7 +152,7 @@ For example, [`/examples/noIndex`](/examples/noIndex) is not included in the [Do
 
 ## Human readable links {#human-readable-links}
 
-Docusaurus uses your file names as links, but you can always change that using slugs, see this [tutorial](./guides/docs/docs-introduction.md#document-id) for more details.
+Docusaurus uses your file names as links, but you can always change that using slugs, see this [tutorial](./guides/docs/docs-introduction.mdx#document-id) for more details.
 
 ## Structured content {#structured-content}
 

website/docs/styling-layout.mdx

@@ -8,7 +8,7 @@ import ColorGenerator from '@site/src/components/ColorGenerator';
 
 :::tip
 
-This section is focused on styling through stylesheets. For more advanced customizations (DOM structure, React code...), refer to the [swizzling guide](./swizzling.md).
+This section is focused on styling through stylesheets. For more advanced customizations (DOM structure, React code...), refer to the [swizzling guide](./swizzling.mdx).
 
 :::
 
@@ -110,7 +110,7 @@ Infima uses 7 shades of each color. We recommend using [ColorBox](https://www.co
 
 Alternatively, use the following tool to generate the different shades for your website and copy the variables into `/src/css/custom.css`.
 
-<ColorGenerator/>
+<ColorGenerator />
 
 ### Dark Mode {#dark-mode}
 

website/docs/swizzling.mdx

@@ -8,7 +8,7 @@ In this section, we will introduce how customization of layout is done in Docusa
 
 > Déja vu...?
 
-This section is similar to [Styling and Layout](./styling-layout.md), but this time, we will write actual React code instead of playing with stylesheets. We will talk about a central concept in Docusaurus: **swizzling**, which allows **deeper site customizations**.
+This section is similar to [Styling and Layout](./styling-layout.mdx), but this time, we will write actual React code instead of playing with stylesheets. We will talk about a central concept in Docusaurus: **swizzling**, which allows **deeper site customizations**.
 
 In practice, swizzling permits to **swap a theme component with your own implementation**, and it comes in 2 patterns:
 
@@ -25,7 +25,7 @@ In practice, swizzling permits to **swap a theme component with your own impleme
 
 You can think of it as [Monkey Patching](https://en.wikipedia.org/wiki/Monkey_patch) for React components, enabling you to override the default implementation. Gatsby has a similar concept called [theme shadowing](https://www.gatsbyjs.com/docs/how-to/plugins-and-themes/shadowing/).
 
-To gain a deeper understanding of this, you have to understand [how theme components are resolved](./advanced/client.md#theme-aliases).
+To gain a deeper understanding of this, you have to understand [how theme components are resolved](./advanced/client.mdx#theme-aliases).
 
 </details>
 
@@ -92,7 +92,7 @@ To get an overview of all the themes and components available to swizzle, run:
 npm run swizzle -- --list
 ```
 
-Use `--help` to see all available CLI options, or refer to the reference [swizzle CLI documentation](./cli.md#docusaurus-swizzle).
+Use `--help` to see all available CLI options, or refer to the reference [swizzle CLI documentation](./cli.mdx#docusaurus-swizzle).
 
 :::note
 
@@ -108,7 +108,7 @@ Be sure to understand [which components are **safe to swizzle**](#what-is-safe-t
 
 :::info
 
-`docusaurus swizzle` is only an automated way to help you swizzle the component. You can also create the `src/theme/SomeComponent.js` file manually, and Docusaurus will [resolve it](./advanced/client.md#theme-aliases). There's no internal magic behind this command!
+`docusaurus swizzle` is only an automated way to help you swizzle the component. You can also create the `src/theme/SomeComponent.js` file manually, and Docusaurus will [resolve it](./advanced/client.mdx#theme-aliases). There's no internal magic behind this command!
 
 :::
 
@@ -195,7 +195,7 @@ export default function FooterWrapper(props) {
 <details>
   <summary>What is this <code>@theme-original</code> thing?</summary>
 
-Docusaurus uses [theme aliases](./advanced/client.md#theme-aliases) to resolve the theme components to use. The newly created wrapper takes the `@theme/SomeComponent` alias. `@theme-original/SomeComponent` permits to import original component that the wrapper shadows without creating an infinite import loop where the wrapper imports itself.
+Docusaurus uses [theme aliases](./advanced/client.mdx#theme-aliases) to resolve the theme components to use. The newly created wrapper takes the `@theme/SomeComponent` alias. `@theme-original/SomeComponent` permits to import original component that the wrapper shadows without creating an infinite import loop where the wrapper imports itself.
 
 </details>
 
@@ -280,7 +280,7 @@ You can follow these steps to locate the appropriate component to swizzle:
 
 1. **Component description.** Some components provide a short description, which is a good way to find the right one.
 2. **Component name.** Official theme components are semantically named, so you should be able to infer its function from the name. The swizzle CLI allows you to enter part of a component name to narrow down the available choices. For example, if you run `yarn swizzle @docusaurus/theme-classic`, and enter `Doc`, only the docs-related components will be listed.
-3. **Start with a higher-level component.** Components form a tree with some components importing others. Every route will be associated with one top-level component that the route will render (most of them listed in [Routing in content plugins](./advanced/routing.md#routing-in-content-plugins)). For example, all blog post pages have `@theme/BlogPostPage` as the topmost component. You can start with swizzling this component, and then go down the component tree to locate the component that renders just what you are targeting. Don't forget to unswizzle the rest by deleting the files after you've found the correct one, so you don't maintain too many components.
+3. **Start with a higher-level component.** Components form a tree with some components importing others. Every route will be associated with one top-level component that the route will render (most of them listed in [Routing in content plugins](./advanced/routing.mdx#routing-in-content-plugins)). For example, all blog post pages have `@theme/BlogPostPage` as the topmost component. You can start with swizzling this component, and then go down the component tree to locate the component that renders just what you are targeting. Don't forget to unswizzle the rest by deleting the files after you've found the correct one, so you don't maintain too many components.
 4. **Read the [theme source code](https://github.com/facebook/docusaurus/tree/main/packages/docusaurus-theme-classic/src/theme)** and use search wisely.
 
 :::tip Just ask!
@@ -295,8 +295,8 @@ We also want to understand better your fanciest customization use-cases, so plea
 
 Swizzling ultimately means you have to maintain some additional React code that interact with Docusaurus internal APIs. If you can, think about the following alternatives when customizing your site:
 
-1. **Use CSS.** CSS rules and selectors can often help you achieve a decent degree of customization. Refer to [styling and layout](./styling-layout.md) for more details.
-2. **Use translations.** It may sound surprising, but translations are ultimately just a way to customize the text labels. For example, if your site's default language is `en`, you can still run `yarn write-translations -l en` and edit the `code.json` emitted. Refer to the [i18n tutorial](./i18n/i18n-tutorial.md) for more details.
+1. **Use CSS.** CSS rules and selectors can often help you achieve a decent degree of customization. Refer to [styling and layout](./styling-layout.mdx) for more details.
+2. **Use translations.** It may sound surprising, but translations are ultimately just a way to customize the text labels. For example, if your site's default language is `en`, you can still run `yarn write-translations -l en` and edit the `code.json` emitted. Refer to the [i18n tutorial](./i18n/i18n-tutorial.mdx) for more details.
 
 :::tip
 

website/docs/typescript-support.mdx

@@ -128,4 +128,4 @@ For themes that support TypeScript theme components, you can add the `--typescri
 npm run swizzle @docusaurus/theme-classic Footer -- --typescript
 ```
 
-All official Docusaurus themes support TypeScript theme components, including [`theme-classic`](./api/themes/theme-classic.md), [`theme-live-codeblock`](./api/themes/theme-live-codeblock.md), and [`theme-search-algolia`](./api/themes/theme-search-algolia.md). If you are a Docusaurus theme package author who wants to add TypeScript support, see the [Lifecycle APIs docs](./api/plugin-methods/extend-infrastructure.md#getTypeScriptThemePath).
+All official Docusaurus themes support TypeScript theme components, including [`theme-classic`](./api/themes/theme-classic.mdx), [`theme-live-codeblock`](./api/themes/theme-live-codeblock.mdx), and [`theme-search-algolia`](./api/themes/theme-search-algolia.mdx). If you are a Docusaurus theme package author who wants to add TypeScript support, see the [Lifecycle APIs docs](./api/plugin-methods/extend-infrastructure.mdx#getTypeScriptThemePath).

website/docs/using-plugins.mdx

@@ -1,12 +1,12 @@
 # Using Plugins
 
-**The Docusaurus core doesn't provide any feature of its own.** All features are delegated to individual plugins: the [docs](./guides/docs/docs-introduction.md) feature provided by the [docs plugin](./api/plugins/plugin-content-docs.md); the [blog](./blog.mdx) feature provided by the [blog plugin](./api/plugins/plugin-content-blog.md); or individual [pages](./guides/creating-pages.md) provided by the [pages plugin](./api/plugins/plugin-content-pages.md). If there are no plugins installed, the site won't contain any routes.
+**The Docusaurus core doesn't provide any feature of its own.** All features are delegated to individual plugins: the [docs](./guides/docs/docs-introduction.mdx) feature provided by the [docs plugin](./api/plugins/plugin-content-docs.mdx); the [blog](./blog.mdx) feature provided by the [blog plugin](./api/plugins/plugin-content-blog.mdx); or individual [pages](./guides/creating-pages.mdx) provided by the [pages plugin](./api/plugins/plugin-content-pages.mdx). If there are no plugins installed, the site won't contain any routes.
 
 You may not need to install common plugins one-by-one though: they can be distributed as a bundle in a [preset](#using-presets). For most users, plugins are configured through the preset configuration.
 
-We maintain a [list of official plugins](./api/plugins/overview.md), but the community has also created some [unofficial plugins](/community/resources#community-plugins). If you want to add any feature: autogenerating doc pages, executing custom scripts, integrating other services... be sure to check out the list: someone may have implemented it for you!
+We maintain a [list of official plugins](./api/plugins/overview.mdx), but the community has also created some [unofficial plugins](/community/resources#community-plugins). If you want to add any feature: autogenerating doc pages, executing custom scripts, integrating other services... be sure to check out the list: someone may have implemented it for you!
 
-If you are feeling energetic, you can also read [the plugin guide](./advanced/plugins.md) or [plugin method references](./api/plugin-methods/README.md) for how to make a plugin yourself.
+If you are feeling energetic, you can also read [the plugin guide](./advanced/plugins.mdx) or [plugin method references](./api/plugin-methods/README.mdx) for how to make a plugin yourself.
 
 ## Installing a plugin {#installing-a-plugin}
 
@@ -114,7 +114,7 @@ At most one plugin instance can be the "default plugin instance", by omitting th
 
 ## Using themes {#using-themes}
 
-Themes are loaded in the exact same way as plugins. From the consumer perspective, the `themes` and `plugins` entries are interchangeable when installing and configuring a plugin. The only nuance is that themes are loaded after plugins, and it's possible for [a theme to override a plugin's default theme components](./swizzling.md#theme-aliases).
+Themes are loaded in the exact same way as plugins. From the consumer perspective, the `themes` and `plugins` entries are interchangeable when installing and configuring a plugin. The only nuance is that themes are loaded after plugins, and it's possible for [a theme to override a plugin's default theme components](./swizzling.mdx#theme-aliases).
 
 :::tip
 
@@ -136,18 +136,18 @@ Presets are bundles of plugins and themes. For example, instead of letting you r
 
 ### `@docusaurus/preset-classic` {#docusauruspreset-classic}
 
-The classic preset is shipped by default to new Docusaurus websites created with [`create-docusaurus`](./installation.md#scaffold-project-website). It contains the following themes and plugins:
+The classic preset is shipped by default to new Docusaurus websites created with [`create-docusaurus`](./installation.mdx#scaffold-project-website). It contains the following themes and plugins:
 
-- [`@docusaurus/theme-classic`](./api/themes/theme-configuration.md)
-- [`@docusaurus/theme-search-algolia`](./api/themes/theme-search-algolia.md)
-- [`@docusaurus/plugin-content-docs`](./api/plugins/plugin-content-docs.md)
-- [`@docusaurus/plugin-content-blog`](./api/plugins/plugin-content-blog.md)
-- [`@docusaurus/plugin-content-pages`](./api/plugins/plugin-content-pages.md)
-- [`@docusaurus/plugin-debug`](./api/plugins/plugin-debug.md)
-- [`@docusaurus/plugin-google-gtag`](./api/plugins/plugin-google-gtag.md)
-- [`@docusaurus/plugin-google-tag-manager`](./api/plugins/plugin-google-tag-manager.md)
-- [`@docusaurus/plugin-google-analytics`](./api/plugins/plugin-google-analytics.md) (**deprecated**)
-- [`@docusaurus/plugin-sitemap`](./api/plugins/plugin-sitemap.md)
+- [`@docusaurus/theme-classic`](./api/themes/theme-configuration.mdx)
+- [`@docusaurus/theme-search-algolia`](./api/themes/theme-search-algolia.mdx)
+- [`@docusaurus/plugin-content-docs`](./api/plugins/plugin-content-docs.mdx)
+- [`@docusaurus/plugin-content-blog`](./api/plugins/plugin-content-blog.mdx)
+- [`@docusaurus/plugin-content-pages`](./api/plugins/plugin-content-pages.mdx)
+- [`@docusaurus/plugin-debug`](./api/plugins/plugin-debug.mdx)
+- [`@docusaurus/plugin-google-gtag`](./api/plugins/plugin-google-gtag.mdx)
+- [`@docusaurus/plugin-google-tag-manager`](./api/plugins/plugin-google-tag-manager.mdx)
+- [`@docusaurus/plugin-google-analytics`](./api/plugins/plugin-google-analytics.mdx) (**deprecated**)
+- [`@docusaurus/plugin-sitemap`](./api/plugins/plugin-sitemap.mdx)
 
 The classic preset will relay each option entry to the respective plugin/theme.
 
@@ -213,7 +213,7 @@ module.exports = {
 
 ### Creating presets {#creating-presets}
 
-A preset is a function with the same shape as the [plugin constructor](./api/plugin-methods/README.md#plugin-constructor). It should return an object of `{ plugins: PluginConfig[], themes: PluginConfig[] }`, in the same as how they are accepted in the site config. For example, you can specify a preset that includes the following themes and plugins:
+A preset is a function with the same shape as the [plugin constructor](./api/plugin-methods/README.mdx#plugin-constructor). It should return an object of `{ plugins: PluginConfig[], themes: PluginConfig[] }`, in the same as how they are accepted in the site config. For example, you can specify a preset that includes the following themes and plugins:
 
 ```js title="src/presets/docusaurus-preset-multi-docs.js"
 module.exports = function preset(context, opts = {}) {
@@ -301,7 +301,7 @@ Below are some examples, for a plugin registered in the `plugins` field. Note th
 | Declaration | May be resolved as |
 | --- | --- |
 | `awesome` | `docusaurus-plugin-awesome` |
-| `sitemap` | [`@docusaurus/plugin-sitemap`](./api/plugins/plugin-sitemap.md) |
+| `sitemap` | [`@docusaurus/plugin-sitemap`](./api/plugins/plugin-sitemap.mdx) |
 | `@my-company` | `@my-company/docusaurus-plugin` (the only possible resolution!) |
 | `@my-company/awesome` | `@my-company/docusaurus-plugin-awesome` |
 | `@my-company/awesome/web` | `@my-company/docusaurus-plugin-awesome/web` |

website/netlify.toml

@@ -12,6 +12,7 @@
   NETLIFY_USE_YARN = "true"
   YARN_VERSION = "1.22.5"
   NODE_VERSION = "16"
+  NODE_OPTIONS = "--max_old_space_size=4096"
 
 [context.production]
   command = "yarn --cwd .. build:packages && yarn netlify:build:production"

website/versioned_docs/version-2.0.1/advanced/architecture.mdx

@@ -25,4 +25,4 @@ Although you (either plugin authors or site creators) are writing JavaScript all
 
 Plugin code and theme code never directly import each other: they only communicate through protocols (in our case, through JSON temp files and calls to `addRoute`). A useful mental model is to imagine that the plugins are not written in JavaScript, but in another language like Rust. The only way to interact with plugins for the user is through `docusaurus.config.js`, which itself is run in Node (hence you can use `require` and pass callbacks as plugin options).
 
-During bundling, the config file itself is serialized and bundled, allowing the theme to access config options like `themeConfig` or `baseUrl` through [`useDocusaurusContext()`](../docusaurus-core.md#useDocusaurusContext). However, the `siteConfig` object only contains **serializable values** (values that are preserved after `JSON.stringify()`). Functions, regexes, etc. would be lost on the client side. The `themeConfig` is designed to be entirely serializable.
+During bundling, the config file itself is serialized and bundled, allowing the theme to access config options like `themeConfig` or `baseUrl` through [`useDocusaurusContext()`](../docusaurus-core.mdx#useDocusaurusContext). However, the `siteConfig` object only contains **serializable values** (values that are preserved after `JSON.stringify()`). Functions, regexes, etc. would be lost on the client side. The `themeConfig` is designed to be entirely serializable.

website/versioned_docs/version-2.0.1/advanced/client.mdx

@@ -91,9 +91,9 @@ These modules are imported globally before React even renders the initial UI.
 import '@generated/client-modules';
 ```
 
-Plugins and sites can both declare client modules, through [`getClientModules`](../api/plugin-methods/lifecycle-apis.md#getClientModules) and [`siteConfig.clientModules`](../api/docusaurus.config.js.md#clientModules), respectively.
+Plugins and sites can both declare client modules, through [`getClientModules`](../api/plugin-methods/lifecycle-apis.mdx#getClientModules) and [`siteConfig.clientModules`](../api/docusaurus.config.js.mdx#clientModules), respectively.
 
-Client modules are called during server-side rendering as well, so remember to check the [execution environment](./ssg.md#escape-hatches) before accessing client-side globals.
+Client modules are called during server-side rendering as well, so remember to check the [execution environment](./ssg.mdx#escape-hatches) before accessing client-side globals.
 
 ```js title="mySiteGlobalJs.js"
 import ExecutionEnvironment from '@docusaurus/ExecutionEnvironment';
@@ -108,7 +108,7 @@ if (ExecutionEnvironment.canUseDOM) {
 }
 ```
 
-CSS stylesheets imported as client modules are [global](../styling-layout.md#global-styles).
+CSS stylesheets imported as client modules are [global](../styling-layout.mdx#global-styles).
 
 ```css title="mySiteGlobalCss.css"
 /* This stylesheet is global. */
@@ -181,6 +181,6 @@ Both lifecycles will fire on first render, but they will not fire on server-side
 
 :::tip Prefer using React
 
-Client module lifecycles are purely imperative, and you can't use React hooks or access React contexts within them. If your operations are state-driven or involve complicated DOM manipulations, you should consider [swizzling components](../swizzling.md) instead.
+Client module lifecycles are purely imperative, and you can't use React hooks or access React contexts within them. If your operations are state-driven or involve complicated DOM manipulations, you should consider [swizzling components](../swizzling.mdx) instead.
 
 :::

website/versioned_docs/version-2.0.1/advanced/index.mdx

@@ -9,4 +9,4 @@ import {useCurrentSidebarCategory} from '@docusaurus/theme-common';
 <DocCardList items={useCurrentSidebarCategory().items}/>
 ```
 
-We will assume that you have finished the guides, and know the basics like how to configure plugins, how to write React components, etc. These sections will have plugin authors and code contributors in mind, so we may occasionally refer to [plugin APIs](../api/plugin-methods/README.md) or other architecture details. Don't panic if you don't understand everything😉
+We will assume that you have finished the guides, and know the basics like how to configure plugins, how to write React components, etc. These sections will have plugin authors and code contributors in mind, so we may occasionally refer to [plugin APIs](../api/plugin-methods/README.mdx) or other architecture details. Don't panic if you don't understand everything😉

website/versioned_docs/version-2.0.1/advanced/plugins.mdx

@@ -4,7 +4,7 @@ Plugins are the building blocks of features in a Docusaurus 2 site. Each plugin
 
 ## Creating plugins {#creating-plugins}
 
-A plugin is a function that takes two parameters: `context` and `options`. It returns a plugin instance object (or a promise). You can create plugins as functions or modules. For more information, refer to the [plugin method references section](../api/plugin-methods/README.md).
+A plugin is a function that takes two parameters: `context` and `options`. It returns a plugin instance object (or a promise). You can create plugins as functions or modules. For more information, refer to the [plugin method references section](../api/plugin-methods/README.mdx).
 
 ### Function definition {#function-definition}
 
@@ -86,7 +86,7 @@ Docusaurus' implementation of the plugins system provides us with a convenient w
 
 ### Theme design {#theme-design}
 
-When plugins have loaded their content, the data is made available to the client side through actions like [`createData` + `addRoute`](../api/plugin-methods/lifecycle-apis.md#addRoute) or [`setGlobalData`](../api/plugin-methods/lifecycle-apis.md#setGlobalData). This data has to be _serialized_ to plain strings, because [plugins and themes run in different environments](./architecture.md). Once the data arrives on the client side, the rest becomes familiar to React developers: data is passed along components, components are bundled with Webpack, and rendered to the window through `ReactDOM.render`...
+When plugins have loaded their content, the data is made available to the client side through actions like [`createData` + `addRoute`](../api/plugin-methods/lifecycle-apis.mdx#addRoute) or [`setGlobalData`](../api/plugin-methods/lifecycle-apis.mdx#setGlobalData). This data has to be _serialized_ to plain strings, because [plugins and themes run in different environments](./architecture.mdx). Once the data arrives on the client side, the rest becomes familiar to React developers: data is passed along components, components are bundled with Webpack, and rendered to the window through `ReactDOM.render`...
 
 **Themes provide the set of UI components to render the content.** Most content plugins need to be paired with a theme in order to be actually useful. The UI is a separate layer from the data schema, which makes swapping designs easy.
 
@@ -120,7 +120,7 @@ Now, although the theme receives the same data from the plugin, how the theme ch
 
 While themes share the exact same lifecycle methods with plugins, themes' implementations can look very different from those of plugins based on themes' designed objectives.
 
-Themes are designed to complete the build of your Docusaurus site and supply the components used by your site, plugins, and the themes themselves. A theme still acts like a plugin and exposes some lifecycle methods, but most likely they would not use [`loadContent`](../api/plugin-methods/lifecycle-apis.md#loadContent), since they only receive data from plugins, but don't generate data themselves; themes are typically also accompanied by an `src/theme` directory full of components, which are made known to the core through the [`getThemePath`](../api/plugin-methods/extend-infrastructure.md#getThemePath) lifecycle.
+Themes are designed to complete the build of your Docusaurus site and supply the components used by your site, plugins, and the themes themselves. A theme still acts like a plugin and exposes some lifecycle methods, but most likely they would not use [`loadContent`](../api/plugin-methods/lifecycle-apis.mdx#loadContent), since they only receive data from plugins, but don't generate data themselves; themes are typically also accompanied by an `src/theme` directory full of components, which are made known to the core through the [`getThemePath`](../api/plugin-methods/extend-infrastructure.mdx#getThemePath) lifecycle.
 
 To summarize:
 

website/versioned_docs/version-2.0.1/advanced/routing.mdx

@@ -38,13 +38,13 @@ graph LR;
 
 Any route will be matched against this nested route config until a good match is found. For example, when given a route `/docs/configuration`, Docusaurus first enters the `/docs` branch, and then searches among the subroutes created by the docs plugin.
 
-Changing `routeBasePath` can effectively alter your site's route structure. For example, in [Docs-only mode](../guides/docs/docs-introduction.md#docs-only-mode), we mentioned that configuring `routeBasePath: '/'` for docs means that all routes that the docs plugin create would not have the `/docs` prefix, yet it doesn't prevent you from having more subroutes like `/blog` created by other plugins.
+Changing `routeBasePath` can effectively alter your site's route structure. For example, in [Docs-only mode](../guides/docs/docs-introduction.mdx#docs-only-mode), we mentioned that configuring `routeBasePath: '/'` for docs means that all routes that the docs plugin create would not have the `/docs` prefix, yet it doesn't prevent you from having more subroutes like `/blog` created by other plugins.
 
 Next, let's look at how the three plugins structure their own "boxes of subroutes".
 
 ### Pages routing {#pages-routing}
 
-Pages routing are straightforward: the file paths directly map to URLs, without any other way to customize. See the [pages docs](../guides/creating-pages.md#routing) for more information.
+Pages routing are straightforward: the file paths directly map to URLs, without any other way to customize. See the [pages docs](../guides/creating-pages.mdx#routing) for more information.
 
 The component used for Markdown pages is `@theme/MDXPage`. React pages are directly used as the route's component.
 
@@ -71,7 +71,7 @@ The blog creates the following routes:
 
 ### Docs routing {#docs-routing}
 
-The docs is the only plugin that creates **nested routes**. At the top, it registers [**version paths**](../guides/docs/versioning.md): `/`, `/next`, `/2.0.0-beta.13`... which provide the version context, including the layout and sidebar. This ensures that when switching between individual docs, the sidebar's state is preserved, and that you can switch between versions through the navbar dropdown while staying on the same doc. The component used is `@theme/DocPage`.
+The docs is the only plugin that creates **nested routes**. At the top, it registers [**version paths**](../guides/docs/versioning.mdx): `/`, `/next`, `/2.0.0-beta.13`... which provide the version context, including the layout and sidebar. This ensures that when switching between individual docs, the sidebar's state is preserved, and that you can switch between versions through the navbar dropdown while staying on the same doc. The component used is `@theme/DocPage`.
 
 ```mdx-code-block
 export const URLPath = () => <code>{useLocation().pathname}</code>;
@@ -221,7 +221,7 @@ Localized sites have the locale as part of the base URL as well. For example, `h
 
 ## Generating and accessing routes {#generating-and-accessing-routes}
 
-The `addRoute` lifecycle action is used to generate routes. It registers a piece of route config to the route tree, giving a route, a component, and props that the component needs. The props and the component are both provided as paths for the bundler to `require`, because as explained in the [architecture overview](architecture.md), server and client only communicate through temp files.
+The `addRoute` lifecycle action is used to generate routes. It registers a piece of route config to the route tree, giving a route, a component, and props that the component needs. The props and the component are both provided as paths for the bundler to `require`, because as explained in the [architecture overview](architecture.mdx), server and client only communicate through temp files.
 
 All routes are aggregated in `.docusaurus/routes.js`, which you can view with the debug plugin's [routes panel](/__docusaurus/debug/routes).
 

website/versioned_docs/version-2.0.1/advanced/ssg.mdx

@@ -5,7 +5,7 @@ description: Docusaurus statically renders your React code into HTML, allowing f
 
 # Static site generation (SSG)
 
-In [architecture](architecture.md), we mentioned that the theme is run in Webpack. But beware: that doesn't mean it always has access to browser globals! The theme is built twice:
+In [architecture](architecture.mdx), we mentioned that the theme is run in Webpack. But beware: that doesn't mean it always has access to browser globals! The theme is built twice:
 
 - During **server-side rendering**, the theme is compiled in a sandbox called [React DOM Server](https://reactjs.org/docs/react-dom-server.html). You can see this as a "headless browser", where there is no `window` or `document`, only React. SSR produces static HTML pages.
 - During **client-side rendering**, the theme is compiled to JavaScript that gets eventually executed in the browser, so it has access to browser variables.
@@ -57,7 +57,8 @@ export default function expensiveComp() {
 
 During Webpack build, the `process.env.NODE_ENV` will be replaced with the value, either `'development'` or `'production'`. You will then get different build results after dead code elimination:
 
-import Tabs from '@theme/Tabs'; import TabItem from '@theme/TabItem';
+import Tabs from '@theme/Tabs';
+import TabItem from '@theme/TabItem';
 
 ```mdx-code-block
 <Tabs>
@@ -105,7 +106,7 @@ export default function expensiveComp() {
 
 React is not just a dynamic UI runtime—it's also a templating engine. Because Docusaurus sites mostly contain static contents, it should be able to work without any JavaScript (which React runs in), but only plain HTML/CSS. And that's what server-side rendering offers: statically rendering your React code into HTML, without any dynamic content. An HTML file has no concept of client state (it's purely markup), hence it shouldn't rely on browser APIs.
 
-These HTML files are the first to arrive at the user's browser screen when a URL is visited (see [routing](routing.md)). Afterwards, the browser fetches and runs other JS code to provide the "dynamic" parts of your site—anything implemented with JavaScript. However, before that, the main content of your page is already visible, allowing faster loading.
+These HTML files are the first to arrive at the user's browser screen when a URL is visited (see [routing](routing.mdx)). Afterwards, the browser fetches and runs other JS code to provide the "dynamic" parts of your site—anything implemented with JavaScript. However, before that, the main content of your page is already visible, allowing faster loading.
 
 In CSR-only apps, all DOM elements are generated on client side with React, and the HTML file only ever contains one root element for React to mount DOM to; in SSR, React is already facing a fully built HTML page, and it only needs to correlate the DOM elements with the virtual DOM in its model. This step is called "hydration". After React has hydrated the static markup, the app starts to work as any normal React app.
 
@@ -135,7 +136,7 @@ We provide several more reliable ways to escape SSR.
 
 ### `<BrowserOnly>` {#browseronly}
 
-If you need to render some component in browser only (for example, because the component relies on browser specifics to be functional at all), one common approach is to wrap your component with [`<BrowserOnly>`](../docusaurus-core.md#browseronly) to make sure it's invisible during SSR and only rendered in CSR.
+If you need to render some component in browser only (for example, because the component relies on browser specifics to be functional at all), one common approach is to wrap your component with [`<BrowserOnly>`](../docusaurus-core.mdx#browseronly) to make sure it's invisible during SSR and only rendered in CSR.
 
 ```jsx
 import BrowserOnly from '@docusaurus/BrowserOnly';
@@ -204,7 +205,7 @@ function MyComponent() {
 
 ### `ExecutionEnvironment` {#executionenvironment}
 
-The [`ExecutionEnvironment`](../docusaurus-core.md#executionenvironment) namespace contains several values, and `canUseDOM` is an effective way to detect browser environment.
+The [`ExecutionEnvironment`](../docusaurus-core.mdx#executionenvironment) namespace contains several values, and `canUseDOM` is an effective way to detect browser environment.
 
 Beware that it essentially checked `typeof window !== 'undefined'` under the hood, so you should not use it for rendering-related logic, but only imperative code, like reacting to user input by sending web requests, or dynamically importing libraries, where DOM isn't updated at all.
 

website/versioned_docs/version-2.0.1/api/docusaurus.config.js.mdx

@@ -119,7 +119,7 @@ Refer to the [deployment guide](../deployment.mdx) and [slorber/trailing-slash-g
 
 - Type: `Object`
 
-The i18n configuration object to [localize your site](../i18n/i18n-introduction.md).
+The i18n configuration object to [localize your site](../i18n/i18n-introduction.mdx).
 
 Example:
 
@@ -201,7 +201,7 @@ By default, it prints a warning, to let you know about your broken Markdown link
 
 - Type: `'ignore' | 'log' | 'warn' | 'throw'`
 
-The behavior of Docusaurus when it detects any [duplicate routes](/guides/creating-pages.md#duplicate-routes).
+The behavior of Docusaurus when it detects any [duplicate routes](/guides/creating-pages.mdx#duplicate-routes).
 
 By default, it displays a warning after you run `yarn start` or `yarn build`.
 
@@ -283,7 +283,7 @@ module.exports = {
 
 - Type: `Object`
 
-The [theme configuration](./themes/theme-configuration.md) object to customize your site UI like navbar and footer.
+The [theme configuration](./themes/theme-configuration.mdx) object to customize your site UI like navbar and footer.
 
 Example:
 
@@ -354,7 +354,7 @@ module.exports = {
 type PluginConfig = string | [string, any] | PluginModule | [PluginModule, any];
 ```
 
-See [plugin method references](./plugin-methods/README.md) for the shape of a `PluginModule`.
+See [plugin method references](./plugin-methods/README.mdx) for the shape of a `PluginModule`.
 
 ```js title="docusaurus.config.js"
 module.exports = {
@@ -482,7 +482,7 @@ By default, the `<link>` tags will have `rel="stylesheet"`, but you can explicit
 
 ### `clientModules` {#clientModules}
 
-An array of [client modules](../advanced/client.md#client-modules) to load globally on your site.
+An array of [client modules](../advanced/client.mdx#client-modules) to load globally on your site.
 
 Example:
 

website/versioned_docs/version-2.0.1/api/misc/eslint-plugin/README.mdx

@@ -51,8 +51,8 @@ Each config contains a set of rules. For more fine-grained control, you can also
 
 | Name | Description |  |
 | --- | --- | --- |
-| [`@docusaurus/no-untranslated-text`](./no-untranslated-text.md) | Enforce text labels in JSX to be wrapped by translate calls |  |
-| [`@docusaurus/string-literal-i18n-messages`](./string-literal-i18n-messages.md) | Enforce translate APIs to be called on plain text labels | ✅ |
+| [`@docusaurus/no-untranslated-text`](./no-untranslated-text.mdx) | Enforce text labels in JSX to be wrapped by translate calls |  |
+| [`@docusaurus/string-literal-i18n-messages`](./string-literal-i18n-messages.mdx) | Enforce translate APIs to be called on plain text labels | ✅ |
 
 ✅ = recommended
 

website/versioned_docs/version-2.0.1/api/misc/eslint-plugin/no-untranslated-text.mdx

@@ -8,7 +8,7 @@ import APITable from '@site/src/components/APITable';
 
 Enforce text labels in JSX to be wrapped by translate calls.
 
-When the [i18n feature](../../../i18n/i18n-introduction.md) is used, this rule ensures that all labels appearing on the website are translatable, so no string accidentally slips through untranslated.
+When the [i18n feature](../../../i18n/i18n-introduction.mdx) is used, this rule ensures that all labels appearing on the website are translatable, so no string accidentally slips through untranslated.
 
 ## Rule Details {#details}
 
@@ -46,7 +46,7 @@ Accepted fields:
 
 ## When Not To Use It {#when-not-to-use}
 
-If you're not using the [i18n feature](../../../i18n/i18n-introduction.md), you can disable this rule. You can also disable this rule where the text is not supposed to be translated.
+If you're not using the [i18n feature](../../../i18n/i18n-introduction.mdx), you can disable this rule. You can also disable this rule where the text is not supposed to be translated.
 
 ## Further Reading {#further-reading}
 

website/versioned_docs/version-2.0.1/api/misc/eslint-plugin/string-literal-i18n-messages.mdx

@@ -6,7 +6,7 @@ slug: /api/misc/@docusaurus/eslint-plugin/string-literal-i18n-messages
 
 Enforce translate APIs to be called on plain text labels.
 
-Docusaurus offers the [`docusaurus write-translations`](../../../cli.md#docusaurus-write-translations-sitedir) API, which statically extracts the text labels marked as translatable. Dynamic values used in `<Translate>` or `translate()` calls will fail to be extracted. This rule will ensure that all translate calls are statically extractable.
+Docusaurus offers the [`docusaurus write-translations`](../../../cli.mdx#docusaurus-write-translations-sitedir) API, which statically extracts the text labels marked as translatable. Dynamic values used in `<Translate>` or `translate()` calls will fail to be extracted. This rule will ensure that all translate calls are statically extractable.
 
 ## Rule Details {#details}
 
@@ -42,7 +42,7 @@ translate({message: 'The logo of site {siteName}'}, {siteName: 'Docusaurus'})
 
 ## When Not To Use It {#when-not-to-use}
 
-If you're not using the [i18n feature](../../../i18n/i18n-introduction.md), you can disable this rule.
+If you're not using the [i18n feature](../../../i18n/i18n-introduction.mdx), you can disable this rule.
 
 ## Further Reading {#further-reading}
 

website/versioned_docs/version-2.0.1/api/plugin-methods/README.mdx

@@ -13,7 +13,7 @@ Plugin APIs are shared by themes and plugins—themes are loaded just like plugi
 Every plugin is imported as a module. The module is expected to have the following members:
 
 - A **default export**: the constructor function for the plugin.
-- **Named exports**: the [static methods](./static-methods.md) called before plugins are initialized.
+- **Named exports**: the [static methods](./static-methods.mdx) called before plugins are initialized.
 
 ## Plugin constructor {#plugin-constructor}
 
@@ -35,7 +35,7 @@ type LoadContext = {
 
 ### `options` {#options}
 
-`options` are the [second optional parameter when the plugins are used](../../using-plugins.md#configuring-plugins). `options` are plugin-specific and are specified by users when they use them in `docusaurus.config.js`. If there's a [`validateOptions`](./static-methods.md#validateOptions) function exported, the `options` will be validated and normalized beforehand.
+`options` are the [second optional parameter when the plugins are used](../../using-plugins.mdx#configuring-plugins). `options` are plugin-specific and are specified by users when they use them in `docusaurus.config.js`. If there's a [`validateOptions`](./static-methods.mdx#validateOptions) function exported, the `options` will be validated and normalized beforehand.
 
 Alternatively, if a preset contains the plugin, the preset will then be in charge of passing the correct options into the plugin. It is up to the individual plugin to define what options it takes.
 

website/versioned_docs/version-2.0.1/api/plugin-methods/i18n-lifecycles.mdx

@@ -15,7 +15,7 @@ Returns translation files `{path: string, content: ChromeI18nJSON}`:
 - `path`: relative to the plugin localized folder `i18n/[locale]/[pluginName]`. Extension `.json` should be omitted to remain generic.
 - `content`: using the Chrome i18n JSON format.
 
-These files will be written by the [`write-translations` CLI](../../cli.md#docusaurus-write-translations-sitedir) to the plugin i18n subfolder, and will be read in the appropriate locale before calling [`translateContent()`](#translateContent) and [`translateThemeConfig()`](#translateThemeConfig)
+These files will be written by the [`write-translations` CLI](../../cli.mdx#docusaurus-write-translations-sitedir) to the plugin i18n subfolder, and will be read in the appropriate locale before calling [`translateContent()`](#translateContent) and [`translateThemeConfig()`](#translateThemeConfig)
 
 Example:
 

website/versioned_docs/version-2.0.1/api/plugin-methods/lifecycle-apis.mdx

@@ -111,7 +111,7 @@ export default function friendsPlugin(context, options) {
 
 This function permits one to create some global plugin data that can be read from any page, including the pages created by other plugins, and your theme layout.
 
-This data becomes accessible to your client-side/theme code through the [`useGlobalData`](../../docusaurus-core.md#useGlobalData) and [`usePluginData`](../../docusaurus-core.md#usePluginData) hooks.
+This data becomes accessible to your client-side/theme code through the [`useGlobalData`](../../docusaurus-core.mdx#useGlobalData) and [`usePluginData`](../../docusaurus-core.mdx#usePluginData) hooks.
 
 :::caution
 
@@ -399,7 +399,7 @@ module.exports = function (context, options) {
 
 ## `getClientModules()` {#getClientModules}
 
-Returns an array of paths to the [client modules](../../advanced/client.md#client-modules) that are to be imported into the client bundle.
+Returns an array of paths to the [client modules](../../advanced/client.mdx#client-modules) that are to be imported into the client bundle.
 
 As an example, to make your theme load a `customCss` or `customJs` file path from `options` passed in by the user:
 

website/versioned_docs/version-2.0.1/api/plugins/overview.mdx

@@ -13,18 +13,18 @@ We provide official Docusaurus plugins.
 
 These plugins are responsible for loading your site's content, and creating pages for your theme to render.
 
-- [@docusaurus/plugin-content-docs](./plugin-content-docs.md)
-- [@docusaurus/plugin-content-blog](./plugin-content-blog.md)
-- [@docusaurus/plugin-content-pages](./plugin-content-pages.md)
+- [@docusaurus/plugin-content-docs](./plugin-content-docs.mdx)
+- [@docusaurus/plugin-content-blog](./plugin-content-blog.mdx)
+- [@docusaurus/plugin-content-pages](./plugin-content-pages.mdx)
 
 ## Behavior plugins {#behavior-plugins}
 
 These plugins will add a useful behavior to your Docusaurus site.
 
-- [@docusaurus/plugin-debug](./plugin-debug.md)
-- [@docusaurus/plugin-sitemap](./plugin-sitemap.md)
-- [@docusaurus/plugin-pwa](./plugin-pwa.md)
-- [@docusaurus/plugin-client-redirects](./plugin-client-redirects.md)
-- [@docusaurus/plugin-ideal-image](./plugin-ideal-image.md)
-- [@docusaurus/plugin-google-analytics](./plugin-google-analytics.md)
-- [@docusaurus/plugin-google-gtag](./plugin-google-gtag.md)
+- [@docusaurus/plugin-debug](./plugin-debug.mdx)
+- [@docusaurus/plugin-sitemap](./plugin-sitemap.mdx)
+- [@docusaurus/plugin-pwa](./plugin-pwa.mdx)
+- [@docusaurus/plugin-client-redirects](./plugin-client-redirects.mdx)
+- [@docusaurus/plugin-ideal-image](./plugin-ideal-image.mdx)
+- [@docusaurus/plugin-google-analytics](./plugin-google-analytics.mdx)
+- [@docusaurus/plugin-google-gtag](./plugin-google-gtag.mdx)

website/versioned_docs/version-2.0.1/api/plugins/plugin-client-redirects.mdx

@@ -52,7 +52,7 @@ Accepted fields:
 
 :::note
 
-This plugin will also read the [`siteConfig.onDuplicateRoutes`](../docusaurus.config.js.md#onDuplicateRoutes) config to adjust its logging level when multiple files will be emitted to the same location.
+This plugin will also read the [`siteConfig.onDuplicateRoutes`](../docusaurus.config.js.mdx#onDuplicateRoutes) config to adjust its logging level when multiple files will be emitted to the same location.
 
 :::
 

website/versioned_docs/version-2.0.1/api/plugins/plugin-content-blog.mdx

@@ -246,13 +246,13 @@ A Markdown blog post
 
 ## i18n {#i18n}
 
-Read the [i18n introduction](../../i18n/i18n-introduction.md) first.
+Read the [i18n introduction](../../i18n/i18n-introduction.mdx) first.
 
 ### Translation files location {#translation-files-location}
 
 - **Base path**: `website/i18n/[locale]/docusaurus-plugin-content-blog`
 - **Multi-instance path**: `website/i18n/[locale]/docusaurus-plugin-content-blog-[pluginId]`
-- **JSON files**: extracted with [`docusaurus write-translations`](../../cli.md#docusaurus-write-translations-sitedir)
+- **JSON files**: extracted with [`docusaurus write-translations`](../../cli.mdx#docusaurus-write-translations-sitedir)
 - **Markdown files**: `website/i18n/[locale]/docusaurus-plugin-content-blog`
 
 ### Example file-system structure {#example-file-system-structure}