"Overrides" similar to eslint

[philsturgeon]

User story.
As a user with a few different types of YAML and JSON in a repo, none of which have any particular format, I'd like to be able to apply Spectral rules and rulesets to specific files and folders without accidentally applying irrelevant rules to other files.

Is your feature request related to a problem?

Right now I am making a ruleset and Spectral VS Code is applying this custom ruleset to .spectral.yml, and everything in .spectral.yml is being applied to other random JSON files too.

Describe the solution you'd like

Configuration based on glob patterns looks like a good place to start.

https://eslint.org/docs/user-guide/configuring#configuration-based-on-glob-patterns

For example, picking a particular ruleset for a bunch of files:

"overrides": [
    {
      "files": ["src/data/actions/*.yaml"],
      "extends": [{
         "./rulesets/actions.yaml
      }]
    },
    {
      "files": ["src/data/jobs/*.yaml"],
      "extends": [{
         "./rulesets/jobs.yaml
      }]
    }

This could be combined with custom rules for specifically those files:

"overrides": [
    {
      "files": ["src/data/jobs/*.yaml"],
      "extends": "extends": [{
         "./rulesets/jobs.yaml
      }],
      "rules": {
        // business as usual rules here
      }
    }

Finally, setting a particular format, even a custom format, we can do this:

"overrides": [
    {
      "files": ["src/apis/*.yaml"],
      "format": "raml"
    }

Then Spectral will know: those files are raml and a ruleset applying to format: "raml" will work fine.

This solves the issue we have currently where only CLI users get formats and nobody else can do anything about them.

[philsturgeon]

@lottamus @marbemac would like some input on this before we get going. I believe it will be very useful for Studio as well as Spectral, but we can start the work over here so long as you're happy with the direction.

[nulltoken]

Few reasonable limits to make this scoped:

• Each override should somehow be a complete ruleset (along with extends, rules, functions, extensions, ...)
• The check requiring a ruleset to have a top-level extend or rules could be relaxed, provided at least one the overrides do so
• Only one layer of overrides would be allowed. No nesting for now.
• The glob based approach may lead to inconsistencies (two rules with same name but different settings trying to lint the same file for instance, ...). This issues may only be checked when the list of files to lint is known. In order to make the user experience better, a pre-validating check will have to occur before the rules start to be processed.

[marbemac]

I would suggest erring on the opinionated side of things to start (aka less flexible but hopefully simpler to implement well).

Perhaps just starting with files and extends:

{
  "overrides": [
    {
      "files": ["src/data/actions/*.yaml"],
      "extends": "./rulesets/actions.yaml"
    },
    {
      "files": ["src/data/jobs/*.yaml"],
      "extends": "./rulesets/jobs.yaml"
    }
  ]
}

Only one layer of overrides would be allowed. No nesting for now.

💯. Just throwing out an alternative, but it might simplify a few things by constraining a bit further and considering this functionality as something like a spectral "workspace" (similar to monorepo workspace terminology). Where basically a spectral ruleset can EITHER define a workspace (that has the sort of "apply this ruleset to these files" info similar to above proposal), or rules, but not both.

To simplify, I'd also propose that the first matched override applies (versus accumulating them).

Thoughts?

[nulltoken]

Perhaps just starting with files and extends
a spectral ruleset can EITHER define a workspace (that has the sort of "apply this ruleset to these files" info similar to above proposal), or rules, but not both.

@marbemac I like this very much!

To simplify, I'd also propose that the first matched override applies (versus accumulating them).

That indeed may help a lot, but might make troubleshooting a lot harder (Why did this rule has been applied? Why didn't this one?).

Another aspect worth considering is that, even if nesting is disallowed, nothing prevents a user from being creative:

• defining both src/data/**/*.yaml and src/data/actions/*.yaml
• leveraging negated globs

[stoplight-bot]

🎉 This issue has been resolved in version @stoplight/spectral-cli-v1.0.0 🎉

The release is available on:

• npm package (@latest dist-tag)
• GitHub release

Your semantic-release bot 📦🚀

[stoplight-bot]

🎉 This issue has been resolved in version @stoplight/spectral-core-v1.0.0 🎉

The release is available on:

• npm package (@latest dist-tag)
• GitHub release

Your semantic-release bot 📦🚀