Dev & Production Variables

[00:00:00]
>> Speaker 1: OK, the problem with environment variables is that they're not typed, and nobody knows which ones exist without having to look at the .env file or if you have some really experienced engineer on your team who's been burned before and set up a vault and did all this stuff

[00:00:00]
Unless you have that person who lives for this, nobody's going to know any of the environment variables On big projects, I've worked on projects that have had well over 100 environment variables with tons of different things

[00:00:00]
So how do you keep track of that I like to make a little helper to help me do that What I'm going to do is make a new file, and you can definitely follow along This is something you're going to need

[00:00:00]
I typically make an env.ts file in the root Before we get there, you probably only have a .env.example You want to also make a .env and a .env.test Make those two files You don't have to put anything in them right now, but you want to make them

[00:00:00]
The reason you don't have them is they're not checked into GitHub intentionally, otherwise our secrets will be on GitHub The pattern is you typically make an example file that you do check in on GitHub to show engineers the names of the environment variables they will need and provide some example values

[00:00:00]
When you make your own .env file, you can pretty much copy-paste these examples and fill in your values The example file shows what environment variables you need to set up in your own .env

[00:00:00]
I just put some in here so you feel official when you make this API - you feel like you have some environment variables And that last part was a joke, but it makes you feel good So you make those files in TypeScript

[00:00:00]
This is an actual TypeScript file The whole point of this file is to basically type-check our environment variables so we get nice autocomplete in our code Currently, if you access environment variables in your code, you do process.env.[variable name]

[00:00:00]
For instance, if I go into the server and log process.env.NODE_ENV, it says undefined because it's not set That's how you access the environment I noticed this isn't really type-checked - there's a TZ thing that might be related to time zones, probably built into Node types, but there's really nothing else here

[00:00:00]
It's annoying to have to type process.env every single time I'd also like guarantees that required environment variables are actually present before my app starts I don't want to find out at runtime that an essential environment variable is not set

[00:00:00]
This helps during deployment I can't tell you how many times I would deploy an app only to find out later that an environment variable was never set, causing the app to break I want to know that as soon as the app tries to start after deployment

[00:00:00]
So we're getting types and guarantees that required environment variables are present, with defaults for optional ones I'm going to import env as loadenv, renaming it because I'll use env elsewhere later

[00:00:00]
We'll use custom-env, which is similar to dotenv We'll use an .env file and an .env.test file because when testing, we want to switch out environment variable files to use different variables - like a different database

[00:00:00]
I'll also import Zod If you don't know Zod, think of it as type-checking at runtime TypeScript checks types at build and dev time, but at runtime, TypeScript doesn't exist Zod lets you type-check actual values at runtime, like runtime schema validation

[00:00:00]
[The transcript continues in this corrected style, maintaining the technical explanation and conversational tone while cleaning up grammar, spelling, and technical terminology.]