Allow for different validator libraries

[softgripper]

Is your feature request related to a problem? Please describe.

Many parts of the web ecosystem allow for different pluggable technologies.

For example, Prisma, tRPC and Felte allow for different, 'typesafe' validator implementations

I have a couple of projects using superstruct, and a couple using Zod, and am starting one with @effect/schema.

I've used Felte a bit, and it's reasonable, however I really like the look of Superforms.

Describe the solution you'd like

Allow for use of other validators (eg, yup, superstruct, joi, validator.js, @effect/schema) etc

Describe alternatives you've considered

The alternatives are

1. Use superforms only on projects that use Zod.
2. Rewrite validation in other projects to Zod if you want to use superforms (not realistic).
3. Write my own "validator X -> Zod" wrapper - which is more code, more dependencies in the consuming app etc (not realistic).
4. Don't use Superforms 😞.

[ciscoheat]

Hi, this question has come up a couple of times, and it's hard to find a library with the requirements needed for Superforms to work properly.

The biggest issue with most other libraries is that you cannot introspect the schema nowhere near Zod's level. For example, I'm able to extract at runtime every little aspect of the schema, generating constraints based on min/max values, regexps, nullable/optional, etc. Also, the default values must be extractable, so correct types can be generated for empty schemas.

Another thing is that the validators consists of validators in Zod, which makes it possible to make a field-for-field validation on the client, so you don't have to run the whole schema for every keystroke, which is especially problematic if there are async validation going on, like a user name check that calls the server.

Because of side effects in schemas (refine/superRefine that sets a custom path), per-field validation is not an issue anymore. The whole schema must always be validated to know the final result.

I've searched around plenty to be able to make an informed decision about this, and haven't been able to find a library except for Zod that satisfies these requirements.

So this won't happen for the upcoming 1.0 release, but maybe 2.0 could do it, if there is some clever way of doing "progressive enhancement" for the data returned from superValidate based on the validation library used: For example, if a library doesn't support constraints, return a type without them.

[softgripper]

For V2, I guess the starting point would be to define the interface that superforms requires from a validator. Some of those things may be optional. (eg, requirements for field-for-field validation). And the Zod implementation of that interface has everything satisfied. Then a matrix of features -> validation library on the website.

Fortunately, I am in early stages with my @effect/schema impl, so I might just use Zod.

[niemyjski]

I'd like to use https://github.com/typestack/class-validator (huntabyte/shadcn-svelte#497) and not be tied to zod. This is preventing me from using this library :(.

[ciscoheat]

Good thing then that v2 is underway: https://blog.encodeart.dev/superforms-v2-supporting-all-validation-libraries
The library has to be supported by TypeSchema though, so you'll need to ensure this is possible.

Also, being able to export the validators from the library as JSON Schema is pretty much required, otherwise you'll have to do the heavy lifting with default values and constraints yourself.

[phobetron]

Will the work in V2 also make it easier to define dynamically-optional fields, without requiring separate schemas for each permutation of a complex form? That's still a concern for some of us with this lib.

[ciscoheat]

Dynamic behavior is a bit tricky with a compile time-defined schema. You can already now swap the schema for any other, it's just that typescript will complain about the schema type that you defined in the first call to superValidate. But maybe you're talking about something like Zod's catchall?

[phobetron]

I'm talking about what was discussed in issue #282. Maintaining separate schemas for geometric permutations of a single form that can have different valid fields based on the values of other fields is just painful, and not necessary with other libraries. Regardless of how difficult that is to handle the way Superforms is architected, libs architected differently (though they don't hook specifically into SK) are superior in this case.

[ciscoheat]

Superforms v2 will at least have union support, but since I don't know the details about your case, I can't say more than that. Good thing there are superior solutions out there, at least.

[phobetron]

My case is basically any case where user input can modify field validations in a way that may be easily specified in a single schema (which is usually accomplished using a union or discriminatedUnion when speaking about Zod). Engineers on my team found that managing multiple schemas and switching between them in Superforms was more cumbersome than what we could accomplish with Felte, or even React Hook Forms in our React🤮 app. The lofty goals of ubiquitous type safety rank lower than overall developer experience, if both can't be simultaneously achieved, and this particular learning didn't come without cost.

[ciscoheat]

What can I say. With OSS, you pay with your time. Superforms doesn't force you to go fully type-safe, since any schema can be used to validate the data, it's just typescript that will complain. The validation will work either way. But it looks like v2 will handle unions properly.

[niemyjski]

Good thing then that v2 is underway: https://blog.encodeart.dev/superforms-v2-supporting-all-validation-libraries The library has to be supported by TypeSchema though, so you'll need to ensure this is possible.

Also, being able to export the validators from the library as JSON Schema is pretty much required, otherwise you'll have to do the heavy lifting with default values and constraints yourself.

That project doesn't seem like it is actively maintained.

[ciscoheat]

I'm sure anyone ("someone else") can contribute with maintenance.

[ciscoheat]

This one is ready for testing, migration guide at: https://superforms.rocks/migration-v2/

[ciscoheat]

Finally time to close this. Arktype, Joi, TypeBox, Valibot, Yup and Zod are all working.

[MentalGear]

Thanks for opening up the library for additional validation libs !
One question though: Is there a reason Superstruct was omitted, or is it still coming ?

[ciscoheat]

There's a problem with the moduleResolution for it: ianstormtaylor/superstruct#1200