.validate(schema) should not dereference the schema

[Jack-Works]

Validator should only check if the schema is correct, but validate() modified the input object.

(Oh my it spent my a whole hour to find validate() mutate the object...)

Workaround: validate(_.cloneDeep(schema))

[JamesMessinger]

Please see my comment on this issue

[Jack-Works]

Umm so can validator deep clone it internally? This behavior is out of expectancy

…

On Tue, Jan 9, 2018, 22:06 James Messinger ***@***.***> wrote: Please see my comment on this issue <#77 (comment)> — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#80 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AFJBf664mlom1w5WuvHP5tpk-tSZWt0wks5tI3JqgaJpZM4RXyTc> .

[JamesMessinger]

I agree that mutating the object is bad behavior. But here are the reasons that I chose to do it that way:

1. I don't want to bloat the library by adding a deep-clone library
2. There are many different deep-cloning algorithms, each with their own trade-offs, and regardless of which one I chose, some people would complain
3. Most people use Swagger Parser to parse/validate files, not in-memory objects. So this mutation behavior only affects a minority of users

That said, there is a solution coming soon. In an upcoming release, I'll be removing the validate() method altogether and moving it to a separate package. So the swagger-parser will only contain logic for reading, parsing, resolving, and dereferencing. The swagger-validator package (or whatever I end up calling it) will contain the validation logic. There are several benefits to this:

1. It reduces the size of the swagger-parser package significantly, since its largest dependency is the JSON Schema validator. This is especially valuable for people who don't need the validate() method.
2. It decouples the parsing and validation logic
3. It gets closer to the Node principle of small, single-purpose packages
4. It allows people to write their own validators on top of swagger-parser. So if want to use a different JSON Schema parser, or bundle-in a deep-cloning algorithm, you can do that.

[Jack-Works]

You're right, there are always something community will argue about I'll wait for the isolated validator, thank you

…

On Tue, Jan 9, 2018, 22:31 James Messinger ***@***.***> wrote: I agree that mutating the object is bad behavior. But here are the reasons that I chose to do it that way: 1. I don't want to bloat the library by adding a deep-clone library 2. There are many different deep-cloning algorithms, each with their own trade-offs, and regardless of which one I chose, some people would complain 3. Most people use Swagger Parser to parse/validate *files*, not in-memory objects. So this mutation behavior only affects a minority of users That said, there *is* a solution coming soon. In an upcoming release, I'll be removing the validate() method altogether and moving it to a separate package. So the swagger-parser will only contain logic for reading, parsing, resolving, and dereferencing. The swagger-validator package (or whatever I end up calling it) will contain the validation logic. There are several benefits to this: 1. It reduces the size of the swagger-parser package significantly, since its largest dependency is the JSON Schema validator. This is especially valuable for people who don't need the validate() method. 2. It decouples the parsing and validation logic 3. It gets closer to the Node principle of small, single-purpose packages 4. It allows people to write their own validators on top of swagger-parser. So if want to use a different JSON Schema parser, or bundle-in a deep-cloning algorithm, you can do that. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#80 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AFJBf1mq2aJTezIGDgQoWHUZ3ekLukYFks5tI3hCgaJpZM4RXyTc> .

[shwetashukla]

Is the validator seprated in a different package ?
I was trying to use the validate and what i found is it breaks on finding the first error doesn't report all the errors in the document.

[silversoul93]

some news on this issue?

[dperez3]

For my use case, it would be great if I could pass in a new configuration property that can disable/ignore dereferencing so that the object is not modified, but with the documented understanding that the referenced objects are then not validated.

Perhaps this can even be more specifically applied to just local JSON pointers (which would get validated anyway without having to dereference).

Would you be open to a PR for that? Not making promises, but it's something I may be able to help with.

Either way, I'll use deep cloning in the meantime.

In any case, thank you for best packages I was able to find! ⚡