Teach ruleset yaml parser to support yaml anchors/merge keys

[ioggstream]

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}}

3. 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

[nulltoken]

@ioggstream Indeed, you're right. Document support merge keys... and teaching Spectral to also support merge keys/anchors in rulesets would be quite fair.

A quick look seems to indicate the culprit would be around this part of the code: https://github.com/stoplightio/spectral/blob/develop/src/rulesets/reader.ts#L18-L24

and maybe leveraging Yaml.parse() from https://github.com/stoplightio/spectral/blob/develop/src/parsers/yaml.ts would help us tackling this.

Would you feel like working on this, I'd be happy to support you.

[ioggstream]

@nulltoken I'll have a look. In the meantime, a question:

• as yaml is a superset of json, why do we need https://github.com/stoplightio/spectral/blob/develop/src/rulesets/reader.ts#L18-L21

[nulltoken]

@ioggstream Good call. We may not need to special case it. AFAIR the document reader always use the yaml parser whatever the document kind.

[P0lip]

as yaml is a superset of json, why do we need https://github.com/stoplightio/spectral/blob/develop/src/rulesets/reader.ts#L18-L21

It's much faster (and safer too).

Speaking of the issue, we need to pass mergeKeys here https://github.com/stoplightio/spectral/blob/develop/src/rulesets/reader.ts#L23

[ioggstream]

1- @P0lip thanks for the PR!

faster and safer
Faster: true (but on rule files I suspect the difference is minimal)
Safer: not sure as the attacker controls the filename extension.

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

[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.

[P0lip]

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