`invalid-ref` errors when components use `!!` yaml syntax

[barrett-schonefeld]

Describe the bug

When API definition is a yaml document with !! syntax to identify the type of the value (!!bool "false", for example), Spectral returns invalid-ref errors even when the refs are valid. It is likely that the underlying yaml parser does not understand this syntax.

To Reproduce

1. Given this OpenAPI/AsyncAPI document:

   "openapi": "3.0.0"
   "paths":
       "/":
           "get":
               "operationId": "getObject"
               "responses":
                   "200":
                       "$ref": "#/components/responses/Object"
                   "default":
                       "description": "error response"
                       "content":
                           "application/json":
                               "schema":
                                   "$ref": "#/components/schemas/Error"
               "summary": "Retrieve object"
   "components":
       "responses":
           "Object":
               "description": "object response"
               "content":
                   "application/json":
                       "schema":
                           "$ref": "#/components/schemas/Object"
       "schemas":
           "Error":
               "additionalProperties": !!bool "false"
               "description": "Error schema"
               "properties":
                   "error":
                       "description": "The name of the error."
                       "type": "string"
               "type": "object"
           "Object":
               "additionalProperties": !!bool "false"
               "description": "Object schema."
               "properties":
                   "prop1":
                       "type": "string"
               "type": "object"

2. Run spectral lint

3. See invalid-ref error

Expected behavior

I would expect that the refs are resolved properly even when !! syntax is used.

[P0lip]

Hey @barrett-schonefeld!

It is likely that the underlying yaml parser does not understand this syntax.

I confirm your finding. We indeed do not resolve the tag properly, and the value we work on is a string scalar "false" instead of the boolean.