@asyncapi/generator 2.7.0 → 2.8.0

package/CHANGELOG.md

@@ -1,5 +1,48 @@
 # @asyncapi/generator
 
+## 2.8.0
+
+### Minor Changes
+
+- 6550745: This release introduces the concept of [`Baked-in Templates`](https://www.asyncapi.com/docs/tools/generator/baked-in-templates).
+
+  List of currently available baked-in templates is located in [BakedInTemplatesList.json](https://github.com/asyncapi/generator/blob/master/apps/generator/lib/templates/BakedInTemplatesList.json) file that is dynamically regenerated on each release.
+
+  ### 🚀 New Experimental Feature: **Baked-in Templates**
+
+  Baked-in Templates are **official AsyncAPI templates that are developed, versioned, and shipped directly inside the `generator` repository**, and are exposed via the `@asyncapi/generator` library. This approach provides a faster, more consistent, and opinionated way to generate code, SDKs, clients, and more—without relying on external packages.
+
+  All baked-in templates live under the `packages/templates` directory, follow a strict folder structure for maintainability, and are automatically registered in the generator during build time.
+
+  ### ⚠️ Important Notes
+
+  - **Experimental**: Baked-in templates are **not recommended for production use yet**. The number of available templates is currently limited, and we’re actively refining the concept.
+  - **We need your feedback**: Try them out with your AsyncAPI documents and share your use cases to help us improve them.
+  - **No changes to existing templates**: Your current workflow with external templates remains fully supported and works exactly the same as before. Nothing breaks, nothing changes.
+
+  ### Benefits
+
+  - Such templates are versioned together with the generator → no mismatches.
+  - Faster template discovery and generation process.
+  - Clear naming conventions and metadata, making templates easier to maintain and extend.
+
+  ### What’s Next
+
+  - We’ll be gradually expanding template coverage (e.g., docs, configs, SDKs) and stabilizing this feature based on community input before recommending production use.
+
+  - Dedicated support for such templates will be enabled in AsyncAPI CLI. [The PR](https://github.com/asyncapi/cli/pull/1830) is already opened.
+
+## 2.7.1
+
+### Patch Changes
+
+- a51f90e: Release of `generator-react-sdk` as part of the `generator` monorepo.
+
+  With this release the code from https://github.com/asyncapi/generator-react-sdk is considered to be an archive, and all future development will take place in this repository under `/apps/react-sdk`.
+
+- Updated dependencies [a51f90e]
+  - @asyncapi/generator-react-sdk@1.1.3
+
 ## 2.7.0
 
 ### Minor Changes

package/docs/api.md

@@ -4,6 +4,22 @@ weight: 75
 ---
 
 Reference API documentation for AsyncAPI Generator library.
+## Classes
+
+<dl>
+<dt><a href="#Generator">Generator</a></dt>
+<dd></dd>
+</dl>
+
+## Members
+
+<dl>
+<dt><a href="#listBakedInTemplates">listBakedInTemplates</a> ⇒ <code>Array.&lt;Object&gt;</code></dt>
+<dd><p>List core templates, optionally filter by type, stack, protocol, or target.
+Use name of returned templates as input for the <code>generate</code> method for template generation. Such core templates code is part of the @asyncapi/generator package.</p>
+</dd>
+</dl>
+
 
 <a name="Generator"></a>
 
@@ -494,3 +510,20 @@ const content = await Generator.getTemplateFile('@asyncapi/html-template', 'part
 const Generator = require('@asyncapi/generator');
 const content = await Generator.getTemplateFile('@asyncapi/html-template', 'partials/content.html', '~/my-templates');
 ```
+
+<a name="listBakedInTemplates"></a>
+
+## listBakedInTemplates
+List core templates, optionally filter by type, stack, protocol, or target.
+Use name of returned templates as input for the `generate` method for template generation. Such core templates code is part of the @asyncapi/generator package.
+
+**Kind**: global variable  
+**Returns**: `Array.<Object>` - Array of template objects matching the filter.  
+**Params**
+
+- [filter] `Object` - Optional filter object.
+    - [.type] `string` - Filter by template type (e.g., 'client', 'docs').
+    - [.stack] `string` - Filter by stack (e.g., 'quarkus', 'express').
+    - [.protocol] `string` - Filter by protocol (e.g., 'websocket', 'http').
+    - [.target] `string` - Filter by target language or format (e.g., 'javascript', 'html').
+

package/docs/baked-in-templates.md

@@ -0,0 +1,100 @@
+---
+title: "Baked-in Templates"
+weight: 55
+---
+
+> This is a new concept introduced in generator version 2.8. The number of templates is limited and solution is still in experimental phase. It is not recommended to use them in production. Instead join us to help to improve them with your use cases and your AsyncAPI documents.
+
+Baked-in templates are official AsyncAPI templates that are **developed, versioned, and shipped directly inside the `generator` repository and exposed with `@asyncapi/generator` library**.
+
+AsyncAPI Generator supports a variety of baked-in template types for generating code, documentation, configs, and SDKs. All templates are managed under the `packages/templates` directory and follow a strict, opinionated directory structure for consistency and ease of maintenance.
+
+> List of baked-in templates: https://github.com/asyncapi/generator/blob/master/apps/generator/lib/templates/BakedInTemplatesList.json
+
+## Supported template types
+
+Templates are grouped by **type**, which must be one of the following:
+
+- `docs` (not yet implemented): Templates that generate documentation
+- `client`: Templates that generate clients
+- `sdk` (not yet implemented): Template that generate full sdk's
+- `config` (not yet implemented): Template that generate configuration files
+
+> **Note:**  
+> The **directory name is always plural** (e.g., `clients`), but the **type recorded in metadata and package name is singular** (e.g., `client`), except for `docs`.
+
+## Template directory structure
+
+### General structure
+
+All template directories must follow this convention:
+```
+packages/templates/{type}/[protocol]/[target]/[stack]
+```
+
+- `type`: One of `docs`, `clients`, `sdks`, or `configs`.
+- `protocol`: (Only for `clients` and `sdks`) The protocol this template supports, e.g. `websocket`, `http`, `kafka`.
+- `target`: The output language, markup, or format, e.g. `javascript`, `python`, `html`, `yaml`.
+- `stack`: (Optional, for `clients` and `sdks`) Used for technology stack, e.g. `express`, `quarkus`.
+
+#### Type-specific rules
+
+- **docs/configs**:  
+  Path must be `type/target` (e.g., `docs/html` or `configs/yaml`).
+- **clients/sdks**:  
+  Path must be `type/protocol/target` or `type/protocol/target/stack` (e.g., `clients/websocket/javascript`, `sdks/kafka/java/spring`).
+
+### Required files
+
+Every template directory **must include**:
+- `.ageneratorrc`: Generator specific configuration, like for example parameters
+- `package.json`: It contains template name. Version information should not be provided as it is versioned together with the generator.
+
+## Metadata and naming conventions
+
+Generator build runs a script that normalize metadata for baked-in templates and their naming:
+- Adds/updates metadata in `.ageneratorrc` file. You do not have to maintain it manually.
+- Validates/updates template name in `package.json` file of given template. The name always starts with `core-template-` prefix.
+- Generates JSON file with list of baked in templates and stores the list inside the generator: `apps/generator/lib/templates/BakedInTemplatesList.json`
+
+#### Example
+
+Example information provided for template stored under `packages/templates/clients/websocket/javascript/express`
+
+```yaml
+# .ageneratorrc
+metadata:
+  type: client
+  protocol: websocket
+  target: javascript
+  stack: express
+```
+
+Package name format:  `core-template-client-websocket-javascript-express`
+
+Resulting entry in `apps/generator/lib/templates/BakedInTemplatesList.json`:
+```json
+  {
+    "name": "core-template-client-websocket-javascript-express",
+    "type": "client",
+    "protocol": "websocket",
+    "target": "javascript",
+    "stack": "express"
+  }
+```
+
+## How to add a new baked-in template
+
+1. Create the directory in `packages/templates` using the correct structure.
+   - For a docs template:  
+     `packages/templates/docs/html`
+   - For a clients template:  
+     `packages/templates/clients/websocket/rust`
+1. Add required files:  
+   - `.ageneratorrc` (do not add `generator` config key as it is not needed)
+   - `package.json`
+1. Run generator's build command: `npm run build`
+
+## Templates exposed through generator
+
+Templates that are exposed as part of the generator are transpiled with the `react-sdk` and located in published library under `/lib/templates/bakedInTemplates`. This means that in case of baked-in templates, they are not picked by the generator from `node_modules`. This way the process of generation is faster and more efficient.

package/docs/configuration-file.md

@@ -5,14 +5,22 @@ weight: 90
 
 You can configure your AsyncAPI Generator template using either a dedicated `.ageneratorrc` YAML file or through the `generator` property in your `package.json` file. Previously, generator configuration had to be defined in the `package.json` file. Now, you can define the configuration in a separate `.ageneratorrc` file. The configuration defined in the `.ageneratorrc` file will override any configuration defined in `package.json`. The generator will first check for the `.ageneratorrc` file in the template's root directory, and if not found, it will look for the generator config in `package.json`.
 
+> **Note:** The `metadata` object is **required** for all baked-in templates (templates developed and shipped as part of the Generator repository) and is used by the generator’s build system to index, categorize, and load these templates.  
+> The `metadata` section is **not used or required** for standalone templates (external npm packages or repositories).
 
-## Configuration Methods
+## Configuration methods
 
-### Option 1: Using `.ageneratorrc` file (Recommended)
+### Option 1: using `.ageneratorrc` file (Recommended)
 
 Create a `.ageneratorrc` file in the root of your template with YAML syntax. This approach keeps your template configuration separate from package metadata:
 
 ```yaml
+metadata:
+  type: client
+  protocol: websocket
+  target: javascript
+  stack: express
+
 renderer: react
 apiVersion: v3
 supportedProtocols:
@@ -64,15 +72,20 @@ hooks:
   my-custom-hooks-package:
     - myHook
     - andAnotherOne
-
 ```
 
-### Option 2: Using `package.json`
+### Option 2: using `package.json`
 
 Alternatively, you can include your configuration in the `generator` property of your `package.json` file:
 
 ```json
 "generator": {
+  "metadata": {
+    "type": "client",
+    "protocol": "websocket",
+    "target": "javascript",
+    "stack": "express"
+  },
   "renderer": "react",
   "apiVersion": "v3",
   "supportedProtocols": ["amqp", "mqtt"],
@@ -105,7 +118,7 @@ Alternatively, you can include your configuration in the `generator` property of
        "validation": {
             "const": "API Support"
         }
-    },
+    }
   },
   "nonRenderableFiles": [
     "src/api/middlewares/*.*",
@@ -124,37 +137,42 @@ Alternatively, you can include your configuration in the `generator` property of
 
 > **Note:** If both `.ageneratorrc` file and the `generator` property in `package.json` exist, the configuration from `.ageneratorrc` will override the `package.json` configuration.
 
-The `generator` property from `package.json` file and must contain a JSON object and the `ageneratorrc` file must contain a YAML object that may have the following information:
-
-
-|Name|Type|Description|
-|---|---|---|
-|`renderer`| String | Its value can be either `react` or `nunjucks` (default).
-|`apiVersion`| String | Determines which **major** version of the [Parser-API](https://github.com/asyncapi/parser-api) the template uses. For example, `v2` for `v2.x.x`. If not specified, the Generator assumes the template is not compatible with the Parser-API so it will use the [Parser-JS v1 API](https://github.com/asyncapi/parser-js/tree/v1.18.1#api-documentation). For templates that need to support AsyncAPI specification v3 make sure to use `v3` [Parser-API](https://github.com/asyncapi/parser-api). If the template uses a version of the Parser-API that is not supported by the Generator, the Generator will throw an error.
-|`supportedProtocols`| [String] | A list with all the protocols this template supports.
-|`parameters`| Object[String, Object] | An object with all the parameters that can be passed when generating the template. When using the command line, it's done by indicating `--param name=value` or `-p name=value`.
-|`parameters[param].description`| String | A user-friendly description about the parameter.
-|`parameters[param].default`| Any | Default value of the parameter if not specified. Shouldn't be used for mandatory `required=true` parameters.
-|`parameters[param].required`| Boolean | Whether the parameter is required or not.
+## Configuration options reference
+
+The following table describes all available configuration options for templates.
+
+The `generator` property from `package.json` file must contain a JSON object and the `ageneratorrc` file must contain a YAML object that may have the following information:
+
+| Name | Type | Description |
+|------|------|-------------|
+| `metadata` | Object | **(Required for baked-in templates)**. Template identification and classification. Contains `type`, `protocol`, `target`, and optional `stack`. See below. |
+| `metadata.type` | String | **Required**. The type of template. Allowed values: `client`, `sdk`, `docs`, `config`. |
+| `metadata.protocol` | String | **Required for `client`/`sdk`**. The protocol this template targets (e.g., `websocket`, `kafka`). Not used for `docs`/`config`. |
+| `metadata.target` | String | **Required**. The output language or format (e.g., `javascript`, `html`, `yaml`). |
+| `metadata.stack` | String | Optional. The stack or framework (e.g., `express`, `quarkus`). Only for `client`/`sdk`. |
+| `renderer` | String | Its value can be either `react` or `nunjucks` (default). |
+| `apiVersion` | String | Determines which **major** version of the [Parser-API](https://github.com/asyncapi/parser-api) the template uses. For example, `v2` for `v2.x.x`. If not specified, the Generator assumes the template is not compatible with the Parser-API so it will use the [Parser-JS v1 API](https://github.com/asyncapi/parser-js/tree/v1.18.1#api-documentation). For templates that need to support AsyncAPI specification v3 make sure to use `v3` [Parser-API](https://github.com/asyncapi/parser-api). If the template uses a version of the Parser-API that is not supported by the Generator, the Generator will throw an error. |
+| `supportedProtocols` | [String] | A list with all the protocols this template supports. |
+| `parameters` | Object[String, Object] | An object with all the parameters that can be passed when generating the template. When using the command line, it's done by indicating `--param name=value` or `-p name=value`. |
+| `parameters[param].description` | String | A user-friendly description about the parameter. |
+| `parameters[param].default` | Any | Default value of the parameter if not specified. Shouldn't be used for mandatory `required=true` parameters. |
+| `parameters[param].required` | Boolean | Whether the parameter is required or not. |
 | `conditionalFiles` | Object[String, Object] | An object containing all the file paths that should be conditionally rendered. Each key represents a file path and each value must be an object with the keys `subject` and `validation`. The file path should be relative to the `template` directory inside the template. **Note: It is deprecated and will be removed with future releases. Use `conditionalGeneration` instead.** |
 | `conditionalFiles[filePath].subject` | String | The `subject` is a [JMESPath](http://jmespath.org/) query to grab the value you want to apply the condition to. It queries an object with the whole AsyncAPI document and, when specified, the given server. The object looks like this: `{ asyncapi: { ... }, server: { ... } }`. If the template supports the `server` parameter, you can access server details, for example, `server.protocol`. During validation with `conditionalFiles`, only the server that the template user selected is available in the specification file. For more information about `server` parameter [read about special parameters](#special-parameters). **Note: It is deprecated and will be removed with future releases. Use `conditionalGeneration` instead.** |
 | `conditionalFiles[filePath].validation` | Object | The `validation` is a JSON Schema Draft 07 object. This JSON Schema definition will be applied to the JSON value resulting from the `subject` query. If validation doesn't have errors, the condition is met, and therefore the given file will be rendered. Otherwise, the file is ignored. Check [JSON Schema Validation](https://json-schema.org/draft-07/json-schema-validation.html#rfc.section.6) for a list of all possible validation keywords. **Note: It is deprecated and will be removed with future releases. Use `conditionalGeneration` instead.** |
-|`conditionalGeneration` | Object[String, { subject?: String, parameter?: String, validation: Object }] | An object containing all the file paths or directory names that should be conditionally rendered. Each key represents a file path or directory name and each value must be an object with the keys `subject`, `parameter` and `validation`. You can use either subject or parameter according to the use case. The path should be relative to the `template` directory inside the template. **Note: conditionalGeneration and conditionalFile are mutually exclusive, which means both cannot be configured at the same time in the template**. |
-|`conditionalGeneration[filePath/directoryName].subject`| String | The `subject` is a [JMESPath](http://jmespath.org/) query to grab the value you want to apply the condition to. It queries an object with the whole AsyncAPI document and, when specified, the given server. The object looks like this: `{ asyncapi: { ... }, server: { ... } }`. If the template supports the `server` parameter, you can access server details like, for example, protocol this way: `server.protocol`. During validation with `conditionalGeneration`, only the server that the template user selected is available in the specification file. For more information about the `server` parameter [read about special parameters](#special-parameters). |
-|`conditionalGeneration[filePath/directoryName].parameter`| String | The `parameter` is the name of a custom template parameter passed through `templateParams` that controls whether a specific file or folder should be included in the generated output. You must define a `validation` rule using a JSON Schema fragment to apply the condition. For example, if you define `"parameter": "includeDocs"` with `"validation": { "const": true }`, the corresponding folder (e.g., `docs/`) will only be generated when the user passes `{ includeDocs: true }`. If `includeDocs` is `false`, it will be skipped. |
-|`conditionalGeneration[filePath/directoryName].validation`| Object (JSON Schema fragment) | The validation defines the condition under which the file or directory will be generated. It must be a valid JSON Schema fragment that validates the value of the parameter. For example, if you want to include a folder only when includeDocs is true, use "validation": { "const": true }. You can also use more complex validation logic, like "enum": ["yes", "true"] or "type": "string" with a "pattern" constraint. If the parameter fails validation, the file or folder will not be included in the generated output. This allows for powerful and flexible control over template generation based on user input. |
-|`nonRenderableFiles`| [String] | A list of file paths or [globs](https://en.wikipedia.org/wiki/Glob_(programming)) that must be copied "as-is" to the target directory, i.e., without performing any rendering process. This is useful when you want to copy binary files.
-|`generator`| [String] | A string representing the generator version-range the template is compatible with. This value must follow the [semver](https://nodejs.dev/learn/semantic-versioning-using-npm) syntax. E.g., `>=1.0.0`, `>=1.0.0 <=2.0.0`, `~1.0.0`, `^1.0.0`, `1.0.0`, etc. [Read more about semver](https://docs.npmjs.com/about-semantic-versioning).
-|`filters`| [String] | A list of modules containing functions that can be used as Nunjucks filters. In case of external modules, remember they need to be added as a dependency in `package.json` of your template.
-|`hooks`| Object[String, String] or Object[String, Array[String]] | A list of modules containing hooks, except for the ones you keep locally in your template in the default location. For each module you must specify the exact name of the hook that should be used in the template. For a single hook, you can specify it as a string; for more hooks, you must pass an array of strings. In the case of external modules, remember they need to be added as a dependency in `package.json` of your template. There is also [an official hooks library](hooks#official-library) always included in the generator. As this is a library of multiple hooks, you still need to explicitly specify in the configuration which one you want to use. Use `@asyncapi/generator-hooks` as the library name.
-
----
+| `conditionalGeneration` | Object[String, `{ subject?: String, parameter?: String, validation: Object }`] | An object containing all the file paths or directory names that should be conditionally rendered. Each key represents a file path or directory name and each value must be an object with the keys `subject`, `parameter` and `validation`. You can use either subject or parameter according to the use case. The path should be relative to the `template` directory inside the template. **Note: conditionalGeneration and conditionalFile are mutually exclusive, which means both cannot be configured at the same time in the template**. |
+| `conditionalGeneration[filePath/directoryName].subject` | String | The `subject` is a [JMESPath](http://jmespath.org/) query to grab the value you want to apply the condition to. It queries an object with the whole AsyncAPI document and, when specified, the given server. The object looks like this: `{ asyncapi: { ... }, server: { ... } }`. If the template supports the `server` parameter, you can access server details like, for example, protocol this way: `server.protocol`. During validation with `conditionalGeneration`, only the server that the template user selected is available in the specification file. For more information about the `server` parameter [read about special parameters](#special-parameters). |
+| `conditionalGeneration[filePath/directoryName].parameter` | String | The `parameter` is the name of a custom template parameter passed through `templateParams` that controls whether a specific file or folder should be included in the generated output. You must define a `validation` rule using a JSON Schema fragment to apply the condition. For example, if you define `"parameter": "includeDocs"` with `"validation": { "const": true }`, the corresponding folder (e.g., `docs/`) will only be generated when the user passes `{ includeDocs: true }`. If `includeDocs` is `false`, it will be skipped. |
+| `conditionalGeneration[filePath/directoryName].validation` | Object (JSON Schema fragment) | The validation defines the condition under which the file or directory will be generated. It must be a valid JSON Schema fragment that validates the value of the parameter. For example, if you want to include a folder only when includeDocs is true, use "validation": `{ "const": true }`. You can also use more complex validation logic, like "enum": ["yes", "true"] or "type": "string" with a "pattern" constraint. If the parameter fails validation, the file or folder will not be included in the generated output. This allows for powerful and flexible control over template generation based on user input. |
+| `nonRenderableFiles` | [String] | A list of file paths or [globs](https://en.wikipedia.org/wiki/Glob_(programming)) that must be copied "as-is" to the target directory, i.e., without performing any rendering process. This is useful when you want to copy binary files. |
+| `generator` | [String] | A string representing the generator version-range the template is compatible with. This value must follow the [semver](https://nodejs.dev/learn/semantic-versioning-using-npm) syntax. E.g., `>=1.0.0`, `>=1.0.0 <=2.0.0`, `~1.0.0`, `^1.0.0`, `1.0.0`, etc. [Read more about semver](https://docs.npmjs.com/about-semantic-versioning). |
+| `filters` | [String] | A list of modules containing functions that can be used as Nunjucks filters. In case of external modules, remember they need to be added as a dependency in `package.json` of your template. |
+| `hooks` | Object[String, String] or Object[String, Array[String]] | A list of modules containing hooks, except for the ones you keep locally in your template in the default location. For each module you must specify the exact name of the hook that should be used in the template. For a single hook, you can specify it as a string; for more hooks, you must pass an array of strings. In the case of external modules, remember they need to be added as a dependency in `package.json` of your template. There is also [an official hooks library](hooks#official-library) always included in the generator. As this is a library of multiple hooks, you still need to explicitly specify in the configuration which one you want to use. Use `@asyncapi/generator-hooks` as the library name. |
 
 ## Special parameters
 
 There are some template parameters that have a special meaning:
 
-|Name|Description|
-|---|---|
-|`server`| It is used to let the template know which server from the AsyncAPI specification file you want to use. In some cases, this may be required. For instance, when generating code that connects to a specific server. Use this parameter in case your template relies on users' information about what server from the specification file they want to use during generation. You also need this parameter if you want to use `server.protocol` notation within `conditionalGeneration` configuration option. Once you decide to specify this parameter for your template, it is recommended you make it a mandatory parameter otherwise a feature like `conditionalGeneration` is not going to work if your users do not use this parameter obligatory.
-
+| Name | Description |
+|------|-------------|
+| `server` | It is used to let the template know which server from the AsyncAPI specification file you want to use. In some cases, this may be required. For instance, when generating code that connects to a specific server. Use this parameter in case your template relies on users' information about what server from the specification file they want to use during generation. You also need this parameter if you want to use `server.protocol` notation within `conditionalGeneration` configuration option. Once you decide to specify this parameter for your template, it is recommended you make it a mandatory parameter otherwise a feature like `conditionalGeneration` is not going to work if your users do not use this parameter obligatory. 

package/docs/template.md

@@ -5,7 +5,7 @@ weight: 50
 
 ## Template
 
-A template is a project that specifies the generation process output by using the AsyncAPI generator and an [AsyncAPI document](asyncapi-document). These files describe the generation results depending on the AsyncAPI document's content.
+A template is a project that specifies the generation process output by using the AsyncAPI Generator (generator) and an [AsyncAPI document](asyncapi-document). These files describe the generation results depending on the AsyncAPI document's content.
 
 Examples outputs:
 
@@ -14,7 +14,26 @@ Examples outputs:
 - Markdown diagrams
 - Python and Java applications
 
-A template is an independent Node.js project unrelated to the `generator` repository. AsyncAPI templates are managed, released, and published separately. You can also create templates and manage templates on your own.
+Templates can be developed as standalone project. There is also a set of baked-in core templates that are available in the generator out of the box.
+
+### Baked-in templates
+
+> This is a new concept introduced in generator version 2.8. The number of templates is limited and solution is still in experimental phase
+
+Baked-in templates are official AsyncAPI templates that are **developed, versioned, and shipped directly inside the `generator` repository and exposed with `@asyncapi/generator` library**. Source code of these templates live in the `packages/templates` directory of the `generator` repository. These templates and are managed alongside the generator’s core source code. Baked-in templates are always available “out of the box” when using the generator. No separate installation or network fetching is required.
+
+Baked-in templates benefit from:
+- **Tight integration** with the generator’s features and release cycle.
+- **Instant availability:** They are bundled as part of every release, so you never need to install or fetch them separately.
+- **Unified contributions:** Any improvements or changes to these templates happen through pull requests to the generator repository itself, keeping everything in sync. They share a lot of common parts which makes templates development faster.
+
+In contrast, **standalone templates** (described below) are maintained as independent Node.js packages, may live in separate repositories, and can be managed or installed separately from the core generator.
+
+Learn more from document [Baked-in Templates](#baked-in-templates).
+
+### Standalone templates
+
+A standalone template is an independent Node.js project unrelated to the `generator` repository. AsyncAPI templates are managed, released, and published separately. You can also create templates and manage templates on your own.
 
 The generator uses the official [Arborist](https://www.npmjs.com/package/@npmcli/arborist) NPM library. (This means templates do not have to be published to package managers to use them.) Arborist helps the generator fetch the template's source code and use it for the generation process. By default, this library pulls data from the default NPM registry, which is https://registry.npmjs.org. You can also configure the generator to fetch templates that are private or hosted in different NPM registry
 
@@ -44,7 +63,7 @@ graph LR
   end
 ```
 
-## Generator `templates` list
+## Standalone templates list
 
 AsyncAPI has a list of available templates to enhance your generation process. Templates are stored as repositories on AsyncAPI's official GitHub profile.
 

package/lib/generator.js

@@ -15,6 +15,7 @@ const { configureReact, renderReact, saveRenderedReactContent } = require('./ren
 const { configureNunjucks, renderNunjucks } = require('./renderer/nunjucks');
 const { validateTemplateConfig } = require('./templateConfigValidator');
 const { isGenerationConditionMet } = require('./conditionalGeneration');
+const { listBakedInTemplates, isCoreTemplate, getTemplate } = require('./templates/bakedInTemplates');
 const {
   convertMapToObject,
   isFileSystemPath,
@@ -281,11 +282,26 @@ class Generator {
    *   A promise that resolves to an object containing the name and path of the installed template.
    */
   async installAndSetupTemplate() {
-    const { name: templatePkgName, path: templatePkgPath } = await this.installTemplate(this.install);
+    const shouldSkipInstall = isCoreTemplate(this.templateName);
+
+    let templatePkgName, templatePkgPath;
+
+    if (shouldSkipInstall) {
+      // Use core template info from local registry
+      const template = await getTemplate(this.templateName);
+      templatePkgName = template.name;
+      templatePkgPath = template.path;
+    } else {
+      // Download and install external template
+      const installResult = await this.installTemplate(this.install);
+      templatePkgName = installResult.name;
+      templatePkgPath = installResult.path;
+    }
+
     this.templateDir = templatePkgPath;
     this.templateName = templatePkgName;
     this.templateContentDir = path.resolve(this.templateDir, TEMPLATE_CONTENT_DIRNAME);
-
+    
     await this.loadTemplateConfig();
 
     return { templatePkgName, templatePkgPath };
@@ -1138,4 +1154,16 @@ class Generator {
 Generator.DEFAULT_TEMPLATES_DIR = DEFAULT_TEMPLATES_DIR;
 Generator.TRANSPILED_TEMPLATE_LOCATION = TRANSPILED_TEMPLATE_LOCATION;
 
-module.exports = Generator;
+module.exports = Generator;
+/**
+ * List core templates, optionally filter by type, stack, protocol, or target.
+ * Use name of returned templates as input for the `generate` method for template generation. Such core templates code is part of the @asyncapi/generator package.
+ * 
+ * @param {Object} [filter] - Optional filter object.
+ * @param {string} [filter.type] - Filter by template type (e.g., 'client', 'docs').
+ * @param {string} [filter.stack] - Filter by stack (e.g., 'quarkus', 'express').
+ * @param {string} [filter.protocol] - Filter by protocol (e.g., 'websocket', 'http').
+ * @param {string} [filter.target] - Filter by target language or format (e.g., 'javascript', 'html').
+ * @returns {Array<Object>} Array of template objects matching the filter.
+ */
+module.exports.listBakedInTemplates = listBakedInTemplates;

package/lib/templates/BakedInTemplatesList.json

@@ -0,0 +1,20 @@
+[
+  {
+    "name": "core-template-client-websocket-dart",
+    "type": "client",
+    "protocol": "websocket",
+    "target": "dart"
+  },
+  {
+    "name": "core-template-client-websocket-javascript",
+    "type": "client",
+    "protocol": "websocket",
+    "target": "javascript"
+  },
+  {
+    "name": "core-template-client-websocket-python",
+    "type": "client",
+    "protocol": "websocket",
+    "target": "python"
+  }
+]

package/lib/templates/bakedInTemplates.js

@@ -0,0 +1,53 @@
+const templates = require('./BakedInTemplatesList.json');
+const path = require('path');
+
+const BAKED_IN_TEMPLATES_DIR = path.resolve(__dirname, 'bakedInTemplates');
+/**
+ * List core templates, optionally filter by type, stack, protocol, or target.
+ * Use name of returned templates as input for the `generate` method for template generation. Such core templates code is part of the @asyncapi/generator package.
+ * 
+ * @param {Object} [filter] - Optional filter object.
+ * @param {string} [filter.type] - Filter by template type (e.g., 'client', 'docs').
+ * @param {string} [filter.stack] - Filter by stack (e.g., 'quarkus', 'express').
+ * @param {string} [filter.protocol] - Filter by protocol (e.g., 'websocket', 'http').
+ * @param {string} [filter.target] - Filter by target language or format (e.g., 'javascript', 'html').
+ * @returns {Array<Object>} Array of template objects matching the filter.
+ */
+module.exports.listBakedInTemplates = (filter) => {
+  const { type, stack, protocol, target } = filter || {};
+
+  return templates.filter(t =>
+    (!type || t.type === type) &&
+    (!stack || t.stack === stack) &&
+    (!protocol || t.protocol === protocol) &&
+    (!target || t.target === target)
+  );
+};
+
+/**
+ * Check if a template exists in the core templates list.
+ * 
+ * @param {string} templateName - The name of the template to check.
+ * @returns {boolean} True if the template exists, false otherwise.
+ */
+module.exports.isCoreTemplate = (templateName) => {
+  return templates.some(t => t.name === templateName);
+};
+
+/**
+ * Retrieve a template by name and validate its path.
+ * If the path does not exist, fallback to `node_modules/{templateName}`.
+ *
+ * @async
+ * @param {string} templateName - The name of the template to retrieve.
+ * @returns {Promise<{name: string, path: string}|undefined>} An object containing the template's name and path, or undefined if not found.
+ */
+module.exports.getTemplate = async (templateName) => {
+  const template = templates.find(t => t.name === templateName);
+
+  const templatePath = template?.path || path.resolve(__dirname, BAKED_IN_TEMPLATES_DIR, template.name);
+  return {
+    name: template.name,
+    path: templatePath
+  };
+};

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@asyncapi/generator",
-  "version": "2.7.0",
+  "version": "2.8.0",
   "description": "The AsyncAPI generator. It can generate documentation, code, anything!",
   "main": "./lib/generator.js",
   "bin": {
@@ -13,17 +13,21 @@
   },
   "scripts": {
     "test": "npm run test:unit && npm run test:integration",
-    "test:unit": "jest --coverage --testPathIgnorePatterns=integration --testPathIgnorePatterns=test-project",
+    "test:unit": "jest --coverage --testPathIgnorePatterns=bakedInTemplates --testPathIgnorePatterns=integration --testPathIgnorePatterns=test-project",
     "test:dev": "npm run test:unit -- --watchAll",
     "test:integration": "npm run test:cleanup && jest --testPathPattern=integration --modulePathIgnorePatterns='./__mocks__(?!\\/loglevel\\.js$)'",
-    "test:integration:update": "jest --updateSnapshot --testPathPattern=integration --modulePathIgnorePatterns='./__mocks__(?!\\/loglevel\\.js$)'",
+    "test:integration:update": "npm run test:integration -- -u",
     "test:cleanup": "rimraf \"test/temp\"",
     "docs": "jsdoc2md --partial docs/jsdoc2md-handlebars/custom-sig-name.hbs docs/jsdoc2md-handlebars/main.hbs docs/jsdoc2md-handlebars/docs.hbs docs/jsdoc2md-handlebars/header.hbs docs/jsdoc2md-handlebars/defaultvalue.hbs docs/jsdoc2md-handlebars/link.hbs docs/jsdoc2md-handlebars/params-table.hbs --files lib/generator.js > docs/api.md",
     "docker:build": "docker build -t asyncapi/generator:latest .",
     "lint": "eslint --max-warnings 0 --config ../../.eslintrc --ignore-path ../../.eslintignore .",
+    "lint:fix": "npm run lint -- --fix",
     "generate:readme:toc": "markdown-toc -i README.md",
     "generate:assets": "npm run docs && npm run generate:readme:toc",
-    "bump:version": "npm --no-git-tag-version --allow-same-version version $VERSION"
+    "bump:version": "npm --no-git-tag-version --allow-same-version version $VERSION",
+    "build": "node scripts/build-templates.js",
+    "pretest": "npm run build",
+    "prepublish": "npm run build"
   },
   "preferGlobal": true,
   "bugs": {
@@ -48,7 +52,7 @@
   "homepage": "https://github.com/asyncapi/generator",
   "dependencies": {
     "@asyncapi/generator-hooks": "*",
-    "@asyncapi/generator-react-sdk": "^1.1.2",
+    "@asyncapi/generator-react-sdk": "*",
     "@asyncapi/multi-parser": "^2.1.1",
     "@asyncapi/nunjucks-filters": "*",
     "@asyncapi/parser": "^3.0.14",

package/test/__mocks__/@npmcli/arborist.js

@@ -1,11 +0,0 @@
-const arb = jest.genMockFromModule('@npmcli/arborist');
-
-arb.prototype[Symbol.for('resolvedAdd')] = [{name: 'test'}];
-
-arb.prototype.reify = jest.fn(async (opt) => {
-  const childrenMap = new Map();
-  childrenMap.set('test', {path: './test'});
-  return { children: childrenMap };
-});
-
-module.exports = arb;

package/test/__mocks__/@npmcli/config.js

@@ -1,3 +0,0 @@
-const npmConfig = jest.genMockFromModule('@npmcli/config');
-
-module.exports = npmConfig;

package/test/__mocks__/fs.extra.js

@@ -1,3 +0,0 @@
-const xfs = jest.genMockFromModule('fs.extra');
-
-module.exports = xfs;

package/test/__mocks__/loglevel.js

@@ -1,3 +0,0 @@
-const log = jest.genMockFromModule('loglevel');
-
-module.exports = log;

package/test/__mocks__/resolve-from.js

@@ -1,8 +0,0 @@
-let resolveFrom = jest.genMockFromModule('resolve-from');
-
-resolveFrom.__resolveFromValue = '';
-resolveFrom = jest.fn((path) => {
-  return resolveFrom.__resolveFromValue;
-});
-
-module.exports = resolveFrom;

package/test/__mocks__/resolve-pkg.js

@@ -1,8 +0,0 @@
-let resolvePkg = jest.genMockFromModule('resolve-pkg');
-
-resolvePkg.__resolvePkgValue = '';
-resolvePkg = jest.fn((path) => {
-  return resolvePkg.__resolvePkgValue;
-});
-
-module.exports = resolvePkg;