Generator do not handle template params that default to `false`

[derberg]

checked with latest 3.3.1

Problem might be in https://github.com/asyncapi/generator/blob/master/apps/generator/lib/templates/config/loader.js#L47. Tests should be checked for loadDefaultValues.

in html-template config https://github.com/asyncapi/html-template/blob/master/package.json#L90-L93 singleFile default is false. So if you do not pass this parameter, false value should be injected with context into generation process.

This false default value is critical for another setting (conditional generation): https://github.com/asyncapi/html-template/blob/master/package.json#L63-L75 which means that required css and js folders will be rendered in output only fi singleFile is set to false.

asyncapi generate fromTemplate test/spec/asyncapi_v3.yml ./ -o dupa --use-new-generator --force-write -p singleFile=false works as expected, false goes through, so directories are there. Of course flah singleFile=true works as well.

---

Problem is that during generation in case like asyncapi generate fromTemplate test/spec/asyncapi_v3.yml ./ -o dupa --use-new-generator --force-write the template gets singleFile as undefined (doesn't get it at all). I can only see the following defaults

{
  "outFilename": "index.html",
  "pdfTimeout": 30000
}

So there is for sure a bug in generator, it is not handling default values set to false

Originally posted by @derberg in #744

[dosubot[bot]]

The bug is in the generator's loadDefaultValues function, which filters parameters by checking if their default value is truthy. This means any parameter with a default value of false (like singleFile in html-template) is skipped and not injected into the generation context when omitted, resulting in undefined instead of false during template rendering. This breaks conditional logic that relies on the default being present, such as rendering CSS/JS folders in html-template when singleFile is false source.

To fix this, the filtering logic should be changed to check if the default is defined (e.g., parameters[key].default !== undefined) rather than relying on truthiness. This ensures that false defaults are correctly injected.

Current unit tests for loadDefaultValues do not cover the scenario where a default false value should be injected when the parameter is omitted; adding such a test would help prevent regressions source.

Until this is fixed, the workaround is to explicitly pass --param=singleFile=false (or true) during generation to ensure the correct behavior.

To reply, just mention @dosu.

---

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

   

[lightning-sagar]

Working on it!!🫡

[VIVEKDHEDHI021]

Thanks for the detailed explanation. I can confirm this issue as well. The generator currently fails to load template parameters whose default value is false, which causes the HTML template to behave incorrectly when singleFile isn’t explicitly passed.

During generation, the template context only contains:

{ "outFilename": "index.html", "pdfTimeout": 30000 } The expected singleFile: false value is missing entirely. This leads to incorrect conditional rendering, since the template logic relies on: {{#unless singleFile}} // render css/js folders {{/unless}} Because singleFile becomes undefined instead of false, required folders are not created.

The root cause seems to be in config/loader.js where default values are applied using a truthy check. As a result, any default set to false is ignored. Updating this logic to explicitly check for undefined (e.g., param.default !== undefined) should resolve the issue.

Explicitly passing parameters (e.g., -p singleFile=false) works correctly, so the bug is isolated to default handling.

Happy to help test any fix or PR for this.

I hope this suggestion adds value and helps the generator work more reliably for all template users. If you want, I can tailor one specifically for your exact comment.

[lightning-sagar]

yup, you guys are correct, both of them were right about the root cause. the default value check was skipping parameters with default: false, so singleFile was never injected into the template context

it took a bit of debugging to trace it properly, but the fix was straightforward: updated the condition to use default !== undefined instead of a truthy check.