@asyncapi/generator@3.2.0

Minor Changes

• 8f06c14: Update @npmcli/arborist from v5.6 to v9.2
  This is a large jump but there are no breaking changes that affect us across these versions
  https://github.com/npm/cli/blob/latest/workspaces/arborist/CHANGELOG.md

@asyncapi/generator@3.1.2

Patch Changes

• 4a09f57: Bump @asyncapi/parser to 3.6.0 to support AsyncAPI 3.1.0

@asyncapi/generator@3.1.1

Patch Changes

• 2bfad27: Fix generator handling of template parameters with false default values, ensuring defaults are correctly injected and conditional generation works as expected.

@asyncapi/generator@3.1.0

Minor Changes

• 11a1b8d: - Updated Component: OnMessage (Python) - Added discriminator-based routing logic that automatically dispatches messages to operation-specific handlers before falling back to generic handlers

  • New Helpers:
    • getMessageDiscriminatorData - Extracts discriminator key and value from individual messages
    • getMessageDiscriminatorsFromOperations - Collects all discriminator metadata from receive operations
  • Enhanced Python webSocket client generation with automatic operation-based message routing:

  How python routing works

  • Generated WebSocket clients now automatically route incoming messages to operation-specific handlers based on message discriminators. Users can register handlers for specific message types without manually parsing or filtering messages.
  • When a message arrives, the client checks it against registered discriminators (e.g., type: "hello", type: "events_api")
  • If a match is found, the message is routed to the specific operation handler (e.g., onHelloMessage, onEvent)
  • If no match is found, the message falls back to generic message handlers
  • This enables clean separation of message handling logic based on message types

  discriminator is a string field that you can add to any AsyncAPI Schema. This also means that it is limited to AsyncAPI Schema only, and it won't work with other schema formats, like for example, Avro.

  The implementation automatically derives discriminator information from your AsyncAPI document:

  • Discriminator key is extracted from the discriminator field in your AsyncAPI spec
  • Discriminator value is extracted from the const property defined in message schemas

  Example AsyncAPI Schema with discriminator and const:

  schemas:
    hello:
      type: object
      discriminator: type # you specify name of property
      properties:
        type:
          type: string
          const: hello # you specify the value of the discriminator property that is used for routing
          description: A hello string confirming WebSocket connection

  Fallback

  When defaults aren't available in the AsyncAPI document, users must provide both discriminator_key and discriminator_value when registering handlers. Providing only one parameter is not supported - you must provide either both or neither.

  Why this limitation exists: When a receive operation has multiple messages sharing the same discriminator key (e.g., all use "type" field), we need the specific value (e.g., "hello", "disconnect") to distinguish between them. Without both pieces of information, the routing becomes ambiguous.

  Example:

  # Default case - discriminator info auto-derived from AsyncAPI doc
  client.register_on_hello_message_handler(my_handler)
  
  # Custom case - must provide both key AND value
  client.register_on_hello_message_handler(
      my_handler,
      discriminator_key="message_type",
      discriminator_value="custom_hello"
  )

Patch Changes

• Updated dependencies [11a1b8d]
  • @asyncapi/generator-components@0.5.0
  • @asyncapi/generator-helpers@1.1.0

@asyncapi/generator-helpers@1.1.0

Minor Changes

• 11a1b8d: - Updated Component: OnMessage (Python) - Added discriminator-based routing logic that automatically dispatches messages to operation-specific handlers before falling back to generic handlers

  • New Helpers:
    • getMessageDiscriminatorData - Extracts discriminator key and value from individual messages
    • getMessageDiscriminatorsFromOperations - Collects all discriminator metadata from receive operations
  • Enhanced Python webSocket client generation with automatic operation-based message routing:

  How python routing works

  • Generated WebSocket clients now automatically route incoming messages to operation-specific handlers based on message discriminators. Users can register handlers for specific message types without manually parsing or filtering messages.
  • When a message arrives, the client checks it against registered discriminators (e.g., type: "hello", type: "events_api")
  • If a match is found, the message is routed to the specific operation handler (e.g., onHelloMessage, onEvent)
  • If no match is found, the message falls back to generic message handlers
  • This enables clean separation of message handling logic based on message types

  discriminator is a string field that you can add to any AsyncAPI Schema. This also means that it is limited to AsyncAPI Schema only, and it won't work with other schema formats, like for example, Avro.

  The implementation automatically derives discriminator information from your AsyncAPI document:

  • Discriminator key is extracted from the discriminator field in your AsyncAPI spec
  • Discriminator value is extracted from the const property defined in message schemas

  Example AsyncAPI Schema with discriminator and const:

  schemas:
    hello:
      type: object
      discriminator: type # you specify name of property
      properties:
        type:
          type: string
          const: hello # you specify the value of the discriminator property that is used for routing
          description: A hello string confirming WebSocket connection

  Fallback

  When defaults aren't available in the AsyncAPI document, users must provide both discriminator_key and discriminator_value when registering handlers. Providing only one parameter is not supported - you must provide either both or neither.

  Why this limitation exists: When a receive operation has multiple messages sharing the same discriminator key (e.g., all use "type" field), we need the specific value (e.g., "hello", "disconnect") to distinguish between them. Without both pieces of information, the routing becomes ambiguous.

  Example:

  # Default case - discriminator info auto-derived from AsyncAPI doc
  client.register_on_hello_message_handler(my_handler)
  
  # Custom case - must provide both key AND value
  client.register_on_hello_message_handler(
      my_handler,
      discriminator_key="message_type",
      discriminator_value="custom_hello"
  )

