Support per-format rulesets

[lornajane]

Is your feature request related to a problem? Please describe.

When I specify a ruleset in extends, such as recommended, it applies to all formats. I want to be able to apply recommended for OpenAPI and minimal for AsyncAPI.

Describe the solution you'd like

I'm actually not sure what would make sense here, since extends is an array. I'm open to suggestions and we should consider this alongside proposed changes in #1723 so they make sense together.

Per-format sections could work? Like the per-api sections, but different?

openapi-31:
  extends:
    - recommended
    - my-super-rules.yaml
  rules:
    security-defined: error

Describe alternatives you've considered

Changing extends completely to be an object.

extends:
  all:
    - minimal
  openapi-31:
     - recommended
  arazzo-10:
    - recommended-strict
    - spot

Another alternative:

• tell users who lint multiple formats not to use extends at all but to use the per-format rules sections and provide copy/paste versions of our built in rulesets for each format (this is the short-term solution whatever we decide) Additional context

From a conversation with @DmitryAnansky and @tatomyr about multi-format linting features.

[tatomyr]

When I specify a ruleset in extends, such as recommended, it applies to all formats.

Please note that it applies the rules according to the specification. For example, oas3_0Rules are applied only to OAS 3.0 API descriptions and so on.

tell users who lint multiple formats not to use extends at all but to use the per-format rules sections and provide copy/paste versions of our built in rulesets for each format

This is what I'd expect. Well, not exactly, but I'd expect to extend rules from something (either recommended, minimal, or a custom ruleset, e.g. defined in our cookbook), and then adjusting the particular rules severities. They can adjust separate rules severity for different specifications like this:

extends: 
- minimal
async2Rules:
  ...
oas3_1Rules:
  ...

If they want to reuse the same configuration later, they can simply extend from their new config.

[lornajane]

I know what you're trying to say but I really think this is a problem for some quite valid use cases where multiple API formats are used, maybe for different purposes. For example I can't configure:

• minimal ruleset for AsyncAPI
• recommended for OpenAPI 3.x
• no rules for OpenAPI 2.x, I'll just add a few myself for those older descriptions

Where the rule in the recommended set is valid for any format, it'll be applied. The custom rulesets are a bit easier because you can restrict the formats that the rule is exported for.

Another alternative that occurred to me since is to allow grouping APIs by something other than format, more like the functionality in the scorecard linting so your "Gold standard" APIs have one set of rules but all the descriptions used for internal warehouse integrations are at some other standard.