feat(Form): update and migrate valibot to v0.31.0

[fabian-hiller]

Resolves #1849

❓ Type of change

• 📖 Documentation (updates to the documentation or readme)
• 🐞 Bug fix (a non-breaking change that fixes an issue)
• 👌 Enhancement (improving an existing functionality)
• ✨ New feature (a non-breaking change that adds functionality)
• 🧹 Chore (updates to the build process or auxiliary tools and libraries)
• ⚠️ Breaking change (fix or feature that would cause existing functionality to change)

📚 Description

I am the author of Valibot and have updated and migrated Nuxt UI to our latest version: https://valibot.dev/blog/valibot-v0.31.0-is-finally-available/

Valibot is still v0. Breaking changes are therefore expected and the update should be no problem.

📝 Checklist

• I have linked an issue or discussion.
• I have updated the documentation accordingly.

[benjamincanac]

Thanks a lot @fabian-hiller for taking the time to help us with this and for creating this awesome library! 😊

[noook]

Does it also resolve #625 ?

[romhml]

Valibot should be an opt-in dependency to promote flexibility in validation library selection and minimize dependencies. It should stay as a dev dependency.

[romhml]

Is there a way to include the parse function inside the schema object so we can fix issues related to the use of _parse without a direct dependency to valibot?

[fabian-hiller]

When Valibot was first added, a dynamic import was used to use safeParseAsync. Later on safeParseAsync was replaced by a direct call of the ._parse method. https://github.com/nuxt/ui/pull/617/files

Back then this was ok because safeParseAsync just called ._parse and did nothing else, but this has changed. That's why we need to use safeParseAsync again, but I don't recommend a dynamic import because I don't think it's tree shakable and it breaks the idea behind Valibot.

We now have two alternatives, the first is to add Valibot as a dependency to Nuxt UI to be able to import safeParseAsync (about 200 bytes). The other would be to force your users to wrap there Valibot schema in our new safeParser or safeParserAsync method. This function returns a callable function that internally calls safeParse or safeParseAsync.

const schema = v.object({
  email: v.string(),
  password: v.string()
})

<UForm :schema="v.safeParser(schema)" ... />

@danielroe recommended via Discord to just add Valibot as a dependency because it makes it easier to use, but in the end both solutions work.

[benjamincanac]

I understand your point but the Form component is meant to be used with either valibot, yup, zod or joi so it seems wrong to me to add valibot as a direct dependency as it would imply doing the same thing for the other validation libraries 🤔

[romhml]

Thanks for the explanation! I think the using the v.safeParser(schema) would be better for us here. Although this means we need to keep _parse as a fallback for valibot validation to avoid introducing a breaking change.

[Gerbuuun]

In the PR I closed in favor of this one, I made the change like this.

This is almost the same as how v.safeParse() does it internally. But this way you do not have valibot as a dependency?

edit: seems like this way the global config will not be used...

[fabian-hiller]

edit: seems like this way the global config will not be used...

Yes, that's the problem. i18n doesn't work that way.

Although this means we need to keep _parse as a fallback for valibot validation to avoid introducing a breaking change.

Since Valibot is still v0, a breaking change should be ok for Valibot users, but we can of course support both.

We could also support all 3 options:

• ._parse(…) for Valibot <0.31.0
• ._run(…) for Valibot >=0.31.0 without global config but less boilerplate
• safeParser for Valibot >=0.31.0 with global config

Please let me know what you decide.

[romhml]

We could also support all 3 options:
._parse(…) for Valibot <0.31.0
._run(…) for Valibot >=0.31.0 without global config but less boilerplate
safeParser for Valibot >=0.31.0 with global config

Adding support for the three options looks like a great compromise. We'll be able to cleanly drop support for versions below 0.31.0 in our next major release.

[fabian-hiller]

I have updated the implementation.

[romhml]

Thanks @fabian-hiller 😄

[benjamincanac]

Shouldn't it be better for typings to keep the latest version as valibot?

Suggested change

	"valibot31": "npm:valibot@^0.31.1",
	"valibot": "^0.31.1",

[fabian-hiller]

I believe there is no difference. I just followed a StackOverflow discussion to install two different versions of the same package. If we change the package name, we also need to update the import statement.

[benjamincanac]

Yeah in the Form.vue component we could import from valibot30 and valibot (instead of valibot31).

[fabian-hiller]

Done

[benjamincanac]

Thanks @fabian-hiller! 😊