-
-
Notifications
You must be signed in to change notification settings - Fork 255
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add option to support override-ready paths in Spectral diagnotsics #2770
Comments
Another option is to add a
mean, so only adding to JSON will meet the need without getting too complex. |
I tried to work on a PR to address this in |
@DavidBiesack We could potentially add the json pointer to the CLI output under the verbose flag. We don't think it requires a new formatter as the goal with formatters is a different formatting for the output depending on where its being used. Would you mind taking a stab at creating a PR based on that? If not, we'll add it to the list of enhancements. |
Thank you @mnaumanali94 - I will try to submit a PR for this. Thank you! |
@mnaumanali94 I'm on MacOS and have yarn 3.5.0
|
User story.
As a Spectral user, I can use a command line option so that the locations in Spectral's error/warning/information diagnostics use the same notation/syntax as the
overrides/files
notation in a Spectral ruleset.Is your feature request related to a problem?
It is tedious and error prone to manually specify the
files
locations in ruleset overrides.The diagnostics emitted by Spectral use one format that differs from that used in a ruleset.
I.e. for the Redocly Museum sample OpenAPI
and the
oas
and Spectral OWASP ruleset, Spectral emits many diagnostics, such asIf one wanted to add an override for a specific instance (not just disable the entire rule), one must "map" the path notation
paths./special-events/{eventId}.get.responses
toDescribe the solution you'd like
Add a command line option so that the Spectral output uses the notation required for the ruleset overrides
Such as
Additional context
Note that the new location should use the relative file location, not the absolute file location that Spectral emits when processing a file, since ruleset files normally use relative
files
file paths (i.e. relative to the current directory when running thespectral
CLI)The text was updated successfully, but these errors were encountered: