feat: add Valibot support with valibot$ to qwik-city

[brandonpittman]

Overview

Adds Valibot support with a valibot$ function similarly to how Zod is supported by zod$.

Fixes #4924

What is it?

• Feature / enhancement
• Bug
• Docs / tests / types / typos

Description

Requires:

• valibot

Use cases and why

So you can use Valibot to validate your actions

Checklist:

• My code follows the developer guidelines of this project
• I have performed a self-review of my own code
• I have made corresponding changes to the documentation
• Added new tests to cover the fix / functionality

[stackblitz]

Run & review this pull request in StackBlitz Codeflow.

[netlify]

✅ Deploy Preview for qwik-insights canceled.

Name	Link
🔨 Latest commit	bfb1d8a
🔍 Latest deploy log	https://app.netlify.com/sites/qwik-insights/deploys/651de4314b616a0008a4368f

[gioboa]

Thanks for your nice PR, can you add the documentation for this please?

[brandonpittman]

Thanks for your nice PR, can you add the documentation for this please?

Sure. Not done, yet. Will update docs tomorrow! Just wanted to share what I had so far.

@fabian-hiller Is there a way with Valibot to check if a value is an ObjectSchema at runtime?

[fabian-hiller]

@brandonpittman yes, this should work via the .schema key: https://github.com/fabian-hiller/valibot/blob/v0.13.1/library/src/schemas/object/object.ts#L65

And via .async you can find out if it needs to be validated async: https://github.com/fabian-hiller/valibot/blob/v0.13.1/library/src/schemas/object/object.ts#L75

[fabian-hiller]

Note that you must also include BaseSchemaAsync and ObjectShapeAsync to support async validation.

[brandonpittman]

Note that you must also include BaseSchemaAsync and ObjectShapeAsync to support async validation.

@fabian-hiller

It's not clear if we need async support. I've updated my PR with working code that satisfies TypeScript. I've removed any async types though. Can you take a look, please?

[fabian-hiller]

It's not clear if we need async support.

Since the validation is done in an async function, we could enable async validation with safeParseAsync, BaseSchemaAsync and ObjectShapeAsync. This would allow, for example, to do network requests as part of the validation. If someone uses only sync validation, this is not a disadvantage. async is compatible with sync, but sync is not compatible with async.

[fabian-hiller]

If you want to add async support, you need to replace safeParse with safePareseAsync and also add BaseSchemaAsync and ObjectShapeAsync to the types.

[brandonpittman]

If you want to add async support, you need to replace safeParse with safePareseAsync and also add BaseSchemaAsync and ObjectShapeAsync to the types.

Okay. Will update it. Thanks.

[fabian-hiller]

You must not remove BaseSchema and ObjectShape from the types. Otherwise the sync validation will not be accepted.

[brandonpittman]

You must not remove BaseSchema and ObjectShape from the types. Otherwise the sync validation will not be accepted.

@fabian-hiller

Should I use BaseSchema instead of ObjectSchema<ObjectShape>? When I tried BaseSchema the .schema === "object' check encountered a type error.

Do I need to do something like obj.async ? safeParseAsync(obj, data) : safeParse(obj, data) or can I just give safeParseAsync a synchronous schema?

[mhevery]

Thanks for working on this! ❤️

[fabian-hiller]

Should I use BaseSchema instead of ObjectSchema<ObjectShape>? When I tried BaseSchema the .schema === "object' check encountered a type error.

I think I would write BaseSchema | BaseSchemaAsync | ObjectShape | ObjectShapeAsync. If we recognize that an object with typeof obj._parse === "function" is passed, it is a scheme that can be passed directly in safeParseAsync. Otherwise the object must be passed into objectAsync before we call safeParseAsync.

Do I need to do something like obj.async ? safeParseAsync(obj, data) : safeParse(obj, data) or can I just give safeParseAsync a synchronous schema?

This is not required. safeParseAsync can also handle BaseSchema.

[mhevery]

1. The first problem I'm having is in packages/qwik-city/runtime/src/types.ts. The return type from valibot$ seems to be returning the same thing that zod$ does. There are a bunch of nested types for the action constructor and I never could figure out how to separate the Zod types so that I could have Valibot types be accepted as well.

So I tried to build it locally but the demo files are failing to build. Something is off from your types...

Not sure how you are building it but here is my process

1. open packages/docs/package.json
2. change to "@builder.io/qwik-city": "wqrkspace:*",
3. from the project root run npm build
4. Notice build errors is packages/docs/src/routes/demo/valibot/advanced/index.tsx and packages/docs/src/routes/demo/valibot/simple/index.tsx

What kind of help do you need from me to move this forward?

[fabian-hiller]

I'll probably finally get around to thoroughly reviewing this PR this weekend. I will then commit directly to the PR and make improvements. I hope that this is possible without special permissions, since I am not an official maintainer of the Qwik repo.

[fabian-hiller]

@brandonpittman a update for you. I have not forgotten about this PR and will finish it as soon as possible. We are currently working on a major structural change to Valibot. As soon as this is done, I will working on this PR.

[wmertens]

So the current state is that @fabian-hiller will make changes when he finds the time, right?

[fabian-hiller]

Yes, this is the current state. But everyone is welcome to continue working on it before I find the time. In about 3 weeks I will be able to fully focus on my open source work again and will probably finish the PR before Christmas.

[fabian-hiller]

I plan to work on and finalize this PR by the end of next week.

[fabian-hiller]

I am very sorry that this is taking so long. I expect to finalize this PR next week.

[shairez]

Thanks @fabian-hiller ! can't wait!

[fabian-hiller]

Other things came up that I wanted to preordain. This PR is on my list for the next two weeks.

[fabian-hiller]

There is a Valibot PR I want to review and maybe merge before I finish this implementation because some types may change. I will give an update here in a few days.

[fabian-hiller]

Sorry to push this implementation back again. You may have seen this discussion on Twitter or GitHub. I plan to work on this first, as some types may change.

[fabian-hiller]

Short update: I am basically rewriting Valibot at the moment. I am trying to improve the API design, performance, bundle size and types, but this will take some time. I also have to rewrite the documentation. I don't want to make any more promises about the timing of this PR. As soon as I feel ready, I will finish the implementation.

[brandonpittman]

The funny thing is: the implementation works. It’s just the types I wanted help with. I didn’t understand the types the original implementation had—because they assumed Zod was being used.

[fabian-hiller]

I expect a lot of breaking changes for the next release. So even though the implementation of this PR is almost done, it might make sense to wait to not confuse people.

[brandonpittman]

@fabian-hiller Can you tell me what is going to change with Valibot that might affect this? The feature worked, it’s just the types that didn’t work.

I’m gonna take a stab at fixing the types again. (Making the action types less Zod-specific in another PR first might be better though.)

[wmertens]

@brandonpittman I spoke with him recently, there's a lot of changes to the API coming, as I understand it. So that zod decoupling first send like a good idea

[fabian-hiller]

The API will be mostly the same (except for the new pipe function), but the types will change and lead to a breaking change for the valibot$ implementation. Therefore, I recommend adding the valibot$ API to Qwik once I am done with the rewrite and start preparing our v1 release.

[gioboa]

@brandonpittman Are you still working on this or is it abandoned?

[brandonpittman]

JS works but couldn’t get any assistance getting the types to work from the original Zod implementation writer. Valibot author too busy with upgrades in the core library to look at it. Seemed only important to me but I’m not good enough with TypeScript to make the types work.

[gioboa]

I'm so sorry for that @brandonpittman
The idea to support Valibot is great btw, thanks for your hard work on this PR.
We appreciate your effort. I'm looking forward to implementing this feature after v2.0

[fabian-hiller]

I still plan to finish this PR, but unfortunately I had to give other things, like rewriting Valibot and updating our docs, a higher priority. I think Valibot is on a pretty good track to reach v1 RC in August. I also plan to work more with Qwik soon. Therefore, I hope to be able to work on it in the next two months. However, everyone should feel welcome to take over this PR to speed up the process. I am happy to answer questions and review everything.

[fabian-hiller]

I have reviewed the zod$ implementation, but to be honest, it is not in good shape. Many types are wrong, typecasting is used, and many edge cases are not considered. Fixing this is hard as I do not have a broader view of everything. Also, it would most likely lead to breaking changes. I may create a new PR to add valibot$, but in general I recommend rewriting and fixing the entire implementation at some point.

[brandonpittman]

I have reviewed the zod$ implementation, but to be honest, it is not in good shape. Many types are wrong, typecasting is used, and many edge cases are not considered. Fixing this is hard as I do not have a broader view of everything. Also, it would most likely lead to breaking changes. I may create a new PR to add valibot$, but in general I recommend rewriting and fixing the entire implementation at some point.

@fabian-hiller You mean my fixes or the original implementation?

[fabian-hiller]

The original implementation.