Support AsyncAPI linting using Spectral

[pjungermann]

Is your feature request related to a problem? Please describe.
A clear and concise description of what the problem is. Ex. I'm always frustrated when […]

Currently, AsyncAPI definitions are not ignored/not linted by Spectral.

Describe the solution you'd like
A clear and concise description of what you want to happen.

There is a linter OPENAPI_SPECTRAL with the config file .openapirc.yml.
The default file shipped with MegaLinter contains

extends: spectral:oas

However, Spectral supports OpenAPI and AsyncAPI.

extends:
  - spectral:asyncapi
  - spectral:oas

could be used to validate both.

The recommended naming for the config file is .spectral.yaml according to their documentation.

However, the linter is called OPENAPI_SPECTRAL which sets the scope to OpenAPI only.

Similar to others like prettier, we could add an additional linter ASYNCAPI_SPECTRAL.
Either with a config file .asyncapirc.yml or using a shared config file .spectral.yaml as default.

Changing the default config filename would be fine as long as there is some backward compatibility
to custom .openapirc.yml files with repos.

Describe alternatives you've considered
A clear and concise description of any alternative solutions or features you've considered.

Additional context
Add any other context or screenshots about the feature request here.

[nvuillam]

@pjungermann would it just work if we update default config file shipped with MegaLinter ?

If not, we could also update the doc to tell to override the config file name using variable OPENAPI_SPECTRAL_CONFIG_FILE

Would you like to make a PR ? :)

[pjungermann]

@nvuillam updating the config file would be a viable option (+ updating docs).

1. reuse same linter and config file
2. separate linter
   1. separate config files (users could override it if they want to use one for both)
   2. shared config file
      1. stick to current file name
      2. use filename as of Spectral's docs

Based on the setup for other linters, I assumed there might be a preference for ASYNCAPI_SPECTRAL.

I'm willing to provide a PR. Before, I wanted to find out the right solution for this project.

[nvuillam]

@pjungermann I would prefer the option where OPENAPI_SPECTRAL can handle sync + async APIs ^^

Ypu could rename the default config file as .spectral.yml, and put the mixed config in default content

extends:
  - spectral:asyncapi
  - spectral:oas

Semantically, OPENAPI_SPECTRAL would analyze openapi + asyncapi , but i wouldn't like to create a new descriptor for each new capability

Another solution might be to deprecate OPENAPI descriptor and create a new descriptor API that would contain API_SPECTRAL, but in my opinion that's not mandatory

[pjungermann]

I like the idea of changing OPENAPI to API as linter grouping 👍

I will have a look at preparing the necessary changes.

[nvuillam]

@pjungermann great :)

In order to ensure compatibility until the next major release (usually once a year), please do not remove the openapi descriptor, just add deprecated and create a new api descriptor aside :)

[github-actions]

This issue has been automatically marked as stale because it has not had recent activity.
It will be closed in 14 days if no further activity occurs.
Thank you for your contributions.

If you think this issue should stay open, please remove the O: stale 🤖 label or comment on the issue.

[pjungermann]

not stale