#1112 - Support JSON Schema 2019-09 and 2020-12 by migrating to @hyperjump/json-schema

[damioune123]

Support JSON Schema 2019-09 and 2020-12 by migrating to @hyperjump/json-schema

🎯 Overview

Fixes #1112 by replacing AJV with @hyperjump/json-schema to enable support for JSON Schema 2019-09 and 2020-12 specifications.

🔄 Key Changes

Dependency Migration

• ❌ Removed: ajv and ajv-draft-04 (limited to draft-04/07)
• ✅ Added: @hyperjump/json-schema (supports all drafts including Draft 04, Draft 07, 2019-09, 2020-12)

Schema Service Updates

• Simplified validation logic in yamlSchemaService.ts
• Maintained full backward compatibility with existing draft-04/07 schemas
• Added native support for modern JSON Schema features:
  • $defs keyword
  • unevaluatedProperties
  • Modern exclusiveMinimum/exclusiveMaximum

Comprehensive Test Coverage

• 11 new test cases validating 2019-09 and 2020-12 support
• Test fixtures for both schema versions
• Verification of modern keyword handling
• Mixed version compatibility testing

[damioune123]

@datho7561 FYI #1006

[github-advanced-security]

ESLint found more than 20 potential problems in the proposed changes. Check the Files changed tab for more details.

[coveralls]

coverage: 83.964% (+0.008%) from 83.956%
when pulling c3abaf3 on damioune123:feature/1112-support-json-schema-2019-and-2020
into 3821411 on redhat-developer:main.

[ernestmajdalani]

We need this !

[HanyAkoury]

Amazing, really need this ! When can this be merged?

[Kosta-Github]

I would love this as well! 👍

[HanyAkoury]

@msivasubramaniaan Hello dear Sir,
Would it be possible to have a review on this Pull request as it is of high importance and for now, asserted public utility ?
Thank you for your feedback and have a blessed day.
Regards

[injeniero]

@gorkem please please :-)

[hadriencoursera]

Nice job !

[datho7561]

I'm planning finishing the release of 1.19.0 first (since we started the release process and never finished), but I intend to take a look at this after 1.19.0 is published.

[HanyAkoury]

Thank you @datho7561 !

[datho7561]

Few notes for now, but I'll keep testing this PR tomorrow:

• I can't get either of $dynamicRef (from 2019-09) or $recursiveRef (from 2020-12) working properly. I thought proper support for these features was the main selling point of swapping from AJV to hyperjump's JSON Schema validator. Can you confirm if this is expected to work?
• Since this PR was opened, it seems like AJV has added support for 2020-12 (at least from what I can tell from the docs). It would be less risky to stick with AJV for validation instead of changing libraries, especially if it can support everything that hyperjump can. What are the advantages of hyperjump's implementation over AJV?

[datho7561]

For this PR, keep in mind (I forgot this myself) that AJV (and now @hyperjump/json-schema in this pr) is only used to validate the referenced schema.

i.e. If you have this YAML file called ./product.yaml open:

# yaml-language-server: $schema=./product.schema.json
productId:
  productId: 12

AJV/@hyperjump/json-schema will be used to validate ./product.schema.json, but not ./product.yaml

[datho7561]

I think the code is working okay. I think the test cases need reworking.

I also think we have to be careful about the wording; this PR will not support validating YAML against 2019-09 and 2020-12 schemas, but it will be able to point out errors in those schemas.

[datho7561]

These tests make sure that you can validate YAML against 2019-09 and 2020-12 schemas. However, this functionality is handled by vscode-json-languageservice ./src/languageservice/parser/jsonParser07.ts, not AJV or hyperjump/json-schema. As a result, I don't think that these tests are helpful.

The main thing that's changed by this PR is how the schema referenced in the yaml file is validated. (If the schema is invalid, we add an error on the YAML file).

In order to test this properly, I think it would be helpful to write tests that validate against some invalid schemas, to make sure that the errors are found.

Here's an interesting case I came up with:

{
  "$schema": "https://json-schema.org/draft/2019-09/schema",
  "$defs": {
    "person": {
      "type": "object",
      "properties": {
        "name": {
          "type": "string"
        },
        "birthday": {
          "type": "string",
          "format": "datetime"
        },
        "location": {
          "type": ["nostril", "nostril"]
        }
      },
      "required": [
        "name",
        "birthday",
        "location"
      ],
      "additionalProperties": false
    }
  },
  "type": "array",
  "items": {
    "$ref": "#/$defs/person"
  }
}

When validated as a draft-07 schema, this schema is listed as valid, since $defs has no meaning in draft-07. However, when validated as a 2019-09 schema, ["nostril", "nostril"] is marked as a bad type.

We need something similar for for 2020-12; something that's invalid in 2020-12 schemas but okay in 2019-09 schemas.

[datho7561]

This PR will validate referenced schemas properly, but doesn't validate the YAML against the referenced schemas properly if they are newer than draft-07, as this behaviour is handled by vscode-json-languageservice ./src/languageservice/parser/jsonParser07.ts.