Joi: Possible to extend with custom validation functions?

[gebrits]

Is it possible to extend Joi with custom validation functions?

[hueniverse]

No. There is little point in that. You can just run whatever functions you want on the data before or after. By keeping all the validation logic well specified, we can do other smart things like auto doc generation.

[Marsup]

I need to validate dates stronger than what joi currently allows, that is :

• a specific format (DD/MM/YYYY)
• check the date actually exists, November 31 is transformed into December 1st since it doesn't exist

How do you suggest I go about it ?

I'm ok to submit a PR to complete date but I think extending any should be allowed for custom validations.
As long as people follow the internals conventions, they should be able to benefit from auto doc generation or other goodnesses.

[hueniverse]

How would that work? example?

[Marsup]

Since base objects are not currently exposed and I'm not sure you're willing to, what would you think of a backbone-like api ?

var customValidator = Joi.any.extend({
    type: 'CustomDate',
    initialize: function() {
        this._test('customdate.base', ...)
    },
    format: function(str) {
        this._test('format' ...)
    },
    _private: function() {}
});

var error = customValidator().format('DD/MM/YYYY').validate('....');

Not sure about Any.error and Utils.assert, maybe expose through this ?

[rlidwka]

+1

I've been using EVE for validation for a long time, and would like to migrate to joi (since that one seem to be unsupported), but an absence of custom validators/transformers here just make that impossible.

[bf]

+1

would be interested into custom validation functions, too

[hueniverse]

@Marsup I would be happy to support the date requirements. I am still opposed to extensible types.

[Marsup]

Would that be ok to include moment for that ? I don't see any reason to reinvent the wheel.

[hueniverse]

I guess.

[myndzi]

+1 some more.

Putting your schema all in one place is advantageous. Forcing the user to perform multiple separate validation steps kind of defeats the purpose of using a validator library.

Here's an example use-case:

I'm implementing a Syslog library with support for structured data. By the RFC, the 'language' value should be a valid BCP_47/RFC4646 language tag. There's a module for that. But can I do anything so simple as { language: Joi.string().validator(tags.check) }? Nope. Now I'm writing validation code which I would rather use Joi to take care of, either in the form of special case functions wherever I call Joi to validate some data or wrapping it in a custom function (which I see you recommending in another custom-validation thread).

It seems like "automatic documentation" is your sticking point, and I just don't understand it. Where does Joi provide anything to generate documentation? Or are you talking about Hapi, in which case, why is it a concern of Joi's to begin with? Or perhaps you're talking about the core Joi documentation, in which case, why would you feel like custom functions need to be documented in Joi's core? Of course they are beyond the scope of the Joi documentation. Custom validators aren't there to fork and extend Joi, they're to add purpose-specific validation to a specific local use of the library.

You want to encourage 'configuration over code', but here you are making a decision that forces code over configuration. No matter how I look at it, I can't see a good reason for sticking so stubbornly to this refusal to implement a wholly useful and obviously desired feature that will take almost no effort to include. Please reconsider.

P.S. - Another problem this causes: inconsistency in validatior error reporting.

[Marsup]

As the long time maintainer of lout, I beg to differ on the documentation side, it is useful and I have no doubt that documentation through code is a great win for anyone who has ever bothered maintaining synchronized code and documentation. It's not yet a supported API hence you don't see it in the docs but it's not a reason to break it.
Now as the new maintainer of joi, I'm willing to at least think about the best possible way to make this happen but it won't happen overnight because it's not as easy as you may think.

[myndzi]

I'm not suggesting so much that it's easy as that it's necessary. I know what you mean about synchronized code and documentation, I'm just confused as to how custom validation functions are any harder to document than anything else, from joi's core's side of things. Its not your responsibility to document the functions people write into it, nor could you possibly do so. The api is pretty obvious given the existing code: it'd be an any() method like .regex() but instead it would call a function. It's nice to hear there's a possibility of getting some action on this; what are the problems that need solving?

[jordancardwell]

+1(million)

[Marsup]

@rlidwka @myndzi @jordancardwell @gebrits #577 is now open for discussion, chime in please.

[kamronbatman]

@Marsup Any update on this? I am sifting through and looking to go with a validation library. Since I am validating dynamic data and I need to do cross-reference checks, it would be nice to be able to create custom validation strategies, or types.

[Marsup]

As the last part of #577 says, it's currently in a branch, I'll try to release an alpha on npm since no one seems interested in giving feedback based on a branch.

[WoLfulus]

@Marsup Is this working? I need to make extensions for document numbers (my country).

[georgyfarniev]

Hello @hueniverse , I’ve been searching through many validators and found this one, which made me very happy: not overloaded syntax and clear functional style. However, for our big ecosystem we need to validate custom data (such as check company registration number, etc). If joi cannot provide option for custom validation, it would be very inconvenient. I would like to know if you still opposing this change or not, because we are making important choice between class-validator and joi. I definitely like joi more, except that we need this feature.

[Marsup]

It's been here for quite a while now, this issue is from 2016. See https://hapi.dev/family/joi/?v=16.1.8#extendextensions.

[georgyfarniev]

@Marsup I missed that out, thank you.

UPD:is there a way to add async validation for custom function? Because I need to query db and other facilities for validating data.

[hueniverse]

@georgyfarniev you are being a bit lazy. You can't search the API page for async yourself?

[georgyfarniev]

@hueniverse cannot disagree about lazy, but I wasn’t able to find that out. I will double check it from my laptop tomorrow. On iPad mini docs little bit inconvenient.