Joi: Feature Request: generate valid example from schema

[mjgpy3]

I just wanted to start by saying that this is an excellent library, keep up the great work!

Is there a way (or library) or would you be open to a PR that generates a random, valid example from a schema?

Something like

var schema = Joi.object().keys({
    username: Joi.string().alphanum().min(3).max(30).required(),
    password: Joi.string().regex(/^[a-zA-Z0-9]{3,30}$/),
    access_token: [Joi.string(), Joi.number()],
    birthyear: Joi.number().integer().min(1900).max(2013),
    email: Joi.string().email()
}).with('username', 'birthyear').without('password', 'access_token');

schema.example()
// => { username: 'asdgdas', password: 'gdsaa', birthyear: 2000, email: '[email protected]'  }

schema.example()
// => { username: 'dasgasdg', access_token: 12345, birthyear: 1901, email: '[email protected]'  }

I'm asking because this would be a brutal feature in combination with something like F#'s JSON TypeProvider

[Marsup]

We tried with example, but it's probably way too complex if you want to make it right. Feel free to give it a shot but making sure you respect all the conditions of a schema is going to be a nightmare. Good luck ;)

[WesTyler]

@Marsup - question for you about this. We built a partial solution to this at work (XO Group) this Spring and have been working toward open sourcing / completing it. Do you think it would be more valuable to submit a PR against Joi itself to build upon the existing project (as described above), or build it as a separate tool to compliment the Joi module (as illustrated below)?

const Joi     = require('joi'),
      Builder = require('plugin-being-built');

let schema = Joi.object().keys({ /* ... */ });

let validSample = new Builder(schema); // =>> { key1: 'validValue1', key2: 'validValue2', ... }

[Marsup]

I'd say it's perfectly fine outside of the core. I may start referencing external projects if that helps people find resources...

[WesTyler]

Awesome, thank you for the input!

[Marsup]

How did you do the implementation btw ? Based on internals or on the undocumented describe ?

[WesTyler]

It's based on the internals of the schema.

And full disclosure: we definitely do not have full coverage of all of the conditions and tests that can be added to all of the data types. We covered what we needed, plus a bit more. Part of our OSS path, though, is expanding that coverage to most, if not all, cases.

[Marsup]

I'm sure you'll get contributors with the same goal. It would have been better to use the API (even though undocumented), I'll change the internals without warning.

[WesTyler]

Yeah, both of those points were actually partial drivers behind our desire to open source.

Right now our internal code is pinned down to a specific version of Joi, so we felt _okay_ using the internals, but we have a larger initiative to unpin our strict version dependencies. Almost certainly as we untangle our implementation into an OSS-able project I will be doing some refactoring, and will certainly keep that suggestion in mind. Thanks!

[WesTyler]

Hey there, just wanted to update you guys since I've been silent on this for the past couple of months. We have OSS'ed the project I mentioned above for generating valid examples based on a schema definition: Felicity.

We haven't deployed v1 to npm, but v0.0.4 on npm should have basic enough functionality to get the idea of how it is working. Also v1 is almost complete on the master branch of the repo if you want to fork/clone to get a better feel for v1 functionality.

[WesTyler]

We just officially launched Felicity v1 to NPM!
http://blog.eng.xogrp.com/post/153784367849/introducing-felicity
https://github.com/xogroup/felicity

[Marsup]

Congrats !

[Marsup]

I guess I'll close this issue now 😛

[lock[bot]]

This thread has been automatically locked due to inactivity. Please open a new issue for related bugs or questions following the new issue template instructions.