Type-Safe Environment Variables

[00:00:00]
>> Speaker 1: So then we'll make a schema using Zod It's kind of cool how I do this I still to this day think this is kind of clever and basically what I want to do is I want to put the keys here of the environment variables that I expect to have, so I expect to have NODE_ENV and APP_STAGE

[00:00:00]
And then I put the Zod schema here So in this case I expect NODE_ENV to be an enum If you don't know what enum means, it just means one of these

[00:00:00]
That's all it means—it's going to be one of these It's short for enumeration, we're enumerating over a select amount of options

[00:00:00]
I think they could have called it something else, but it's called an enum—it predates all of us Typically, the three values for NODE_ENV are development, test, and production, very similar to our app stage

[00:00:00]
We'll do that, but we'll also set a default to development Then I want to do my APP_STAGE, which is pretty much the same thing

[00:00:00]
I'm going to copy that, change this to APP_STAGE, and change the enum values to dev and not 'deve' I'll also default to dev here

[00:00:00]
I've got a bunch of other environment variables that I expect to have, and I'll talk about them as I do them

[00:00:00]
So port—right now we hardcoded a port, but when you deploy this, you get assigned a port You don't get to pick what port you have when you deploy, so we need to not hardcode our ports and instead dynamically use them from environment variables

[00:00:00]
That's the number one environment variable you'll use when you deploy a server What I want to do here is use this cool thing called coerce because port should be a number, but technically every single environment variable is always a string

[00:00:00]
So I can use Zod to coerce it to the type I want I'm going to coerce this port to be a number because Express expects a number

[00:00:00]
I'll say it should be a positive number and default to 3000 There are some other variables like hosts, depending on your provider

[00:00:00]
I'm just going to put the ones we're definitely going to use, like DATABASE_URL We'll add some extra validation—it's going to start with the PostgreSQL protocol

[00:00:00]
Databases have their own protocols, and for PostgreSQL, it's prefixed with 'postgres://' This is how you know it's a PostgreSQL database

[00:00:00]
We're going to write code that validates these environment variables, and when we start the server, it'll run validation

[00:00:00]
If any of these fail, we'll get an error and the server will stop This prevents running the server without proper environment variables, which is a common beginner problem

[00:00:00]
We'll also need a JWT_SECRET, which should be a string with a minimum of 32 characters JWT_EXPIRES_IN will be a string describing how long the token is valid—I'll set it to 7 days

[00:00:00]
BCRYPT_ROUNDS will be a number for password hashing, with a minimum of 10 and maximum of 20 The last thing we want to do is validate this

[00:00:00]
I'll create a type using Zod's inference capabilities, which allows creating a TypeScript type directly from a Zod schema

[00:00:00]
This means I can write the schema once and get both runtime and compile-time type checking I'll use a try-catch block because Zod will throw an error if any validations fail

[00:00:00]
We'll parse the process.env object, and if there's a Zod validation error, we'll log the details and exit the process

[00:00:00]
If it's not a Zod error, we'll throw it as normal I'll also add some helper functions based on the validated environment variables, like setting APP_STAGE to either production, development, or testing

[00:00:00]
The key takeaway is that environment variables can be set locally through .env files (using a package like dotenv) and in production through the hosting platform's settings panel

[00:00:00]
When the server starts, these variables are loaded into process.env and can be validated and used throughout the application.