search

stoplightio / spectral

A flexible JSON/YAML linter for creating automated style guides, with baked in support for OpenAPI (v3.1, v3.0, and v2.0), Arazzo v1.0, as well as AsyncAPI v2.x.
https://stoplight.io/spectral
Apache License 2.0
2.47k stars 233 forks source link

Request for feedback: Using custom rulesets with Spectral CLI #127

Closed tbarn closed 5 years ago

tbarn commented 5 years ago

Request for feedback!

We would love to hear from users what syntax you would like to used -- please comment with your feedback!

I'm submitting a...

feature request

What is the current behavior?

Currently, the CLI detects if you are using a OpenAPI 2 or 3 based document and uses the default rulesets. No specifications or rulesets outside of that works with it.

What is the expected behavior?

You have the ability to use any custom ruleset when using the Spectral CLI.

One potential syntax could be:

spectral lint foo.yaml --ruleset=whatever.json --ruleset=advanced.js

What is the motivation / use case for changing the behavior?

One of the things that makes Spectral so great is the ability to build out custom rulesets, which can already be done now, but not in the CLI.

Other information

We are also exploring adding a ESLint or TSLint like config file (i.e. .spectralrc) with all the plugins/rules/presets setup. Current plan is that this would come after adding the custom ruleset option to the CLI.

philsturgeon commented 5 years ago

One idea: An OpenAPI extension to check for application/problem+json responses and make sure they actually conform to RFC 7807.

tbarn commented 5 years ago

@philsturgeon how would it work to have two different rulesets apply?

philsturgeon commented 5 years ago

I wrote a feature into speccy where one ruleset could require another: https://github.com/wework/speccy/blob/master/rules/strict.yaml

That made requiring multiple rulesets fairly simple:

https://github.com/wework/speccy/blob/master/lib/loader.js#L153

It would just grab all the ones you list, and all their dependencies, then unique up the rules. Anything with the same name would be overridden with whatever came in last, which is probably fine. IF it becomes and issue we can implement a clash detection feature.

erunion commented 5 years ago

Being able to supply custom rulesets through the CLI would be wonderful because having to dig through the source to get access to stylish and running that manually isn't great.

philsturgeon commented 5 years ago

@erunion hey I understood the first half of the message but got a bit confused when you mentioned stylish. Rulesets are files containing rules, and stylish is what we call a formatter. Custom formatters would be nice one day, but this is about rulesets. Does that make sense?

erunion commented 5 years ago

Sorry! It would be nice to be able to supply a custom ruleset directly to the CLI because that would allow you to take advantage of the automatic formatters that the CLI offers. Instead, right now, to supply a custom ruleset, I have to deal with the formatters manually in order to get a non-JSON readable format.

philsturgeon commented 5 years ago

Riiiiight I gotcha, absolutely. The CLI is new and needs to catch up with the JS library for sure. It’ll be coming very soon. Nobody has raised any concerns with the approach I mentioned so I think it’s going to be that?

tbarn commented 5 years ago

@erunion would you be down to test our solution for this?

erunion commented 5 years ago

@tbarn Absolutely!

philsturgeon commented 5 years ago

@chris-miaskowski is working on the implementation for this over here #144. Let's discuss details over there.

philsturgeon commented 5 years ago

This was done a while back, we just forgot to close the issue somehow :D