Schema association with fallbacks (wildcards)

[qvalentin]

Summary

I would like to associate certain files with a specific schema and use a fallback for all other files.

The concrete usecase would be to provide schema association for Kubernetes CRDs and use the default Kubernetes schema for all other files.

Relevant information

This is the config I tried, but it seems that this will enable the Kubernetes schema even for the servicemonitor and cause validation errors:

yaml.schemas: {
	"https://raw.githubusercontent.com/datreeio/CRDs-catalog/main/monitoring.coreos.com/servicemonitor_v1.json": "**servicemonitor.yaml",
	"kubernetes": "templates/**.yaml"
}

The Readme contains a similar example, which is quite confusing:

yaml.schemas: {
    "https://json.schemastore.org/composer": "/*",
    "kubernetes": "/myYamlFile.yaml"
}

From my understanding this will enable the composer schema (some php stuff I guess) for all files in the root directory but will also enable the Kubernetes schema for the file myYamlFile.yaml. Would you not get validation errors in the Kubernetes file from the composer schema?

[k8ieone]

I'd like to achieve the same thing, but I'm getting the same result. The moment I add "kubernetes": "/*.yaml", everything is treated as a Kubernetes manifest. The order doesn't matter.

[NefedovDA]

It looks like that I have similar problem.

Project setup:

// files structure
api/
  |- openapi_file_x.yaml
  |- openapi_file_y.yaml
  |- definitions.yaml

// lsp configuration
yaml.schemas: {
    "/Users/<username>/.config/zed/json-schemas/openapi-v3.0.json": "/api/*.yaml",
    "/Users/<username>/.config/zed/json-schemas/openapi-v3.0-definitions.json": "/api/definitions.yaml"
}

Expect:

• openapi-v3.0.json will be applied to all files expect definitions.yml
• openapi-v3.0-definitions.json will be applied to definitions.yml file

Actual:

• openapi-v3.0.json will be applied to all files except definitions.yml -- ok
• openapi-v3.0-definitions.json no validation at all -- not ok

I have tried to specify schema directly in the definitions.yml file and it's work fine, but not applicable for my setup

[drlucaa]

This “fallback / wildcard precedence” problem is exactly what pushed me to build a workaround: yaml-schema-router (stdio proxy in front of yamlls) which injects a single schema per document based on content (apiVersion/kind), avoiding the “multiple schemas match” collisions when mixing kubernetes + CRDs.

Repo: https://github.com/traiproject/yaml-schema-router

If yamlls ever grows a “first match wins” / explicit priority (or “exclusive schema”) mode for yaml.schemas, that would solve this cleanly upstream. Happy to share notes / test cases from the router if useful.

[qvalentin]

@drlucaa seems like a nice project, but is it required anymore since #1050 was merged (at least for CRDs)?

[drlucaa]

@qvalentin No you right. Thats just some really bad timing. I guess the only feature mine has that theirs doesn't is local disk caching that saves about 1 to 2 seconds when opening a file.

[drlucaa]

@qvalentin And its also easily extensible so if you have any schema you miss in the ls, feel free to create an issue.