Ruleset file is inferred from workspace directory and not from directory of the file that gets validated

[richardboehme]

Describe the bug According to the documentation of the configuration option "Spectral: Ruleset File" the default ruleset file "is a .spectral.yml/.spectral.json in the same folder as the document being validated". However, this does not work. The ruleset file is only recognized if it is in the workspace root.

This is impractical for having documentation in subfolders, because it requires the ruleset file to be in the root directory of the workspace.

To Reproduce

1. Given any specification document in a subdirectory that does not match some rule.
2. Add .spectral.yml in this subdirectory and turn off the conflicting rule.
3. The conflicting rule is still validated against.

Expected behavior The extension should behave as documented. The ruleset file should be looked up from the directory the document is in. Alternatively, the documentation of the "Spectral: Ruleset File" should be adjusted.

Environment:

• Extension version: 1.0.0
• VS Code version: 1.70.2
• Operating System: Windows 10 running VS Code with the Remote Extension on WSL

Additional context To not break existing setups, both directories could be used to find a ruleset configuration file. This would be a new feature though.

[DawMatt]

I've encountered this exact same issue. To test this I created a .spectral.yml file in my API folder with the following content:

rules:
  openapi-v3-info-contact:
    description: Ensures that all APIs have contact information.
    message: API must have a contact information available.
    given: $.info
    severity: error
    recommended: true
    type: style
    formats:
      - oas3
    then:
      field: contact
      function: truthy

Even though I only have a single rule configured the extension reports a number of additional opinionated rules in addition to any parser issues spectral always detects.

If I instead either move the .spectral.yml file to the workspace root folder, or use the Spectral CLI to do the linting within the folder containing the API file, the single spectral rule will be detected (along with any parser issues).

VS Code's support for multi-root workspaces seems to be the only workaround for the impracticality issue @richardboehme mentions above of having a single spectral configuration file at the workspace level. But using multi-root workspaces this way is trading one form of impracticality (single config file for all documentation subfolders) for another (creating a new workspace root for each documentation subfolder). Either approach seems suboptimal.