Skip to content

docs: rewrite generator template tutorial to AsyncAPI v3#1826

Merged
asyncapi-bot merged 11 commits intoasyncapi:masterfrom
Harsh16gupta:docs/rewrite-template-tutorial-v3
Feb 16, 2026
Merged

docs: rewrite generator template tutorial to AsyncAPI v3#1826
asyncapi-bot merged 11 commits intoasyncapi:masterfrom
Harsh16gupta:docs/rewrite-template-tutorial-v3

Conversation

@Harsh16gupta
Copy link
Contributor

@Harsh16gupta Harsh16gupta commented Jan 10, 2026

What this PR does

This PR updates the “Creating a template – Python” tutorial to be fully based on AsyncAPI v3.

It:

  • Migrates all AsyncAPI document examples from v2 → v3
  • Updates template code to use the v3 Parser API (operations, channels separation, host() instead of url())
  • Updates generator configuration and scripts to match v3
  • Keeps changes focused on documentation only, without unrelated formatting or refactors

Validation

Before opening this PR, I followed the updated tutorial end-to-end and generated a working Python MQTT client using AsyncAPI v3.

The complete working reference implementation is available here:
https://github.com/Harsh16gupta/asyncapi-v3-template-final

Using this repo, reviewers can:

  • Generate a project using the tutorial
  • Run the generated client locally
  • Verify that the template, parser API usage, and scripts work as documented

Validation output

Screenshots of successful generation and execution are available here:
image

Related issue

Resolves #1503

Summary by CodeRabbit

  • New Features

    • Support for AsyncAPI 3.0.1 and new temperature event operations (temperatureDropped, temperatureRisen, temperatureChanged).
  • Updates

    • Server configuration now uses host-based definitions.
    • Templates and generator now process operations (receive-filtering) instead of channels.
    • Generator API bumped to v3 and version range widened.
    • Public component API updated to consume operations-based interfaces.
  • Documentation

    • Examples and narratives updated to the new operations/channel naming and flow.

@changeset-bot
Copy link

changeset-bot bot commented Jan 10, 2026

⚠️ No Changeset found

Latest commit: e1a418d

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

This PR includes no changesets

When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR

@asyncapi-bot
Copy link
Contributor

What reviewer looks at during PR review

The following are ideal points maintainers look for during review. Reviewing these points yourself beforehand can help streamline the review process and reduce time to merge.

  1. PR Title: Use a concise title that follows our Conventional Commits guidelines and clearly summarizes the change using imperative mood (it means spoken or written as if giving a command or instruction, like "add new helper for listing operations")

    Note - In Generator, prepend feat: or fix: in PR title only when PATCH/MINOR release must be triggered.

  2. PR Description: Clearly explain the issue being solved, summarize the changes made, and mention the related issue.

    Note - In Generator, we use Maintainers Work board to track progress. Ensure the PR Description includes Resolves #<issue-number> or Fixes #<issue-number> this will automatically close the linked issue when the PR is merged and helps automate the maintainers workflow.

  3. Documentation: Update the relevant Generator documentation to accurately reflect the changes introduced in the PR, ensuring users and contributors have up-to-date guidance.

  4. Comments and JSDoc: Write clear and consistent JSDoc comments for functions, including parameter types, return values, and error conditions, so others can easily understand and use the code.

  5. DRY Code: Ensure the code follows the Don't Repeat Yourself principle. Look out for duplicate logic that can be reused.

  6. Test Coverage: Ensure the new code is well-tested with meaningful test cases that pass consistently and cover all relevant edge cases.

  7. Commit History: Contributors should avoid force-pushing as much as possible. It makes it harder to track incremental changes and review the latest updates.

  8. Template Design Principles Alignment: While reviewing template-related changes in the packages/ directory, ensure they align with the Assumptions and Principles. If any principle feels outdated or no longer applicable, start a discussion these principles are meant to evolve with the project.

  9. Reduce Scope When Needed: If an issue or PR feels too large or complex, consider splitting it and creating follow-up issues. Smaller, focused PRs are easier to review and merge.

  10. Bot Comments: As reviewers, check that contributors have appropriately addressed comments or suggestions made by automated bots. If there are bot comments the reviewer disagrees with, react to them or mark them as resolved, so the review history remains clear and accurate.

@coderabbitai
Copy link

coderabbitai bot commented Jan 10, 2026

Caution

Review failed

The pull request is closed.

📝 Walkthrough

Walkthrough

Update templates, docs, and generator metadata to AsyncAPI v3 (2.6.0 → 3.0.1): server lookups use host() instead of url(), channel-centric APIs refactored to operations-centric APIs, TopicFunction and helpers now accept operations, and generator/package metadata and examples updated accordingly.

Changes

