feat(rulesets): support 2.1.0, 2.2.0, 2.3.0 AsyncAPI versions #2067
Conversation
magicmatatjahu
force-pushed
the
support-latest-asyncapi
branch
from
ca8f87b
to
78885c5
Compare
|
Thanks a bunch for the PR. I truly appreciate it.
Hmmm, that is odd. It did work on the CI though, so everything's good. |
| @@ -17,6 +17,13 @@ __metadata: | |||
| languageName: node | |||
| linkType: hard | |||
|
|
|||
| "@asyncapi/specs@npm:^2.13.0": | |||
There was a problem hiding this comment.
so good to see that schema.asyncapi2.json disappear ❤️
|
@P0lip Thanks for quick response!
No problem, no rush :) If something will be wrong (like duplicated functions) please comment and I will handle that.
I see that on CI it pass so probably it's env problems. |
|
How to test that? It wasn't working for me. I tried: A rules file: extends: "spectral:asyncapi"I just copied the sample from https://studio.asyncapi.com/: asyncapi: '2.3.0'
info:
title: Streetlights Kafka API
version: '1.0.0'
description: |
The Smartylighting Streetlights API allows you to remotely manage the city lights.
...Then I get the error: A simple solution is to correct the file |
|
@muenchhausen Hello! I tested in this way (you need to checkout to this branch):
I have these errors for simple AsyncAPI file (based on I also tested this https://raw.githubusercontent.com/asyncapi/spec/master/examples/streetlights-kafka.yml and it also works :) |
| function shouldIgnoreError(error: ErrorObject): boolean { | ||
| return ( | ||
| // oneOf is a fairly error as we have 2 options to choose from for most of the time. | ||
| error.keyword === 'oneOf' || | ||
| // the required $ref is entirely useless, since aas-schema rules operate on resolved content, so there won't be any $refs in the document | ||
| (error.keyword === 'required' && error.params.missingProperty === '$ref') | ||
| ); | ||
| } | ||
|
|
||
| // this is supposed to cover edge cases we need to cover manually, when it's impossible to detect the most appropriate error, i.e. oneOf consisting of more than 3 members, etc. | ||
| // note, more errors can be included if certain messages reported by AJV are not quite meaningful | ||
| const ERROR_MAP = [ | ||
| { | ||
| path: /^components\/securitySchemes\/[^/]+$/, | ||
| message: 'Invalid security scheme', | ||
| }, | ||
| ]; | ||
|
|
||
| // The function removes irrelevant (aka misleading, confusing, useless, whatever you call it) errors. | ||
| // There are a few exceptions, i.e. security components I covered manually, | ||
| // yet apart from them we usually deal with a relatively simple scenario that can be literally expressed as: "either proper value of $ref property". | ||
| // The $ref part is never going to be interesting for us, because both aas-schema rules operate on resolved content, so we won't have any $refs left. | ||
| // As you can see, what we deal here wit is actually not really oneOf anymore - it's always the first member of oneOf we match against. | ||
| // That being said, we always strip both oneOf and $ref, since we are always interested in the first error. | ||
| export function prepareResults(errors: ErrorObject[]): void { | ||
| // Update additionalProperties errors to make them more precise and prevent them from being treated as duplicates | ||
| for (const error of errors) { | ||
| if (error.keyword === 'additionalProperties') { | ||
| error.instancePath = `${error.instancePath}/${String(error.params['additionalProperty'])}`; | ||
| } | ||
| } | ||
|
|
||
| for (let i = 0; i < errors.length; i++) { | ||
| const error = errors[i]; | ||
|
|
||
| if (i + 1 < errors.length && errors[i + 1].instancePath === error.instancePath) { | ||
| errors.splice(i + 1, 1); | ||
| i--; | ||
| } else if (i > 0 && shouldIgnoreError(error) && errors[i - 1].instancePath.startsWith(error.instancePath)) { | ||
| errors.splice(i, 1); | ||
| i--; | ||
| } |
There was a problem hiding this comment.
most of that stuff could be indeed shared with the OAS ruleset, but we can do it later.
It's not a big deal for now.
|
@P0lip Thanks a lot! If there will be problems/bugs, please ping me in this thread :) We at AsyncAPI are thinking about moving (if you don't mind) all the rules related to AsyncAPI to our organization on github. That way, people could use the up-to-date ruleset for AsyncAPI and you wouldn't have to worry about maintaning AsyncAPI on your side. Here is the issue I created asyncapi/parser-js#477. Of course I don't give a word that we will do such a thing, we have to discuss it at our place first, but if we decided to do such a thing, would Stoplight have something against it? By the way, I'm currently testing a custom rules for more complex validations like binding validations, extensions etc and I'm delighted. Super project! |
|
@magicmatatjahu I'll let you know soon. I reached out to folks internally to see what their take on it is and will try to provide an update as soon as I learn anything.
Thanks! ❤️ We're really glad you like the project. |
# [@stoplight/spectral-formats-v1.1.0](https://github.com/stoplightio/spectral/compare/@stoplight/spectral-formats-v1.0.2...@stoplight/spectral-formats-v1.1.0) (2022-02-24) ### Features * **formats:** support 2.1.0, 2.2.0, 2.3.0 AsyncAPI versions ([#2067](#2067)) ([b0b008d](b0b008d))
# [@stoplight/spectral-rulesets-v1.5.0](https://github.com/stoplightio/spectral/compare/@stoplight/spectral-rulesets-v1.4.3...@stoplight/spectral-rulesets-v1.5.0) (2022-02-24) ### Features * **rulesets:** support 2.1.0, 2.2.0, 2.3.0 AsyncAPI versions ([#2067](#2067)) ([2f1d7bf](2f1d7bf))
After stoplightio#2067 I think this change was missed 🙂
Fixes #1759.
Checklist
Does this PR introduce a breaking change?
There're not a breaking changes but are some backward compatible named exports.
Additional context
This is my first contribution to this project (btw. awesome project!), so if I forgot something please let me know. I don't know if I should describe somewhere in the documentation the support for the latest versions of AsyncAPI, if so please let me know where.
Changes:
@asyncapi/specspackage where there are always up-to-date JSON Schemas.aas2_0,aas2_1etc.asyncApi2DocumentSchemarule identical as for OpenAPI to validate the document using the appropriate JSON Schema version - I know about duplicated code so please let me know if I should create something likecommon.tsfile with reusable functions for AsyncAPI and OpenAPI in therulesetspackage.NOTE:
I cannot run all tests locally, because I have several failed tests related to the
spectral-functionspackage like:Is a known issue, or perhaps it's related to my environment? 🤷🏼