-
Notifications
You must be signed in to change notification settings - Fork 9
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Support Joi extensions #80
Comments
Maybe we can support Joi extensions like Joi does and make Felicity extensible. Author of a Joi extension can also author a Felicity extension. We can create a new repo for |
Yeah I'm not sure about that either. I'll do some digging. |
Specifically take a look at supporting https://github.com/hapijs/joi-date-extensions first, since it is a Joi syntax that was deprecated in upgrading from Joi v9->v10. |
Once the extension API/convention is figured out, I'd like to remove joi-date-extensions from the dependencies and go back to using "vanilla" Joi. |
Per discussions with @danielo515 on #116, this could potentially be support through the use of a if (typeof Hoek.reach(schemaDescription, 'generate') === 'function') {
return schemaDescription.generate();
}
return this._generate(rules); |
This is a forum to discuss support and implementation of Joi extensions.
In order to maintain a 1:1 api parity with Joi, we will eventually need some level of support for Joi extensions.
It's important to note in thinking about implementation that extensions do not modify the Joi module itself, but provide a new Joi instance to the consumer. Felicity will not be able to pick up extensions automagically through Joi because of this fact. So we will need some sort of dynamic behavior for
example
andentityFor
around customized schema types/extensions.The text was updated successfully, but these errors were encountered: