[BUG]: Generator does not validate template parameter types (invalid values silently ignored)

[sahillllllllll-bit]

Describe the bug.

The AsyncAPI Generator does not validate template parameter types. When an invalid value is provided for a template parameter (e.g., a non-boolean value for a boolean parameter), the generator silently accepts it and proceeds with generation without any error or warning.

Expected behavior

When a template parameter is provided with an invalid type (for example, a non-boolean value for a boolean parameter like singleFile), the AsyncAPI Generator should fail and display a clear, descriptive validation error instead of proceeding with generation.

Screenshots

How to Reproduce

1. I first ran the AsyncAPI Generator with an invalid template parameter value:

   asyncapi generate fromTemplate asyncapi.yaml @asyncapi/html-template -o output -p singleFile=abc
   

2. I observed that the generator started and completed successfully without showing any error or warning.
3. I checked the generated output and confirmed that the invalid parameter value was silently ignored.

🖥️ Device Information [optional]

• Operating System (OS):Windows(WSL)
• Browser:N/A
• Browser Version:N/A

👀 Have you checked for similar open issues?

• I checked and didn't find similar issue

🏢 Have you read the Contributing Guidelines?

• I have read the Contributing Guidelines

Are you willing to work on this issue ?

Yes I am willing to submit a PR!

[dosubot]

You're right—currently, the AsyncAPI Generator does not validate the types of template parameter values. The validation logic (in validateTemplateConfig) only checks for required parameters and unknown names, but it doesn't check if, for example, a boolean parameter like singleFile actually receives a boolean value. This means invalid values like singleFile=abc are silently accepted and ignored, which can lead to confusing behavior and bugs source.

To implement type validation, you'd need to extend the template configuration schema to support a type field for each parameter (e.g., "type": "boolean"). Then, update the validateTemplateConfig function to check each parameter value against its declared type and throw a clear error if there's a mismatch. Since CLI input is always a string, you'll want to handle type coercion or validation carefully—don't auto-cast, but do fail if the value can't be interpreted as the correct type. For backward compatibility, skip type checks for parameters without a type field.

Tests for this logic should go in templateConfigValidator.test.js. You can look at how JSON Schema fragments are used for conditional rendering in conditionalGeneration as a reference, but note that this is currently only used for file/folder inclusion, not global parameter validation source.

Let me know if you want a sample schema or validation snippet to get started!

To reply, just mention @dosu.

---

^{How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other}

   

[sahillllllllll-bit]

Thanks @dosu for the clarification. This matches the issue I reported—invalid parameter types are not validated and are silently ignored. Let me know if you’d like me to open a PR to add type support and validation in validateTemplateConfig.

[Harsh16gupta]

@sahillllllllll-bit Thanks for raising this. Since the generator has behaved this way for a long time, it’s possible this is intentional . Changes to template parameter validation could have broader impact, so it would be best to wait for maintainer confirmation on the desired behavior before proceeding with a PR.

[sahillllllllll-bit]

@sahillllllllll-bit Thanks for raising this. Since the generator has behaved this way for a long time, it’s possible this is intentional . Changes to template parameter validation could have broader impact, so it would be best to wait for maintainer confirmation on the desired behavior before proceeding with a PR.

Thanks for the clarification. I agree that this could be intentional given the long-standing behavior. I’ll wait for maintainer confirmation on the expected behavior before proceeding with any PR

[lightning-sagar]

@sahillllllllll-bit, the issue has was already fixed asyncapi/html-template#757, so I think you can close the issue

[sahillllllllll-bit]

@sahillllllllll-bit, the issue has was already fixed asyncapi/html-template#757, so I think you can close the issue

Thanks for the clarification. Closing this issue since the fix has already been released in the Generator