docs: Update deployment docs

docs/docs/guides/deployment/deploying-admin-ui.md

@@ -3,9 +3,8 @@ title: "Deploying the Admin UI"
 showtoc: true
 ---
 
-## Deploying the Admin UI
 
-If you have customized the Admin UI with extensions, you should [compile your extensions ahead of time as part of the deployment process]({{< relref "/guides/plugins/extending-the-admin-ui" >}}#compiling-as-a-deployment-step).
+If you have customized the Admin UI with extensions, you should [compile your extensions ahead of time as part of the deployment process](/guides/extending-the-admin-ui/introduction#compiling-as-a-deployment-step).
 
 ### Deploying a stand-alone Admin UI
 
@@ -15,14 +14,14 @@ Usually, the Admin UI is served from the Vendure server via the AdminUiPlugin. H
 
 The AdminUiPlugin not only serves the Admin UI app, but also provides a `metricSummary` query which is used to display the order metrics on the dashboard. If you wish to deploy the Admin UI app stand-alone (not served by the AdminUiPlugin), but still want to display the metrics on the dashboard, you'll need to include the AdminUiPlugin in your server's plugins array, but do not call `init()`:
 
-```ts
-import { AdminUiPlugin } from '\@vendure/admin-ui-plugin';
+```ts title="src/vendure-config.ts"
+import { AdminUiPlugin } from '@vendure/admin-ui-plugin';
 
 const config: VendureConfig = {
-  plugins: [
-    AdminUiPlugin, // <== include the plugin, but don't call init()
-  ],
-  // ...
+    plugins: [
+        AdminUiPlugin, // <== include the plugin, but don't call init()
+    ],
+    // ...
 };
 ```
 
@@ -36,7 +35,7 @@ This example is for Vercel, and assumes:
 * A public (output) directory set to `build/dist`
 * A build command set to `npm run build` or `yarn build`
 * A package.json like this:
-    ```json
+    ```json title="package.json"
     {
       "name": "standalone-admin-ui",
       "version": "0.1.0",
@@ -52,46 +51,45 @@ This example is for Vercel, and assumes:
     }
     ```
 
-```ts
-// compile.ts
+```ts title="compile.ts"
 import { compileUiExtensions } from '@vendure/ui-devkit/compiler';
 import { DEFAULT_BASE_HREF } from '@vendure/ui-devkit/compiler/constants';
 import path from 'path';
 import { promises as fs } from 'fs';
 
 /**
- * Compiles the Admin UI. If the BASE_HREF is defined, use that. 
+ * Compiles the Admin UI. If the BASE_HREF is defined, use that.
  * Otherwise, go back to the default admin route.
  */
 compileUiExtensions({
-  outputPath: path.join(__dirname, 'build'),
-  baseHref: process.env.BASE_HREF ?? DEFAULT_BASE_HREF,
-  extensions: [
-      /* any UI extensions would go here, or leave empty */
-  ],
+    outputPath: path.join(__dirname, 'build'),
+    baseHref: process.env.BASE_HREF ?? DEFAULT_BASE_HREF,
+    extensions: [
+        /* any UI extensions would go here, or leave empty */
+    ],
 })
-  .compile?.()
-  .then(() => {
-    // If building for Vercel deployment, replace the config to make 
-    // api calls to api.example.com instead of localhost.
-    if (process.env.VERCEL) {
-      console.log('Overwriting the vendure-ui-config.json for Vercel deployment.');
-      return fs.writeFile(
-        path.join(__dirname, 'build', 'dist', 'vendure-ui-config.json'),
-        JSON.stringify({
-          apiHost: 'https://api.example.com',
-          apiPort: '443',
-          adminApiPath: 'admin-api',
-          tokenMethod: 'cookie',
-          defaultLanguage: 'en',
-          availableLanguages: ['en', 'de'],
-          hideVendureBranding: false,
-          hideVersion: false,
-        }),
-      );
-    }
-  })
-  .then(() => {
-    process.exit(0);
-  });
+    .compile?.()
+    .then(() => {
+        // If building for Vercel deployment, replace the config to make 
+        // api calls to api.example.com instead of localhost.
+        if (process.env.VERCEL) {
+            console.log('Overwriting the vendure-ui-config.json for Vercel deployment.');
+            return fs.writeFile(
+                path.join(__dirname, 'build', 'dist', 'vendure-ui-config.json'),
+                JSON.stringify({
+                    apiHost: 'https://api.example.com',
+                    apiPort: '443',
+                    adminApiPath: 'admin-api',
+                    tokenMethod: 'cookie',
+                    defaultLanguage: 'en',
+                    availableLanguages: ['en', 'de'],
+                    hideVendureBranding: false,
+                    hideVersion: false,
+                }),
+            );
+        }
+    })
+    .then(() => {
+        process.exit(0);
+    });
 ```

docs/docs/guides/deployment/getting-data-into-production.md

@@ -20,19 +20,22 @@ The main tasks will be:
 The first item - creation of the schema - can be automatically handled by TypeORM's `synchronize` feature. Switching it on for the initial
 run will automatically create the schema. This can be done by using an environment variable:
 
-```ts {hl_lines=[5]}
+```ts title="src/vendure-config.ts"
+import { VendureConfig } from '@vendure/core';
+
 export const config: VendureConfig = {
-  // ...
-  dbConnectionOptions: {
-    type: 'postgres',
-    synchronize: process.env.DB_SYNCHRONIZE,
-    host: process.env.DB_HOST,
-    port: process.env.DB_PORT,
-    username: process.env.DB_USER,
-    password: process.env.DB_PASSWORD,
-    database: process.env.DB_DATABASE,
-  },
-  // ...
+    // ...
+    dbConnectionOptions: {
+        type: 'postgres',
+        // highlight-next-line
+        synchronize: process.env.DB_SYNCHRONIZE,
+        host: process.env.DB_HOST,
+        port: process.env.DB_PORT,
+        username: process.env.DB_USER,
+        password: process.env.DB_PASSWORD,
+        database: process.env.DB_DATABASE,
+    },
+    // ...
 };
 ```
 
@@ -40,8 +43,8 @@ Set the `DB_SYNCHRONIZE` variable to `true` on first start, and then after the s
 
 ## Importing initial & catalog data
 
-Importing initial and catalog data can be handled by Vendure `populate()` helper function - see the [Importing Product Data guide]({{< relref "importing-product-data" >}}).
+Importing initial and catalog data can be handled by Vendure `populate()` helper function - see the [Importing Product Data guide](/guides/how-to/importing-data/).
 
 ## Importing other data
 
-Any kinds of data not covered by the `populate()` function can be imported using a custom script, which can use any Vendure service or service defined by your custom plugins to populate data in any way you like. See the [Stand-alone scripts guide]({{< relref "stand-alone-scripts" >}}).
+Any kinds of data not covered by the `populate()` function can be imported using a custom script, which can use any Vendure service or service defined by your custom plugins to populate data in any way you like. See the [Stand-alone scripts guide](/guides/advanced-topics/stand-alone-scripts).

docs/docs/guides/deployment/horizontal-scaling.md

@@ -13,7 +13,7 @@ This type of scaling has two main advantages:
 1. It can enable increased throughput (requests/second) by distributing the incoming requests between multiple instances.
 2. It can increase resilience because if a single instance fails, the other instances will still be able to service requests.
 
-As discussed in the [Server resource requirements guide]({{< relref "server-resource-requirements" >}}), horizontal scaling can be the most cost-effective way of deploying your Vendure server due to the single-threaded nature of Node.js.
+As discussed in the [Server resource requirements guide](/guides/deployment/server-resource-requirements), horizontal scaling can be the most cost-effective way of deploying your Vendure server due to the single-threaded nature of Node.js.
 
 In Vendure, both the server and the worker can be scaled horizontally. Scaling the server will increase the throughput of the GraphQL APIs, whereas scaling the worker can increase the speed with which the job queue is processed by allowing more jobs to be run in parallel.
 
@@ -21,10 +21,10 @@ In Vendure, both the server and the worker can be scaled horizontally. Scaling t
 
 In order to run Vendure in a multi-instance configuration, there are some important configuration changes you'll need to make. The key consideration in configuring Vendure for this scenario is to ensure that any persistent state is managed externally from the Node process, and is shared by all instances. Namely:
 
-* The JobQueue should be stored externally using the [DefaultJobQueuePlugin]({{< relref "default-job-queue-plugin" >}}) (which stores jobs in the database) or the [BullMQJobQueuePlugin]({{< relref "bull-mqjob-queue-plugin" >}}) (which stores jobs in Redis), or some other custom JobQueueStrategy. **Note:** the BullMQJobQueuePlugin is much more efficient than the DefaultJobQueuePlugin, and is recommended for production applications.
-* A custom [SessionCacheStrategy]({{< relref "session-cache-strategy" >}}) must be used which stores the session cache externally (such as in the database or Redis), since the default strategy stores the cache in-memory and will cause inconsistencies in multi-instance setups. [Example Redis-based SessionCacheStrategy]({{< relref "session-cache-strategy" >}})
+* The JobQueue should be stored externally using the [DefaultJobQueuePlugin](/reference/typescript-api/job-queue/default-job-queue-plugin/) (which stores jobs in the database) or the [BullMQJobQueuePlugin](/reference/core-plugins/job-queue-plugin/bull-mqjob-queue-plugin) (which stores jobs in Redis), or some other custom JobQueueStrategy. **Note:** the BullMQJobQueuePlugin is much more efficient than the DefaultJobQueuePlugin, and is recommended for production applications.
+* A custom [SessionCacheStrategy](/reference/typescript-api/auth/session-cache-strategy/) must be used which stores the session cache externally (such as in the database or Redis), since the default strategy stores the cache in-memory and will cause inconsistencies in multi-instance setups. [Example Redis-based SessionCacheStrategy](/reference/typescript-api/auth/session-cache-strategy/)
 * When using cookies to manage sessions, make sure all instances are using the _same_ cookie secret:
-    ```ts
+    ```ts title="src/vendure-config.ts"
     const config: VendureConfig = {
       authOptions: {
         cookieOptions: {
@@ -33,7 +33,7 @@ In order to run Vendure in a multi-instance configuration, there are some import
       }
     }
     ```
-* Channel and Zone data gets cached in-memory as this data is used in virtually every request. The cache time-to-live defaults to 30 seconds, which is probably fine for most cases, but it can be configured in the [EntityOptions]({{< relref "entity-options" >}}#channelcachettl).
+* Channel and Zone data gets cached in-memory as this data is used in virtually every request. The cache time-to-live defaults to 30 seconds, which is probably fine for most cases, but it can be configured in the [EntityOptions](/reference/typescript-api/configuration/entity-options/#channelcachettl).
 
 ## Using Docker or Kubernetes
 
@@ -42,7 +42,7 @@ One way of implementing horizontal scaling is to use Docker to wrap your Vendure
 Some hosting providers allow you to provide a Docker image and will then run multiple instances of that image. Kubernetes can also be used to manage multiple instances
 of a Docker image.
 
-For a more complete guide, see the [Using Docker guide]({{< relref "using-docker" >}}).
+For a more complete guide, see the [Using Docker guide](/guides/deployment/using-docker).
 
 ## Using PM2
 
@@ -64,7 +64,7 @@ The above command will start a cluster of 4 instances. You can also instruct PM2
 
 Note that if you are using pm2 inside a Docker container, you should use the `pm2-runtime` command:
 
-```Dockerfile
+```dockerfile
 # ... your existing Dockerfile config
 RUN npm install pm2 -g
 

docs/docs/guides/deployment/production-configuration/index.md

@@ -45,7 +45,7 @@ export const config: VendureConfig = {
 
 ## API hardening
 
-It is recommended that you install and configure the [HardenPlugin]({{< relref "/reference/core-plugins/harden-plugin" >}}) for all production deployments. This plugin locks down your schema (disabling introspection and field suggestions) and protects your Shop API against malicious queries that could otherwise overwhelm your server.
+It is recommended that you install and configure the [HardenPlugin](/reference/core-plugins/harden-plugin/) for all production deployments. This plugin locks down your schema (disabling introspection and field suggestions) and protects your Shop API against malicious queries that could otherwise overwhelm your server.
 
 Install the plugin: 
 
@@ -77,9 +77,9 @@ export const config: VendureConfig = {
 };
 ```
 
-{{< alert primary >}}
-For a detailed explanation of how to best configure this plugin, see the [HardenPlugin docs]({{< relref "/reference/core-plugins/harden-plugin" >}}).
-{{< /alert >}}
+:::info
+For a detailed explanation of how to best configure this plugin, see the [HardenPlugin docs](/reference/core-plugins/harden-plugin/).
+:::
 
 ## ID Strategy
 
@@ -87,18 +87,18 @@ By default, Vendure uses auto-increment integer IDs as entity primary keys. Whil
 
 For this reason you should consider using the UuidIdStrategy for production.
 
-```ts
+```ts title="src/vendure-config.ts"
 import { UuidIdStrategy, VendureConfig } from '@vendure/core';
-  
+
 export const config: VendureConfig = {
-  entityOptions: {
+    entityOptions: {
         entityIdStrategy: new UuidIdStrategy(),
-  },
-  // ...
+    },
+    // ...
 }
 ```
 
-Another option, if you wish to stick with integer IDs, is to create a custom [EntityIdStrategy]({{< relref "entity-id-strategy" >}}) which uses the `encodeId()` and `decodeId()` methods to obfuscate the sequential nature of the ID.
+Another option, if you wish to stick with integer IDs, is to create a custom [EntityIdStrategy](/reference/typescript-api/configuration/entity-id-strategy/) which uses the `encodeId()` and `decodeId()` methods to obfuscate the sequential nature of the ID.
 
 ## Database Timezone
 

docs/docs/guides/deployment/server-resource-requirements.md

@@ -18,7 +18,7 @@ CPU resources are generally measured in "cores" or "vCPUs" (virtual CPUs) depend
 
 Because Node.js is single-threaded, a single instance of the Vendure server or worker will not be able to take advantage of multiple CPUs. For example, if you set up a server instance running with 4 CPUs, the server will only use 1 of those CPUs and the other 3 will be wasted.
 
-Therefore, when looking to optimize performance (for example, the number of requests that can be serviced per second), it makes sense to scale horizontally by running multiple instances of the Vendure server. See the [Horizontal Scaling guide]({{< relref "horizontal-scaling" >}}).
+Therefore, when looking to optimize performance (for example, the number of requests that can be serviced per second), it makes sense to scale horizontally by running multiple instances of the Vendure server. See the [Horizontal Scaling guide](/guides/deployment/horizontal-scaling).
 
 ## Load testing
 

docs/docs/guides/deployment/using-docker.md

@@ -9,13 +9,13 @@ weight: 3
 [Docker](https://docs.docker.com/) is a technology which allows you to run your Vendure application inside a [container](https://docs.docker.com/get-started/#what-is-a-container).
 The default installation with `@vendure/create` includes a sample Dockerfile:
 
-```Dockerfile
+```dockerfile title="Dockerfile"
 FROM node:16
 
 WORKDIR /usr/src/app
 
 COPY package.json ./
-COPY package-lock.json ./
+COPY package-lock.json ./ 
 RUN npm install --production
 COPY . .
 RUN npm run build
@@ -166,7 +166,7 @@ REQUEST: GET http://localhost:3000/health
 }
 ```
 
-Health checks are built on the [Nestjs Terminus module](https://docs.nestjs.com/recipes/terminus). You can also add your own health checks by creating plugins that make use of the [HealthCheckRegistryService]({{< relref "health-check-registry-service" >}}).
+Health checks are built on the [Nestjs Terminus module](https://docs.nestjs.com/recipes/terminus). You can also add your own health checks by creating plugins that make use of the [HealthCheckRegistryService](/reference/typescript-api/health-check/health-check-registry-service/).
 
 ### Worker
 
@@ -174,11 +174,11 @@ Although the worker is not designed as an HTTP server, it contains a minimal HTT
 
 ```ts
 bootstrapWorker(config)
-  .then(worker => worker.startJobQueue())
-  .then(worker => worker.startHealthCheckServer({ port: 3020 }))
-  .catch(err => {
-    console.log(err);
-  });
+    .then(worker => worker.startJobQueue())
+    .then(worker => worker.startHealthCheckServer({ port: 3020 }))
+    .catch(err => {
+        console.log(err);
+    });
 ```
 This will make the `/health` endpoint available. When the worker instance is running, it will return the following:
 

docs/docusaurus.config.js

@@ -121,6 +121,7 @@ const config = {
             prism: {
                 theme: lightCodeTheme,
                 darkTheme: darkCodeTheme,
+                additionalLanguages: ['docker', 'bash'],
             },
             typesense: {
                 // Replace this with the name of your index/collection.