Skip to content

fix(validator): treat falsy values as valid template params (#2008)#2072

Open
armorbreak001 wants to merge 1 commit intoasyncapi:masterfrom
armorbreak001:fix/required-param-falsy
Open

fix(validator): treat falsy values as valid template params (#2008)#2072
armorbreak001 wants to merge 1 commit intoasyncapi:masterfrom
armorbreak001:fix/required-param-falsy

Conversation

@armorbreak001
Copy link
Copy Markdown

@armorbreak001 armorbreak001 commented Apr 22, 2026

Problem

Fixes #2008

In validator.js, required template parameters are validated with:

.filter(key => configParams[key].required && !templateParams[key]);

The !templateParams[key] check uses truthiness, which incorrectly treats these valid values as missing:

Value !value Should be missing?
undefined true ✅ Yes
null true ✅ Yes (arguably)
false true ❌ No!
0 true ❌ No!
'' (empty string) true ❌ No!

Fix

1 line change: !templateParams[key]templateParams[key] === undefined

Only truly undefined values are treated as missing required params.

Impact

  • Generators used programmatically can now pass false, 0, or '' as template param values
  • Template validation behavior matches developer intent
  • No breaking change — only makes the validator less strict (more correct)

Summary by CodeRabbit

  • Bug Fixes
    • Fixed parameter validation to properly recognize explicitly provided falsy values (such as false, 0, empty strings, and null) as valid for required parameters, preventing unnecessary validation errors.

…#2008)

Problem:  treats , ,  as missing
required parameters, causing false-positive validation errors.

Fix: Use  check instead of truthiness check.

Before: required param with value  → marked as missing ❌
After:  required param with value  → accepted ✅
@changeset-bot
Copy link
Copy Markdown

changeset-bot Bot commented Apr 22, 2026

⚠️ No Changeset found

Latest commit: 5452ed2

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
Copy Markdown
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
Copy Markdown

coderabbitai Bot commented Apr 22, 2026

📝 Walkthrough

Walkthrough

Modified the required parameter validation logic in validator.js to use strict undefined checking instead of falsy-checking. This enables required parameters to accept falsy values (e.g., false, 0, '', null) as valid provided inputs without triggering missing-parameter errors.

Changes

Cohort / File(s) Summary
Required Parameter Validation
apps/generator/lib/templates/config/validator.js
Changed parameter presence check from falsy-checking (!templateParams[key]) to strict undefined checking (templateParams[key] === undefined), allowing falsy values to be treated as provided.

Estimated code review effort

🎯 2 (Simple) | ⏱️ ~5 minutes

🚥 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 'fix:' prefix, clearly summarizes the change in imperative mood, and directly matches the changeset which corrects required parameter validation.
Linked Issues check ✅ Passed The pull request fully addresses all coding objectives from #2008: it replaces the falsy truthiness check with an explicit undefined comparison for required parameters.
Out of Scope Changes check ✅ Passed The single-line change in validator.js is directly scoped to fixing the required parameter validation logic as specified in #2008 with no extraneous modifications.
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

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.

@sonarqubecloud
Copy link
Copy Markdown

Copy link
Copy Markdown

@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

🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.

Inline comments:
In `@apps/generator/lib/templates/config/validator.js`:
- Line 78: Add Jest test cases in
apps/generator/test/templateConfigValidator.test.js that call
validateTemplateConfig (the function under test) with required parameters set to
falsy values to ensure they are accepted: add assertions that
validateTemplateConfig does not throw when a required param is provided as
false, 0, '', and null (in addition to the existing “missing” case), and keep
the existing configParams/templateParams setup so the missing-parameter
detection still only treats undefined as missing.
🪄 Autofix (Beta)

Fix all unresolved CodeRabbit comments on this PR:

  • Push a commit to this branch (recommended)
  • Create a new PR with the fixes

ℹ️ Review info
⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro

Run ID: fb32b841-26e9-49dc-b962-70bb07ded726

📥 Commits

Reviewing files that changed from the base of the PR and between 5c4b597 and 5452ed2.

📒 Files selected for processing (1)
  • apps/generator/lib/templates/config/validator.js

function isRequiredParamProvided(configParams, templateParams) {
const missingParams = Object.keys(configParams || {})
.filter(key => configParams[key].required && !templateParams[key]);
.filter(key => configParams[key].required && templateParams[key] === undefined);
Copy link
Copy Markdown

Choose a reason for hiding this comment

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

⚠️ Potential issue | 🟡 Minor

Add test coverage for falsy required-parameter values.

The fix correctly narrows the missing-parameter check to === undefined, which aligns with the PR objective and permits false, 0, '', and null as valid inputs. However, per the existing test at apps/generator/test/templateConfigValidator.test.js:68-80, only the "completely missing" case is covered. Without new tests, a future regression that reintroduces a truthiness check (or switches to == null, which would re-reject null) could silently slip through.

Consider adding cases that assert validateTemplateConfig does not throw when a required param is provided as false, 0, '', and null.

Also worth confirming explicitly: accepting null as "provided" is intentional here (the PR description says "arguably null"); the AI summary lists null among accepted values, so the current === undefined semantics match that intent.

Want me to draft the additional Jest cases for templateConfigValidator.test.js?

🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.

In `@apps/generator/lib/templates/config/validator.js` at line 78, Add Jest test
cases in apps/generator/test/templateConfigValidator.test.js that call
validateTemplateConfig (the function under test) with required parameters set to
falsy values to ensure they are accepted: add assertions that
validateTemplateConfig does not throw when a required param is provided as
false, 0, '', and null (in addition to the existing “missing” case), and keep
the existing configParams/templateParams setup so the missing-parameter
detection still only treats undefined as missing.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

[BUG] Required template parameter validation incorrectly treats falsy values as missing

2 participants