search

hjkcai / typesafe-joi

A fork of joi that produces typed validation results in TypeScript
MIT License
73 stars 9 forks source link

joi-extract-type #5

Open typeofweb opened 5 years ago

typeofweb commented 5 years ago

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 commented 5 years ago

@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 commented 5 years ago

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 :grin: (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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

@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 commented 5 years ago

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 (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 commented 5 years ago

@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 commented 5 years ago

@hjkcai created #6

hjkcai commented 5 years ago

@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 commented 5 years ago

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 commented 4 years ago

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

dsebastien commented 3 years ago

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

TCMiranda commented 3 years ago

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 commented 3 years ago

@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.