feat: validate unparsed AsyncAPI document #720
Conversation
magicmatatjahu
requested review from
fmvilas,
jonaslagoni,
derberg and
asyncapi-bot-eve
as code owners
|
@jonaslagoni Could you check? |
There was a problem hiding this comment.
I guess I dont understand why we don't change the parsing logic to validate before resolving references, and then again after? This fix looks like an incorrect approach to take 🤔 Or is there some underlying reason?
Related to #405
| }, | ||
| errors: [ | ||
| { | ||
| message: 'Referencing in this place is not allowed', |
There was a problem hiding this comment.
Why is this needed? Is it not caught by the spec-schema?
| }, | ||
| errors: [ | ||
| { | ||
| message: 'Referencing in this place is not allowed', |
There was a problem hiding this comment.
Why is this needed? Is it not caught by the spec-schema?
Spectral resolver (and other json-schema resolvers) doesn't validate the json-schema but only resolve it. Also AJV try to validate the spec based on json-schema and that's the problem. After referencing we don't know if |
|
Ahh shit, validation happens through spectral now, yea then you can't do a simple double validation once before refs are resolved and once after... Right? |
this is what I do 😄 underneath is AJV and JSON Schema validation. |
|
Kudos, SonarCloud Quality Gate passed!
|
|
/rtm |
|
🎉 This PR is included in version 2.0.0-next-major.15 🎉 The release is available on: Your semantic-release bot 📦🚀 |
Description
Validate unparsed AsyncAPI document (before
$refs resolving).