-
-
Notifications
You must be signed in to change notification settings - Fork 99
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
refactor: update Readme.md v1 #601
refactor: update Readme.md v1 #601
Conversation
But we don't have such a link in this file, lol 😆 |
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.
Looks pretty good! Just some minor changes.
asyncapi: '2.4.0' | ||
info: | ||
title: Example AsyncAPI specification | ||
version: '0.1.0' | ||
channels: | ||
example-channel: | ||
subscribe: | ||
message: | ||
payload: | ||
type: object | ||
properties: | ||
exampleField: | ||
type: string | ||
exampleNumber: | ||
type: number | ||
exampleDate: | ||
type: string | ||
format: date-time | ||
`); |
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 example is not valid to Spectral because of this rule asyncapi-operation-operationId
: https://github.com/stoplightio/spectral/blob/297531bbc6f26393d325a101b59f9e8b1f57e21e/packages/rulesets/src/asyncapi/index.ts#L230-L240
Not sure if we really want to keep that rule there. The operationId
is not mandatory by the spec.
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.
I know about some "problems" with Spectral. Now I would leave that spec, because at the end operationId
won't be mandatory on Spectral side, don't worry.
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.
Do you mean that particular spectral rule will be gone? Could you bring more details, please?
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.
Changed will be severity from error to warning - then there will be information that it is a good pattern design. Most of the rules from Spectral were made 2 years ago by the Stoplight team itself and a lot of things are not up to date. This week I have a plan to go through all the rules and improve 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.
Changed will be severity from error to warning
That makes totally sense to me. I have few concerns regarding this but I'm not gonna add anything extra into this issue, but rather please ping me on the work you plan to do 🙏
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.
I will create PR with that in Spectral side, so maybe better will be if you will list everything bugs that you see, hmm?
Co-authored-by: Sergio Moya <[email protected]>
Kudos, SonarCloud Quality Gate passed! |
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.
LGTM!
/rtm |
Description
Update Readme.md with informations:
custom parsers
sectionstringify
sectiondevelop
sectionOther section will be updated in next PRs.
cc @smoya
Related issue(s)
Part of #481
Part of #482