Upgrade json schema version

[fcollonval]

Problem

It could be interesting to bump the JSON Schema version used from draft04 to some more recent flavor (last proposal is 2020-12).

The new version needs to be compatible with:

• JS ajv
• JS react-json-schema-form
• Python jsonschema

The Python package seems to be the one falling behind in term of standard support.

[bollwyvl]

Python jsonschema

Things look mostly fine here: Draft202012Validator, with the README suggesting a key missing useful thing ($vocabulary) will be supported, presumably at some point within the jsonschema@4.* release cycle.

JS react-json-schema-form

Indeed: I've been waiting with baited breath to get a live rjsf 5, which splits out the ajv dependency, so it can be upgraded. ajv is already a huge dep, so should be moved wholesale to 8, if possible, for lab4.

Getting this hoisted as a shared package would be huge, as well as loading it as lazily as possible, as it is, well, huge.

JS ajv

Of note: even ajv@8 still gets flagged for unsafe-eval, by default, and there's really no way around it for the kinds of dynamic things jupyterlab does (e.g. translation). When addressing this systematically, it likely makes sense to offer a IJSONSchema plugin, such that one could inject a "safe" parser... if it were to exist. It would definitely be slower... even the rust-based one says just go use ajv... and WASM is usually not the best place to go without a sound reason.

[bollwyvl]

rjsf 5 is out 🎉

[bollwyvl]

Buried in updating after 6 months of version drift, the actual work was not that bad upgrading to rjsf5/ajv8. Once I've done some more work (and gotten a 3.x compatible release out of the stable of downstreams), it should be relatively easy to get a PR together to get lab going.

I'm working on cutting the file sizes down... but as the lab ajv and rjsf aren't singletons/exposed, I was paying for it anyway.

However, lowering the bar for extension authors to "ship thoughtful schema, get 🍬" is going to be really good.

Also: holy mackerel, this looks like an excellent thing:

https://ajv.js.org/guide/typescript.html#type-safe-parsers-and-serializers

There are a lot of places where i do a lot of intermediate processing of schema to get to types, but having the ts directly consume and validate the JSON string off the wire seems really powerful for frequently-used message types.

[bollwyvl]

Some notes from the field of #13924:

[bollwyvl]

On custom keywords.

• we can't yet use ajv strict mode
  • while it is possible to add custom vocabularies...
    • ... we can't even pass that, due to use of the . character in custom plugin schema keywords
      • i don't know, or really care why
    • one approach would be to blanket replace . with : for URN-like constructs, e.g.:
      • jupyter.lab.internationalization
      • jupyter:lab:internationalization

[bollwyvl]

Of note: even if we move the front end to ajv8, eslint still uses ajv6. I don't know what the support window for ajv6 is.

[krassowski]

Closing because we migrated to draft07 in 4.0.x cycle:

• Update to ajv 8 and react-json-schema-form 5 #13924 (ajv8 by default uses draft07)
• Align JSON schema validator with one used on the frontend jupyterlab_server#423 (explicitly moved backend to draft07 to close the loop)

I believe it would be safer to stay on draft07 for a while, until support for newer versions stabilises, and because the newer versions have breaking changes we may want to wait until JupyterLab 5.