Teach ruleset yaml parser to support yaml anchors/merge keys

Describe the bug The following yaml rule with anchor does not validate correctly

To Reproduce

1. Go to online spectral parser
2. paste the content of the following rules

rules:
  no-x-headers-request: &no-x-headers
    description: "All 'HTTP' headers SHOULD NOT include 'X-' headers (https://tools.ietf.org/html/rfc6648)."
    severity: warn
    given:
      - "$..parameters[?(@.in == 'header')].name"
    message: |-
      HTTP header '{{value}}' SHOULD NOT include 'X-' prefix in {{path}}
    recommended: true
    type: style
    then:
      function: pattern
      functionOptions:
        notMatch: "/^[xX]-/"
  no-x-headers-response:
    <<: *no-x-headers
    given:
      - $.[responses][*].headers.*~
    message: |-
      HTTP header '{{value}}' SHOULD NOT include 'X-' prefix in {{path}}

1. See error

/rules/no-x-headers-response should have required property 'then'

Expected behavior No errors

Environment (remove any that are not applicable):

• Version: spectral 5.1.0

[P0lip]

@ioggstream I just wanted to let you know 5.6.0 is out with the support for YAML merge keys inside of rulesets.

[P0lip]

Faster: true (but on rule files I suspect the difference is minimal)

It depends, since we have these huge OAS2 and OAS3 JSON schemas referenced in our ruleset, so the impact might be a bit higher than it may seem. Moreover, the AsyncAPI ruleset references the AsyncAPI JSON schema which is not small either. Either way, shouldn’t be a big deal to use yaml everywhere.

Safer: not sure as the attacker controls the filename extension.

yeah, sure. Agreed.

Thanks again! This will DRY rule files where the same rule should be applied - with different error messages - to request parameters and response fields.

You are welcome. If there is any other spot that does not support merge keys, do let me know. We should be supporting them almost everywhere now.