Parser should return all errors

[magicmatatjahu]

Maybe the title is not clear, but I will try to explain it in the description.

At the moment parser returns only particular errors related to stage of parsing. What does it mean? If we have broken specification in point of view JSON Schema, then parser returns errors only from ajv. If user will fix them, then can have another errors related to our custom validators like validation of channel parameters. But there is an another problem. When we have several errors, e.g., invalid server's variables and channel's parameters, we only return the errors for one validator - we don't collect them and return as array of errors. So user will end with ajv errors -> server's variables -> channel's parameters and next errors are displayed after resolving the previous ones. It's not a good in DX terms. He/she must run parser several times.

My idea: we should return all errors including ajv and from custom validators. If some part of spec is broken and we cannot run custom validator for this part, we can skip it, but if it's valid we should execute the validator.

Any other idea?

[github-actions]

This issue has been automatically marked as stale because it has not had recent activity 😴
It will be closed in 60 days if no further activity occurs. To unstale this issue, add a comment with detailed explanation.
Thank you for your contributions ❤️

[github-actions]

This issue has been automatically marked as stale because it has not had recent activity 😴

It will be closed in 120 days if no further activity occurs. To unstale this issue, add a comment with a detailed explanation.

There can be many reasons why some specific issue has no activity. The most probable cause is lack of time, not lack of interest. AsyncAPI Initiative is a Linux Foundation project not owned by a single for-profit company. It is a community-driven initiative ruled under open governance model.

Let us figure out together how to push this issue forward. Connect with us through one of many communication channels we established here.

Thank you for your patience ❤️

[magicmatatjahu]

Related issue - #119

[github-actions]

This issue has been automatically marked as stale because it has not had recent activity 😴

It will be closed in 120 days if no further activity occurs. To unstale this issue, add a comment with a detailed explanation.

There can be many reasons why some specific issue has no activity. The most probable cause is lack of time, not lack of interest. AsyncAPI Initiative is a Linux Foundation project not owned by a single for-profit company. It is a community-driven initiative ruled under open governance model.

Let us figure out together how to push this issue forward. Connect with us through one of many communication channels we established here.

Thank you for your patience ❤️

[github-actions]

This issue has been automatically marked as stale because it has not had recent activity 😴

It will be closed in 120 days if no further activity occurs. To unstale this issue, add a comment with a detailed explanation.

There can be many reasons why some specific issue has no activity. The most probable cause is lack of time, not lack of interest. AsyncAPI Initiative is a Linux Foundation project not owned by a single for-profit company. It is a community-driven initiative ruled under open governance model.

Let us figure out together how to push this issue forward. Connect with us through one of many communication channels we established here.

Thank you for your patience ❤️

[magicmatatjahu]

Still valid. It will be resolved in v2 version.

[magicmatatjahu]

Issue is resolved in v2 ParserJS - now in https://github.com/asyncapi/parser-js/tree/next-major branch