joi-extract-type

[typeofweb]

Hey! 👋 First of all let me tell you I love this library and this approach to making Joi type-safe!

There's another very similar library out there: https://github.com/TCMiranda/joi-extract-type
It seems to have similar goals and patterns. Do you think any kind of cooperation or inspiration is possible?

It would be a pity to have two very similar libs, both in early alpha-stage, instead of one polished lib, thanks to common effort :)

[hjkcai]

@TCMiranda Hey, what is your opinion? I'd like to cooperate to make a better library.

Anyway, TypeScript is currently too far away from expressing joi's API. So I think there must be a standalone package.

[TCMiranda]

Hey @hjkcai thanks for reaching out. I like your approach.

Having a standalone package is nice to discourage the usage of "undefinable" methods like reach: https://github.com/hjkcai/typesafe-joi/blob/master/joi.d.ts#L1462
Just by using the declaration it should be possible to ignore those methods 😁 (Of couse I see problems with this if the goal is to enhance an existing code base, but would be great for new projects).

Is this within your goals?
That is the only thing I didn't understand.

---

About the code / cooperation, I see that we had a different approach. I've built upon @types/joi using module augmentation.

So the code I wrote is considerably shorter. This library is more complete thought. Not everything is easy to do with module augmentation since the types must be compatible. This is another advantage on your approach.

Can you also give me your perspective on the implementation aspect?

[TCMiranda]

Also @hjkcai do you have in mind what are the next goals you want to accomplish?

ps. Also thanks @mmiszy for connecting us on this thread.

[typeofweb]

Another advantage of joi-extract-type is that it's compatible with existing Hapi typings so you can still use your schemas to validate request/response. You get some errors with typesafe-joi. Other than this, both are pleasant to use :D

[hjkcai]

@TCMiranda Thanks for your reply. In the very beginning I just needed something like typesafe-joi or joi-extract-type to simplify my validation code. I did a lot of search but only found gists and repos still in prototype stage. Then I started to create this. In fact I don't really have a shape of what this library will going to be. What I would like to build is the original flavor of joi in a typesafe way.

However, when I was reaching this goal, I found that joi is so powerful that TypeScript can never cover all its APIs statically. And like you said: "Not everything is easy to do with module augmentation since the types must be compatible." By rewriting the original joi interfaces it is more flexible to do more TypeScript magic. So I chose to make a new library. Also I copied everything else from the official @types/joi package to make typesafe-joi more compatible with joi.

So I think my goal is:

Make typesafe-joi the closest approach to typesafe and joi

[hjkcai]

Having a standalone package is nice to discourage the usage of "undefinable" methods like reach: https://github.com/hjkcai/typesafe-joi/blob/master/joi.d.ts#L1462 Just by using the declaration it should be possible to ignore those methods 😁 (Of couse I see problems with this if the goal is to enhance an existing code base, but would be great for new projects).

Is this within your goals?

No, I think users should use those "undefinable" methods if they need them. Since users want to use those methods, they have to accept that the TypeScript magic does not work at all. But we can help users to define the type by themselves. For example:

Joi.object({ a: Joi.string() }).rename<{ b?: string }>('a', 'b')

Also @hjkcai do you have in mind what are the next goals you want to accomplish?

1. Stability: There are too much recursion in typesafe-joi. It makes TypeScript pretty slow (you can feel it in vscode). Also TypeScript was crashed once (typesafe-joi blows up TypeScript 3.2+ microsoft/TypeScript#28873).
2. Unit tests: of course we need quality!
3. Help user define their types: the example above.
4. Documents: some users will be confused by the current readme because it is too simple.

BTW, I wanna say sorry because I am doing intern and writing graduate paper simultaneously. I guess I will have no enough time for this library until my graduate 😞. Please let me know if you have time to help me make this library better. Thanks!!!!!!

[hjkcai]

@mmiszy

Another advantage of joi-extract-type is that it's compatible with existing Hapi typings so you can still use your schemas to validate request/response. You get some errors with typesafe-joi. Other than this, both are pleasant to use :D

Hey, please tell me what it is. Maybe I can fix it.

[typeofweb]

@hjkcai created #6

[hjkcai]

@mmiszy @TCMiranda I have published typesafe-joi 2.0.0 alpha version, which is more powerful now. Please have a try! If you found any bug, feel free to open another issue 😀

[typeofweb]

Thanks a bunch! I'll pull it and test together with https://github.com/mmiszy/typesafe-hapi and probably release a new version too :)

[Melodyn]

Today I tried both libraries and yours has an important advantage - it works! :)

[dsebastien]

I'm curious about the state of your two libraries. Are they both still maintained?

[TCMiranda]

Hi, joi-extract-type is fine and maintained for joi version 15.
Version 16 is out of reach with the "patch" strategy it uses.

[hjkcai]

@dsebastien typesafe-joi maintains for bugfix only. Joi v16 has changed to a too dynamic way so that there is no way to statically define the core API. Yup is another joi-like lib with active maintenance and type safety.