diff --git a/docs/angular-testing-library/api.mdx b/docs/angular-testing-library/api.mdx
index ee88c49df..774d0810d 100644
--- a/docs/angular-testing-library/api.mdx
+++ b/docs/angular-testing-library/api.mdx
@@ -324,9 +324,9 @@ const component = await render(AppComponent)
 const componentInstance = component.fixture.componentInstance as AppComponent
 ```
 
-> 🚨 If you find yourself using `fixture` to access the component's internal
-> values you should reconsider! This probable means, you're testing
-> implementation details.
+:::danger If you find yourself using `fixture` to access the component's
+internal values you should reconsider! This probable means, you're testing
+implementation details. :::
 
 ### `navigate`
 
diff --git a/docs/angular-testing-library/examples.mdx b/docs/angular-testing-library/examples.mdx
index c4eee4601..812e60705 100644
--- a/docs/angular-testing-library/examples.mdx
+++ b/docs/angular-testing-library/examples.mdx
@@ -4,9 +4,9 @@ title: Examples
 sidebar_label: Examples
 ---
 
-> Read
-> [Good testing practices with 🦔 Angular Testing Library](https://timdeschryver.dev/posts/good-testing-practices-with-angular-testing-library)
-> for a guided example
+:::info Read
+[Good testing practices with 🦔 Angular Testing Library](https://timdeschryver.dev/posts/good-testing-practices-with-angular-testing-library)
+for a guided example :::
 
 counter.component.ts
 
diff --git a/docs/cypress-testing-library/intro.mdx b/docs/cypress-testing-library/intro.mdx
index ec1135944..395c485fa 100644
--- a/docs/cypress-testing-library/intro.mdx
+++ b/docs/cypress-testing-library/intro.mdx
@@ -26,11 +26,11 @@ You can now use all of `DOM Testing Library`'s `findBy`, `findAllBy`, `queryBy`
 and `queryAllBy` commands off the global `cy` object.
 [See the `DOM Testing Library` docs for reference](https://testing-library.com/docs/dom-testing-library/api-queries).
 
-> Note: the `get*` queries are not supported because for reasonable Cypress
-> tests you need retryability and `find*` queries already support that. `query*`
-> queries are no longer necessary since v5 and will be removed in v6. `find*`
-> fully support built-in Cypress assertions (removes the only use-case for
-> `query*`).
+:::caution the `get*` queries are not supported because for reasonable Cypress
+tests you need retryability and `find*` queries already support that. `query*`
+queries are no longer necessary since v5 and will be removed in v6. `find*`
+fully support built-in Cypress assertions (removes the only use-case for
+`query*`). :::
 
 ## With TypeScript
 
diff --git a/docs/dom-testing-library/api-events.mdx b/docs/dom-testing-library/api-events.mdx
index cbd2a96fa..4a68a256d 100644
--- a/docs/dom-testing-library/api-events.mdx
+++ b/docs/dom-testing-library/api-events.mdx
@@ -6,9 +6,11 @@ title: Firing Events
 import Tabs from '@theme/Tabs'
 import TabItem from '@theme/TabItem'
 
-> Most projects have a few use cases for `fireEvent`, but the majority of the
-> time you should probably use
-> [`@testing-library/user-event`](https://github.com/testing-library/user-event).
+:::tip
+Most projects have a few use cases for `fireEvent`, but the majority of the
+time you should probably use
+[`@testing-library/user-event`](https://github.com/testing-library/user-event).
+:::
 
 ## `fireEvent`
 
diff --git a/docs/dom-testing-library/api-helpers.mdx b/docs/dom-testing-library/api-helpers.mdx
index c749d1c3e..5791bb520 100644
--- a/docs/dom-testing-library/api-helpers.mdx
+++ b/docs/dom-testing-library/api-helpers.mdx
@@ -57,11 +57,11 @@ module.exports = {
 }
 ```
 
