Lack of error messages hampers adoption

[ghola]

We're currently using json-guard to validate incoming API requests. The validation errors it produces are developer friendly and can be localized. You can immediately use them as part of the API error response.

Unfortunately json-guard is abandoned and we're looking to switch to a different library. justinrainbow/json-schema is a hot mess, so that leaves us with swaggest/json-schema and opis/json-schema. Both the swaggest and opis libraries are lacking developer friendly error messages.

I read the conversation in #11 and thought about implementing a formatter/renderer as suggested. Unfortunately, to do so I pretty much have to go though the entire spec and test each possible error to see how it looks in opis/json-schema. For someone who wants to consume a library, this requires intimate knowledge of the library internals.

So IMO this library is incomplete/unusable until error messages are added and most likely other people will decide to stay away from it as well. Hence the issue title. As for us, we will keep using json-guard for now.

[ghola]

I forgot to mention that the path for the invalid element is vital as well. Without it, the error message by itself can potentially be very unhelpful.

[msarca]

As an open-source company, we are constantly investing thousands of man-working hours into open source projects like Opis, and we are paying from our own pockets for the costs. And trust me, the costs are not small! Now you are coming here and tell us that our library is unusable because it doesn't fit your company's commercial product by default? C'mon! You have a product built on a library that uses a different formatting, you don't want to build a custom formatter because that takes time and money, so you thought that you should ask us to do it for free? Well, it doesn't work like that.

Opis Schema is a great library, well maintained and well documented. If your company wants to stick with a library that has severe security issues that will never be addressed because the library is unmaintained, we're fine with that! It's your reputation and your business at risk, not ours. As for the other libraries out there.. Let's get serious! We didn't invest such a great amount of time into this library just for fun.

Good luck and good day!

[ghola]

I think for the most part you are correct in your statements, but if you take out the drama in all of this, the issue I raise still holds true. Most consumers of this library will need to implement a (more or less buggy) formatter when it would make more sense for it to be part of the library. I don't expect you to admit it to me, but think about it without the anger and outrage.

You can take our need as an example of a real need that does exist out there. In this case it was an asshole expressing it, but maybe not all users of the library are like that :).

[msarca]

I don't want to be mean, but the only drama here is that your company is using an unsecure and unmaintained software for providing services to the public, and It seems to be determined to keep using it. As for myself, I admit that I would be more than happy to be able to tell you that we have some kind of formatter that works great with your private software. But we don't have it. We'll try to think a solution that works well for all users. Until then I strongly suggest you to switch to Opis Schema and implement a custom formatter. It definitely worth doing it

[sorinsarca]

We're currently using json-guard to validate incoming API requests. The validation errors it produces are developer friendly and can be localized. You can immediately use them as part of the API error response.

Yes, the errors are friendly when you are using simple keywords like minLength -> "The string must be at least 5 characters long.", but when you are using keywords like anyOf you get "The data must match one of the schemas." which is helpful if (and only if) you are exposing your schemas, otherwise is nonsense or equivalent to "Unknown error".

I forgot to mention that the path for the invalid element is vital as well. Without it, the error message by itself can potentially be very unhelpful.

This will be added.

You can take our need as an example of a real need that does exist out there.

We are, that's why I'm closing this in favour of #16.