Different result for a given spec/rule than spectral

[ajoga]

Hello,

This rule does not raise with vacuum v0.5.0 while Spectral correctly raises an issue: https://github.com/andylockran/spectral-aws-apigateway-ruleset/blob/62d912f7da7f5a5291c7a6d438d9d527b8001deb/aws_important_notes.yml#L28-L36

against this test spec:

openapi: "3.0.0"
info:
  version: 1.0.0
  title: Swagger Petstore
  license:
    name: MIT
servers:
  - url: http://petstore.swagger.io/v1
paths:
  /pets:
    get:
      summary: List all pets
      operationId: listPets
components:
  schemas:
    Pet:
      type: object
      properties:
        id:
          type: integer
          format: int64
    __invalidname__:
      type: object
      properties:
        id:
          type: integer
          format: int64

Spectral:

The culprit seems to be the "field: "@key"" ; my experience is not strong enough to understand if this is Vacuum that misses something or if spectral is too permissive and the rule was poorly written to begin with

[daveshanley]

Hi There,

Yeah, there is no concept of @key in vacuum, this is why it's not passing.

This is an example I pulled from that spectral ruleset:

Spectral version

aws-model-names:
    description: 'Model names can only contain alphanumeric characters.'
    given: $.components.schemas
    severity: error
    then:
      field: "@key"
      function: pattern
      functionOptions:
        match: "^[A-Za-z0-9]+$"

vacuum version

aws-model-names:
    description: 'Model names can only contain alphanumeric characters.'
    given: $.components.schemas
    severity: error
    then:
      function: pattern
      functionOptions:
        match: "^[A-Za-z0-9]+$"

The solution? just delete the key from the rule, vacuum will figure out what to do, it can tell that $.components.schemas is an array or a map.