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