feat: add valibot addon#1157
Conversation
🦋 Changeset detectedLatest commit: 18a64f9 The changes in this PR will be included in the next version bump. This PR includes changesets to release 1 package
Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
| homepage: 'https://valibot.dev', | ||
| options: {}, | ||
| run: ({ sv }) => { | ||
| sv.devDependency('valibot', '^1.4.1'); |
There was a problem hiding this comment.
Not sure if you saw my note in the ticket early enough. In the maintainers meeting it was brought up that the addon would basically be a one liner as displayed here and therefore making it an addon would be an overstatement.
The idea was to make that a question during create, since you will always be capable of adding on line to your package.json by hand. Honestly, IMHO I wouldn't even bother asking a question and just always add it. But maybe @jycouet has an opinion here as well.
Most of your PR is still valid though and can probably stay unchanged.
There was a problem hiding this comment.
I did see your msg, but it seems I have misinterpreted it.
IMHO I wouldn't even bother asking a question and just always add it
I am also in favour of not asking. But that seems a bit too opinionated considering standard-schema allows for different validation libraries. Users shouldn't have to reverse what the CLI has done. So I made it optional.
There was a problem hiding this comment.
Assuming we keep it this way we would need to ensure that better-auth runs after valibot by running runsAfter('valibot') in better-auth's setup.
I'm still not convinced what is the right forward here:
- optional addon (as of now)
- question during create
- no question during create
I do get your point about the different libs. However we have used valibot everywhere (docs, demos, etc). But yes, users might have other choices.
There was a problem hiding this comment.
To avoid the rolling back code problem, my original idea was to provide a list of validators. But that added maintenance burden to the CLI team and opted for this instead.
Side note: It would be nice if validation libraries create their own community addon and users can select it from a list within the CLI.
You can discuss this again in the next maintainers meeting.
2 participants
Closes #1152
Description
I don't know what test to write.
Removed write guards for demo paths. We already warn on dirty and they're demos, not real code.
Checklist