Running spectral 6.0.0 command without --ruleset CLI option fails

[DavidBiesack]

Describe the bug

Using 6.0.0 installed from the installation page, running lint returns an error No ruleset has been found

To Reproduce

# Assuming user has write access to /usr/local/bin ....
$ curl -L https://raw.github.com/stoplightio/spectral/master/scripts/install.sh | sh
$ spectral --version
6.0.0
$ head -1 openapi.yaml
openapi: 3.1.0
$ type spectral
spectral is a tracked alias for /usr/local/bin/spectral
$ spectral lint openapi.yaml
spectral lint openapi.yaml
No ruleset has been found. Please provide a ruleset using the --ruleset CLI argument, or make sure your ruleset file matches .?spectral.(js|ya?ml|json)

Expected behavior

As per the doc page , use the default ruleset (i.e. spectral:oas in this case)

Using a Ruleset File
If you don't specify a ruleset file with the --ruleset parameter, the Spectral CLI will look for a ruleset file called .spectral.yml, .spectral.yaml, or .spectral.json in the current working directory. If no ruleset is specified and no default ruleset file is found, the built-in rulesets will be used.

Environment:

• spectral CLI 6.0.0
• OS: Mac OS

[P0lip]

Hey!
That is expected - I updated the documentation to reflect the change in behavior.

[DavidBiesack]

Ouch! It is expected to make a command line option required where one was not required before?
As a user, I don't think that is very user friendly. I respectfully ask that you revert the decision to make this spectral's expected behavior.

Also note that the CLI help does not document this as required either, just spectral lint [documents..] :

$ /usr/local/bin/spectral lint --help
spectral lint [documents..]

lint JSON/YAML documents from files or URLs

Positionals:
  documents  Location of JSON/YAML documents. Can be either a file, a glob or fetchable resource(s) on the web.                                                                                  [array] [default: []]

Options:
      --version                  Show version number                                                                                                                                                         [boolean]
      --help                     Show help                                                                                                                                                                   [boolean]
  [...]
  -r, --ruleset                  path/URL to a ruleset file                                                                                                                                                   [string]
...

( --ruleset is not one of the "Options" because it is no longer optional; it is one of the "Requireds" :-)

[falnyr]

I am also facing this issue, documentation across the board specifies that the ruleset is not required.

IMHO it prevents people from adopting the tool simply because now you have to specify configuration even though you are actually not adding anything to it (as per your comment on #1797)

echo "extends: spectral:oas" > .spectral.yaml

[P0lip]

Ouch! It is expected to make a command line option required where one was not required before?

It's not required to provide the ruleset flag - the flag is needed only if you don't have the ruleset file in your current working directory. Otherwise, it's no longer required.

That said, as long as you have .spectral.json or .spectral.yaml you're good to go, and don't need to do anything.

As a user, I don't think that is very user friendly. I respectfully ask that you revert the decision to make this spectral's expected behavior.

It depends on the usage of Spectral - I presume most of users actually do have their own rulesets, so they won't notice any difference.

Don't get me wrong - I'm not saying we wouldn't revert the behavior, I hear you and your concerns.
It still wouldn't be a recommended usage, however - see my reply below for more insights.

IMHO it prevents people from adopting the tool simply because now you have to specify configuration even though you are actually not adding anything to it (as per your comment on #1797)

You are adding an OpenAPI styleguide, so it's not such a no-op thing after all.

In general, it's never been encouraged to rely on the default ruleset, as you are always at some risk when upgrading.
For instance, if we happen to add a JSON Schema styleguide, your standalone JSON Schema files might end up throwing validation errors, so you'll inevitably end up having your own styleguide anyway (currently we don't have any specific rules for standalone JSON Schema files).
Moreover, the OpenAPI styleguide has quite a few rules that aren't enabled by default, so it's really worth creating your own styleguide and fine-tune everything according to your taste.

Overall, the "default" ruleset thing was mostly the heritage of times where custom styleguides weren't a thing, thus you were forced to run the rulesets we provided, and couldn't change much.

[falnyr]

I presume most of users actually do have their own rulesets, so they won't notice any difference.

I'm not sure if you can validate that assumption in some way, but Spectral is part of GitHub's SuperLinter. Which has a major use case of "run this against your repo with zero config".

I am not sure how SuperLinter's team is going to address this as it takes away the generic approach and forces you to go more specific.

[P0lip]

Which has a major use case of "run this against your repo with zero config".

As far as I can see they cover plenty of various configuration files.

I might be wrong, but I believe their zero-config approach means you don't need to configure SuperLinter itself.
It doesn't imply that a given validator won't need some sort of a styleguide or configuration.

I actually went ahead and checked how stylelint behaves, as it's somewhat difficult in some way, and this is what I got

I am not sure how SuperLinter's team is going to address this as it takes away the generic approach and forces you to go more specific.

It shouldn't be a problem at all for them - they support plenty of configuration files already.

[spyrbri]

Maybe it would be good to include the new documentation in the installation steps or link the new documentation somehow in an earlier stage. I followed the installation steps and I got stuck on:

No ruleset has been found. Please provide a ruleset using the --ruleset CLI argument, or make sure your ruleset file matches .?spectral.(js|ya?ml|json),

then I checked the issues to see if anything relevant and I landed here.

[philsturgeon]

Thanks for the feedback folks. This decision was made because the goal is for Spectral to be a generic linter, with rulesets for common use cases like OpenAPI being available but not the assumed default. We have been autoguessing a lot of stuff, and now with Overrides its much easier to say "stuff in this folder is OpenAPI, stuff in this folder is GitHub Actions" or whatever other stuff needs linting.

We'll get the documentation updated as part of a big of a revamp anyway, so this will become more obvious soon. This might seem like a jarring change but it's been done in a major version to avoid breaking things for anyone, so hopefully we'll get used to it. If people continue to struggle with needing a ruleset (either locally or passed in) then we look at bringing back the autoguessing.