Too broad pattern for ansible Var Files results in spurious errors working with pandoc defaults file

[chrisgrieser]

Area with issue?

JSON Schema

✔️ Expected Behavior

pandoc defaults file should not report spurious errors when using keys with a hyphen, since they are totally valid.

❌ Actual Behavior

All keys with a hyphen are treated as invalid, with the error "Property xyz not allowed (yaml-schema: Ansible Vars Files".

After quite a bit of digging, I figured out that the issue seems to be that the respective ansible schema used by the schemastore treats any yaml file in a defaults directory as ansible vars file. I have tested this and confirmed that renaming the directory to something other than defaults stops the error messages from appearing.

"examples": [
  /* ... */
  "defaults/*.yml",
  /* ... */
],

Concidentally, pandoc defaults files are also yaml files located in a directory called defaults:

(...) The file will be searched for first in the working directory, and then in the defaults subdirectory of the user data directory.

If I do not want to store my pandoc defaults files in the working directory, I have no other choice than putting them in a directory called defaults. I also have no other choice in regards to the keys containing hyphens, since I do not name the key names myself. And the yaml-lsp has no setting to disable schemas just for a specific file or directory.. So in other words, there is no way I can disable the spurious errors on my side other than turning off the LSP entirely.

I did notice that the culprit schema file is hosted at ansiblelint and not at this repo, but I assume that in the context of the linter, it does make sense to use the broader pattern. In fact, the problem is not with the schema file itself, but the fact that a schema meant for a very specific linter is applied to all yaml files (that match certain patterns), making this an issue for this repo rather than the ansiblelint repo, if I am not mistaken.

YAML or JSON file that does not work.

No response

IDE or code editor.

None

Are you making a PR for this?

No, someone else must create the PR.