feat: add validation and descriptive errors to QueryParamsVariables

[Jatin24062005]

Description

This PR introduces the first step toward a consistent error-handling pattern inside @asyncapi/generator-components.

Implemented proper validation and clear error messages in the QueryParamsVariables component.
Previously, unsupported language or framework values resulted in deep runtime failures or confusing stack traces.
With this update, the component now fails early with descriptive and actionable errors, improving the developer experience for template authors.

This PR serves as a demonstration of the proposed error-handling approach that can be extended to the rest of the components.
Issue-: #1712

Related issue(s)
See also: Issue: #1712

Summary by CodeRabbit

• Bug Fixes
  • Improved error handling and validation for language and framework configurations.
  • Enhanced error messages to clearly communicate supported options when an unsupported configuration is detected.
  • Ensured framework-specific configurations are properly resolved and validated.

_{✏️ Tip: You can customize this high-level summary in your review settings.}

[changeset-bot]

⚠️ No Changeset found

Latest commit: 95ecd04

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]

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]

Walkthrough

This PR enhances the resolveQueryParamLogic function in QueryParamsVariables.js by adding comprehensive validation and error handling. It implements language validation with descriptive errors, introduces framework-aware resolution logic that maps languages to framework-specific configurations, and adds JSDoc documentation without altering public exports.

Changes

Cohort / File(s)	Summary
Logic validation and error handling packages/components/src/components/QueryParamsVariables.js	Adds language and framework validation with error messages listing supported options, implements framework-aware resolution that returns framework-specific configs when available, adds explicit error handling for unsupported or missing frameworks, and introduces JSDoc documentation blocks.

Estimated code review effort

🎯 3 (Moderate) | ⏱️ ~20 minutes

• The validation logic and error message generation for supported languages/frameworks may need verification to ensure completeness
• Framework-aware resolution mapping should be reviewed to confirm correct framework selection and config handling
• Error messages should be validated for clarity and usefulness to end users

Possibly related PRs

• refactor: move QueryParamsVariables component to @asyncapi/generator-components #1709: Modifies the same resolveQueryParamLogic function; this PR extends its implementation with additional validation and framework-aware resolution capabilities.

Pre-merge checks and finishing touches

✅ Passed checks (3 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Docstring Coverage	✅ Passed	Docstring coverage is 100.00% which is sufficient. The required threshold is 80.00%.
Title check	✅ Passed	The title 'feat: add validation and descriptive errors to QueryParamsVariables' accurately and specifically summarizes the main changes in the pull request—adding validation and error handling to the QueryParamsVariables component.

✨ Finishing touches

• 📝 Generate docstrings

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Post copyable unit tests in a comment

---

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

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[Adi-204]

@Jatin24062005 You’ve added error handling in a single component, but the issue is more widespread than that. This isn’t really a beginner-level problem. If you still want to work on it, I’d recommend first researching in detail how we can implement a DRY approach—perhaps by centralizing error handling through shared helpers or a common abstraction.

Given the current state, I’m closing this PR for now.

[Jatin24062005]

@Adi-204 Thanks for reviewing this. I think I can really work on this, and it’s not that tough from a research perspective, as you mentioned. Could you please share any reference documentation related to this so I can move forward? Alternatively, you could provide a brief blueprint or high-level overview of how I should proceed.

My approach isn’t wrong, but I think it’s not very efficient right now because a single component is being used in the file. If you could help guide me on how to move forward, I’d really appreciate it. Also, this is a demo PR, as I mentioned earlier in the issue comments.