Update to ajv 8 and react-json-schema-form 5

[bollwyvl]

References

• starts Upgrade json schema version #13746

Code changes

• add version 5 of @rjsf/core, @rjsf/utils and @rjsf/validator-ajv8
• update to ajv8
• add explicit version property to plugin schema
• remove submit button with default ui:options rather than CSS (the .rjsf class is gone).
• applies (and removes) TODOs about replacing home-grown types with RJSF ones

User-facing changes

• forms return somewhat more useful error messages

master	#13924

Backwards-incompatible changes

• the ajv instances wasn't strictly exposed, so this probably doesn't change much
• the validator prop on FormComponent is required
• the props of custom fields, etc. will change

Feedback Sought

🛎️ @brichet @marthacryan @krassowski

Future Work

A follow-on PR will refactor the dependencies on ajv 8 and @rjsf/validator-ajv8 in a single @jupyterlab/validator-ajv8.

This will allow for cleanly replacing the runtime JSON Schema-related dependencies served to the browser by disabling the default provider.

@jupyterlab/builder could be changed (in another PR) to use a correct, but less-performant validator that isn't flagged for unsafe-eval, or somehow pre-compiles all the schema with ajv-cli.

[jupyterlab-probot]

Thanks for making a pull request to jupyterlab!
To try out this branch on binder, follow this link:

[fcollonval]

Thanks a lot for working on this @bollwyvl

I have one question.

[bollwyvl]

Thanks for the speedy review.

The follow-on work is proving quite tricky: moving the form validator out to a plugin/package in #13927 is no problem (aside from the CI complaints about installing not-on-npm packages), but trying to generalize the way settings (and other future consumers) use a number of ajv's features (like merging default values in-place) is challenging to think about without having a specific implementation in mind.

Of the recognized JS implementations, many appear unmaintained. Of the remaining, few have these capabilities, or the model of a "validator factory."

On the general topic of other implementations: all of this smells somewhat like security theater, as oh noes! unsafe-eval! in full JupyterLab is kind of... silly. I'd much rather spend time getting a nice, reusable lumino form for extension authors working for 4, but the architectural stuff seems like it is important to at least consider.

[bollwyvl]

Ubuntu's mirrors are having A Day, so i wouldn't sweat the snapshot tests failing at the moment. Not sure what the right approach is to get access to more mirrors.

[brichet]

Thanks @bollwyvl, that looks good to me.

Do you think we could do without the IMetadataSchema described in settingregistry ? It seems that its properties already exist in RJSFSchema.
It can also be done in a follow up PR, as I don't know the consequences of changing the properties property.

[bollwyvl]

Yeah, on this PR was looking to keep stuff similar-ish when i could.

But it indeed needs a further specialization of RJSFSchema to capture having properties, and or any special sauce.

[bollwyvl]

settingregistry

Actually, to that point: I think we don't want any RJSF (or any R for that matter) imports (even just type ones) in places we don't absolutely need them. By having a custom, documented type in the plumbing package, we are a little more able to keep stuff consistent if rjsf6 or whatever comes along and changes things during the lab 4.x line.

This is part of my motivation for breaking some more of these things up, and providing more Lab-owned APIs than relying on R/JSF: as an extension author, relying on

import {SchemaForm} from '@jupyterlab/ui-components'
...
activate: (app) => {
  //...
  const form = new SchemaForm({schema, instance});
  form.submitted.connect(() => app.commands.execute('some-command', form.instance))
}

...will require caring much less over time about the underlying packages, and getting to UI+validation quickly.

If an author wades into heavy customization, that's up to them! Indeed, I'd really like to be able to wrap a lumino Widget into the registry (i can taste the datagrid as an ArrayField) but that's real far down the line, and I'm unlikely to get to it in the 4.0.0 window.

[fcollonval]

Thanks @bollwyvl

As you mentioned, let's move on with the package upgrade with this PR. And leave further enhancement for follow up tasks.