Closed antialias closed 4 years ago
The question is, why the default behaviour should change. The purpose of having breakOnFirstError:false
as default, is that usually I want to see all the errors in the JSON, and not go through the validate-fix-validate-fix-validate-fix loop.
breakOnFirstError
makes sense when you want as fast validation as possible (but honestly there're faster alternatives published out there since I've written this code in 4-5 years ago), but this project had in mind to conform to as much specification and give as many features as possible.
That's why I also don't see much reason by having ignoreUnresolvableReferences:true
as default as well. What's your usecase for that?
The purpose of having
breakOnFirstError:false
as default...
So just to be clear, breakOnFirstError:false
should be the default because the most common use case is that users want to see all the errors up front so they don’t have to go through the validate-fix loop?
The question is, why the default behaviour should change.
Perhaps because you provided a detailed explanation and sensible argument for why the default behavior should be breakOnFirstError: false
– default behavior is currently breakOnFirstError: true
.
bump
npm publish
+ z-schema@5.0.0
This seems like a more sensible default. Should be published with the next major release since it is a breaking change to any dependent that doesn't explicitly set this config value.