Support for json-schema > draft-7

[mitodrummer]

Summary

Hello, I am wondering if there is a plan to update to the newest json schema (2020-12 at the time of this ticket). I am needing features from 2019 schema.

TY

[mitodrummer]

microsoft/vscode-json-languageservice#133

Looks like maybe version 4.2.1 of json-languageservice should have it :)

[remcohaszing]

FYI #637 explains why the version is locked. That issue includes a number of related references.

As the reporter of that issue I would totally understand if the version is unlocked in order to support newer JSON schema features.

[gorkem]

@remcohaszing I think we will have to move to a later vscode-json-languageservice not only to get schema support for more recent schema versions but also for issues like #823 are also fixed by later versions.

[remcohaszing]

I suggest to wait for SchemaStore/schemastore#2858.

[gorkem]

No problem. Unfortunately, there are breaking changes on vscode-language-service that we need to adjust yaml-language-server for.

[amimas]

Any update available for this?

[apupier]

microsoft/vscode-json-languageservice#133

Looks like maybe version 4.2.1 of json-languageservice should have it :)

Unfortunately, it seems that it is not workign as expected, this issue is linked from the pointed issue microsoft/vscode#98724

[remcohaszing]

I don’t know what’s the hold up for SchemaStore/schemastore#2858, but it’s taking a long time. It only affects 3 schemas, of which I manage 1, so I can create a workaround for that.

I think it’s best to just update. This will break for a couple of users, but benefit the majority.

[michaeltlombardi]

Updating would be very helpful, as there's a good number of useful keywords in 2019-09 that work even without full support for dynamic references/anchors/vocabulary - notably, the unevaluated* and dependent* keywords for schema composition/extension/conditional validation.

[Cerebus]

Updating is a must, b/c I've got schemas I'd like to use that are on draft 2019-09 and 2020-12. It's a royal PITA when completion is busted for half my stuff b/c yamlls won't grok the schema.

[baywet]

@datho7561 could you please articulate in broad strokes where the changes need to be made for this? Sort of an introduction to the code base + considerations to keep in mind.
From reading this thread, I'm under the impression that this has a dependency on the JSON language server, but the upgrade has been kept behind for some reason, do you have specifics as to why?

[datho7561]

I believe the validation logic is mostly contained in ./src/languageservice/parser/jsonParser07.ts and that updating vscode-json-languageservice isn't necessary.

I forget what specific issues updating vscode-json-languageservice would fix. The main problem with updating it is that we access/subclass internal code. By updating, some of that breaks (a mix of function names/signatures changing and the semantics of those functions being slightly different). I think we're mainly using vscode-json-languageservice in order to reuse some of the schema resolving logic?

[baywet]

Thank you for the additional information.

Can I assume we don't want to loose support for draft 7 and earlier as we implement 2020-12?

What's the benefit of having yet another implementation of JSON schema here when json language service already offers one? (or a lib like hyperjump)

[datho7561]

Can I assume we don't want to loose support for draft 7 and earlier as we implement 2020-12?

Ideally yes, we don't want to lose support for draft 7. There's a lot of schemas still using it (OAI/OpenAPI-Specification#5130 (reply in thread)). There's also many schemas using draft-04 (see #780). I think that for most of the breaking changes it should be fairly simple to handle both the new and old behaviours.

What's the benefit of having yet another implementation of JSON schema here when json language service already offers one? (or a lib like hyperjump)

For an IDE/text editing experience, we need to provide accurate error ranges when something is wrong. As a result, we need to validate the AST of the parsed YAML rather than the deserialized data, since the AST will contain information on the range of the erroneous text. This makes it difficult to use any of the existing validators (ajv, hyperjump), since from my understanding, they are built to validate the deserialized JSON. vscode-json-languageservice 's implementation validates the AST against the schema, but since the AST structure of JSON and YAML documents is different, validating YAML will need to be handled slightly differently (this is why we have a modified version of that class in this repo).