Evaluate alternative library to replace joy-browser

[noandrea]

• I'm submitting a ...

  • bug report
  • feature request
  • support request => Please do not submit support request here, see note at the top of this template.

• What is the current behavior?
  the library joy-browser is very heavy in terms of dependency size

• What is the motivation / use case for changing the behavior?

Evaluate another library to validate arguments of contract calls.
Otherwise explore the possibility to add the checks on the compiler side (preferred)

• Please tell us about your environment:

  • SDK Version: v6.0.2
  • Environment: browser

• Other information (e.g. detailed explanation, stacktraces, related issues, suggestions how to fix, links for us to have context, eg. forum, telegram, etc)

related to #435

[noandrea]

hey @tarasherasymchuk, any findings on this one?

[tarasherasymchuk]

@noandrea there is a library like this: https://www.npmjs.com/package/validator
but didn't have time to go through all cases that are needed.

[tarasherasymchuk]

There are some results of the investigation that was targeted to find an alternative for joi-browser.
During the investigation, two libraries were taken into account: validatorjs and schema-typed.
The former one is supposed to work only with strings and other string-based input.
The latter one is more robust (in terms of data types support) and it's pretty good when only simple types (list, object, object shape, string, number) are used in the app. The other side in using this library is that it does not support extensions (like creating custom data type validators), it only supports adding additional rules to the existing data types validators. So, we cannot integrate this library because of custom data types like hash, address, binary, tuple, etc.
So there was an attempt to develop a simple schema validator on our own. After some small development, it appears to be a non-trivial task that requires solid efforts to implement a robust library with informative messages (with required object depth). Also, it requires additional efforts to test it and to support it.
Even if the development team spends some time to develop a well-tested and robust library, there is no guarantee that this library will be smaller in size than joi-browser.

Currently, it looks pointless to spend some time for the development of our own schema validator, because it might have the same size as joi-browser has + we will spend enormous a great deal of time for development and testing instead of just using joi-browser that is a mature and well-tested library that also generates error messages with the desired object depth.

enhancement branch with a demo schema validator

[davidyuk]

joi was removed in #1313, arguments are validated by @aeternity/aepp-calldata library