Expose errors from filter feature
#54
Open
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
* Make errors available when using this feature * Ignore errors from `additionalProperties: false` * Formalize semantics in `README.md` * Warn about input mutation. * Warn that this is a non-standard feature. * Added test cases covering the `filter` feature
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
filterfeatureadditionalProperties: falseREADME.mdfilterfeatureThis is clearly an implementation-specific feature. I'll admit I thought it was a bit weird when I first saw the feature... But I now realize that is has some use-cases, and, hence, think that issue #44 deserves a bit of attention.
Interface change, before the feature was available both using the option flag
filter: trueand usingvalidator.filter. As thevalidator.filterinterface doesn't expose errors I think it makes most sense to restrict to the option flag method (it seems like a good way to provide various implementation-specific options).Formal semantics, I changed the implementation to ignore errors from
additionalProperties: falsewhenfilter: true... But still produce all the other errors. I'm not what semantics are best for this feature, but it seems reasonably sane to say that idea to change the semantics ofadditionalProperties: falsefrom producing validation errors, to instead deleting additional properties.This way the validation errors produced are still well-defined, all we have a clear change in semantics for objects with
additionalProperties: false.