@asyncapi/generator@3.2.1

Patch Changes

• 643f194: Fix browserslist error when using pnpm

  Set BROWSERSLIST_ROOT_PATH environment variable during template compilation
  to prevent browserslist from searching outside the template directory. This
  fixes an issue where pnpm's shim files were incorrectly parsed as browserslist
  configuration, causing "Unknown browser query" errors.

  Fixes: asyncapi/cli#1781

@asyncapi/generator-components@0.6.0

Minor Changes

• 51bcc7b: Add unified error handling for @asyncapi/generator-components.
  A set of error codes was introduced to help template component development, so you can consistently introduce input validation errors.

@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