Provide API for dynamically supplying JSON Schemas

[ak1394]

I'd like to extend built-in json-language-features extension to allow specifying JSON Schemas dynamically. This is somewhat related to #69868

[msftclas]

All CLA requirements met.

[aeschli]

The way I see it, the JSON language extension is just a consumer of schema associations. They can be used by other extensions too (e.g. YAML). Adding the suggested API is IMO the wrong approach.
Also I'd like to avoid extension APIs as to avoid coupling of extensions.

I'd like to understand your use case.

[ak1394]

I'm working on the extension for editing OpenAPI v2/v3 files. Depending on a version of the OpenAPI file (which is determined by looking at the "swagger" or "openapi" attribute in the file body) a relevant schema must be used.

However, existing mechanisms for providing json schemas (for example "jsonValidation" in the extension manifest) mostly employ filename matching, which doesn't work in my case.

So, I'm looking for a way to provide schemas to json-language-features dynamically.

This is related to #69868 if the approach suggested by @alexandrudima is adopted, there sill needs to be a way to select a schema to be used, for cases where JSON doesn't have "$schema" attribute.

[aeschli]

@ak1394 Would it be possible to define a schema that does the check on the "swagger" or "openapi" attributes and then references the correct schema?

[ak1394]

Thanks for suggestion! It would provide short-term workaround, but I hit few issues this approach:

I would have to apply this schema with "fileMatch": "*.json" which would affect all JSON files, even ones which have nothing to do with OpenAPI.

Depending on the way I structure top-level schema I either see validation errors on all non-OpenAPI files open in the editor (when using combination of oneOf / required) or (when using anyOf) autocompletion feature offers to insert "openapi" attribute into OpenAPI v2 file and "swagger" to OpenAPI v3 file.

When using more lax schema (with anyOf) it's easy enough to loose schema association between schema and file if user accidentally removes "swagger" or "openapi" attribute (which wouldn't happen if schema was associated to a file with a file name).

[ak1394]

In any case, I agree with "JSON language extension is just a consumer of schema associations." However, the current way for providing these associations is based mostly on filename matching, which is limiting.

I think there is a case for providing this information in the runtime, but maybe not necessarily by directly talking to json-language-features.

[aeschli]

The other alternative is to recommend users to use a file name convention myfile.openApi3.json.

It looks like you already have an extension that parses the JSON of every JSON file, to find out if it is OpenAPI2or 3 file. Why not doing the schema validation yourself? The vscode-json-language service is there to be reused. You kind of provide a swagger-language-server which will be able to provide much deeper support than the JSON language server will be able to do.

[ak1394]

I've seen other extensions going with this approach, but I think it worsens usability of the extension. There is a lot of existing OpenAPI files out there, and asking users to rename them is probably not going to work.

Forking vscode-json-language is not something we would like to do either - the next feature we are working on is YAML/OpenAPI support, which would use vscode-yaml and yaml-language-server.
Building own swagger language server would mean forking these as well, which is quite a bit of work.

By the way, vscode-yaml exposes an API which allows dynamically supply schemas to yaml-language-server. The API is somewhat different, but it handles the same problem:
https://github.com/redhat-developer/vscode-yaml/blob/master/src/extension.ts#L77

[aeschli]

I didn't suggest to fork, but to use the vscode-json-langaugeservice in your language server.

Thanks for the yaml pointer, it's a intersting idea.

[ak1394]

Fair enough regarding the forking, I didn't look close enough at vscode-json-langaugeservice to see it it could be used directly.

[aeschli]

Closing the PR as an API on the json-language-feature API is not the right way IMO.

I think you are best served by doing the validation in your own server, given that you already have to parse the file to find out what type of file it is.