support unevaluatedProperties

[smeijer]

With unevaluatedProperties: false, additional keys { [key: string]: unknown } should not be allowed. The unevaluatedProperties keyword is similar to additionalProperties except that it can recognize properties declared in subschemas.

https://json-schema.org/understanding-json-schema/reference/object.html#unevaluated-properties

[ThomasAribart]

Hi @smeijer and thanks for the heads up ! I'll look into it ASAP!

[smeijer]

Do you have any pointers for me if I were to take a stab at this?

[ThomasAribart]

Hello @smeijer ! Sorry I was busy with https://github.com/jeremydaly/dynamodb-toolbox and https://github.com/castore-dev/castore

Could you start by creating a failing test for unevaluatedProperties ? I'm still wrapping my head around what it does

I use jest for unit-testing as well as A.Equals from ts-toolbelt for type assertions. You can extend src/parse-schema/object.unit.test with unevaluated properties cases.

[toomuchdesign]

Hi @ThomasAribart! Here is a failing test for allOf + unevaluatedProperties: https://github.com/ThomasAribart/json-schema-to-ts/pull/149

And this is my use case for unevaluatedProperties: https://www.jsonschemavalidator.net/s/FQPxdYIV

The idea is to "merge" different JSON schemas declarations providing instructions about how to deal with extra props. In this case setting unevaluatedProperties to false does not allow any other extraneous props, but it might be configured to better fine tune what kind of extraneous props are allowed.

BTW, I believe that even an initial support for unevaluatedProperties set to false only, could provide a lot of value.

Unevaluated Properties docs: https://json-schema.org/understanding-json-schema/reference/object.html#unevaluated-properties

Happy to try and provide a possible implementation based on what you think is the right direction to go.

[smeijer]

Thanks for the extra context info @toomuchdesign!

This ticket totally slipped my mind. I'd still benefit from a fix, but unfortunately don't have the time atm to work on a pr.

[feritarou]

Hello everyone! I'm also definitely interested in this, since I'm quite extensively using "partial" JSON schemas and references to those via allOf. Any news on this and/or pointers as to where I could start implementing a PR are appreciated!

[ThomasAribart]

I kind of see how to do it but it's not trivial. Will look into that this week.

[aliyss]

Hi just for some info, this is based on draft 2019-09

[feritarou]

Hello everyone, any progress since "this week" of half a year ago? :smile:

[ThomasAribart]

Sorry I'm focused on the v1 of dynamodb-toolbox right now. But I'll come back to json-schema-to-ts once it's released.

If someone wants to take a shot at this, here's what I think should be done:

First, update https://github.com/ThomasAribart/ts-algebra Meta-objects to have a closeOnResolve property which removes the { [x: string]: unknown } if set to true. Release a major version as its a breaking change.

Then use it here if unevaluatedProperties is set to false + actually use the unevaluatedProperties if it is a json schema, like I did with additionalProperties and patternProperties

[toomuchdesign]

Thank you @ThomasAribart! While taking a look at ts-algebra I've read the unevaluatedProperties specs again:

Validation with "unevaluatedProperties" applies only to the child values of instance names that do not appear in the "properties", "patternProperties", "additionalProperties", or "unevaluatedProperties" annotation results that apply to the instance location being validated.

For all such properties, validation succeeds if the child instance validates against the "unevaluatedProperties" schema.

This means that "properties", "patternProperties", "additionalProperties", and all in-place applicators MUST be evaluated before this keyword can be evaluated.

[ThomasAribart]

Should be supported in 3.1 !