@asyncapi/generator-components@0.5.0

Minor Changes

• 11a1b8d: - Updated Component: OnMessage (Python) - Added discriminator-based routing logic that automatically dispatches messages to operation-specific handlers before falling back to generic handlers

  • New Helpers:
    • getMessageDiscriminatorData - Extracts discriminator key and value from individual messages
    • getMessageDiscriminatorsFromOperations - Collects all discriminator metadata from receive operations
  • Enhanced Python webSocket client generation with automatic operation-based message routing:

  How python routing works

  • Generated WebSocket clients now automatically route incoming messages to operation-specific handlers based on message discriminators. Users can register handlers for specific message types without manually parsing or filtering messages.
  • When a message arrives, the client checks it against registered discriminators (e.g., type: "hello", type: "events_api")
  • If a match is found, the message is routed to the specific operation handler (e.g., onHelloMessage, onEvent)
  • If no match is found, the message falls back to generic message handlers
  • This enables clean separation of message handling logic based on message types

  discriminator is a string field that you can add to any AsyncAPI Schema. This also means that it is limited to AsyncAPI Schema only, and it won't work with other schema formats, like for example, Avro.

  The implementation automatically derives discriminator information from your AsyncAPI document:

  • Discriminator key is extracted from the discriminator field in your AsyncAPI spec
  • Discriminator value is extracted from the const property defined in message schemas

  Example AsyncAPI Schema with discriminator and const:

  schemas:
    hello:
      type: object
      discriminator: type # you specify name of property
      properties:
        type:
          type: string
          const: hello # you specify the value of the discriminator property that is used for routing
          description: A hello string confirming WebSocket connection

  Fallback

  When defaults aren't available in the AsyncAPI document, users must provide both discriminator_key and discriminator_value when registering handlers. Providing only one parameter is not supported - you must provide either both or neither.

  Why this limitation exists: When a receive operation has multiple messages sharing the same discriminator key (e.g., all use "type" field), we need the specific value (e.g., "hello", "disconnect") to distinguish between them. Without both pieces of information, the routing becomes ambiguous.

  Example:

  # Default case - discriminator info auto-derived from AsyncAPI doc
  client.register_on_hello_message_handler(my_handler)
  
  # Custom case - must provide both key AND value
  client.register_on_hello_message_handler(
      my_handler,
      discriminator_key="message_type",
      discriminator_value="custom_hello"
  )

Patch Changes

• Updated dependencies [11a1b8d]
  • @asyncapi/generator-helpers@1.1.0

@asyncapi/template-kafka-integration-test@0.0.2

Patch Changes

• Updated dependencies [df08ae7]
  • @asyncapi/generator-helpers@1.0.0

@asyncapi/generator@3.0.1

Patch Changes

• c5be81a: Enforce new helpers and components release to use latest versions in generator. Required because of the recent misconfiguration of releases and Trusted Publishing.
• Updated dependencies [c5be81a]
  • @asyncapi/generator-helpers@1.0.1
  • @asyncapi/generator-components@0.4.1

@asyncapi/generator@3.0.0

Major Changes

• df08ae7: ### Breaking Changes

  • You must use Node.js 24.11 or higher, and NPM 11.5.1 or higher
  • Nunjucks renderer removed — React is now the sole rendering engine. No need to specify render engine in config anymore
  • Nunjucks filters package and its public filters removed; filter-based template APIs no longer available.
  • ag CLI is no longer available. It was announced some time ago that it would be deprecated, and users are encouraged to switch to the AsyncAPI CLI

  Migration Guides

  • Migrating from Nunjucks to React render engine
  • Migrating from ag CLI to AsyncAPI CLI

Patch Changes

• Updated dependencies [df08ae7]
  • @asyncapi/generator-helpers@1.0.0

@asyncapi/generator-helpers@1.0.1

Patch Changes

• c5be81a: Enforce new helpers and components release to use latest versions in generator. Required because of the recent misconfiguration of releases and Trusted Publishing.