Make next-typesafe-url validation library agnostic

[ethanniser]

currently next-typesafe-url requires the use of zod

it would be ideal if it could support a multitude of libraries:

typebox, valibot, @effect/schema, etc.

trpc supports a bunch of validation libraries, we should look to do something similar

https://trpc.io/docs/server/validators
https://github.com/trpc/trpc/blob/main/packages/server/src/core/parser.ts
https://github.com/trpc/trpc/blob/main/packages/server/src/core/internals/getParseFn.ts

[riordanpawley]

I found this the other day: https://typeschema.com/
Other than missing @effect/schema support at the moment, it seems to do exactly what we're looking for here.
We can probs just put up a PR for @effect/schema on their github and use typeschema.
Do you see any benefit to maintaining our own lib agnostic validation code instead of rolling with typeschema?

[ethanniser]

@riordanpawley thank you for sharing this

Do you see any benefit to maintaining our own lib agnostic validation code instead of rolling with typeschema?

No, this project is awesome and we should use it.

We can probs just put up a PR for @effect/schema on their github and use typeschema.

Agree, can't imagine it's too difficult. Could probably get some effect guys to do it as well.

[decs]

Nice, let's partner up on this! I saw that someone just sent a PR for @effect/schema support (decs/typeschema#17). I'll work with them to get that production ready to unblock your integration.

[ethanniser]

Thanks for the help! I'll give it a shot when I get home. I think it should be as easy as changing the zod infer methods to the type schema ones, plus some small runtime stuff.

My hope is that updating the docs will take longer.

[ethanniser]

@decs ran into a small issue
I can't discriminate the union returned from validate
Heres a reproduction: https://tsplay.dev/WJ13Rm

Would it be possible to add a success: true | false field to the result type to discriminate them? I showed an example in the playground link

[decs]

hey, @ethanniser! to follow up on @effect/schema support, it's now landed and released as part of v0.10.1.

for discriminating between success/fail, you can check for the existence of the "issues" key, like so:

if ('issues' in result) {
  console.log(result.issues);
} else {
  console.log(result.data);
}

[ethanniser]

@decs got it thanks for the help!
it may be worth adding an example of this on the docs/website, thats the main reason I was confused at first

---

if I may ask, do you have a specific objection to having a discriminating field like success? I would consider this behavior pretty standard for validation libraries like this (if they choose to not throw errors):

zod:

valibot:

typia:

in my opinion, having a discriminating success field makes code clearer and more readable, as well as being more in like with 'standard conventions' for union types

happy to move this discussion to an issue on the typeschema repo btw

[decs]

hey, @ethanniser! initially, I had picked issues in result (instead of results.success) because it would result in a more concise object. but this isn't the first time I get this question, so I can see it's not that intuitive.

I decided to update typeschema to add a success field and released it as v0.10.2. let me know if that works, thanks!

[ethanniser]

@decs looks great, appreciate your support
really excited to get this shipped

[ethanniser]

@decs wrote some basic tests using valibot and typebox for the functions that take in a generic schema

but im getting some weird errors

the exact same code works with no issues in a playground: https://tsplay.dev/mqylQm

any clue what this might be? im using ver 0.10.2
thanks again for all the help with this, really appreciate it

[ethanniser]

I'm closing this as not planned.

Long term I want to move to @effect/schema which will address #77 fully