DON'T USE Environment Variables Without This

This quick setup fixes environment variables in JavaScript.
T3 env - env.t3.gg/docs...
*Newsletter*
Newsletter 🗞 - www.jamesqquic...
*DISCORD*
Join the Learn Build Teach Discord Server 💬 - / discord
Follow me on Twitter 🐦 - / jamesqquick
Check out the Podcast - compressed.fm/
Courses - jamesqquick.co...
*QUESTIONS ABOUT MY SETUP*
Check out my Uses page for my VS Code setup, what recording equipment I use, etc. www.jamesqquic...

[@lucaszapico926]

Thanks for the introduction to Zod very cool.

[@LarsRyeJeppesen]

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

[@gagiknavasatariyan7316]

This was really helpful for me, Thanks!

[@JamesQQuick]

So glad to hear that. Thanks for watching!!

[@datra3237]

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

[@wobsoriano]

Ill do tsx env.ts && npm run build

[@dechobarca]

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

[@sprioleau]

+1. I think it’s best to keep the pre-defined properties (NODE_ENV, etc.) as part of the exported parsed environment object.

[@dechobarca]

​@@sprioleau I think you possibly misunderstood what I was trying to say. The zod parsed object will NOT contain any properties that aren't defined in your schema. All that said, there is a schema method called passthrough that would preserve them without any validation.

[@Goshified]

I don't think the destructuring has anything to do with validation -- the T3 Env docs for Next.js mention that the environment variables need to be destructrured because of how Next bundles environment variables. If the variable isn't defined explicitly, it'll get stripped out of the build.

[@akvirus2]

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

[@DmytroZhyvonitko]

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

[@sabuein]

Thank you.

[@gosnooky]

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.

[@studio_egoryakimov]

Really useful video, absolute like😃

[@ayushshende4290]

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.

[@xdneos]

You can use the property transform from zod

[@xdneos]

Even you can use regex to be sure that the property only contain Numbers

[@FreeCodeArena]

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.

[@jajargg]

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

[@kiikoh]

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

[@technobanjo]

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.

[@asteinerd]

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

[@gleitonfranco1260]

I use IntelliJ btw ;-)

[@CharcoalDaddyBBQ]

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

[@JamesQQuick]

Do you not see value in intellisense and validation for those variables?

[@jonathangamble]

use Valibot, way less overhead and has treeshaking

[@Danielo515]

Zod was a nice proof of concept, but nobody should be using it by now.

[@IvanRandomDude]

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

[@anasouardini]

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 ¯\_(ツ)_/¯

[@_neuromanser_]

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

[@LearningSpaceYC]

Overcomplicated. Should be much simpler from vendors for a such simple thing.

[@Danielo515]

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

[@zapfska7390]

You earned a cookie for being so intelligent and knowledgeable

[@gokulkrishh]

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.

[@immikegt]

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