Support for ES6 Types

[esatterwhite]

There is no way to validate against Map, WeakMap, Set, WeakSet or Symbol. Right now the only work around I see is to define them as joi.any() in a schema.

[hueniverse]

Joi is not really a JS types validator. It is for input validation...

[esatterwhite]

Yes, I understand that. Maybe I worded the issue poorly. But the problem remains that there is no way to validate input that is of or objects that contain those types.

{
    a: 1,
    b: Symbol('b'),
    c: new Set([1,2,3])
}

The only way to deal with this would be to not validate some of the keys / use object().unknown(), or to use joi.any() for b and c and do some manual validation of them.

[bricss]

@esatterwhite did you ever seen the plain JSON with that kind of types Map, WeakMap, Set, WeakSet or Symbol?

[esatterwhite]

@bricss if by plain, you are mean what JSON.parse and stringify support, then no. But that is not the problem. The problem is that it is not possible to validate objects of or containing those types with joi

[AdriVanHoudt]

to come back to what @hueniverse said the description of Joi does state ... and validator for JavaScript objects

[esatterwhite]

Not if the objects contain sets, maps, or symbols.

[esatterwhite]

Plainly - ES6 introduces new primitives that joi should understand just as well as arrays, objects or strings

[Marsup]

I agree that it's core-ish, I don't want to ship it with normal joi builds, but there should be an extension for it, not necessarily an official one, but if it gets adoption it would make sense to have it in hapi org.

[AdriVanHoudt]

My comment was pro integrating the new types btw ;)
@Marsup why not ship it with normal builds?

[Marsup]

Because it would make Joi fatter than it already is, and it's usually not needed, most people validate POJOs.

[Marsup]

Another way would be to have require('joi') and require('joi/es2015').

[Clement-TS]

And what about promises? Actually we have to set a callback, and joi is not thenable right?
I also feel joi should include new JS features.

[Marsup]

This specific detail isn't related to this issue and has already been answered in #636 (comment). I don't think there's anything to check in promises either.

[Marsup]

Is anyone interested in implementing the last strategy ?

[AdriVanHoudt]

can't we just do this with .extend() now?

[hueniverse]

Closing due to lack of interest.

[kirillgroshkov]

Would be nice to have it:)

[candu]

Agree that it's useful, and also that it's probably best handled with an extension. I'll provide a sample use case as well, in case that helps motivate this - the TL;DR here is that, as mentioned elsewhere, Joi is used for validating both input and output.

I'm building a REST API with Hapi. To limit N + 1 query problems, several endpoints perform multi-lookups by some ID / field. One natural way to return those results is as a Map: that way, I can guarantee that I'm not duplicating results.

Of course, ES6 Map doesn't exist in JSON, so I configure routes.json.replacer to apply Array.from here:

replacer(_, value) {
  if (value instanceof Map || value instanceof Set) {
    return Array.from(value);
  }
  return value;
},

I can then either do new Map(response) in the frontend, or even build a REST API client layer that uses the reviver argument to JSON.parse to do that automatically.

Now, this isn't the only solution to my problem. I could instead use Array.from() within the REST API endpoint handler and validate it as an array instead:

response: {
  schema: Joi.array().items(
    Joi.array().ordered(keySchema, valueSchema),
  ),
},

That's OK, but it does mean that I'm weakening the response type guarantee from my REST API.

(Of course, if I really care that my REST API returns a Map and not the result of Array.from(myMap), one might reasonably tell me I'm better off using a statically-typed server-side language.)

A hypothetical equivalent map() validator might look like:

response: {
  schema: Joi.map().entries(keySchema, valueSchema),
},