Schema modeline should also resolve schema path from project root or multi-project root

[saver-r]

Describe the bug

In a multi-root workspace, there's a schema

def/bla_schema.json

{
  "$schema": "http://json-schema.org/draft-07/schema#",
  "type": "object",
  "properties": {
    "bla": {
      "type": "array",
      "items": {
        "type": "string",
        "enum": ["foo", "bar", "fla"]
      }
    }
  },
  "required": ["bla"],
  "additionalProperties": false
}

In another project there's a file

use/bla.json

# yaml-language-server: $schema=def/bla_schema.json

bla:
  - foo
  - bar
  - fla
  - foo

Even though README says that paths are resolved wrt multi-project roots, validating just errors out.

Now trying a relative path over workspace roots:

# yaml-language-server: $schema=../def/bla_schema.json

Expected result

Path is resolved to <prefix>/use/../def/bla_schema.json and autocompletion is working.

Actual result

Path is resolved to <prefix>/use/def/bla_schema.json, thus yielding an invalid location. Obviously, autocompletion does not work.

Unable to load schema from '<prefix>/use/def/bla_schema.json': No content.YAML(768)

Proposed solution

Either

1. support paths relative to workspace roots, or
2. retain .. parts in modeline.

Environment

• Windows
• Mac
• Linux (WSL2)
• other (please specify)

[shin19991207]

Thanks for the report. I think there are two different schema resolution modes being mixed here.

The multi-root behavior documented in the README applies to yaml.schemas settings, not to modelines:
https://github.com/redhat-developer/vscode-yaml#multi-root-schema-association

For modelines, relative paths are resolved relative to the current YAML file location, as documented here:
https://github.com/redhat-developer/vscode-yaml#associating-a-schema-in-the-yaml-file

So if the workspace contains these two roots:

def -> <prefix>/project-a/def
use -> <prefix>/project-b/use

and the YAML file is:

<prefix>/project-b/use/bla.yaml

then this modeline:

# yaml-language-server: $schema=../def/bla_schema.json

is resolved as a path relative to <prefix>/project-b/use/bla.yaml as:

<prefix>/project-b/use/../def/bla_schema.json

which normalizes to:

<prefix>/project-b/def/bla_schema.json

It does not look at the multi-root workspace folder list and reinterpret def as the workspace root named def. That workspace-root-name behavior is only supported through yaml.schemas.

If you want workspace-root-based schema resolution in a multi-root workspace, use yaml.schemas instead. For example:

"yaml.schemas": {
  "def/bla_schema.json": "use/bla.yaml"
}

In that case, def/bla_schema.json is resolved using the workspace folder named def, and the schema is applied to use/bla.yaml.

I also checked the ../def/bla_schema.json modeline case. When interpreted as a path relative to the YAML file, it resolves correctly: the .. segment moves up one directory from the YAML file’s directory before appending def/bla_schema.json. So the behavior appears correct for file-relative modeline resolution. What is not supported is resolving that same modeline through the multi-root workspace folder names.

[saver-r]

Thank you for your clarification!

The .. indirection from the location of the yaml file (instead of the project root) seems to be an acceptable workaround.

It bears the disadvantage that you cannot provide a single yaml template with a single modeline that makes validation work without regard of the specific location of the yaml file within any use project. I changed the issue title to reflect this meaning.

Using a config file is impractical as it's an additional location that must be maintained and kept up to date.