Open jstuckey opened 1 month ago
The spec explicitly says that the path item object supports $ref
while the operation object does not. I'm guessing that is why the setup I've described above is now considered invalid.
Still, the OpenAPI rendering tools I've used (Redoc, GitLab) handle this setup, and Spectral previously allowed it. It caught me off guard that our OpenAPI doc suddenly failed to lint.
Running into this issue as well. I think it is fair that $refs are resolved when determining if the contents of a schema are valid.
It makes using reusable servers, externalDocs, and other parts of OAS definitions standard and I don't want to disable that rule (as it is usually helpful :) )
I eventually bundle the OAS document, resolving these, but spectral is the initial linting tool to make sure we can bundle it all up.
If this was not set to "resolved": false, I believe the issue would have been avoided
Describe the bug
Using a
$ref
keyword under a path http verb started producing an error in version 1.19.0 of the spectral-rulesets package:This behavior is not present in spectral-rulesets 1.18.1 and earlier.
To Reproduce
paths: /foos: get: $ref: 'foo_request.yaml'
Expected behavior
Using version 1.18.1 of the spectral-rulesets package produces the expected behavior:
Environment (remove any that are not applicable):
Additional context
If I had to hazard a guess, I suspect this change to be the culprit: https://github.com/stoplightio/spectral/pull/2574