Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support all standard schema libraries #299

Merged
merged 18 commits into from
Jan 25, 2025

Conversation

EskiMojo14
Copy link
Contributor

@EskiMojo14 EskiMojo14 commented Jan 25, 2025

Replaces Zod specific logic and types with Standard Schema, meaning all of these should work.

fixes #6

Breaking changes:

  • replace ZodError in onValidationError with an array of Issues.

The minimum version of Zod has been bumped to 3.24, which is the first version to support Standard Schema. I've also made Zod an optional peer dependency, as it's now only needed for presets.

Once this is released, this package can be added here :)

Copy link

vercel bot commented Jan 25, 2025

@EskiMojo14 is attempting to deploy a commit to the t3-oss Team on Vercel.

A member of the Team first needs to authorize it.

Copy link

vercel bot commented Jan 25, 2025

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name Status Preview Comments Updated (UTC)
t3-env ✅ Ready (Inspect) Visit Preview 💬 Add feedback Jan 25, 2025 1:43pm
t3-env-nextjs ✅ Ready (Inspect) Visit Preview 💬 Add feedback Jan 25, 2025 1:43pm

@juliusmarminge
Copy link
Member

I've also made Zod an optional peer dependency, as it's now only needed for presets.

I wonder if we should rename the presets entrypoint to preset-zod or something so that there can be preset-valibot etc too

@EskiMojo14
Copy link
Contributor Author

sure, that'd make sense - you could maybe export interfaces from /presets that /presets-zod has to satisfy, to make sure they're all matching

it'd be a breaking change but we've already got one of those anyway

@EskiMojo14
Copy link
Contributor Author

happy to make that change in this or a follow up PR if you want :)

Copy link
Member

@juliusmarminge juliusmarminge left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Fantastic work 🔥

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nit: would be nice with another example since we already have astro - but i don't really mind

};
}

export function parseWithDictionary<TDict extends StandardSchemaDictionary>(
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

would be nice if we'd accept object validators so we wouldn't need this, but it was hell getting good types with ZodObject compared to Record<...> when I initially made this

Copy link
Contributor Author

@EskiMojo14 EskiMojo14 Jan 25, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

the alternative would be requiring the user to provide the object schema builder as an option, but that seems a little annoying from a user perspective (and I haven't tested to make sure it's possible)

createEnv({
  ...opts,
  buildObjectSchema: z.object
})

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

we need the raw shape to properly check if an accessed variable is shared

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

i think it should be possible to add (although not sure if StandardSchema has a shape type like Zod has. it was just a pain and i think a Record<string, Validator> has worked fine

@juliusmarminge
Copy link
Member

juliusmarminge commented Jan 25, 2025

sure, that'd make sense - you could maybe export interfaces from /presets that /presets-zod has to satisfy, to make sure they're all matching

it'd be a breaking change but we've already got one of those anyway

happy to make that change in this or a follow up PR if you want :)

Yea go ahead! Breaking changes are fine. Either follow up or in this one is fine by me

@juliusmarminge
Copy link
Member

Actually I'll merge this now. You can make the preset changes in a follow up.

lmk if you're doing them or not so i know if i should push a release or wait

@juliusmarminge juliusmarminge added this pull request to the merge queue Jan 25, 2025
@EskiMojo14
Copy link
Contributor Author

I'll get them done in the next hour or so, so if you're happy to wait to release I'll give you a shout

@juliusmarminge
Copy link
Member

sounds good

Merged via the queue into t3-oss:main with commit b13d46b Jan 25, 2025
7 checks passed
@EskiMojo14 EskiMojo14 deleted the standard-schema branch January 25, 2025 14:42
@EskiMojo14
Copy link
Contributor Author

@juliusmarminge raised #310

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

feat: support more validation libraries
2 participants