[AsyncAPI] Identify more orphaned components besides schemas

[nulltoken]

In #974, the asyncapi ruleset has been initiated with a rule which will identify unused/orphaned schemas, under components.

As identified in #1073 this rule could really benefit from being extended to be able to detect other kinds of orphan objects (messageTraits, ...).

/cc @derberg

[jonaslagoni]

I have/plan to create sub-issues for solving this issue, it is based on the available components in https://www.asyncapi.com/docs/specifications/v2.3.0#componentsObject.

List of sub-issues:

• servers - https://github.com/stoplightio/spectral/pull/2097
• channels - https://github.com/stoplightio/spectral/issues/2098
• messages - TODO
• securitySchemes - TODO
• parameters - TODO
• correlationIds - TODO
• operationTraits - TODO
• messageTraits - TODO
• serverBindings - TODO
• channelBindings - TODO
• operationBindings - TODO
• messageBindings - TODO

[jonaslagoni]

Before adding the rest of the issues, a thought came to mind. Do we want all of these checks as part of one rule or split into multiple, as it seems https://github.com/stoplightio/spectral/pull/1440/files introduced 🤔

Or asked another way, have you folks seen a reason why someone might want to only check some of the components instead of all?

cc @P0lip

[jonaslagoni]

cc @magicmatatjahu @smoya

[magicmatatjahu]

I wa surprised that a rule was made that only checks for one type of component (I have in mind that PR with servers). I would prefer to go the way it is done in OpenAPI (as you mentioned) - one rule for all types of components.

[jonaslagoni]

Alright, let's keep it consistent then.