I like this - it gives control and one place where settings change and are managed, still in a global/static way.

Well, there's actually a limitation to this approach, if you try to intialize something globally (for instance, database connection) when the server starts-up, you will notice that the `env` will always/sometimes return undefined, as it's not ready.

@@chungweileong Sounds like you have some other issue. Import loop? Or async parsing perhaps?

@@chungweileong I think mutating the env or lazy loading it is a problematic practice, you could store lazy loaded or deferred stuff in another globally available variable. The approach of exporting env globally works fantastically when you rely on env variables that should be present on the program's initial start, whether it be a node server or even a frontend framework

@@chungweileong don't mutate your env from inside your application. Env is for passing data to your application.

and you can't forget to actually validate the process env. For example if you're code has multiple entry points you need to make sure that everyone of them actually calls envVariables.parse

Matts approach seems to be quite elegant and is impressive. But what @zheil says, is the way! The usage of zod to simplify validation is really convenient though 🎉

@@davidadamson1588 To be honest, to me this jumps out as a great opportunity for Typescript to make some improvements to interaction of env vars with the rest of your code.

@@Gigusx I am not sure if I am a little old school… But I prefer to have such things as configuration in its own place, like inside a class. This helps to comply with the SOLID principle which again ensures the correct usage of eg a strategy pattern. Since when done properly, it will allow me to simply exchange the source of configuration by swapping out the configuration strategy. Strategies could be: loading configuration from a file or env vars or a combimation of both or what ever suits your needs. Hardcoding against process.env is not a thing you should do (in my opinion). Code against abstractions not concretions. People might argue that this is a „java thing“, but it has the same advantages when used with typescript, especially when working on large scale projects.

@@davidadamson1588 It has the same downsides too. You added complexity that you carry for the life of the project which you may never take advantage of. Put them in a class sure, but strategy pattern? abstractions? If you love acronyms then don't forget KISS.

Good to hear!

One thing to note about zod though, is that it sucks with cross field validation

​@@parlor3115 wouldn't the refine method serve that need?

@deepkit/type is far superior to that garbage

(UPDATE: WHOOPS, this is incorrect) Many js libraries that provide a build process parse things like `process.env.MY_ENV_VAR`, and replace them with the actual env var found at build time. If you export the parsed object that won't happen while @mattpocockuk 's solution will work with that. Without such feature, I'd agree with your solution and the lack of ability to transform data.

@@Erandros no. Matts solution will not work as well when using such build tools! This is due to the fact, that process.env cannot be validated by zod (since env vars are getting replaced individually). Typing process.env globally without having the validation will result in pure nonsense.

@@davidadamson1588 sorry

@@Erandros no reason to be sorry. I hope my comment did not offend you 😨

@@davidadamson1588 not at all, I just felt ashamed that I gave inaccurate information, but that's on me, dont worry

So then to make this work I just used the process.env.NODE_ENV directly for these cases, and other places I access the env properties from this custom object.

@@emkisn Yeah I wouldn't use this for env variables I don't control. NODE_ENV being an example of this, or even PATH in POSIX because it shouldn't matter that they don't exist in those cases, there should be a reasonable fallback for those cases.

@@dealloc Makes sense, the only thing that borders me is that then we will have two different ways to access env variables, so it's not really consistent. Maybe an ESLint rule to only allow certain kinds of it usages like NODE_ENV could help with that.

Cool comment

ps. Hopefully this Zod + process env also works together with dot env eg. @fastofy/dot-ev?

This is designed to work with a .env file!

If we forget an environment variable zod will just throw an error for us instantly and we won't have to debug and find out what's missing.

I have that same question, what is the benefit of zod here...

What Nicolai said. Free Validation and typing is the key here

Could you rephrase your question? It works great.

Wym? You want to mutate the env variables?

@mattpocockuk look at libraries like envalid and envsafe. Instead of parsing the result and than doing nothing with the actual result object, we can parse the environment and than export it (I like to than add a path to it in the tsconfig, I.e. @/env) and use the resulting object instead of process.env. That way, any mutation you make to the environment variable (for example, using JSON.parse to turn a stringified object into a string proper) can be used

Good idea!

Call dotenv.config() before you do your imports.

The problem with that is Next is not able to transform your `env(...)` calls during build time, which makes it unusable in client-side code. The same problem happens when during process.env[someArbitraryKey]. Next cannot inline those environment variables. Same if you were to destructure, or assign process.env to a variable.

Do they do the declare global thing in T3? I thought they used the export const envVariables setup.

@@mattpocockuk Correct, it uses export const env setup with a variation that allows to throw error if env vars are accessed client side. But extending global namespace interfaces is certainly a neat idea.

@Clemens Horn thx, i was wandering from where `ProcessEnv` came, so apparently it is a part of NodeJS typings in typescript. good to know

process.env.X is string | undefined by default!

It gives you runtime safety by ensuring that the env variable you are accessing actually exists

@@mattpocockuk ahh, true. Thanks!

Try it

Yes, though this won't give you any runtime validation.

I address this in the video itself. I find it just a bit more truthful. process.env.WHATEVER _is_ available, so why not make it type safe?

@@mattpocockuk only issue is that if you add something like "DEBUG_LEVEL: z.number()" on the object, TS will assume that process.env.DEBUG_LEVEL is a number, which would be wrong

@@scezar8880 That's not correct. It'll conflict with the built-in ProcessEnv type, so it'll give you the proper error.

Good tip! Though the types wouldn't be quite there

The point of this is that zod ENSURES that your .env file is correct.

Yep, true! Just wanted to show the awesome z.infer thing

not needed, assuming you're gonna typecheck process.env manually, otherwise you're assigning a type to it that isn't accurate

@@mattpocockuk oh yeah! that way u don’t need to add types manually, honestly could save a lot of confusion!

Because you'll be sure that at runtime, the correct env variables are being passed in

@@mattpocockuk Ah yes. That makes sense. Thanks for your answer!

Yep, this'll just work