Skip to content

Fix schema deselection through the schema picker - #1283

Merged
shin19991207 merged 2 commits into
redhat-developer:mainfrom
shin19991207:fix-schema-deselection
Sep 21, 2026
Merged

shin19991207 merged 2 commits into
redhat-developer:mainfrom
shin19991207:fix-schema-deselection

Conversation

@shin19991207

@shin19991207 shin19991207 commented Sep 17, 2026 •

Copy link
Copy Markdown
Member

What does this PR do?

Preserve schema globs and configuration scopes when deselecting schemas

Previously, the schema picker operated on the effective merged yaml.schemas value. This caused two problems:

  1. When schema associations came from different configuration scopes, such as User vs Workspace settings, deselecting one schema could not correctly update the scope where that association was defined
  2. When a schema was associated through a glob such as *.yaml, deselecting the schema for one matching file did not remove the association because the original glob continued to match that file

The picker also used yaml.disableSchemaDetection when "No JSON Schema" was selected. That setting suppresses all detected/configured schemas for a matching file, rather than only the schema the user deselected.

This PR changes the picker behavior:

  • User, Workspace, and Workspace Folder settings are inspected and updated independently.
  • When deselecting a schema that is associated through a broader glob, the glob is preserved and a negated file URI is added, e.g.
    {
      "yaml.schemas": {
        "https://example.com/schema.json": [
          "*.yaml",
          "!file:///path/to/test.yaml"
        ]
      }
    }
  • Deselecting schemas does not add the file to yaml.disableSchemaDetection

The yaml.schemas README documentation and VS Code setting description now document exclusion patterns.

Support for negated schema file-match patterns is provided by redhat-developer/yaml-language-server#1345

What issues does this PR fix or reference?

Related to #1212

The issue reports that when schemas configured at the User and Workspace scopes target the same files, an unexpected schema may be selected (from my testing, all are selected). It proposes prioritizing those schemas based on their versions.

This PR does not implement schema-version priority or change how settings from different scopes are merged. Configuration scope precedence and effective merged setting values are managed by VS Code: https://code.visualstudio.com/docs/configure/settings
The schema picker UI already supports choosing a schema version when the schema explicitly provides version metadata. However, assigning priority based on arbitrary local schema filenames would not be reliable (IMO). For example, there is no dependable way to determine that schema-1.1.0.json and schema-1.2.0.json represent different versions of the same logical schema. Inferring schema identity and semantic-version ordering from arbitrary paths or URIs could produce incorrect results.

However, while investigating the issue, I found the schema-picker issues. This PR fixes the issues. User reporting the original issue can therefore uses the schema picker UI to select their preferred schema now.

Is it tested? How?

Manual test 1: Basic select/deselect

  1. Create a file named test.yaml:

    name: hello
  2. Open the file and click the schema status bar item.

  3. Select any schema, such as one from SchemaStore.

  4. Verify .vscode/settings.json contains:

    {
      "yaml.schemas": {
        "https://the-schema-url": "file:///path/to/test.yaml"
      }
    }
  5. Open the schema picker again and choose No JSON Schema.

  6. Verify the yaml.schemas entry is removed.

  7. Verify yaml.disableSchemaDetection is unchanged and does not receive the file URI.

Manual test 2: Negation with a glob

  1. Add the following Workspace setting:

    {
      "yaml.schemas": {
        "https://json.schemastore.org/github-workflow.json": "*.yaml"
      }
    }
  2. Open test.yaml.

  3. Verify the status bar shows github-workflow.

  4. Open the schema picker and deselect github-workflow.

  5. Verify the setting becomes:

    {
      "yaml.schemas": {
        "https://json.schemastore.org/github-workflow.json": [
          "*.yaml",
          "!file:///path/to/test.yaml"
        ]
      }
    }
  6. Open another YAML file, such as other.yaml.

  7. Verify other.yaml still uses github-workflow.

Manual test 3: Configuration-scope independence

  1. Add the following User setting:

    {
      "yaml.schemas": {
        "https://json.schemastore.org/github-workflow.json": "*.yaml"
      }
    }
  2. Add a different schema to .vscode/settings.json:

    {
      "yaml.schemas": {
        "https://json.schemastore.org/docker-compose.json": "*.yaml"
      }
    }
  3. Open test.yaml.

  4. Verify both schemas are active.

  5. Open the schema picker.

  6. Deselect docker-compose while keeping github-workflow selected.

  7. Verify the User setting is unchanged.

  8. Verify only the Workspace setting is updated:

    {
      "yaml.schemas": {
        "https://json.schemastore.org/docker-compose.json": [
          "*.yaml",
          "!file:///path/to/test.yaml"
        ]
      }
    }

Signed-off-by: Morgan Chang <shin19991207@gmail.com>
Signed-off-by: Morgan Chang <shin19991207@gmail.com>

@datho7561 datho7561 left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good and works well! Thanks, Morgan!

Found one edge case that works a bit odd but I think it's still good to merge. Feel free to merge if you agree.

Here's the edge case:

Disable schema detection through yaml.disableSchemaDetection using a glob, then create a file that matches the glob. Try to set the schema for the file using the schema picking UI.

@shin19991207
shin19991207 merged commit 0ce73af into redhat-developer:main Sep 21, 2026
8 of 10 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

Status: Done

Development

Successfully merging this pull request may close these issues.

2 participants