Cohort / File(s) Summary
AsyncAPI document & docs
apps/generator/docs/generator-template.md
Bumped AsyncAPI version 2.6.0 → 3.0.1; servers migrated from urlhost; channels renamed/added (e.g., temperatureChanged, temperatureDropped, temperatureRisen) and mapped via addresses to new top-level operations; examples and narrative updated to operations-based usage.
Template components / public API
python-mqtt-client-template/components/TopicFunction.js
TopicFunction signature changed from { channels }{ operations }; internal getTopics updated to accept operations and derive topics by mapping operations → channel addresses.
Template entry & templating blocks
python-mqtt-client-template/index.js, python-mqtt-client-template/.../text/template
Templates now call operations={asyncapi.operations().filterByReceive()}; text/template blocks filter operations() by action: receive; server access uses servers().get(params.server).host().
Codegen snippets / lookups
templates/..., .../server-lookup.*, .../channel-lookup.*
Code snippets updated to replace url()host() lookups and to resolve operation → channel references (address / $ref) when deriving topics.
Generator & package metadata
package.json, .../package.json (generator sections)
Generator apiVersion updated v1v3; generator version-range widened (e.g., >=2.0.0 <4.0.0) across package metadata.
Tests, examples & scripts
docs/examples/*, test scripts, narrative/test files
Test descriptions, scripts and examples updated to new operation/channel names (e.g., temperatureDrop/temperatureRise) and adjusted generation flow and assertions.

Estimated code review effort

🎯 4 (Complex) | ⏱️ ~45 minutes

Possibly related PRs

🚥 Pre-merge checks | ✅ 5
✅ Passed checks (5 passed)
Check name Status Explanation
Description Check ✅ Passed Check skipped - CodeRabbit’s high-level summary is enabled.
Title check ✅ Passed The title follows Conventional Commits format with 'docs:' prefix and uses imperative mood describing the main change: rewriting the generator template tutorial to AsyncAPI v3.
Linked Issues check ✅ Passed The PR successfully addresses all coding requirements from issue #1503: AsyncAPI document examples migrated to v3, template code updated to use v3 Parser API (operations/channels separation, host() instead of url()), and generator configuration aligned with v3.
Out of Scope Changes check ✅ Passed All changes are focused on documentation updates for AsyncAPI v3 migration as specified in the linked issue; no unrelated refactoring or formatting changes are present.
Docstring Coverage ✅ Passed No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.

✏️ Tip: You can configure your own custom pre-merge checks in the settings.

✨ Finishing touches
🧪 Generate unit tests (beta)
  • Create PR with unit tests
  • Post copyable unit tests in a comment

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

Comment @coderabbitai help to get the list of available commands and usage tips.

Copy link

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 1

🤖 Fix all issues with AI agents
In @apps/generator/docs/generator-template.md:
- Line 494: The TopicFunction component expects a prop named "operations"
(destructured as { operations }) but the invocations pass a "channels" prop;
update the two invocations that call TopicFunction (currently using
channels={asyncapi.operations().filterByReceive()}) to use
operations={asyncapi.operations().filterByReceive()} so the component receives
the correct prop name and avoids undefined operations at runtime.
📜 Review details

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between a640160 and 86067c5.

📒 Files selected for processing (1)
  • apps/generator/docs/generator-template.md
🧰 Additional context used
🧠 Learnings (7)
📓 Common learnings
Learnt from: CR
Repo: asyncapi/generator PR: 0
File: .github/pr-review-checklist.md:0-0
Timestamp: 2026-01-05T09:57:34.800Z
Learning: Update relevant Generator documentation to accurately reflect PR changes introduced
Learnt from: derberg
Repo: asyncapi/generator PR: 1551
File: apps/generator/docs/generator-template.md:45-73
Timestamp: 2025-05-12T14:23:48.919Z
Learning: AsyncAPI 3.0.0 specification introduces significant structural changes from 2.x:
1. Operations become top-level elements with references to channels
2. Channels use 'address' for the topic path instead of having nested publish/subscribe
3. Messages are defined under a 'messages' container in channels
4. Servers can use a 'host' property
Learnt from: derberg
Repo: asyncapi/generator PR: 1551
File: apps/generator/docs/generator-template.md:45-73
Timestamp: 2025-05-12T14:23:48.919Z
Learning: AsyncAPI 3.0.0 specification introduces significant structural changes from 2.x:
1. Operations become top-level elements with action property (send/receive) and references to channels
2. Channels use 'address' for the topic path instead of having nested publish/subscribe operations
3. Messages are defined under a 'messages' container in channels
4. The specification decouples operations, channels and messages to improve reusability
5. Servers can use a 'host' property
📚 Learning: 2025-05-12T14:23:48.919Z
Learnt from: derberg
Repo: asyncapi/generator PR: 1551
File: apps/generator/docs/generator-template.md:45-73
Timestamp: 2025-05-12T14:23:48.919Z
Learning: AsyncAPI 3.0.0 specification introduces significant structural changes from 2.x:
1. Operations become top-level elements with references to channels
2. Channels use 'address' for the topic path instead of having nested publish/subscribe
3. Messages are defined under a 'messages' container in channels
4. Servers can use a 'host' property

Applied to files:

  • apps/generator/docs/generator-template.md
📚 Learning: 2025-05-12T14:23:48.919Z
Learnt from: derberg
Repo: asyncapi/generator PR: 1551
File: apps/generator/docs/generator-template.md:45-73
Timestamp: 2025-05-12T14:23:48.919Z
Learning: AsyncAPI 3.0.0 specification introduces significant structural changes from 2.x:
1. Operations become top-level elements with action property (send/receive) and references to channels
2. Channels use 'address' for the topic path instead of having nested publish/subscribe operations
3. Messages are defined under a 'messages' container in channels
4. The specification decouples operations, channels and messages to improve reusability
5. Servers can use a 'host' property

Applied to files:

  • apps/generator/docs/generator-template.md
📚 Learning: 2026-01-05T09:57:34.800Z
Learnt from: CR
Repo: asyncapi/generator PR: 0
File: .github/pr-review-checklist.md:0-0
Timestamp: 2026-01-05T09:57:34.800Z
Learning: Update relevant Generator documentation to accurately reflect PR changes introduced

Applied to files:

  • apps/generator/docs/generator-template.md
📚 Learning: 2026-01-05T09:57:44.281Z
Learnt from: CR
Repo: asyncapi/generator PR: 0
File: Development.md:0-0
Timestamp: 2026-01-05T09:57:44.281Z
Learning: Run tests locally using npm run generator:test:unit for unit tests and npm run generator:test:integration for integration tests

Applied to files:

  • apps/generator/docs/generator-template.md
📚 Learning: 2026-01-05T09:57:44.281Z
Learnt from: CR
Repo: asyncapi/generator PR: 0
File: Development.md:0-0
Timestamp: 2026-01-05T09:57:44.281Z
Learning: Applies to apps/generator/test/**/*.test.{js,ts} : Create new test files in the appropriate directory under apps/generator/test/ and follow existing test patterns