-> **Note**
->
-> Custom queries can be added to `React Testing Library`'s `render` method by
-> adding `queries` to the options config object. See the render
-> [options](react-testing-library/api.mdx#render-options).
+:::info
+Custom queries can be added to `React Testing Library`'s `render` method by
+adding `queries` to the options config object. See the render
+[options](react-testing-library/api.mdx#render-options).
+:::
 
 ## `buildQueries`
 
diff --git a/docs/dom-testing-library/api-queries.mdx b/docs/dom-testing-library/api-queries.mdx
index 7608daa80..af44b42fe 100644
--- a/docs/dom-testing-library/api-queries.mdx
+++ b/docs/dom-testing-library/api-queries.mdx
@@ -8,8 +8,10 @@ import TabItem from '@theme/TabItem'
 
 ## Variants
 
-> `getBy` queries are shown by default in the [query documentation](#queries)
-> below.
+:::info
+`getBy` queries are shown by default in the [query documentation](#queries)
+below.
+:::
 
 ### getBy
 
@@ -41,12 +43,12 @@ matches the given query. The promise is rejected if no element is found or if
 more than one element is found after a default timeout of `1000`ms. If you need
 to find more than one element, then use `findAllBy`.
 
-> **Note**
->
-> this is a simple combination of `getBy*` queries and
-> [`waitFor`](api-async.mdx#waitfor). The `findBy*` queries accept the `waitFor`
-> options as the last argument. (i.e.
-> `screen.findByText('text', queryOptions, waitForOptions)`)
+:::info
+this is a simple combination of `getBy*` queries and
+[`waitFor`](api-async.mdx#waitfor). The `findBy*` queries accept the `waitFor`
+options as the last argument. (i.e.
+`screen.findByText('text', queryOptions, waitForOptions)`)
+:::
 
 ### findAllBy
 
@@ -87,16 +89,16 @@ document.body.innerHTML = exampleHTML
 const exampleInput = screen.getByLabelText(/example/i)
 ```
 
-> **Note**
->
-> You need a global DOM environment to use `screen`. If you're using jest, with
-> the
-> [testEnvironment](https://jestjs.io/docs/en/configuration#testenvironment-string)
-> set to `jsdom`, a global DOM environment will be available for you.
->
-> If you're loading your test with a `script` tag, make sure it comes after the
-> `body`. An example can be seen
-> [here](https://github.com/testing-library/dom-testing-library/issues/700#issuecomment-692218886).
+:::caution
+You need a global DOM environment to use `screen`. If you're using jest, with
+the
+[testEnvironment](https://jestjs.io/docs/en/configuration#testenvironment-string)
+set to `jsdom`, a global DOM environment will be available for you.
+
+If you're loading your test with a `script` tag, make sure it comes after the
+`body`. An example can be seen
+[here](https://github.com/testing-library/dom-testing-library/issues/700#issuecomment-692218886).
+:::
 
 ### `screen.debug`
 
@@ -143,14 +145,14 @@ screen.logTestingPlaygroundURL(screen.getByText('test'))
 
 ## Queries
 
-> **Note**
->
-> These queries are the base queries and require you to pass a `container` as
-> the first argument. Most framework-implementations of Testing Library provide
-> a pre-bound version of these queries when you render your components with them
-> which means you do not have to provide a container. In addition, if you just
-> want to query `document.body` then you can use the [`screen`](#screen) export
-> as demonstrated above (using `screen` is recommended).
+:::info
+These queries are the base queries and require you to pass a `container` as
+the first argument. Most framework-implementations of Testing Library provide
+a pre-bound version of these queries when you render your components with them
+which means you do not have to provide a container. In addition, if you just
+want to query `document.body` then you can use the [`screen`](#screen) export
+as demonstrated above (using `screen` is recommended).
+:::
 
 ### `ByLabelText`
 
@@ -256,10 +258,10 @@ If it is important that you query an actual `<label>` element you can provide a
 const inputNode = screen.getByLabelText('Username', { selector: 'input' })
 ```
 
-> **Note**
->
-> `getByLabelText` will not work in the case where a `for` attribute on a
-> `<label>` element matches an `id` attribute on a non-form element.
+:::danger
+`getByLabelText` will not work in the case where a `for` attribute on a
+`<label>` element matches an `id` attribute on a non-form element.
+:::
 
 ```js
 // This case is not valid
@@ -321,10 +323,10 @@ cy.findByPlaceholderText('Username').should('exist')
   </TabItem>
   </Tabs>
 
-> **Note**
->
-> A placeholder is not a good substitute for a label so you should generally use
-> `getByLabelText` instead.
+:::tip
+A placeholder is not a good substitute for a label so you should generally use
+`getByLabelText` instead.
+:::
 
 ### `ByText`
 
@@ -387,10 +389,10 @@ It also works with `input`s whose `type` attribute is either `submit` or
 <input type="submit" value="Send data" />
 ```
 
-> **Note**
->
-> See [`getByLabelText`](#bylabeltext) for more details on how and when to use
-> the `selector` option
+:::info
+See [`getByLabelText`](#bylabeltext) for more details on how and when to use
+the `selector` option
+:::
 
 The `ignore` option accepts a query selector. If the
 [`node.matches`](https://developer.mozilla.org/en-US/docs/Web/API/Element/matches)
@@ -697,9 +699,11 @@ example, a `button` element can't have the `role` attribute of `heading`,
 because the `button` element has default characteristics that conflict with the
 `heading` role.
 
-> Roles are matched literally by string equality, without inheriting from the
-> ARIA role hierarchy. As a result, querying a superclass role like `checkbox`
-> will not include elements with a subclass role like `switch`.
+:::caution
+Roles are matched literally by string equality, without inheriting from the
+ARIA role hierarchy. As a result, querying a superclass role like `checkbox`
+will not include elements with a subclass role like `switch`.
+:::
 
 You can query the returned element(s) by their
 [accessible name](https://www.w3.org/TR/accname-1.1/). The accessible name is
@@ -786,10 +790,10 @@ you can get the "Sugar" option by calling
 state and which elements can have this state see
 [ARIA `aria-checked`](https://www.w3.org/TR/wai-aria-1.2/#aria-checked).
 
-> **Note**
->
-> Checkboxes have a "mixed" state, which is considered neither checked nor
-> unchecked (details [here](https://www.w3.org/TR/html-aam-1.0/#details-id-56)).
+:::info
+Checkboxes have a "mixed" state, which is considered neither checked nor
+unchecked (details [here](https://www.w3.org/TR/html-aam-1.0/#details-id-56)).
+:::
 
 #### `pressed`
 
@@ -888,11 +892,13 @@ For example, `getByRole('switch')` would always match
 `getByRole('checkbox', { queryFallbacks: true })` would enable all fallback
 roles and therefore match the same element.
 
-> An element doesn't have multiple roles in a given environment. It has a single
-> one. Multiple roles in the attribute are evaluated from left to right until
-> the environment finds the first role it understands. This is useful when new
-> roles get introduced and you want to start supporting those as well as older
-> environments that don't understand that role (yet).
+:::info
+An element doesn't have multiple roles in a given environment. It has a single
+one. Multiple roles in the attribute are evaluated from left to right until
+the environment finds the first role it understands. This is useful when new
+roles get introduced and you want to start supporting those as well as older
+environments that don't understand that role (yet).
+:::
 
 #### `level`
 
@@ -938,8 +944,10 @@ headings `<h1>-<h6>`.
 To learn more about the `aria-level` property, see
 [ARIA `aria-level`](https://www.w3.org/TR/wai-aria-1.2/#aria-level).
 
-> The `level` option is _only_ applicable to the `heading` role. An error will
-> be thrown when used with any other role.
+:::danger
+The `level` option is _only_ applicable to the `heading` role. An error will
+be thrown when used with any other role.
+:::
 
 ### `ByTestId`
 
@@ -993,13 +1001,15 @@ cy.findByTestId('custom-element').should('exist')
   </TabItem>
   </Tabs>
 
-> In the spirit of [the guiding principles](guiding-principles.mdx), it is
-> recommended to use this only after the other queries don't work for your use
-> case. Using data-testid attributes do not resemble how your software is used
-> and should be avoided if possible. That said, they are _way_ better than
-> querying based on DOM structure or styling css class names. Learn more about
-> `data-testid`s from the blog post
-> ["Making your UI tests resilient to change"](https://kentcdodds.com/blog/making-your-ui-tests-resilient-to-change)
+:::caution
+In the spirit of [the guiding principles](guiding-principles.mdx), it is
+recommended to use this only after the other queries don't work for your use
+case. Using data-testid attributes do not resemble how your software is used
+and should be avoided if possible. That said, they are _way_ better than
+querying based on DOM structure or styling css class names. Learn more about
+`data-testid`s from the blog post
+["Making your UI tests resilient to change"](https://kentcdodds.com/blog/making-your-ui-tests-resilient-to-change)
+:::
 
 #### Overriding `data-testid`
 
@@ -1042,11 +1052,11 @@ If you want to prevent that normalization, or provide alternative normalization
 function in the options object. This function will be given a string and is
 expected to return a normalized version of that string.
 
-> **Note**
->
-> Specifying a value for `normalizer` _replaces_ the built-in normalization, but
-> you can call `getDefaultNormalizer` to obtain a built-in normalizer, either to
-> adjust that normalization or to call it from your own normalizer.
+:::info
+Specifying a value for `normalizer` _replaces_ the built-in normalization, but
+you can call `getDefaultNormalizer` to obtain a built-in normalizer, either to
+adjust that normalization or to call it from your own normalizer.
+:::
 
 `getDefaultNormalizer` takes an options object which allows the selection of
 behaviour:
diff --git a/docs/dom-testing-library/cheatsheet.mdx b/docs/dom-testing-library/cheatsheet.mdx
index 42b376b8d..cc730fae5 100644
--- a/docs/dom-testing-library/cheatsheet.mdx
+++ b/docs/dom-testing-library/cheatsheet.mdx
@@ -85,16 +85,15 @@ See [Async API](dom-testing-library/api-async.mdx). Remember to `await` or
 - **waitForElementToBeRemoved** (Promise) retry the function until it no longer
   returns a DOM node
 
-> **Deprecated since v7.0.0:**
->
-> - **wait** (Promise) retry the function within until it stops throwing or
->   times
-> - **waitForElement** (Promise) retry the function until it returns an element
->   or an array of elements
-> - `findBy` and `findAllBy` queries are async and retry until either a timeout
->   or if the query returns successfully; they wrap `waitForElement`
-> - **waitForDomChange** (Promise) retry the function each time the DOM is
->   changed
+:::danger Deprecated since v7.0.0
+
+- **wait** (Promise) retry the function within until it stops throwing or times
+- **waitForElement** (Promise) retry the function until it returns an element or
+  an array of elements
+- `findBy` and `findAllBy` queries are async and retry until either a timeout or
+  if the query returns successfully; they wrap `waitForElement`
+- **waitForDomChange** (Promise) retry the function each time the DOM is changed
+  :::
 
 ## Events
 
diff --git a/docs/ecosystem-jasmine-dom.mdx b/docs/ecosystem-jasmine-dom.mdx
index 956fd154d..1961e2f77 100644
--- a/docs/ecosystem-jasmine-dom.mdx
+++ b/docs/ecosystem-jasmine-dom.mdx
@@ -21,10 +21,10 @@ expect(screen.queryByTestId('not-empty')).not.toBeEmptyDOMElement()
 expect(screen.getByText('Visible Example')).toBeVisible()
 ```
 
-> Note: when using some of these matchers, you may need to make sure you use a
-> query function (like `queryByTestId`) rather than a get function (like
-> `getByTestId`). Otherwise the `get*` function could throw an error before your
-> assertion.
+:::caution When using some of these matchers, you may need to make sure you use
+a query function (like `queryByTestId`) rather than a get function (like
+`getByTestId`). Otherwise the `get*` function could throw an error before your
+assertion. :::
 
 Check out [jasmine-dom's documentation][gh] for a full list of available
 matchers.
diff --git a/docs/ecosystem-jest-dom.mdx b/docs/ecosystem-jest-dom.mdx
index ce90a6d8a..ddd5d416c 100644
--- a/docs/ecosystem-jest-dom.mdx
+++ b/docs/ecosystem-jest-dom.mdx
@@ -27,10 +27,10 @@ test('uses jest-dom', () => {
 })
 ```
 
-> Note: when using some of these matchers, you may need to make sure you use a
-> query function (like `queryByTestId`) rather than a get function (like
-> `getByTestId`). Otherwise the `get*` function could throw an error before your
-> assertion.
+:::caution When using some of these matchers, you may need to make sure you use
+a query function (like `queryByTestId`) rather than a get function (like
+`getByTestId`). Otherwise the `get*` function could throw an error before your
+assertion. :::
 
 Check out [jest-dom's documentation][gh] for a full list of available matchers.
 
diff --git a/docs/ecosystem-jest-native.mdx b/docs/ecosystem-jest-native.mdx
index 6b3f20634..8d069ecd2 100644
--- a/docs/ecosystem-jest-native.mdx
+++ b/docs/ecosystem-jest-native.mdx
@@ -24,10 +24,10 @@ expect(queryByTestId(baseElement, 'not-empty')).not.toBeEmpty()
 expect(getByText(baseElement, 'Visible Example')).toBeVisible()
 ```
 
-> Note: when using some of these matchers, you may need to make sure you use a
-> query function (like `queryByTestId`) rather than a get function (like
-> `getByTestId`). Otherwise the `get*` function could throw an error before your
-> assertion.
+:::caution When using some of these matchers, you may need to make sure you use
+a query function (like `queryByTestId`) rather than a get function (like
+`getByTestId`). Otherwise the `get*` function could throw an error before your
+assertion. :::
 
 Check out
 [Jest Native's documentation](https://github.com/testing-library/jest-native)
diff --git a/docs/example-drag.mdx b/docs/example-drag.mdx
index 2d0fcecff..b2a982aa4 100644
--- a/docs/example-drag.mdx
+++ b/docs/example-drag.mdx
@@ -4,10 +4,8 @@ title: Drag
 sidebar_label: Drag
 ---
 
-> **Note**
->
-> This example only works with a real browser (not with jsdom, as it does not
-> support `getBoundingClientRect`).
+:::caution This example only works with a real browser (not with jsdom, as it
+does not support `getBoundingClientRect`). :::
 
 # Usage
 
@@ -57,11 +55,11 @@ function getElementClientCenter(element) {
   }
 }
 
-const getCoords = (charlie) =>
+const getCoords = charlie =>
   isElement(charlie) ? getElementClientCenter(charlie) : charlie
 
-const sleep = (ms) =>
-  new Promise((resolve) => {
+const sleep = ms =>
+  new Promise(resolve => {
     setTimeout(resolve, ms)
   })
 
diff --git a/docs/example-input-event.mdx b/docs/example-input-event.mdx
index 689439bda..4438349b8 100644
--- a/docs/example-input-event.mdx
+++ b/docs/example-input-event.mdx
@@ -4,11 +4,9 @@ title: Input Event
 sidebar_label: Input Event
 ---
 
-> **Note**
->
-> If you want to simulate a more natural typing behaviour while testing your
-> component, consider the companion library
-> [`user-event`](ecosystem-user-event.mdx)
+:::tip If you want to simulate a more natural typing behaviour while testing
+your component, consider the companion library
+[`user-event`](ecosystem-user-event.mdx) :::
 
 ```jsx
 import React, { useState } from 'react'
@@ -17,10 +15,10 @@ import { render, fireEvent } from '@testing-library/react'
 function CostInput() {
   const [value, setValue] = useState('')
 
-  removeDollarSign = (value) => (value[0] === '$' ? value.slice(1) : value)
-  getReturnValue = (value) => (value === '' ? '' : `$${value}`)
+  removeDollarSign = value => (value[0] === '$' ? value.slice(1) : value)
+  getReturnValue = value => (value === '' ? '' : `$${value}`)
 
-  handleChange = (ev) => {
+  handleChange = ev => {
     ev.preventDefault()
     const inputtedValue = ev.currentTarget.value
     const noDollarSign = removeDollarSign(inputtedValue)
diff --git a/docs/example-react-intl.mdx b/docs/example-react-intl.mdx
index 79e6f3e36..9246a566f 100644
--- a/docs/example-react-intl.mdx
+++ b/docs/example-react-intl.mdx
@@ -3,10 +3,8 @@ id: example-react-intl
 title: React Intl
 ---
 
-> **Note**
->
-> If you want to combine setupTests with another setup you should check
-> [`setup`](react-testing-library/setup.mdx)
+:::info If you want to combine setupTests with another setup you should check
+[`setup`](react-testing-library/setup.mdx) :::
 
 ## Configuring React-Intl Polyfills / Locales
 
diff --git a/docs/marko-testing-library/api.mdx b/docs/marko-testing-library/api.mdx
index f352a79c9..8acff49fe 100644
--- a/docs/marko-testing-library/api.mdx
+++ b/docs/marko-testing-library/api.mdx
@@ -54,10 +54,8 @@ test('renders a message', async () => {
 })
 ```
 
-> Note
->
-> The [cleanup](#cleanup) function should be called between tests to remove the
-> created DOM nodes and keep the tests isolated.
+:::tip The [cleanup](#cleanup) function should be called between tests to remove
+the created DOM nodes and keep the tests isolated. :::
 
 ### `render` Options
 
@@ -219,13 +217,13 @@ this is a [JSDOM.fragment](https://github.com/jsdom/jsdom#fragment), and for
 client side tests this will be whatever is passed as the `container` render
 option.
 
-> Tip: To get the root element of your rendered element, use
-> `container.firstChild`.
+:::tip Tip: To get the root element of your rendered element, use
+`container.firstChild`. :::
 
-> 🚨 If you find yourself using `container` to query for rendered elements then
-> you should reconsider! The other queries are designed to be more resilient to
-> changes that will be made to the component you're testing. Avoid using
-> `container` to query for elements!
+:::caution If you find yourself using `container` to query for rendered elements
+then you should reconsider! The other queries are designed to be more resilient
+to changes that will be made to the component you're testing. Avoid using
+`container` to query for elements! :::
 
 ## `cleanup`
 
diff --git a/docs/marko-testing-library/intro.mdx b/docs/marko-testing-library/intro.mdx
index 8b102a20a..5d5fb95d7 100644
--- a/docs/marko-testing-library/intro.mdx
+++ b/docs/marko-testing-library/intro.mdx
@@ -52,6 +52,6 @@ when a real user uses it.
 2.  Specific to a testing framework, you can [use it with Jest](setup.mdx#jest),
     [mocha](setup.mdx#mocha), or other test runners.
 
-> NOTE: This library is built on top of
-> [`DOM Testing Library`](dom-testing-library/intro.mdx) which is where most of
-> the logic behind the queries is.
+:::info This library is built on top of
+[`DOM Testing Library`](dom-testing-library/intro.mdx) which is where most of
+the logic behind the queries is. :::
diff --git a/docs/nightwatch-testing-library/intro.mdx b/docs/nightwatch-testing-library/intro.mdx
index 2bb55fa12..d14b9607a 100644
--- a/docs/nightwatch-testing-library/intro.mdx
+++ b/docs/nightwatch-testing-library/intro.mdx
@@ -8,8 +8,9 @@ in [Nightwatch](https://nightwatchjs.org) for end-to-end web testing.
 
 ## Install
 
-> Be sure to follow the
-> [Nightwatch install & config instructions first](https://nightwatchjs.org/gettingstarted/installation/)
+:::info Be sure to follow the
+[Nightwatch install & config instructions first](https://nightwatchjs.org/gettingstarted/installation/)
+:::
 
 then just
 
@@ -33,7 +34,7 @@ to solve this problem 🤗.
 **So remember, the results from NWTL queries are WebDriver locators, not DOM
 nodes.**
 
-> Note, in NWTL, all queries must be `await`ed.
+:::caution In NWTL, all queries must be `await`ed. :::
 
 ## Usage
 
diff --git a/docs/preact-testing-library/example.mdx b/docs/preact-testing-library/example.mdx
index 331b0128d..e496efe7f 100644
--- a/docs/preact-testing-library/example.mdx
+++ b/docs/preact-testing-library/example.mdx
@@ -4,8 +4,8 @@ title: Example
 sidebar_label: Example
 ---
 
-> Preact Testing Library works with both Preact Hooks and Classes. Your tests
-> will be the same however you write your components.
+:::info Preact Testing Library works with both Preact Hooks and Classes. Your
+tests will be the same however you write your components. :::
 
 ## Component
 
@@ -19,7 +19,7 @@ function HiddenMessage({ children }) {
       <input
         id="toggle"
         type="checkbox"
-        onChange={(e) => setShowMessage(e.target.checked)}
+        onChange={e => setShowMessage(e.target.checked)}
         checked={showMessage}
       />
       {showMessage ? children : null}
diff --git a/docs/preact-testing-library/intro.mdx b/docs/preact-testing-library/intro.mdx
index e175a2900..3c41d4060 100644
--- a/docs/preact-testing-library/intro.mdx
+++ b/docs/preact-testing-library/intro.mdx
@@ -12,9 +12,9 @@ sidebar_label: Introduction
 npm install --save-dev @testing-library/preact
 ```
 
-> This library is built on top of
-> [`DOM Testing Library`](dom-testing-library/intro.mdx) which is where most of
-> the logic behind the queries is.
+:::info This library is built on top of
+[`DOM Testing Library`](dom-testing-library/intro.mdx) which is where most of
+the logic behind the queries is. :::
 
 ## The Problem
 
diff --git a/docs/react-testing-library/api.mdx b/docs/react-testing-library/api.mdx
index 1806b5cea..5876dd1f0 100644
--- a/docs/react-testing-library/api.mdx
+++ b/docs/react-testing-library/api.mdx
@@ -146,18 +146,18 @@ The containing DOM node of your rendered React Element (rendered using
 `ReactDOM.render`). It's a `div`. This is a regular DOM node, so you can call
 `container.querySelector` etc. to inspect the children.
 
-> Tip: To get the root element of your rendered element, use
-> `container.firstChild`.
->
-> NOTE: When that root element is a
-> [React Fragment](https://reactjs.org/docs/fragments.html),
-> `container.firstChild` will only get the first child of that Fragment, not the
-> Fragment itself.
-
-> 🚨 If you find yourself using `container` to query for rendered elements then
-> you should reconsider! The other queries are designed to be more resilient to
-> changes that will be made to the component you're testing. Avoid using
-> `container` to query for elements!
+:::tip Tip: To get the root element of your rendered element, use
+`container.firstChild`. :::
+
+:::info When that root element is a
+[React Fragment](https://reactjs.org/docs/fragments.html),
+`container.firstChild` will only get the first child of that Fragment, not the
+Fragment itself. :::
+
+:::caution 🚨 If you find yourself using `container` to query for rendered
+elements then you should reconsider! The other queries are designed to be more
+resilient to changes that will be made to the component you're testing. Avoid
+using `container` to query for elements! :::
 
 ### `baseElement`
 
@@ -169,14 +169,14 @@ This is useful when the component you want to test renders something outside the
 container div, e.g. when you want to snapshot test your portal component which
 renders its HTML directly in the body.
 
-> Note: the queries returned by the `render` looks into baseElement, so you can
-> use queries to test your portal component without the baseElement.
+:::info The queries returned by the `render` looks into baseElement, so you can
+use queries to test your portal component without the baseElement. :::
 
 ### `debug`
 
-> NOTE: It's recommended to use
-> [`screen.debug`](https://testing-library.com/docs/dom-testing-library/api-queries#screendebug)
-> instead.
+:::caution NOTE: It's recommended to use
+[`screen.debug`](https://testing-library.com/docs/dom-testing-library/api-queries#screendebug)
+instead. :::
 
 This method is a shortcut for `console.log(prettyDOM(baseElement))`.
 
@@ -225,8 +225,8 @@ This will cause the rendered component to be unmounted. This is useful for
 testing what happens when your component is removed from the page (like testing
 that you don't leave event handlers hanging around causing memory leaks).
 
-> This method is a pretty small abstraction over
-> `ReactDOM.unmountComponentAtNode`
+:::info This method is a pretty small abstraction over
+`ReactDOM.unmountComponentAtNode` :::
 
 ```jsx
 import { render } from '@testing-library/react'
@@ -249,7 +249,7 @@ const TestComponent = () => {
   const [count, setCounter] = useState(0)
 
   return (
-    <button onClick={() => setCounter((count) => count + 1)}>
+    <button onClick={() => setCounter(count => count + 1)}>
       Click to increase: {count}
     </button>
   )
@@ -272,10 +272,10 @@ expect(firstRender).toMatchDiffSnapshot(asFragment())
 
 Unmounts React trees that were mounted with [render](#render).
 
-> Please note that this is done automatically if the testing framework you're
-> using supports the `afterEach` global and it is injected to your testing
-> environment (like mocha, Jest, and Jasmine). If not, you will need to do
-> manual cleanups after each test.
+:::info This is done automatically if the testing framework you're using
+supports the `afterEach` global and it is injected to your testing environment
+(like mocha, Jest, and Jasmine). If not, you will need to do manual cleanups
+after each test. :::
 
 For example, if you're using the [ava](https://github.com/avajs/ava) testing
 framework, then you would need to use the `test.afterEach` hook like so:
diff --git a/docs/react-testing-library/cheatsheet.mdx b/docs/react-testing-library/cheatsheet.mdx
index 1e879d097..626794deb 100644
--- a/docs/react-testing-library/cheatsheet.mdx
+++ b/docs/react-testing-library/cheatsheet.mdx
@@ -31,11 +31,10 @@ test('loads items eventually', async () => {
 
 ## Queries
 
-> **Difference from DOM Testing Library**
->
-> The queries returned from `render` in `React Testing Library` are the same as
-> `DOM Testing Library` except they have the first argument bound to the
-> document, so instead of `getByText(node, 'text')` you do `getByText('text')`
+:::info Difference from DOM Testing Library The queries returned from `render`
+in `React Testing Library` are the same as `DOM Testing Library` except they
+have the first argument bound to the document, so instead of
+`getByText(node, 'text')` you do `getByText('text')` :::
 
 See [Which query should I use?](guide-which-query.mdx)
 
diff --git a/docs/react-testing-library/example-intro.mdx b/docs/react-testing-library/example-intro.mdx
index c0afe6e48..3bb2e29a3 100644
--- a/docs/react-testing-library/example-intro.mdx
+++ b/docs/react-testing-library/example-intro.mdx
@@ -56,9 +56,9 @@ test('handles server error', async () => {
 })
 ```
 
-> We recommend using [Mock Service Worker](https://github.com/mswjs/msw) library
-> to declaratively mock API communication in your tests instead of stubbing
-> `window.fetch`, or relying on third-party adapters.
+:::tip We recommend using [Mock Service Worker](https://github.com/mswjs/msw)
+library to declaratively mock API communication in your tests instead of
+stubbing `window.fetch`, or relying on third-party adapters. :::
 
 ---
 
@@ -208,13 +208,13 @@ export default function Fetch({ url }) {
   const fetchGreeting = async () => {
     axios
       .get(url)
-      .then((response) => {
+      .then(response => {
         const { data } = response
         const { greeting } = data
         dispatch({ type: 'SUCCESS', greeting })
         setButtonClicked(true)
       })
-      .catch((error) => {
+      .catch(error => {
         dispatch({ type: 'ERROR', error })
       })
   }
diff --git a/docs/react-testing-library/intro.mdx b/docs/react-testing-library/intro.mdx
index da81e0781..0555ddacd 100644
--- a/docs/react-testing-library/intro.mdx
+++ b/docs/react-testing-library/intro.mdx
@@ -7,9 +7,9 @@ sidebar_label: Introduction
 [`React Testing Library`][gh] builds on top of `DOM Testing Library` by adding
 APIs for working with React components.
 
-> Projects created with [`Create React App`](https://create-react-app.dev/) have
-> out of the box support for **React Testing Library**. If that is not the case,
-> you can add it via `npm` like so:
+:::tip Projects created with [`Create React App`](https://create-react-app.dev/)
+have out of the box support for **React Testing Library**. If that is not the
+case, you can add it via `npm` like so: :::
 
 ```
 npm install --save-dev @testing-library/react
@@ -64,9 +64,9 @@ facilitate testing implementation details). Read more about this in
     the library works with any framework. See
     [Using Without Jest](setup.mdx#using-without-jest))
 
-> NOTE: This library is built on top of
-> [`DOM Testing Library`](dom-testing-library/intro.mdx) which is where most of
-> the logic behind the queries is.
+:::info This library is built on top of
+[`DOM Testing Library`](dom-testing-library/intro.mdx) which is where most of
+the logic behind the queries is. :::
 
 ## Tutorials
 
diff --git a/docs/react-testing-library/migrate-from-enzyme.mdx b/docs/react-testing-library/migrate-from-enzyme.mdx
index 483973699..12420fb09 100644
--- a/docs/react-testing-library/migrate-from-enzyme.mdx
+++ b/docs/react-testing-library/migrate-from-enzyme.mdx
@@ -96,10 +96,11 @@ test('test title', () => {
 })
 ```
 
-> Note: you can also use `describe` and `it` blocks with React Testing Library.
-> React Testing Library doesn't replace Jest, just Enzyme. We recommend `test`
-> because it helps with this:
-> [Avoid Nesting When You're Testing](https://kentcdodds.com/blog/avoid-nesting-when-youre-testing)
+:::info You can also use `describe` and `it` blocks with React Testing Library.
+React Testing Library doesn't replace Jest, just Enzyme. We recommend `test`
+because it helps with this:
+[Avoid Nesting When You're Testing](https://kentcdodds.com/blog/avoid-nesting-when-youre-testing)
+:::
 
 ## Basic Enzyme to React Testing Library migration examples
 
@@ -125,13 +126,13 @@ different name, and the template updates accordingly. Check the live version on
 [Codesandbox](https://codesandbox.io/s/ecstatic-hellman-fh7in)
 
 ```jsx
-const Welcome = (props) => {
+const Welcome = props => {
   const [values, setValues] = useState({
     firstName: props.firstName,
     lastName: props.lastName,
   })
 
-  const handleChange = (event) => {
+  const handleChange = event => {
     setValues({ ...values, [event.target.name]: event.target.value })
   }
 
@@ -246,8 +247,8 @@ those who are using screen readers. This
 [section](dom-testing-library/api-queries.mdx#byrole) of the query page might
 help you to understand better.
 
-> Keep in mind that a `<form>` must have a `name` attribute in order to have an
-> implicit `role` of `form` (as required by the specification).
+:::caution A `<form>` must have a `name` attribute in order to have an implicit
+`role` of `form` (as required by the specification). :::
 
 React Testing Library aims to test the component, like how users would, users
 see the button, heading, form and other elements by their role, not by their
diff --git a/docs/react-testing-library/setup.mdx b/docs/react-testing-library/setup.mdx
index 5bdcac68d..4fdd1dfa8 100644
--- a/docs/react-testing-library/setup.mdx
+++ b/docs/react-testing-library/setup.mdx
@@ -60,12 +60,10 @@ export * from '@testing-library/react'
 export { customRender as render }
 ```
 
-> **Note**
->
-> Babel versions lower than 7 throw an error when trying to override the named
-> export in the example above. See
-> [#169](https://github.com/testing-library/react-testing-library/issues/169)
-> and the workaround below.
+:::caution Babel versions lower than 7 throw an error when trying to override
+the named export in the example above. See
+[#169](https://github.com/testing-library/react-testing-library/issues/169) and
+the workaround below. :::
 
 <summary>Workaround for Babel 6</summary>
 
@@ -88,12 +86,10 @@ module.exports = {
 
 ### Add custom queries
 
-> **Note**
->
-> Generally you should not need to create custom queries for
-> react-testing-library. Where you do use it, you should consider whether your
-> new queries encourage you to test in a user-centric way, without testing
-> implementation details.
+:::tip Generally you should not need to create custom queries for
+react-testing-library. Where you do use it, you should consider whether your new
+queries encourage you to test in a user-centric way, without testing
+implementation details. :::
 
 You can define your own custom queries as described in the example in the
 [Helpers API](dom-testing-library/api-helpers.mdx) documentation, or via the
diff --git a/docs/svelte-testing-library/api.mdx b/docs/svelte-testing-library/api.mdx
index 4788921c5..c9d4f10e4 100644
--- a/docs/svelte-testing-library/api.mdx
+++ b/docs/svelte-testing-library/api.mdx
@@ -75,7 +75,8 @@ const { results } = render(YourComponent, { myProp: 'value' })
 
 ## `cleanup`
 
-> You don't need to import or use this, it's done automagically for you!
+:::info You don't need to import or use this, it's done automagically for you!
+:::
 
 Unmounts the component from the container and destroys the container.
 
diff --git a/docs/svelte-testing-library/intro.mdx b/docs/svelte-testing-library/intro.mdx
index 7a5d2be56..87e89e76d 100644
--- a/docs/svelte-testing-library/intro.mdx
+++ b/docs/svelte-testing-library/intro.mdx
@@ -12,9 +12,9 @@ sidebar_label: Introduction
 npm install --save-dev @testing-library/svelte
 ```
 
-> This library is built on top of
-> [`DOM Testing Library`](dom-testing-library/intro.mdx) which is where most of
-> the logic behind the queries is.
+:::info This library is built on top of
+[`DOM Testing Library`](dom-testing-library/intro.mdx) which is where most of
+the logic behind the queries is. :::
 
 ## The Problem
 
diff --git a/docs/testcafe-testing-library/intro.mdx b/docs/testcafe-testing-library/intro.mdx
index 144d1059e..fb1b2a9aa 100644
--- a/docs/testcafe-testing-library/intro.mdx
+++ b/docs/testcafe-testing-library/intro.mdx
@@ -41,12 +41,12 @@ find[All]By\* selectors that you can use in your tests.
 
 [See `DOM Testing Library` API for reference](dom-testing-library/api-queries.mdx)
 
-> A note about queries in testcafe. Testcafe has
-> [built in waiting](https://devexpress.github.io/testcafe/documentation/test-api/built-in-waiting-mechanisms.html#wait-mechanism-for-selectors),
-> for this reason, there's no difference between `queryBy` and `findBy` queries
-> in testcafe testing library. `getBy` queries will throw an exception (as
-> designed) so they will fail immediately and do not work with the built in
-> waiting that Testcafe provides.
+:::caution Queries in Testcafe Testcafe has
+[built in waiting](https://devexpress.github.io/testcafe/documentation/test-api/built-in-waiting-mechanisms.html#wait-mechanism-for-selectors),
+for this reason, there's no difference between `queryBy` and `findBy` queries in
+testcafe testing library. `getBy` queries will throw an exception (as designed)
+so they will fail immediately and do not work with the built in waiting that
+Testcafe provides. :::
 
 ## Examples
 
@@ -56,24 +56,24 @@ To show some simple examples (from
 ```javascript
 import { screen } from '@testing-library/testcafe'
 
-test('getByPlaceHolderText', async (t) => {
+test('getByPlaceHolderText', async t => {
   await t.typeText(
     screen.getByPlaceholderText('Placeholder Text'),
     'Hello Placeholder'
   )
 })
-test('getByText', async (t) => {
+test('getByText', async t => {
   await t.click(screen.getByText('getByText'))
 })
 
-test('getByLabelText', async (t) => {
+test('getByLabelText', async t => {
   await t.typeText(
     screen.getByLabelText('Label For Input Labelled By Id'),
     'Hello Input Labelled By Id'
   )
 })
 
-test('queryAllByText', async (t) => {
+test('queryAllByText', async t => {
   await t.expect(screen.queryAllByText('Button Text').exists).ok()
   await t
     .expect(screen.queryAllByText('Non-existing Button Text').exists)
@@ -91,7 +91,7 @@ Testing Library][config] in a few different ways:
 ```javascript
 import { configureOnce, getByTestId } from '@testing-library/testcafe'
 
-test('can be configured once in a single page load', async (t) => {
+test('can be configured once in a single page load', async t => {
   await configureOnce({ testIdAttribute: 'data-other-test-id' })
   await t.click(screen.getByTestId('other-id'))
 })
@@ -106,11 +106,11 @@ fixture`configure`.clientScripts(
   configure({ testIdAttribute: 'data-automation-id' })
 ).page`http://localhost:13370`
 
-test('supports alternative testIdAttribute', async (t) => {
+test('supports alternative testIdAttribute', async t => {
   await t.click(screen.getByTestId('image-with-random-alt-tag'))
 })
 
-test('still works after browser page load and reload', async (t) => {
+test('still works after browser page load and reload', async t => {
   await t.click(screen.getByText('Go to Page 2'))
 
   await t.eval(() => location.reload(true))
@@ -124,7 +124,8 @@ test('still works after browser page load and reload', async (t) => {
 
 ### Globally for all fixtures, tests and page loads by [injecting clientScripts][inject]
 
-> Note: the dom-testing-library umd must come before your configure script
+:::caution The dom-testing-library umd must come before your configure script
+:::
 
 ```json title=".testcaferc.json"
   "clientScripts": [
@@ -151,7 +152,7 @@ import { within, screen } from '@testing-library/testcafe'
 
 fixture`within`.page`http://localhost:13370`
 
-test('works with getBy* selectors', async (t) => {
+test('works with getBy* selectors', async t => {
   await t
     .expect(
       within(screen.getByTestId('nested')).getByText('Button Text').exists
@@ -159,18 +160,18 @@ test('works with getBy* selectors', async (t) => {
     .ok()
 })
 
-test('works with CSS selector strings', async (t) => {
+test('works with CSS selector strings', async t => {
   const { getByText } = await within('#nested')
   await t.click(getByText('Button Text')).ok()
 })
 
-test('works on any testcafe selector', async (t) => {
+test('works on any testcafe selector', async t => {
   const nested = Selector('#nested')
 
   await t.expect(within(nested).getByText('Button Text').exists).ok()
 })
 
-test('works with results from "byAll" query with index - regex', async (t) => {
+test('works with results from "byAll" query with index - regex', async t => {
   const nestedDivs = screen.getAllByTestId(/nested/)
   await t.expect(nestedDivs.count).eql(2)
 
diff --git a/docs/vue-testing-library/api.mdx b/docs/vue-testing-library/api.mdx
index b602d1171..31873c601 100644
--- a/docs/vue-testing-library/api.mdx
+++ b/docs/vue-testing-library/api.mdx
@@ -81,8 +81,10 @@ Router.
 function callbackFunction(vueInstance, vuexStore, router) {}
 ```
 
-A callback function that receives the Vue instance as a parameter. Its return value is merged with [options](#options), allowing
-3rd party plugins to be installed prior to mount. To see how this works, see the example using [`vue-i18n`](https://github.com/testing-library/vue-testing-library/blob/master/src/__tests__/vue-i18n.js).
+A callback function that receives the Vue instance as a parameter. Its return
+value is merged with [options](#options), allowing 3rd party plugins to be
+installed prior to mount. To see how this works, see the example using
+[`vue-i18n`](https://github.com/testing-library/vue-testing-library/blob/master/src/__tests__/vue-i18n.js).
 
 The function will also receive the Store or the Router object if the associated
 option was passed in during render.
@@ -120,8 +122,8 @@ const { container } = render(TableBody, {
 })
 ```
 
-> Tip: To get the root element of your rendered element, use
-> `container.firstChild`.
+:::tip To get the root element of your rendered element, use
+`container.firstChild`. :::
 
 #### `baseElement`
 
@@ -226,9 +228,9 @@ See a working example of `update` in the
 Unmounts Vue trees that were mounted with
 [render](#rendercomponent-options-callback).
 
-> If you are using an environment that supports `afterEach` hook (as in Jest),
-> there's no need to call `cleanup` manually. Vue Testing Library handles it for
-> you.
+:::info If you are using an environment that supports `afterEach` hook (as in
+Jest), there's no need to call `cleanup` manually. Vue Testing Library handles
+it for you. :::
 
 Failing to call `cleanup` when you've called `render` could result in a memory
 leak and tests which are not idempotent (which can lead to difficult to debug
diff --git a/docs/vue-testing-library/cheatsheet.mdx b/docs/vue-testing-library/cheatsheet.mdx
index 3b29b7dfe..2eb370ffb 100644
--- a/docs/vue-testing-library/cheatsheet.mdx
+++ b/docs/vue-testing-library/cheatsheet.mdx
@@ -7,12 +7,10 @@ A short guide to all the exported functions in `Vue Testing Library`.
 
 ## Queries
 
-> **Difference from DOM Testing Library**
->
-> The queries returned from `render` in `Vue Testing Library` are the same as
-> `DOM Testing Library`. Yet, they have the first argument bound to the
-> document, so instead of `getByText(node, 'text')` you write
-> `getByText('text')`.
+:::info Difference from DOM Testing Library The queries returned from `render`
+in `Vue Testing Library` are the same as `DOM Testing Library`. Yet, they have
+the first argument bound to the document, so instead of
+`getByText(node, 'text')` you write `getByText('text')`. :::
 
 ### Search variants
 
@@ -38,7 +36,7 @@ A short guide to all the exported functions in `Vue Testing Library`.
 | **...ByRole**            | ARIA role                        | `<div role="dialog" />`               |
 | **...ByTestId**          | data-testid attribute            | `<div data-testid="some-message" />`  |
 
-> You can write any combination of Search variants and Search types.
+:::info You can write any combination of Search variants and Search types. :::
 
 ### An example
 
@@ -63,7 +61,8 @@ For more information, see [Which query should I use?](guide-which-query.mdx).
 For more information, see
 [DOM Testing Library Async API](dom-testing-library/api-async.mdx).
 
-> Remember to `await` or `.then()` the result of async functions in your tests!
+:::caution Remember to `await` or `.then()` the result of async functions in
+your tests! :::
 
 ## Firing events
 
@@ -75,13 +74,13 @@ For more information, see
 
 For more information, see [Events API](dom-testing-library/api-events.mdx)
 
-> **Difference from DOM Testing Library**
->
-> The events returned from `Vue Testing Library` are all async, so you should
-> `await` or `then()` the result.
->
-> VTL also exposes `fireEvent.update(node, value)` event to deal with `v-model`.
-> See [the API](vue-testing-library/api.mdx#updateelem-value) for more details.
+:::info Difference from DOM Testing Library The events returned from
+`Vue Testing Library` are all async, so you should `await` or `then()` the
+result.
+
+VTL also exposes `fireEvent.update(node, value)` event to deal with `v-model`.
+See [the API](vue-testing-library/api.mdx#updateelem-value) for more details.
+:::
 
 ## Other