-
-
Notifications
You must be signed in to change notification settings - Fork 240
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Ruleset: AsyncAPI #974
Ruleset: AsyncAPI #974
Conversation
ccac9a2
to
3ddd35a
Compare
83cdc4a
to
d8006df
Compare
c351478
to
40234f9
Compare
@philsturgeon Few questions:
@P0lip @philsturgeon Next steps:
|
@nulltoken the commented out ones were things I didn't delete or make work. I deleted some things which were definitely not worth trying to port over, and left in some things I hadn't researched. If those rules are relevant lets get them working, if they are not we can delete them.
A little bit of duplication is ok for now, I'd rather get it working than spend a bunch of time on DRYing it prematurely. |
@nulltoken the commented out ones were things I didn't delete or make work. I deleted some things which were definitely not worth trying to port over, and left in some things I hadn't researched. If those rules are relevant lets get them working, if they are not we can delete them.
A little bit of duplication is ok for now, I'd rather get it working than spend a bunch of time on DRYing it prematurely. |
a1e8cba
to
6429157
Compare
05e9e50
to
be2be40
Compare
Dear Diary, At last! Back in the world of CI green. Pretty relieved! Suffered a lot in Karma land and weird execution of jest BeforeAll() test hooks. Had to switch over to BeforeEach(). A bit of a waste as we keep on rebuilding something which is supposed to be immutable, but, at least... it works. |
|
||
### asyncapi2-channel-no-query-nor-fragment | ||
|
||
Query parameters and fragments shouldn't be used in channel names. Instead, use bindings to define them. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can we get some examples?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@philsturgeon I'm afraid I won't be able to come up with a good/bad example that would make sense in an AsyncAPI context.
@fmvilas Could you please help me here? What's the known bad practices regarding query and fragments and how should they be converted to bindings?
docs/reference/asyncapi-rules.md
Outdated
Spectral currently only supports payload validation against the default AsyncAPI schema. | ||
|
||
This rule will notify you when a payload is decorated with a `schemaFormat` property. Spectral won't be able to validate it and potential issues in this payload will go undetected by the `asyncapi-payload-*` rules. | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Let's go with something like....
AsyncAPI can support various schemaFormat
values, with the default being one of the following:
application/vnd.aai.asyncapi;version=2.0.0
application/vnd.aai.asyncapi+json;version=2.0.0
application/vnd.aai.asyncapi+yaml;version=2.0.0
At this point no other schemaFormat's are supported by Spectral, so if you use them this rule will emit an info
message and skip validating the payload.
Other formats such as OpenAPI Schema Object, JSON Schema Draft 07 and Avro will be added in various upcoming versions.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@philsturgeon Awesome! I've slightly reworded your proposal (as we don't support setting the schemaFormat
at all).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@nulltoken with those few changes done this is all thumbs from me! When you and @P0lip are happy merge away and let's get a beta out for people to play with! 🥳
import { IFunction, IFunctionContext } from '../types'; | ||
import { IFunctionResult } from '../types/function'; | ||
|
||
import * as asyncApi2Schema from '../rulesets/asyncapi/schemas/schema.asyncapi2.json'; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This could be provided in a ruleset as a function option?
40cb464
to
ab947a0
Compare
@philsturgeon Thanks a lot for the feedback. @P0lip What's your thinking Sir? |
|
||
import { IFunction, IFunctionResult } from '../types'; | ||
import { getLintTargets } from '../utils'; | ||
import { schema } from './schema'; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We don't need to import it.
return validator; | ||
}; | ||
|
||
export const asyncApi2PayloadValidation: IFunction<IPayloadValidationOptions> = ( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
export const asyncApi2PayloadValidation: IFunction<IPayloadValidationOptions> = ( | |
export function asyncApi2PayloadValidation = ( | |
this: IFunctionContext, | |
// ..rest of args |
paths, | ||
otherValues, | ||
) => { | ||
const ajvValidationFn = buildAsyncApi2SchemaObjectValidator(schema); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
const ajvValidationFn = buildAsyncApi2SchemaObjectValidator(schema); | |
const ajvValidationFn = buildAsyncApi2SchemaObjectValidator(this.functions.schema); |
const results: IFunctionResult[] = []; | ||
|
||
for (const relevantItem of relevantItems) { | ||
const path = rootPath.slice(0); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
How about?
const path = rootPath.slice(0); | |
const path = [...rootPath, ...relevantItem.path] |
const path = rootPath.slice(0); | ||
Array.prototype.push.apply(path, relevantItem.path); | ||
|
||
const result = schema( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
const result = schema( | |
const result = this.functions.schema( |
) => { | ||
const ajvValidationFn = buildAsyncApi2SchemaObjectValidator(schema); | ||
|
||
const relevantItems = getLintTargets(targetVal, opts.field); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just for the clarity, we've discussed this one on slack - this should not be needed, since runner
already handles it for us.
Dang, hit the button too late. 😆 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
One last comment.
Looks good from my point of view.
src/rulesets/reader.ts
Outdated
// happens | ||
} | ||
return opts; | ||
return { result: parse(opts.result) }; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If I am not mistaken, we should return original options.
I suggest not touch it unless it's needed?
Fixes #965
Fixes #789
Checklist
asyncApi2PayloadValidation
to a custom function of the rulesetDoes this PR introduce a breaking change?
Screenshots
If applicable, add screenshots or gifs to help demonstrate the changes. If not applicable, remove this screenshots section before creating the PR.
Additional context
Add any other context about the pull request here. Remove this section if there is no additional context.