Applied to files:

  • apps/generator/docs/generator-template.md
📚 Learning: 2025-05-12T14:57:35.024Z
Learnt from: Adi-204
Repo: asyncapi/generator PR: 1557
File: packages/templates/clients/websocket/javascript/components/SendOperation.js:21-21
Timestamp: 2025-05-12T14:57:35.024Z
Learning: In the AsyncAPI generator templates, particularly in the JavaScript WebSocket client, single quotes are used for string literals inside template-generated code (which is itself inside backticks) to preserve template placeholders like ${variable} as literal text in the generated code output.

Applied to files:

  • apps/generator/docs/generator-template.md
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (1)
  • GitHub Check: preview
🔇 Additional comments (5)
apps/generator/docs/generator-template.md (5)

45-84: AsyncAPI v3.0.0 document examples are correct. The document properly reflects v3 structure with servers using host, channels with address and message containers, and top-level operations with channel references. Based on learnings, the migration correctly implements the v3 specification changes including operation-channel decoupling.


119-120: Generator configuration correctly updated for v3. The apiVersion is set to "v3" and the generator version range ">=1.10.0 <=3.0.1" is appropriate for v3 compatibility.

Also applies to: 333-334


398-398: Parser API usage is correct for AsyncAPI v3. All references use the correct v3 methods: asyncapi.servers().get(params.server).host() (instead of v2's url()) and asyncapi.operations().filterByReceive() for operation filtering.

Also applies to: 412-412, 443-443, 559-559


500-542: TopicFunction component correctly migrated to operations-based API. The component properly destructures the operations parameter, iterates through operations, and accesses their associated channels via op.channels() to extract the address and operation ID. The logic correctly aligns with AsyncAPI v3 structure.


6-15: Tutorial narrative and objectives align with AsyncAPI v3 migration. The introduction, prerequisites, and learning objectives correctly set expectations for v3-based template development. The reference to the completed implementation in the author's repo supports reproducibility.

@asyncapi-bot
Copy link
Contributor

asyncapi-bot commented Jan 10, 2026

🚀 Docs preview deployed
Below link points directly to the generator docs preview. May the force be with you!
https://69935f11d0c89213f98a8144--asyncapi-website.netlify.app/docs/tools/generator

@Harsh16gupta
Copy link
Contributor Author

Verified with docker also

image

Copy link

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 1

Caution

Some comments are outside the diff and can’t be posted inline due to platform limitations.

⚠️ Outside diff range comments (1)
apps/generator/docs/generator-template.md (1)

518-523: Clarify the getTopics function logic in documentation.

The comment describes the output as "one for each channel" but the logic iterates over operations and extracts associated channel addresses. The explanation should reflect that the function processes operations and their channel references.

📝 Proposed comment improvement
 /*
- * This function returns a list of objects, one for each channel with two properties, name and topic
- * name - holds information about the operationId provided in the AsyncAPI document
- * topic - holds information about the address of the topic
- *
- * As input it requires a list of Channel models from the parsed AsyncAPI document
+ * This function returns a list of objects, one for each operation, with two properties: name and topic.
+ * name - holds the operationId from the AsyncAPI document (or generated ID if not set)
+ * topic - holds the address of the operation's associated channel
+ *
+ * As input it requires a list of Operation models from the parsed AsyncAPI document.
  */
🤖 Fix all issues with AI agents
In @apps/generator/docs/generator-template.md:
- Around line 501-504: The JSDoc incorrectly mentions "Channel models" but the
component now accepts an operations list; update the comment to say the input is
a list/array of operation objects (parameter name "operations") that map to
AsyncAPI v3 channel operations (e.g., each operation corresponds to a specific
channel and its publish/subscribe operation), and briefly explain that the
returned block provides helper functions to send messages to topics derived from
those operations; update any references to "channels" to clarify the
operations-to-channel relationship.
🧹 Nitpick comments (1)
apps/generator/docs/generator-template.md (1)

528-539: Silent skipping of operations without channels may mask configuration errors.

The early return at line 530 skips operations that have no associated channels without any warning or logging. This could hide misconfigured AsyncAPI documents silently.

Consider logging a warning or including a note in documentation explaining that operations must have associated channels to be included in the generated output.

📜 Review details

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 86067c5 and 4b972b7.

📒 Files selected for processing (1)
  • apps/generator/docs/generator-template.md
🧰 Additional context used
🧠 Learnings (9)
📓 Common learnings
Learnt from: CR
Repo: asyncapi/generator PR: 0
File: .github/pr-review-checklist.md:0-0
Timestamp: 2026-01-05T09:57:34.800Z
Learning: Update relevant Generator documentation to accurately reflect PR changes introduced
Learnt from: derberg
Repo: asyncapi/generator PR: 1551
File: apps/generator/docs/generator-template.md:45-73
Timestamp: 2025-05-12T14:23:48.919Z
Learning: AsyncAPI 3.0.0 specification introduces significant structural changes from 2.x:
1. Operations become top-level elements with references to channels
2. Channels use 'address' for the topic path instead of having nested publish/subscribe
3. Messages are defined under a 'messages' container in channels
4. Servers can use a 'host' property
Learnt from: derberg
Repo: asyncapi/generator PR: 1551
File: apps/generator/docs/generator-template.md:45-73
Timestamp: 2025-05-12T14:23:48.919Z
Learning: AsyncAPI 3.0.0 specification introduces significant structural changes from 2.x:
1. Operations become top-level elements with action property (send/receive) and references to channels
2. Channels use 'address' for the topic path instead of having nested publish/subscribe operations
3. Messages are defined under a 'messages' container in channels
4. The specification decouples operations, channels and messages to improve reusability
5. Servers can use a 'host' property
📚 Learning: 2025-05-12T14:23:48.919Z
Learnt from: derberg
Repo: asyncapi/generator PR: 1551
File: apps/generator/docs/generator-template.md:45-73
Timestamp: 2025-05-12T14:23:48.919Z
Learning: AsyncAPI 3.0.0 specification introduces significant structural changes from 2.x:
1. Operations become top-level elements with references to channels
2. Channels use 'address' for the topic path instead of having nested publish/subscribe
3. Messages are defined under a 'messages' container in channels
4. Servers can use a 'host' property

Applied to files:

  • apps/generator/docs/generator-template.md
📚 Learning: 2025-05-12T14:23:48.919Z
Learnt from: derberg
Repo: asyncapi/generator PR: 1551
File: apps/generator/docs/generator-template.md:45-73
Timestamp: 2025-05-12T14:23:48.919Z
Learning: AsyncAPI 3.0.0 specification introduces significant structural changes from 2.x:
1. Operations become top-level elements with action property (send/receive) and references to channels
2. Channels use 'address' for the topic path instead of having nested publish/subscribe operations
3. Messages are defined under a 'messages' container in channels
4. The specification decouples operations, channels and messages to improve reusability
5. Servers can use a 'host' property

Applied to files:

  • apps/generator/docs/generator-template.md
📚 Learning: 2026-01-05T09:57:34.800Z
Learnt from: CR
Repo: asyncapi/generator PR: 0
File: .github/pr-review-checklist.md:0-0
Timestamp: 2026-01-05T09:57:34.800Z
Learning: Update relevant Generator documentation to accurately reflect PR changes introduced

Applied to files:

  • apps/generator/docs/generator-template.md
📚 Learning: 2025-05-06T12:39:42.189Z
Learnt from: derberg
Repo: asyncapi/generator PR: 1536
File: packages/templates/clients/websocket/test/__fixtures__/asyncapi-slack-client.yml:48-53
Timestamp: 2025-05-06T12:39:42.189Z
Learning: In AsyncAPI 3.0.0, security schemes can be defined inline directly at various levels including the server level, and don't need to be centrally defined in components.securitySchemes first. This is a change from previous versions of the AsyncAPI specification.

Applied to files:

  • apps/generator/docs/generator-template.md
📚 Learning: 2025-04-23T09:18:38.333Z
Learnt from: derberg
Repo: asyncapi/generator PR: 1512
File: packages/templates/clients/websocket/javascript/components/AvailableOperations.js:10-15
Timestamp: 2025-04-23T09:18:38.333Z
Learning: In the asyncapi/generator repository, keys aren't required when mapping over operations array in the AvailableOperations component, contrary to the typical React pattern.

Applied to files:

  • apps/generator/docs/generator-template.md
📚 Learning: 2026-01-05T09:57:44.281Z
Learnt from: CR
Repo: asyncapi/generator PR: 0
File: Development.md:0-0
Timestamp: 2026-01-05T09:57:44.281Z
Learning: Run tests locally using npm run generator:test:unit for unit tests and npm run generator:test:integration for integration tests

Applied to files:

  • apps/generator/docs/generator-template.md
📚 Learning: 2026-01-05T09:57:44.281Z
Learnt from: CR
Repo: asyncapi/generator PR: 0
File: Development.md:0-0
Timestamp: 2026-01-05T09:57:44.281Z
Learning: Applies to apps/generator/test/**/*.test.{js,ts} : Create new test files in the appropriate directory under apps/generator/test/ and follow existing test patterns

Applied to files:

  • apps/generator/docs/generator-template.md
📚 Learning: 2025-05-12T14:57:35.024Z
Learnt from: Adi-204
Repo: asyncapi/generator PR: 1557
File: packages/templates/clients/websocket/javascript/components/SendOperation.js:21-21
Timestamp: 2025-05-12T14:57:35.024Z
Learning: In the AsyncAPI generator templates, particularly in the JavaScript WebSocket client, single quotes are used for string literals inside template-generated code (which is itself inside backticks) to preserve template placeholders like ${variable} as literal text in the generated code output.

Applied to files:

  • apps/generator/docs/generator-template.md
🔇 Additional comments (2)
apps/generator/docs/generator-template.md (2)

1-652: AsyncAPI v3 migration is comprehensive and well-documented.

The tutorial successfully migrates from v2 to v3 with clear explanations of structural changes. The AsyncAPI document examples, generator configuration, and template code all reflect v3 patterns. The TopicFunction component correctly processes operations instead of channels, and examples demonstrate working implementations.

Based on learnings, the changes align with AsyncAPI v3 specification where operations become top-level elements with action property and channels use address fields.


398-398: All AsyncAPI v3 Parser API methods are available and correctly used.

The methods asyncapi.servers().get(params.server).host(), operations(), filterByReceive(), id(), and operationId() are confirmed in the codebase. The host() method is actively used in helper functions (packages/helpers/src/servers.js), component code (packages/components/src/components/FileHeaderInfo.js), and test files, confirming the API pattern is valid and functional for v3 Parser.

@Harsh16gupta
Copy link
Contributor Author

@derberg whenever you have a moment, could you please have a look?
Thanks!

Copy link

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 1

Caution

Some comments are outside the diff and can’t be posted inline due to platform limitations.

⚠️ Outside diff range comments (1)
apps/generator/docs/generator-template.md (1)

505-542: Replace op.operationId() with op.id()—the operationId method does not exist in Parser v3.

The TopicFunction component refactoring is otherwise correct. The methods op.channels(), op.channels().all(), op.id(), and channel.address() are all confirmed and working. However, op.operationId() is not a valid method in Parser v3.4.0. All working code in the repository uses only operation.id().

Change line 533 from:

const operationId = op.operationId() || op.id();

to:

const operationId = op.id();
🤖 Fix all issues with AI agents
In @apps/generator/docs/generator-template.md:
- Around line 119-120: The generator version range in the template is incorrect:
update the "generator" field to use the documented range format by changing its
value from ">=1.10.0 <=3.0.1" to ">=1.3.0 <3.0.0" while keeping "apiVersion":
"v3" as-is; locate the "apiVersion" and "generator" entries in the template and
replace the generator string with the new lower bound >=1.3.0 and exclusive
upper bound <3.0.0.
📜 Review details

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 4b972b7 and 84671f7.

📒 Files selected for processing (1)
  • apps/generator/docs/generator-template.md
🧰 Additional context used
🧠 Learnings (9)
📓 Common learnings
Learnt from: derberg
Repo: asyncapi/generator PR: 1551
File: apps/generator/docs/generator-template.md:45-73
Timestamp: 2025-05-12T14:23:48.919Z
Learning: AsyncAPI 3.0.0 specification introduces significant structural changes from 2.x:
1. Operations become top-level elements with references to channels
2. Channels use 'address' for the topic path instead of having nested publish/subscribe
3. Messages are defined under a 'messages' container in channels
4. Servers can use a 'host' property
Learnt from: derberg
Repo: asyncapi/generator PR: 1551
File: apps/generator/docs/generator-template.md:45-73
Timestamp: 2025-05-12T14:23:48.919Z
Learning: AsyncAPI 3.0.0 specification introduces significant structural changes from 2.x:
1. Operations become top-level elements with action property (send/receive) and references to channels
2. Channels use 'address' for the topic path instead of having nested publish/subscribe operations
3. Messages are defined under a 'messages' container in channels
4. The specification decouples operations, channels and messages to improve reusability
5. Servers can use a 'host' property
Learnt from: derberg
Repo: asyncapi/generator PR: 1536
File: packages/templates/clients/websocket/test/__fixtures__/asyncapi-slack-client.yml:48-53
Timestamp: 2025-05-06T12:39:42.189Z
Learning: In AsyncAPI 3.0.0, security schemes can be defined inline directly at various levels including the server level, and don't need to be centrally defined in components.securitySchemes first. This is a change from previous versions of the AsyncAPI specification.
Learnt from: CR
Repo: asyncapi/generator PR: 0
File: .github/pr-review-checklist.md:0-0
Timestamp: 2026-01-05T09:57:34.800Z
Learning: Update relevant Generator documentation to accurately reflect PR changes introduced
📚 Learning: 2025-05-12T14:23:48.919Z
Learnt from: derberg
Repo: asyncapi/generator PR: 1551
File: apps/generator/docs/generator-template.md:45-73
Timestamp: 2025-05-12T14:23:48.919Z
Learning: AsyncAPI 3.0.0 specification introduces significant structural changes from 2.x:
1. Operations become top-level elements with references to channels
2. Channels use 'address' for the topic path instead of having nested publish/subscribe
3. Messages are defined under a 'messages' container in channels
4. Servers can use a 'host' property

Applied to files:

  • apps/generator/docs/generator-template.md
📚 Learning: 2025-05-12T14:23:48.919Z
Learnt from: derberg
Repo: asyncapi/generator PR: 1551
File: apps/generator/docs/generator-template.md:45-73
Timestamp: 2025-05-12T14:23:48.919Z
Learning: AsyncAPI 3.0.0 specification introduces significant structural changes from 2.x:
1. Operations become top-level elements with action property (send/receive) and references to channels
2. Channels use 'address' for the topic path instead of having nested publish/subscribe operations
3. Messages are defined under a 'messages' container in channels
4. The specification decouples operations, channels and messages to improve reusability
5. Servers can use a 'host' property

Applied to files:

  • apps/generator/docs/generator-template.md
📚 Learning: 2026-01-05T09:57:34.800Z
Learnt from: CR
Repo: asyncapi/generator PR: 0
File: .github/pr-review-checklist.md:0-0
Timestamp: 2026-01-05T09:57:34.800Z
Learning: Update relevant Generator documentation to accurately reflect PR changes introduced

Applied to files:

  • apps/generator/docs/generator-template.md
📚 Learning: 2026-01-05T09:57:34.800Z
Learnt from: CR
Repo: asyncapi/generator PR: 0
File: .github/pr-review-checklist.md:0-0
Timestamp: 2026-01-05T09:57:34.800Z
Learning: Applies to **/*.{js,ts,jsx,tsx} : Write clear and consistent JSDoc comments for functions, including parameter types, return values, and error conditions

Applied to files:

  • apps/generator/docs/generator-template.md
📚 Learning: 2025-04-23T09:18:38.333Z
Learnt from: derberg
Repo: asyncapi/generator PR: 1512
File: packages/templates/clients/websocket/javascript/components/AvailableOperations.js:10-15
Timestamp: 2025-04-23T09:18:38.333Z
Learning: In the asyncapi/generator repository, keys aren't required when mapping over operations array in the AvailableOperations component, contrary to the typical React pattern.

Applied to files:

  • apps/generator/docs/generator-template.md
📚 Learning: 2026-01-05T09:57:44.281Z
Learnt from: CR
Repo: asyncapi/generator PR: 0
File: Development.md:0-0
Timestamp: 2026-01-05T09:57:44.281Z
Learning: Run tests locally using npm run generator:test:unit for unit tests and npm run generator:test:integration for integration tests

Applied to files:

  • apps/generator/docs/generator-template.md
📚 Learning: 2026-01-05T09:57:44.281Z
Learnt from: CR
Repo: asyncapi/generator PR: 0
File: Development.md:0-0
Timestamp: 2026-01-05T09:57:44.281Z
Learning: Applies to apps/generator/test/**/*.test.{js,ts} : Create new test files in the appropriate directory under apps/generator/test/ and follow existing test patterns

Applied to files:

  • apps/generator/docs/generator-template.md
📚 Learning: 2025-05-12T14:57:35.024Z
Learnt from: Adi-204
Repo: asyncapi/generator PR: 1557
File: packages/templates/clients/websocket/javascript/components/SendOperation.js:21-21
Timestamp: 2025-05-12T14:57:35.024Z
Learning: In the AsyncAPI generator templates, particularly in the JavaScript WebSocket client, single quotes are used for string literals inside template-generated code (which is itself inside backticks) to preserve template placeholders like ${variable} as literal text in the generated code output.

Applied to files:

  • apps/generator/docs/generator-template.md
🔇 Additional comments (4)
apps/generator/docs/generator-template.md (4)

47-84: LGTM! AsyncAPI v3 document structure is correct.

The AsyncAPI document has been properly migrated to v3 with all the key structural changes in place: operations as top-level elements with action: receive, channels using address for topic paths, messages under a messages container, and servers using the host property.

Based on learnings, this aligns with AsyncAPI 3.0.0 specification requirements.


398-398: LGTM! Correct usage of host() for AsyncAPI v3.

The template code has been correctly updated to use asyncapi.servers().get(params.server).host() instead of the v2 url() method. This change is consistently applied throughout all template examples.

Based on learnings, servers in AsyncAPI v3 use the host property.

Also applies to: 412-412, 443-443, 559-559


490-496: LGTM! Operations-based API correctly implemented for AsyncAPI v3.

The template has been properly updated to use asyncapi.operations().filterByReceive() instead of the v2 channel-based approach. This correctly reflects the v3 specification where operations are top-level elements with an action property that can be filtered.

The explanatory comment clearly describes that the template generates functions for operations marked with action: receive.

Based on learnings, AsyncAPI 3.0.0 decouples operations, channels, and messages to improve reusability.

Also applies to: 570-570


605-632: LGTM! Multi-channel AsyncAPI v3 document correctly structured.

The updated AsyncAPI document with two channels (temperatureDropped and temperatureRisen) and their corresponding operations (temperatureDrop and temperatureRise) is correctly structured for v3:

  • Each channel uses the address field for the topic path
  • Messages are properly nested under the messages container
  • Operations are defined at the top level with action: receive
  • Operations reference channels using $ref: '#/channels/...'

This demonstrates the proper decoupling of operations, channels, and messages in AsyncAPI v3.

Comment on lines 119 to 120
"apiVersion": "v3",
"generator": ">=1.10.0 <=3.0.1",
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⚠️ Potential issue | 🟡 Minor

🧩 Analysis chain

🌐 Web query:

AsyncAPI generator v3 API compatibility version requirements

💡 Result:

Short answer: Templates must declare apiVersion: "v3" in their generator configuration so the AsyncAPI Generator will use the Parser-API/Parser v3 runtime and accept AsyncAPI spec v3 documents. If a template omits or uses a non‑v3 apiVersion the Generator assumes older Parser-API behavior and will error (e.g., "Version '3.0.0' is not supported"). Also check the template's declared supported generator range (generator field) to ensure the template is compatible with your @asyncapi/generator version. [1][2][3]

Example (package.json or .ageneratorrc): include "apiVersion": "v3" under the generator config. [1][3]

Sources:

  • AsyncAPI generator configuration documentation. [1]
  • Generator version vs template version / compatibility checks. [2]
  • Community example explaining setting apiVersion to "v3" to fix the error. [3]

🏁 Script executed:

# Search for AsyncAPI generator version information and v3 compatibility
rg -i "generator.*version|apiVersion.*v3|v3.*compatibility|changelog|release" --type=md --type=json -A 2 -B 2

Repository: asyncapi/generator

Length of output: 37640


🏁 Script executed:

# Search for v3 API introduction in CHANGELOG
rg -A 5 -B 5 "v3.*API|Parser.*v3|apiVersion.*v3" apps/generator/CHANGELOG.md --type=md | head -100

# Look for generator version requirements and v3 compatibility mentions
rg "generator.*1\.\d+\.\d+|v3" apps/generator/docs/configuration-file.md -A 2 -B 2 --type=md

Repository: asyncapi/generator

Length of output: 4186


🏁 Script executed:

# Check if there's a specific release note about v3 support
rg -i "v3 parser|parser-api|apiVersion" apps/generator/CHANGELOG.md -C 5 --type=md | grep -A 10 -B 10 "v3"

Repository: asyncapi/generator

Length of output: 708


🏁 Script executed:

# Search CHANGELOG more comprehensively for v3 support introduction
rg "v3|1\.3\.0|1\.10\.0" apps/generator/CHANGELOG.md -B 5 -A 5 | head -150

Repository: asyncapi/generator

Length of output: 739


🏁 Script executed:

# Check the generator-template.md file specifically to see all version references
grep -n "generator.*1\." apps/generator/docs/generator-template.md

Repository: asyncapi/generator

Length of output: 147


🏁 Script executed:

# Search for when v3 API support was introduced in CHANGELOG
rg "Parser.*API.*v3|v3.*Parser|apiVersion.*v3" apps/generator/CHANGELOG.md -B 10 -A 10 | head -200

Repository: asyncapi/generator

Length of output: 1210


🏁 Script executed:

# Look at actual package.json or configuration files in the repo to understand v3 requirements
fd "package.json" apps/generator/docs -o apps/generator/test | xargs grep -l "apiVersion" | head -5

Repository: asyncapi/generator

Length of output: 219


🏁 Script executed:

# Check if there are any test templates or examples with v3 that show the actual minimum version needed
find apps/generator -name "*.json" -o -name "*.yaml" -o -name ".ageneratorrc" | xargs grep -h "apiVersion.*v3" -A 1 -B 1 2>/dev/null | sort | uniq

Repository: asyncapi/generator

Length of output: 83


🏁 Script executed:

# Check the entire generator-template.md file context around those lines
sed -n '115,125p' apps/generator/docs/generator-template.md
sed -n '330,340p' apps/generator/docs/generator-template.md

Repository: asyncapi/generator

Length of output: 735


🏁 Script executed:

# Look for any documentation or changelog entries explaining why this template has a different version range
rg "1\.10\.0|3\.0\.1" apps/generator/ --type=md --type=json

Repository: asyncapi/generator

Length of output: 1277


🏁 Script executed:

# Check the generator changelog for v3 introduction
rg "## 3\." apps/generator/CHANGELOG.md -A 20 | head -80

Repository: asyncapi/generator

Length of output: 1376


🏁 Script executed:

# Look for v3 API first appearance in CHANGELOG
rg "v3|Parser.*API" apps/generator/CHANGELOG.md | head -20

Repository: asyncapi/generator

Length of output: 104


🏁 Script executed:

# Check the exact context of both occurrences in generator-template.md
cat -n apps/generator/docs/generator-template.md | sed -n '115,340p'

Repository: asyncapi/generator

Length of output: 11051


🌐 Web query:

AsyncAPI generator v3 API support minimum version 1.3.0 1.10.0 documentation

💡 Result:

I’m missing context—do you want (a) the AsyncAPI Generator v3 release/docs that state minimum supported AsyncAPI spec versions (e.g., 1.3.0 vs 1.10.0), (b) instructions for installing Generator v3 with a minimum dependency version, or (c) links to the specific AsyncAPI docs/pages? Which exactly do you want?


🌐 Web query:

AsyncAPI parser API v3 template compatibility generator version requirements

💡 Result:

Short answer

  • To use Parser API v3 in a template, set apiVersion: "v3" in the template config (package.json "generator" property or .ageneratorrc). [1]
  • The template must also declare a generator semver range it’s compatible with (the "generator" field) so the Generator CLI can validate compatibility. Use a Generator version that supports passing Parser v3 (use the Generator/CLI release that provides the new parser or run the CLI with the new-generator option if documented). [1][2]
  • Example fix (package.json generator section): "apiVersion": "v3". This is the recommended way to make the Generator use parser-js v3 for AsyncAPI v3 specs. [3]

Sources

  • Template configuration (apiVersion, generator compatibility, .ageneratorrc / package.json). [1]
  • Generator vs template versioning and how generator validates template "generator" ranges; note about using the newer generator/CLI. [2]
  • Community example showing setting apiVersion: "v3" to enable parser v3. [3]

Update generator version range to match documentation standard.

The apiVersion: v3 is correct for v3 Parser API support. However, the generator version range should be >=1.3.0 <3.0.0 to align with official template documentation. The current range >=1.10.0 <=3.0.1 is unnecessarily restrictive on the lower bound and uses an incorrect upper bound pattern (inclusive patch version instead of exclusive major version).

🤖 Prompt for AI Agents
In @apps/generator/docs/generator-template.md around lines 119 - 120, The
generator version range in the template is incorrect: update the "generator"
field to use the documented range format by changing its value from ">=1.10.0
<=3.0.1" to ">=1.3.0 <3.0.0" while keeping "apiVersion": "v3" as-is; locate the
"apiVersion" and "generator" entries in the template and replace the generator
string with the new lower bound >=1.3.0 and exclusive upper bound <3.0.0.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

actually update the value to >=2.0.0 <4.0.0, let us support latest AsyncAPI CLI v5

cc @Harsh16gupta

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@derberg done.
Updated the version range and reference repo. Please have a look.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

but you pushed [__transpiled](https://github.com/Harsh16gupta/asyncapi-v3-template-final/tree/main/__transpiled) which is the result of generator transpilation. I meant you should push the result of generation. Look at https://69669ff3b5b23637cad28600--asyncapi-website.netlify.app/docs/tools/generator/generator-template#4-write-script-to-run-the-test-code and output. You need to make sure the new tutorial works end to end - and I need to be able to verify how you tested it

Copy link
Contributor Author

@Harsh16gupta Harsh16gupta Jan 14, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I followed the same flow as the v2 docs and ran npm test, which internally does:

  • asyncapi generate fromTemplate test/fixtures/asyncapi.yml ./ --output test/project
  • then runs python test/project/test.py

The generated output for this tutorial is therefore test/project/client.py, and the runtime behavior is verified via test.py.

When I run this, I get exactly the same output as shown in the v2 tutorial logs (temperature dropped / risen messages), matching the expected behavior:
https://69669ff3b5b23637cad28600--asyncapi-website.netlify.app/docs/tools/generator/generator-template#5d-update-asyncapi-document:~:text=Run%20npm%20test%20to%20validate%20that%20everything,Where%20to%20go%20from%20here%3F

This confirms that the v2 → v3 conversion works end to end, and test/project is already committed in the repo so the generated output and verification steps are visible. I’ve also removed __transpiled since it’s not part of the generated output.

Please let me know if there’s any additional generated artifact you expect beyond test/project.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@derberg
I tried dong this
image
and I have commited the output generated to this
https://github.com/Harsh16gupta/Testing

Just wanted to confirm if this is what you were asking me to do

@sonarqubecloud
Copy link

@derberg derberg moved this to Todo in Maintainers work Jan 21, 2026
@derberg derberg self-assigned this Jan 21, 2026
@derberg derberg moved this from Todo to In Progress in Maintainers work Jan 21, 2026
@Harsh16gupta
Copy link
Contributor Author

Harsh16gupta commented Jan 28, 2026

Hi @derberg, just checking in on this PR
I’ve addressed all the feedback so far If there’s anything else you’d like me to change or clarify, I’m more than happy to do it.
Thanks!

Copy link
Member

@derberg derberg left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

great work, sorry for such lengthy review

last thing - at the bottom of the document you see a link to my repo and my article:

@sonarqubecloud
Copy link

@Harsh16gupta
Copy link
Contributor Author

Thanks for the review
Since the tutorial now links to my reference repo, I’ll add a proper README there (similar to the previous reference) to clearly document the end-to-end validation steps and usage.

@derberg
Copy link
Member

derberg commented Feb 16, 2026

/rtm

@asyncapi-bot asyncapi-bot merged commit 5cf3422 into asyncapi:master Feb 16, 2026
15 of 16 checks passed
@github-project-automation github-project-automation bot moved this from In Progress to Done in Maintainers work Feb 16, 2026
@Harsh16gupta Harsh16gupta deleted the docs/rewrite-template-tutorial-v3 branch February 16, 2026 18:37
@derberg derberg moved this from Done to Archive in Maintainers work Feb 18, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

Status: Archive

Development

Successfully merging this pull request may close these issues.

rewrite tutorial on template creation to use AsyncAPI v3

3 participants