chore(docs): Migrate Docusaurus to v3

docs/docs/guides/developer-guide/importing-data/index.md

@@ -47,7 +47,7 @@ Here's an explanation of each column:
 
 ### Importing Custom Field Data
 
-If you have [CustomFields]({{< relref "customizing-models" >}}) defined on your Product or ProductVariant entities, this data can also be encoded in the import csv:
+If you have [CustomFields](/guides/developer-guide/custom-fields/) defined on your Product or ProductVariant entities, this data can also be encoded in the import csv:
 
 * `product:<customFieldName>`: The value of this column will populate `Product.customFields[customFieldName]`. 
 * `variant:<customFieldName>`: The value of this column will populate `ProductVariant.customFields[customFieldName]`. 

docs/docs/guides/developer-guide/migrating-from-v1/breaking-api-changes.md

@@ -127,7 +127,7 @@ const order = await this.connection
 
 With [#1545](https://github.com/vendure-ecommerce/vendure/issues/1545) we have changed the way we model stock levels in order to support multiple stock locations. This means that the `ProductVariant.stockOnHand` and `ProductVariant.stockAllocated` properties no longer exist on the `ProductVariant` entity in TypeScript.
 
-Instead, this information is now located at `ProductVariant.stockLevels`, which is an array of [StockLevel]({{< relref "stock-level" >}}) entities.
+Instead, this information is now located at `ProductVariant.stockLevels`, which is an array of [StockLevel](/reference/typescript-api/entities/stock-level) entities.
 
 ### New return type for Channel, TaxCategory & Zone lists
 
@@ -166,7 +166,7 @@ If you are using the `@vendure/ui-devkit` package to generate custom ui extensio
 - The Admin UI component `vdr-product-selector` has been renamed to `vdr-product-variant-selector` to more accurately represent what it does. If you are using `vdr-product-selector` if any ui extensions code, update it to use the new selector.
 
 ### Other breaking API changes
-- **End-to-end tests using Jest** will likely run into issues due to our move towards using some dependencies that make use of ES modules. We have found the best solution to be to migrate tests over to [Vitest](https://vitest.dev), which can handle this and is also significantly faster than Jest. See the updated [Testing guide]({{< relref "/guides/developer-guide/testing" >}}) for instructions on getting started with Vitest.
+- **End-to-end tests using Jest** will likely run into issues due to our move towards using some dependencies that make use of ES modules. We have found the best solution to be to migrate tests over to [Vitest](https://vitest.dev), which can handle this and is also significantly faster than Jest. See the updated [Testing guide](/guides/developer-guide/testing) for instructions on getting started with Vitest.
 - Internal `ErrorResult` classes now take a single object argument rather than multiple args.
 - All monetary values are now represented in the GraphQL APIs with a new `Money` scalar type. If you use [graphql-code-generator](https://the-guild.dev/graphql/codegen), you'll want to tell it to treat this scalar as a number:
     ```ts
@@ -210,4 +210,4 @@ If you are using the `@vendure/ui-devkit` package to generate custom ui extensio
 - If you are using the **BullMQJobQueuePlugin**, the minimum Redis recommended version is 6.2.0.
 - The `WorkerHealthIndicator` which was deprecated in v1.3.0 has been removed, as well as the `jobQueueOptions.enableWorkerHealthCheck` config option.
 - The `CustomerGroupEntityEvent` (fired on creation, update or deletion of a CustomerGroup) has been renamed to `CustomerGroupEvent`, and the former `CustomerGroupEvent` (fired when Customers are added to or removed from a group) has been renamed to `CustomerGroupChangeEvent`.
-- We introduced the [plugin compatibility API]({{< relref "vendure-plugin-metadata" >}}#compatibility) to allow plugins to indicate what version of Vendure they are compatible with. To avoid bootstrap messages you should add this property to your plugins.
+- We introduced the [plugin compatibility API](/guides/developer-guide/plugins/#step-7-specify-compatibility) to allow plugins to indicate what version of Vendure they are compatible with. To avoid bootstrap messages you should add this property to your plugins.

docs/docs/guides/developer-guide/migrating-from-v1/database-migration.md

@@ -7,11 +7,11 @@ sidebar_position: 2
 
 Vendure v2 introduces a number of breaking changes to the database schema, some of which require quite complex migrations in order to preserve existing data. To make this process as smooth as possible, we have created a migration tool which will handle the hard parts for you!
 
-{{< alert "warning" >}}
+:::warning
 **Important!** It is _critical_ that you back up your production data prior to attempting this migration.
 
 **Note for MySQL/MariaDB users:** transactions for migrations are [not supported by these databases](https://dev.mysql.com/doc/refman/5.7/en/cannot-roll-back.html). This means that if the migration fails for some reason, the statements that have executed will not get rolled back, and your DB schema can be left in an inconsistent state from which is it can be hard to recover. Therefore, it is doubly critical that you have a good backup that you can easily restore prior to attempting this migration.
-{{< /alert >}}
+:::
 
 1. Make sure all your Vendure packages to the latest v2 versions.
 2. Use your package manager to install the [v2 migration tool](https://github.com/vendure-ecommerce/v2-migration-tool): `npm install @vendure/migrate-v2`

docs/docs/guides/developer-guide/uploading-files/index.md

@@ -99,7 +99,7 @@ extend type Mutation {
 
 ### Resolver
 
-The resolver will make use of the built-in [AssetService]({{< relref "asset-service" >}}) to handle the processing of the uploaded file into an Asset.
+The resolver will make use of the built-in [AssetService](/reference/typescript-api/services/asset-service) to handle the processing of the uploaded file into an Asset.
 
 ```ts title="src/plugins/customer-avatar/api/customer-avatar.resolver.ts"
 import { Args, Mutation, Resolver } from '@nestjs/graphql';

docs/docs/guides/getting-started/graphql-intro/index.mdx

@@ -6,10 +6,12 @@ import Tabs from '@theme/Tabs';
 import TabItem from '@theme/TabItem';
 
 :::info
+
 Vendure uses [GraphQL](https://graphql.org/) as its API layer.
 
 This is an introduction to GraphQL for those who are new to it. If you are already familiar with GraphQL, you may choose
 to skip this section.
+
 :::
 
 ## What is GraphQL?

docs/docs/guides/storefront/order-workflow/index.md

@@ -5,29 +5,29 @@ showtoc: true
 
 # Order Workflow
 
-An Order is a collection of one or more ProductVariants which can be purchased by a Customer. Orders are represented internally by the [Order entity]({{< relref "order" >}}) and in the GraphQL API by the [Order type]({{< relref "/reference/graphql-api/shop/object-types#order" >}}).
+An Order is a collection of one or more ProductVariants which can be purchased by a Customer. Orders are represented internally by the [Order entity](/reference/typescript-api/entities/order/) and in the GraphQL API by the [Order type](/reference/graphql-api/admin/enums/#ordertype).
 
 ## Order State
 
-Every Order has a `state` property of type [`OrderState`]({{< relref "order-process" >}}#orderstate). The following diagram shows the default states and how an Order transitions from one to the next.
+Every Order has a `state` property of type [`OrderState`](/reference/typescript-api/orders/order-process/#orderstate). The following diagram shows the default states and how an Order transitions from one to the next.
 
-{{% alert %}}
-Note that this default workflow can be modified to better fit your business processes. See the [Customizing the Order Process guide]({{< relref "customizing-the-order-process" >}}).
-{{< /alert >}}
+:::note
+Note that this default workflow can be modified to better fit your business processes. See the [Customizing the Order Process guide](/guides/core-concepts/orders/#custom-order-processes).
+:::
 
 ![./order_state_diagram.png](./order_state_diagram.png)
 
 ## Structure of an Order
 
-In Vendure an [Order]({{< relref "order" >}}) consists of one or more [OrderLines]({{< relref "order-line" >}}) (representing a given quantity of a particular SKU).
+In Vendure an [Order](/reference/typescript-api/entities/order) consists of one or more [OrderLines](/reference/typescript-api/entities/order-line) (representing a given quantity of a particular SKU).
 
 Here is a simplified diagram illustrating this relationship:
 
 ![./order_class_diagram.png](./order_class_diagram.png)
 
 ## Shop client order workflow
 
-The [GraphQL Shop API Guide]({{< relref "/guides/storefront/shop-api-guide" >}}#order-flow) lists the GraphQL operations you will need to implement this workflow in your storefront client application.
+The [GraphQL Shop API Guide](/guides/storefront/active-order) lists the GraphQL operations you will need to implement this workflow in your storefront client application.
 
 In this section, we'll cover some examples of how these operations would look in your storefront.
 
@@ -228,4 +228,4 @@ query OrderByCode($code: String!) {
 
 In the above examples, the active Order is always associated with the current session and is therefore implicit - which is why there is no need to pass an ID to each of the above operations.
 
-Sometimes you _do_ want to be able to explicitly specify the Order you wish to operate on. In this case, you need to define a custom [ActiveOrderStrategy]({{< relref "active-order-strategy" >}}).
+Sometimes you _do_ want to be able to explicitly specify the Order you wish to operate on. In this case, you need to define a custom [ActiveOrderStrategy](/reference/typescript-api/orders/active-order-strategy).

docs/docs/reference/admin-ui-api/custom-table-components/register-data-table-component.md

@@ -14,7 +14,7 @@ import MemberDescription from '@site/src/components/MemberDescription';
 <GenerationInfo sourceFile="packages/admin-ui/src/lib/core/src/extension/register-data-table-component.ts" sourceLine="45" packageName="@vendure/admin-ui" />
 
 Allows you to override the default component used to render the data of a particular column in a DataTable.
-The component should implement the {@link CustomDataTableColumnComponent} interface. The tableId and columnId can
+The component should implement the <a href='/reference/admin-ui-api/custom-table-components/custom-column-component#customcolumncomponent'>CustomColumnComponent</a> interface. The tableId and columnId can
 be determined by pressing `ctrl + u` when running the Admin UI in dev mode.
 
 *Example*

docs/docs/reference/admin-ui-api/index.md

@@ -8,6 +8,6 @@ showtoc: false
 
 These APIs are used when building your own custom extensions to the Admin UI provided by the AdminUiPlugin.
 
-{{% alert %}}
+:::note
 All documentation in this section is auto-generated from the TypeScript & HTML source of the Vendure Admin UI package.
-{{< /alert >}}
+:::

docs/docs/reference/core-plugins/admin-ui-plugin/admin-ui-plugin-options.md

@@ -33,7 +33,7 @@ interface AdminUiPluginOptions {
 
 The route to the Admin UI.
 
-Note: If you are using the {@link compileUiExtensions} function to compile a custom version of the Admin UI, then
+Note: If you are using the `compileUiExtensions` function to compile a custom version of the Admin UI, then
 the route should match the `baseHref` option passed to that function. The default value of `baseHref` is `/admin/`,
 so it only needs to be changed if you set this `route` option to something other than `"admin"`.
 ### port

docs/docs/reference/core-plugins/job-queue-plugin/bull-mqjob-queue-strategy.md

@@ -30,15 +30,15 @@ class BullMQJobQueueStrategy implements InspectableJobQueueStrategy {
     stop(queueName: string, process: (job: Job<Data>) => Promise<any>) => Promise<void>;
 }
 ```
-* Implements: <code><a href='/reference/typescript-api/job-queue/inspectable-job-queue-strategy#inspectablejobqueuestrategy'>InspectableJobQueueStrategy</a></code>
+* Implements: <code>InspectableJobQueueStrategy</code>
 
 
 
 <div className="members-wrapper">
 
 ### init
 
-<MemberInfo kind="method" type={`(injector: <a href='/reference/typescript-api/common/injector#injector'>Injector</a>) => Promise&#60;void&#62;`}   />
+<MemberInfo kind="method" type={`(injector: Injector) => Promise&#60;void&#62;`}   />
 
 
 ### destroy
@@ -48,27 +48,27 @@ class BullMQJobQueueStrategy implements InspectableJobQueueStrategy {
 
 ### add
 
-<MemberInfo kind="method" type={`(job: <a href='/reference/typescript-api/job-queue/job#job'>Job</a>&#60;Data&#62;) => Promise&#60;<a href='/reference/typescript-api/job-queue/job#job'>Job</a>&#60;Data&#62;&#62;`}   />
+<MemberInfo kind="method" type={`(job: Job&#60;Data&#62;) => Promise&#60;Job&#60;Data&#62;&#62;`}   />
 
 
 ### cancelJob
 
-<MemberInfo kind="method" type={`(jobId: string) => Promise&#60;<a href='/reference/typescript-api/job-queue/job#job'>Job</a> | undefined&#62;`}   />
+<MemberInfo kind="method" type={`(jobId: string) => Promise&#60;Job | undefined&#62;`}   />
 
 
 ### findMany
 
-<MemberInfo kind="method" type={`(options?: JobListOptions) => Promise&#60;<a href='/reference/typescript-api/common/paginated-list#paginatedlist'>PaginatedList</a>&#60;<a href='/reference/typescript-api/job-queue/job#job'>Job</a>&#62;&#62;`}   />
+<MemberInfo kind="method" type={`(options?: JobListOptions) => Promise&#60;PaginatedList&#60;Job&#62;&#62;`}   />
 
 
 ### findManyById
 
-<MemberInfo kind="method" type={`(ids: <a href='/reference/typescript-api/common/id#id'>ID</a>[]) => Promise&#60;<a href='/reference/typescript-api/job-queue/job#job'>Job</a>[]&#62;`}   />
+<MemberInfo kind="method" type={`(ids: ID[]) => Promise&#60;Job[]&#62;`}   />
 
 
 ### findOne
 
-<MemberInfo kind="method" type={`(id: <a href='/reference/typescript-api/common/id#id'>ID</a>) => Promise&#60;<a href='/reference/typescript-api/job-queue/job#job'>Job</a> | undefined&#62;`}   />
+<MemberInfo kind="method" type={`(id: ID) => Promise&#60;Job | undefined&#62;`}   />
 
 
 ### removeSettledJobs
@@ -78,12 +78,12 @@ class BullMQJobQueueStrategy implements InspectableJobQueueStrategy {
 
 ### start
 
-<MemberInfo kind="method" type={`(queueName: string, process: (job: <a href='/reference/typescript-api/job-queue/job#job'>Job</a>&#60;Data&#62;) =&#62; Promise&#60;any&#62;) => Promise&#60;void&#62;`}   />
+<MemberInfo kind="method" type={`(queueName: string, process: (job: Job&#60;Data&#62;) =&#62; Promise&#60;any&#62;) => Promise&#60;void&#62;`}   />
 
 
 ### stop
 
-<MemberInfo kind="method" type={`(queueName: string, process: (job: <a href='/reference/typescript-api/job-queue/job#job'>Job</a>&#60;Data&#62;) =&#62; Promise&#60;any&#62;) => Promise&#60;void&#62;`}   />
+<MemberInfo kind="method" type={`(queueName: string, process: (job: Job&#60;Data&#62;) =&#62; Promise&#60;any&#62;) => Promise&#60;void&#62;`}   />
 
 
 

docs/docs/reference/core-plugins/job-queue-plugin/bull-mqplugin-options.md

@@ -51,7 +51,7 @@ Worker instance.
 See the [BullMQ WorkerOptions docs](https://github.com/taskforcesh/bullmq/blob/master/docs/gitbook/api/bullmq.workeroptions.md)
 ### setRetries
 
-<MemberInfo kind="property" type={`(queueName: string, job: <a href='/reference/typescript-api/job-queue/job#job'>Job</a>) =&#62; number`}  since="1.3.0"  />
+<MemberInfo kind="property" type={`(queueName: string, job: Job) =&#62; number`}  since="1.3.0"  />
 
 When a job is added to the JobQueue using `JobQueue.add()`, the calling
 code may specify the number of retries in case of failure. This option allows
@@ -73,7 +73,7 @@ setRetries: (queueName, job) => {
  ```
 ### setBackoff
 
-<MemberInfo kind="property" type={`(queueName: string, job: <a href='/reference/typescript-api/job-queue/job#job'>Job</a>) =&#62; <a href='/reference/core-plugins/job-queue-plugin/bull-mqplugin-options#backoffoptions'>BackoffOptions</a> | undefined`} default="'exponential', 1000"  since="1.3.0"  />
+<MemberInfo kind="property" type={`(queueName: string, job: Job) =&#62; <a href='/reference/core-plugins/job-queue-plugin/bull-mqplugin-options#backoffoptions'>BackoffOptions</a> | undefined`} default="'exponential', 1000"  since="1.3.0"  />
 
 This allows you to specify the backoff settings when a failed job gets retried.
 In other words, this determines how much time should pass before attempting to

docs/docs/reference/graphql-api/_index.md

@@ -10,7 +10,7 @@ This section contains a description of all queries, mutations and related types
 
 The API is split into two distinct endpoints: *Shop* and *Admin*. The Shop API is for storefront client applications, whereas the Admin API is used for administrative tasks.
 
-{{% alert %}}
+:::note
 All documentation in this section is auto-generated from the Vendure GraphQL schema.
-{{< /alert >}}
+:::
 

docs/docs/reference/graphql-api/admin/_index.md

@@ -8,6 +8,6 @@ showtoc: false
 
 The Admin API is primarily used by the included Admin UI web app to perform administrative tasks such as inventory management, order tracking etc.
 
-{{% alert %}}
+:::note
 Explore the interactive GraphQL Admin API at [demo.vendure.io/admin-api](https://demo.vendure.io/admin-api)
-{{< /alert >}}
+:::