feat(ci): add sourcemeta/jsonschema to find linting issues

[Karan-Palan]

Description

ref #401 and #401 (comment)

Added the sourcemeta/jsonschema cli as an npm dependency and created a dedicated job for JSON Schema linting

$ npx jsonschema lint --exclude const_with_type --ignore spec/schemas/json-schema-draft-07.json spec/schemas/*.json
spec/schemas/config_schema.json:4:12:
  Future versions of JSON Schema will refuse to evaluate unknown keywords that don't have an x- prefix (unknown_keywords_prefix)
    at schema location "/$defs"
spec/schemas/csr_schema.json:4:12:
  In Draft 7 and older dialects, keywords sibling to `$ref` are never evaluated (draft_ref_siblings)
    at schema location "/title"
spec/schemas/csr_schema.json:7:12:
  Future versions of JSON Schema will refuse to evaluate unknown keywords that don't have an x- prefix (unknown_keywords_prefix)
    at schema location "/$defs"
spec/schemas/ext_schema.json:4:12:
  In Draft 7 and older dialects, keywords sibling to `$ref` are never evaluated (draft_ref_siblings)
    at schema location "/$defs"
spec/schemas/ext_schema.json:4:12:
  Future versions of JSON Schema will refuse to evaluate unknown keywords that don't have an x- prefix (unknown_keywords_prefix)
    at schema location "/$defs"
spec/schemas/inst_schema.json:4:12:
  In Draft 7 and older dialects, keywords sibling to `$ref` are never evaluated (draft_ref_siblings)
    at schema location "/$defs"
spec/schemas/inst_schema.json:4:12:
  Future versions of JSON Schema will refuse to evaluate unknown keywords that don't have an x- prefix (unknown_keywords_prefix)
    at schema location "/$defs"
spec/schemas/inst_subtype_schema.json:10:12:
  Future versions of JSON Schema will refuse to evaluate unknown keywords that don't have an x- prefix (unknown_keywords_prefix)
    at schema location "/$defs"
spec/schemas/inst_subtype_schema.json:173:15:
  In Draft 7 and older dialects, keywords sibling to `$ref` are never evaluated (draft_ref_siblings)
    at schema location "/properties/name/type"
spec/schemas/inst_var_schema.json:6:12:
  Future versions of JSON Schema will refuse to evaluate unknown keywords that don't have an x- prefix (unknown_keywords_prefix)
    at schema location "/$defs"
spec/schemas/inst_var_type_schema.json:7:28:
  Future versions of JSON Schema will refuse to evaluate unknown keywords that don't have an x- prefix (unknown_keywords_prefix)
    at schema location "/unevaluatedProperties"
spec/schemas/inst_var_type_schema.json:25:13:
  Wrapping any keyword other than `$ref` in `allOf` is unnecessary and may even introduce a minor evaluation performance overhead (unnecessary_allof_wrapper_draft)
    at schema location "/allOf/0/if"
spec/schemas/manual_schema.json:27:22:
  In Draft 7 and older dialects, keywords sibling to `$ref` are never evaluated (draft_ref_siblings)
    at schema location "/properties/state/description"
spec/schemas/manual_version_schema.json:4:12:
  Future versions of JSON Schema will refuse to evaluate unknown keywords that don't have an x- prefix (unknown_keywords_prefix)
    at schema location "/$defs"
spec/schemas/manual_version_schema.json:100:22:
  In Draft 7 and older dialects, keywords sibling to `$ref` are never evaluated (draft_ref_siblings)
    at schema location "/properties/state/description"
spec/schemas/manual_version_schema.json:92:22:
  In Draft 7 and older dialects, keywords sibling to `$ref` are never evaluated (draft_ref_siblings)
    at schema location "/properties/version/description"
spec/schemas/profile_family_schema.json:34:22:
  In Draft 7 and older dialects, keywords sibling to `$ref` are never evaluated (draft_ref_siblings)
    at schema location "/properties/description/description"
spec/schemas/schema_defs.json:6:12:
  Future versions of JSON Schema will refuse to evaluate unknown keywords that don't have an x- prefix (unknown_keywords_prefix)
    at schema location "/$defs"

Note

I, along with Juan (JSON Schema TSC member) are defining linting rules for JSON Schema as a Part of a GSoC (Google Summer of code) project here - https://github.com/Karan-Palan/JSON-Schema-Linting, and implementing their auto-fixes here - https://github.com/sourcemeta/jsonschema/blob/main/docs/lint.markdown. We have recently added many rules prefixing unknown keywords with x- which will be introduced in the newer JSON Schema drafts
If beneficial to the project, I suggest integrating the complete cli with it to write the best schemas and catch any errors and follow best practices. Example of an integration - https://github.com/krakend/krakend-schema/blob/main/.github/workflows/validate-json-schema.yml#L10

[Karan-Palan]

If required, I can update the CI to have the cli in pre-commit job, and commit the auto-fixed schemas using jsonschema lint {schema-name/dir} --fix command. Examples - SchemaStore/schemastore#4831, daveshanley/vacuum#670 , daveshanley/vacuum#701

[dhower-qc]

Glad to see this!

I'd like to transition us even more to the sourcemeta tool (over JsonSchemer [Ruby] and jsonschema [python]) since I suspect it's going to be more helpful with error messages. However, when I tried a while back to use it for validation, it was hitting what appeared to be a sourcemeta bug while handling our schema. Might be time to revisit after this PR gets in.

And, yes, adding this to pre-commit would be great.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 46.05%. Comparing base (b5d25b9) to head (3160b65).

Additional details and impacted files

@@           Coverage Diff           @@
##             main    #1053   +/-   ##
=======================================
  Coverage   46.05%   46.05%           
=======================================
  Files          11       11           
  Lines        4942     4942           
  Branches     1345     1345           
=======================================
  Hits         2276     2276           
  Misses       2666     2666           

Flag	Coverage Δ
idlc	46.05% <ø> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[kbroch-rivosinc]

@dhower-qc : this new CI is failing for all the reasons flagged in the description, I assume we'd want to start with a passing CI before this PR lands?

[kbroch-rivosinc]

If required, I can update the CI to have the cli in pre-commit job, and commit the auto-fixed schemas using jsonschema lint {schema-name/dir} --fix command. Examples - SchemaStore/schemastore#4831, daveshanley/vacuum#670 , daveshanley/vacuum#701

Just heads up on --fix and that we are currently relying on prettier for formatting and that there could be some conflicts with that some of which discussed here:
sourcemeta/jsonschema#271

[Karan-Palan]

Updated the pre-commit in the following order:

1. jsonschema lint --fix (to fix the schemas)
2. prettier (to update the formatting if changed by jsonschema lint --fix command)
3. jsonschema lint to show any other errors that persist

This is done because the new version of the cli does not change schemas if auto-fixing contains breaking changes:

[dhower-qc]

@dhower-qc : this new CI is failing for all the reasons flagged in the description, I assume we'd want to start with a passing CI before this PR lands?

Correct. We'll want to fix up the files at the same time.

[Karan-Palan]

The CI fails as it prevents committing the changes caused by lint --fix command. If wanted I can push the changes after running pre-commit run --all-files and the CI will pass. That contains ~500 lines of code changes in schemas

[dhower-qc]

yea, add the changes in the PR here