JSON Schemas precedence managment

[bd82]

Intro

JSON Schemas can be registered from multiple sources.:

• "$schema" prop in file.
• user/workspace settings.json fileMatch.
• jsonContribution package.json fileMatch.
• Schemas registered by Theia Extensions.
• SchemaStore catalog fileMatches.

This can easily lead to a situation where an end user's JSON file will be validated by many schemas which in turn can cause:

• false positive errors.
• Irrelevant suggestions in auto-complete.

Feature Request:

I believe some mechanisms are needed to allow the end user more granular control on which schemas would be applied to a specific file. Currently (Theia 1.4) most of these sources only add a schema to the set of schemas. Making it difficult to manage the set (remove/replace).

Possible Approach

From an implementation perspective it seems that the origin of each registered fileMatch/schema pair could be "saved" and given a precedence and that only schemas from the highest precedence level should be applied to a specific file.

I believe the precedence levels should be.

1. "$schema" prop in file.
2. user/workspace settings.json fileMatch.
3. Identical Precedence for these two:
   • contributes.jsonValidation package.json fileMatch.
   • Schemas registered by Theia Extensions.
4. SchemaStore fileMatches.

Basically this means that Schemas would only be applied from one of the above (1-4) categories. And the higher numbered categories would have priority.

The logic is that the closer to the user/file we are, than the stronger the configuration, e.g:

• A settings.json fileMatch would enable an end-user to avoid schemas coming from the SchemaStore.
• A jsonValidation contribution in a VSCode extension would overwrite/replace the schemaStore catalog.
  • Note an end-user should be able to control which VSCode extensions are installed...

This currently seems to work with the "$schema" prop in file. as it replaces other registered schemas. However, with the other categories they seem to only add another registered Schema.

[tsmaeder]

These days, json schema support is implemented in the VS Code json-language-features built-in extension. Nothing Theia can do here unless we want to return to implementing this ourselves 🤷 Closing. @bd82 let me know if I'm missing the point here.

[bd82]

Hi @tsmaeder.

When I originally created this issue in Theia additional schemas were loaded automatically (from the Schema Store) which aggravated the precedence issue.

I am not sure what is the situation now...

[tsmaeder]

@bd82 I'm not sure what the state is either, but the code handling those issues is no longer in Theia, but in VS Code, as far as I understand.

[bd82]

@tsmaeder everything may be working perfectly now (I honestly don't know, may have time to check next week...).

But imho the logic that JSON Schema --> VS VSocde --> Not Theia's problem is not 100% accurate. I believe Theia adds additional features on-top of basic VSCode JSON Schema support (see below), So if these extra features causes issues they should be resolved / documented / listed as limitations / ...

For example Theia registers (all) the schemas from the schemaStore which VSCode does not (afaik).

• https://github.com/eclipse-theia/theia/blob/7d3b1d3b33cb565ec07965e5baf10c926006cdfd/packages/core/src/browser/json-schema-store.ts#L98-L109

This behavior of registering many additional schemas can lead to strange edge cases:

• What happens when a fileMatcher in schemasStore is identical to a fileMatcher in the preferences?
• same as above but with $schema property in a specific .json file.
• can multiple schemas be activate for a single file?
• Does the answer to the above question changes if the fileMatchers are identical or just similar?

We have encountered such issues in the past, I am interested in inspecting the state in Theia 1.13.0 (hopefully next week...).