feat: Use t3's ENV setup w/ Zod #319
Conversation
| const server = z.object({ | ||
| APP_ENV: z.enum(['development', 'test', 'production']), | ||
| APP_URL: z.string(), | ||
| DATABASE_URL: z.string().url(), | ||
| DEBUG: z.boolean().optional(), | ||
| FC_GIT_COMMIT_SHA: z.string().optional(), | ||
| IS_CI: z.boolean().optional(), | ||
| NEXTAUTH_SECRET: | ||
| process.env.NODE_ENV === 'production' ? z.string().min(1) : z.string().min(1).optional(), | ||
| NEXTAUTH_URL: z.string().min(1), | ||
| NODE_ENV: z.enum(['development', 'test', 'production']), | ||
| PORT: z.number().int().positive(), | ||
| RENDER_EXTERNAL_URL: z.string().optional(), | ||
| SHOULD_MIGRATE: z.boolean(), | ||
| }); |
There was a problem hiding this comment.
I’ve run into a lot of annoying issues using zod to validate config in this way and on a couple projects have ended up just scrapping it. A few reasons why:
-
You have to coerce to get booleans and numbers from env strings. This doesn't work the way you want by default (e.g.
"false"will be coerced astrue). You can write transformation functions for zod which works ok, but it isn't ideal. -
Sometimes config for different stages have different requirements.
-
It's almost always cleaner to have a nested config structure (e.g.
config.db.urlvsconfig.DB_URL). This is especially true when you have a lot of env variables and complex config. By using a nested config, you at least constrain that complication in one place, where the config object is defined. -
There was another reason and I can't remember it.
I’d avoid running it against config in this way. There are a few alternatives:
-
The way we're doing config on Tachus (e.g. those
envToString, etc. functions). This has worked great for me on a number of projects. -
Run a zod schema check on
process.envitself to just verify that required values are provided and nothing more. -
Create your
configvariable using option no.1 above, but then run a zod schema check against that.
There was a problem hiding this comment.
I think this is a good pattern for config:
https://gist.github.com/cullylarson/d710be62559c593c0f7dd6680e22daca
There was a problem hiding this comment.
These are all great comments Cully.
Reading through - I'm fine not moving along with Zod at the moment.
| const parsed = /** @type {MergedSafeParseReturn} */ isServer | ||
| ? merged.safeParse(processEnv) // on server we can validate all env vars | ||
| : client.safeParse(processEnv); // on client we can only validate the ones that are exposed |
There was a problem hiding this comment.
This is going to fail for all the z.boolean and z.number values because all process.env values are strings.
| * Specify your server-side environment variables schema here. This way you can ensure the app isn't | ||
| * built with invalid env vars. | ||
| */ | ||
| const server = z.object({ |
There was a problem hiding this comment.
I've found a helpful naming convention when working zod to be including Schema at the end of schema variables (e.g. serverSchema).
|
These are all great comments Cully. |
Changes
feat: Use t3's ENV setup w/ Zod to give strict errors if ENVs are missing
https://create.t3.gg/en/usage/env-variables#envmjs