DON'T USE Environment Variables Without This 

FYI you don't need to destructure process.env since zod will just drop any extra properties which aren't defined in your schema.

Instead of this, I always make a central "config" object where I set all the environment variables. Also creates a type for this. Any place in my application that needs an environment varialbe will just import config and use the prop (environment variable) it needs. And because I typed config, I never miss a name

Let's install some packages and write a bunch of code to access and validate the types of our env variables that we control.

or you can use type augmentation to define your types. use zod for form validation or other stuff

Environment variables at build time I think is only a modern thing with Next/Nuxt and these things. Normally environs are introduced at application start up time with the same ENV as the shell executing the application. Maybe certain ENV are not known at build time and depend on where the application is being deployed. I ran into this problem with Nuxt once and had to write a hack to get runtime environs into the application. It's a very strange thing to BUILD with environs.

This video has the right idea but this can be much simpler. Just export the results of .parse(). Every file you use needs to import process anyway so its no additional work

You can also just make global types like this: declare global { namespace NodeJS { interface ProcessEnv { DB_CONNECTION: string; DB_NAME: string; } } }

10:57 how would you go about handling the validation at build time?

This was really helpful for me, Thanks!

Interesting james, so far i been using something like below. namespace NodeJS { interface ProcessEnv { [key: string]: string | undefined; NODE_ENV: 'development' | 'production'; NEXT_PUBLIC_SUPABASE_URL: string; } } Though above mostly helped to typesafe env variable but not validation. I will try out Zod and see. Thanks for sharing. I know this setup is not super hard to do but would love to have CLI to automatically do this for me via ZOD by passing local env file in local and automate this inference and safety process in a file for me.

This seems like a HUGE amount of overhead... If there was a way to have it ONLY run when you're building/generating so it only does the checks during BUILD-TIME, and not run-time; that would be awesome. ... if it is... I'm missing it. [EDIT]: You said that right after I wrote this comment LOL

lol I made a bun plugin for this yesterday and published on npm called bun-plugin-env-types. It gets all defined vars from all .env files them generates a env.d.ts file for you. so you can still use process.env, Bun.env or import.meta.env with autocomplete. Can use at build time or runtime.

I use IntelliJ btw ;-)

Really useful video, absolute like😃

Nice video. I had to implement this recently in a project I'm working on. I usually couple it with a build script that validates the important env variables are set correctly before building the app.

Love this improvement

What about properties which are other that string like every field in an env file is string but in the schema let's say we have defined Port as a number, how would that work wouldn't that throw an error.

But I set my environment variables.... I don't see the point of all this extra code...

use Valibot, way less overhead and has treeshaking

Yes, add another dependency to project just to check env variable… 🙄

I was hoping it's a code-gen solution, not sure if ti's going to be good or bad, but I'm too lazy ¯\_(ツ)_/¯

We are seriously at the point where even using env variables is "hard"

This may be an impressive revelation... For those with 0 experience programming

And if just use ‘${process.env.EMAIL}’ ? The error disappeared and works.