diff --git a/14/umbraco-cms/customizing/extending-overview/extension-types/kind.md b/14/umbraco-cms/customizing/extending-overview/extension-types/kind.md
index 418f3fa03b8..b34b64c1fe7 100644
--- a/14/umbraco-cms/customizing/extending-overview/extension-types/kind.md
+++ b/14/umbraco-cms/customizing/extending-overview/extension-types/kind.md
@@ -8,8 +8,6 @@ description: A kind extension provides the preset for other extensions to use
 This page is a work in progress and may undergo further revisions, updates, or amendments. The information contained herein is subject to change without notice.
 {% endhint %}
 
-## Kind
-
 A kind is matched with a specific type. When another extension uses that type and kind it will inherit the preset manifest of the kind extension.
 
 The registration of Kinds is done in the same manner as the registration of other extensions. But the format of it is different. Let's take a look at an example of how to implement the `Kind registration` for a [**Header App**](../extension-types/header-apps.md) **Button Kind**.
@@ -18,7 +16,7 @@ The registration of Kinds is done in the same manner as the registration of othe
 
 The root properties of this object define the `Kind registration`. Then the manifest property holds the preset for the extension using this kind to be based upon. This object can hold the property values that make sense for the Kind.
 
-```ts
+```typescript
 ...
 
 const manifest: ManifestKind = {
@@ -36,7 +34,7 @@ const manifest: ManifestKind = {
 
 For the kind to be used, it needs to match up with the registration of the extension using it. This happens when the extension uses a type, which matches the value of `matchType` of the Kind. As well the extension has to utilize that kind, by setting the value of `kind` to the value of `matchKind` the Kind.
 
-```ts
+```typescript
 ...
 
 const manifest = {
@@ -52,7 +50,7 @@ const manifest = {
 
 In the following example, a kind is registered. This kind provides a default element for extensions utilizing this kind.
 
-```ts
+```typescript
 import { ManifestHeaderAppButtonKind, umbExtensionsRegistry } from '@umbraco-cms/backoffice/extension-registry';
 import { ManifestKind } from '@umbraco-cms/backoffice/extension-api';
 
@@ -73,7 +71,7 @@ This enables other extensions to use this kind and inherit the manifest properti
 
 In this example a **Header App** is registered without defining an element, this is possible because the registration inherits the elementName from the kind.
 
-```ts
+```typescript
 import { extensionRegistry } from '@umbraco-cms/extension-registry';
 
 const manifest = {
diff --git a/14/umbraco-commerce/key-concepts/ui-extensions/store-menu-items.md b/14/umbraco-commerce/key-concepts/ui-extensions/store-menu-items.md
index f64348495d7..02d7bf55fe7 100644
--- a/14/umbraco-commerce/key-concepts/ui-extensions/store-menu-items.md
+++ b/14/umbraco-commerce/key-concepts/ui-extensions/store-menu-items.md
@@ -31,11 +31,11 @@ export const manifests : UcManifestStoreMenuItem[] = [
 extensionRegistry.register(manifests);
 ```
 
-Each entry must have a type of `ucStoreMenuItem` along with a unique `alias` and `name`. 
+Each entry must have a type of `ucStoreMenuItem` along with a unique `alias` and `name`.
 
 A `meta` entry provides configuration options for the menu item
 
-| Name | Description |  
+| Name | Description |
 | -- | -- |
 | `label` | A label for this menu item (supports the `#` prefix localization string syntax) |
 | `icon` | An icon to display in the menu item |
@@ -53,9 +53,9 @@ section/{currentSection}/workspace/{rootEntityType}/{rootUnique}/{entityType}
 
 Here:
 
-- `{currentSection}` is the current section you are in, 
-- `{rootEntityType}` is the entity type of the menu this item is a child of (should be one of `uc:store-management` or `uc:store-settings`), 
-- `{rootUnique}` is the ID of the Store this menu is for, and 
+- `{currentSection}` is the current section you are in,
+- `{rootEntityType}` is the entity type of the menu this item is a child of (should be one of `uc:store-management` or `uc:store-settings`),
+- `{rootUnique}` is the ID of the Store this menu is for, and
 - `{entityType}` is the entity type as defined in the menu items manifest meta data.
 
 ## Handling Store Menu Item Requests
@@ -80,4 +80,4 @@ const manifests: ManifestWorkspace[] = [
 
 extensionRegistry.register(manifests);
 
-```
\ No newline at end of file
+```
diff --git a/15/umbraco-cms/customizing/development-flow/vite-package-setup.md b/15/umbraco-cms/customizing/development-flow/vite-package-setup.md
index 6d88193858a..fe067e8c629 100644
--- a/15/umbraco-cms/customizing/development-flow/vite-package-setup.md
+++ b/15/umbraco-cms/customizing/development-flow/vite-package-setup.md
@@ -70,7 +70,21 @@ Optionally you can use `--legacy-peer-deps` in the installation command to avoid
 If this is used the Intellisense to those external references will not be available.
 {% endhint %}
 
-7. Create a new file called `vite.config.ts` in the folder and insert the following code:
+7. Open the `tsconfig.json` file.
+8. Add the array `types` inside `compilerOptions`, with the entry of `@umbraco-cms/backoffice/extension-types`:
+
+```json
+{
+    "compilerOptions": {
+        ...
+        "types": [
+            "@umbraco-cms/backoffice/extension-types"
+        ]
+    }
+}
+```
+
+9. Create a new file called `vite.config.ts` in the folder and insert the following code:
 
 {% code title="vite.config.ts" lineNumbers="true" %}
 ```ts
diff --git a/15/umbraco-cms/customizing/extending-overview/extension-types/condition.md b/15/umbraco-cms/customizing/extending-overview/extension-types/condition.md
index 491e2a25ad6..df6ca44feec 100644
--- a/15/umbraco-cms/customizing/extending-overview/extension-types/condition.md
+++ b/15/umbraco-cms/customizing/extending-overview/extension-types/condition.md
@@ -20,7 +20,6 @@ You can make your own Conditions by creating a class that implements the `UmbExt
 
 ```typescript
 import {
-  ManifestCondition,
   UmbConditionConfigBase,
   UmbConditionControllerArguments,
   UmbExtensionCondition
@@ -28,8 +27,8 @@ import {
 import { UmbConditionBase } from '@umbraco-cms/backoffice/extension-registry';
 import { UmbControllerHost } from '@umbraco-cms/backoffice/controller-api';
 
-export type MyExtensionConditionConfig = UmbConditionConfigBase & {
-  match: string;
+export type MyExtensionConditionConfig = UmbConditionConfigBase<'My.Condition.CustomName'> & {
+  match?: string;
 };
 
 export class MyExtensionCondition extends UmbConditionBase<MyExtensionConditionConfig> implements UmbExtensionCondition {
@@ -47,15 +46,17 @@ export class MyExtensionCondition extends UmbConditionBase<MyExtensionConditionC
 // Declare the Condition Configuration Type in the global UmbExtensionConditionConfigMap interface:
 declare global {
     interface UmbExtensionConditionConfigMap {
-        MyExtensionConditionConfig: MyExtensionCondition;
+        MyExtensionConditionConfig: MyExtensionConditionConfig;
     }
 }
 ```
 
-This has to be registered in the extension registry, shown below:
+The global declaration on the last five lines makes your Condition appear valid for manifests using the type `UmbExtensionManifest`. Also, the Condition Config Type alias should match the alias given when registering the condition below.
+
+The Condition then needs to be registered in the Extension Registry:
 
 ```typescript
-export const manifest: ManifestCondition = {
+export const manifest: UmbExtensionManifest = {
  type: 'condition',
  name: 'My Condition',
  alias: 'My.Condition.CustomName',
@@ -63,10 +64,10 @@ export const manifest: ManifestCondition = {
 };
 ```
 
-Finally, you can make use of the condition in your configuration. See an example of this below:
+Finally, you can make use of your condition in any manifests:
 
 ```typescript
-{
+export const manifest: UmbExtensionManifest = {
  type: 'workspaceAction',
  name: 'example-workspace-action',
  alias: 'My.Example.WorkspaceAction',
@@ -83,7 +84,7 @@ Finally, you can make use of the condition in your configuration. See an example
 }
 ```
 
-As can be seen in the code above, we never make use of `match`. We can do this by replacing the timeout with some other check.
+As shown in the code above, the configuration property `match` isn't used for our condition. We can do this by replacing the timeout with some other check:
 
 ```typescript
 // ...
diff --git a/15/umbraco-cms/customizing/extending-overview/extension-types/header-apps.md b/15/umbraco-cms/customizing/extending-overview/extension-types/header-apps.md
index 1faa14da7f3..cffe04a2632 100644
--- a/15/umbraco-cms/customizing/extending-overview/extension-types/header-apps.md
+++ b/15/umbraco-cms/customizing/extending-overview/extension-types/header-apps.md
@@ -93,9 +93,9 @@ This is a continuation of the above steps from the **Button Header App with Mani
 
 {% code title="my-element.ts" lineNumbers="true" %}
 ```typescript
-import { ManifestHeaderAppButtonKind, umbExtensionsRegistry } from '@umbraco-cms/backoffice/extension-registry';
+import { umbExtensionsRegistry } from '@umbraco-cms/backoffice/extension-registry';
 
-const manifest: ManifestHeaderAppButtonKind = {
+const manifest: UmbExtensionManifest = {
   type: "headerApp",
   alias: "My.HeaderApp.Documentation",
   name: "My Header App Documentation",
diff --git a/15/umbraco-cms/customizing/extending-overview/extension-types/kind.md b/15/umbraco-cms/customizing/extending-overview/extension-types/kind.md
index 418f3fa03b8..014c1d26eb6 100644
--- a/15/umbraco-cms/customizing/extending-overview/extension-types/kind.md
+++ b/15/umbraco-cms/customizing/extending-overview/extension-types/kind.md
@@ -8,8 +8,6 @@ description: A kind extension provides the preset for other extensions to use
 This page is a work in progress and may undergo further revisions, updates, or amendments. The information contained herein is subject to change without notice.
 {% endhint %}
 
-## Kind
-
 A kind is matched with a specific type. When another extension uses that type and kind it will inherit the preset manifest of the kind extension.
 
 The registration of Kinds is done in the same manner as the registration of other extensions. But the format of it is different. Let's take a look at an example of how to implement the `Kind registration` for a [**Header App**](../extension-types/header-apps.md) **Button Kind**.
@@ -18,7 +16,7 @@ The registration of Kinds is done in the same manner as the registration of othe
 
 The root properties of this object define the `Kind registration`. Then the manifest property holds the preset for the extension using this kind to be based upon. This object can hold the property values that make sense for the Kind.
 
-```ts
+```typescript
 ...
 
 const manifest: ManifestKind = {
@@ -36,7 +34,7 @@ const manifest: ManifestKind = {
 
 For the kind to be used, it needs to match up with the registration of the extension using it. This happens when the extension uses a type, which matches the value of `matchType` of the Kind. As well the extension has to utilize that kind, by setting the value of `kind` to the value of `matchKind` the Kind.
 
-```ts
+```typescript
 ...
 
 const manifest = {
@@ -52,11 +50,10 @@ const manifest = {
 
 In the following example, a kind is registered. This kind provides a default element for extensions utilizing this kind.
 
-```ts
-import { ManifestHeaderAppButtonKind, umbExtensionsRegistry } from '@umbraco-cms/backoffice/extension-registry';
-import { ManifestKind } from '@umbraco-cms/backoffice/extension-api';
+```typescript
+import { umbExtensionsRegistry } from '@umbraco-cms/backoffice/extension-registry';
 
-const manifest: ManifestKind<ManifestHeaderAppButtonKind> = {
+const manifest: UmbExtensionManifest = {
   type: 'kind',
   alias: 'Umb.Kind.MyButtonKind',
   matchType: 'headerApp',
@@ -73,7 +70,7 @@ This enables other extensions to use this kind and inherit the manifest properti
 
 In this example a **Header App** is registered without defining an element, this is possible because the registration inherits the elementName from the kind.
 
-```ts
+```typescript
 import { extensionRegistry } from '@umbraco-cms/extension-registry';
 
 const manifest = {
diff --git a/15/umbraco-cms/customizing/extending-overview/extension-types/sections/section.md b/15/umbraco-cms/customizing/extending-overview/extension-types/sections/section.md
index 6d799c4e10b..ea01a688e02 100644
--- a/15/umbraco-cms/customizing/extending-overview/extension-types/sections/section.md
+++ b/15/umbraco-cms/customizing/extending-overview/extension-types/sections/section.md
@@ -61,7 +61,7 @@ This is not recommended as it limits the content of your section to this element
 If you like to have full control, you can define an element like this:
 
 ```typescript
-const section : ManifestSection = {
+const section : UmbExtensionManifest = {
     type: "section",
     alias: "Empty.Section",
     name : 'Empty Section',
diff --git a/15/umbraco-commerce/key-concepts/ui-extensions/store-menu-items.md b/15/umbraco-commerce/key-concepts/ui-extensions/store-menu-items.md
index f64348495d7..e3e8557a21b 100644
--- a/15/umbraco-commerce/key-concepts/ui-extensions/store-menu-items.md
+++ b/15/umbraco-commerce/key-concepts/ui-extensions/store-menu-items.md
@@ -63,9 +63,7 @@ Here:
 To handle requests to this endpoint, you should define a workspace manifest for the given entity type.
 
 ```typescript
-import { ManifestWorkspace } from '@umbraco-cms/backoffice/extension-registry';
-
-const manifests: ManifestWorkspace[] = [
+const manifests: UmbExtensionManifest[] = [
     {
         type: 'workspace',
         kind: 'routable',