I am working on a project in nextJS written in Typescript. I have gone one step further and implemented a library called Joi to validate .ENV variables. Problem with TypeScript is that it offers no validation on strings really. With Joi you can validate if the string is of the correct length and do validation using regEx.
This way your build will fail if someone did a typo in a crucial .ENV variable. Obviously it won't be bulletproof, but it will provide more confidence than simply checking that the variable isn't undefined.

Does this still work?
Not working on my side because of this I think from the nextjs doc:

"Note: In order to keep server-only secrets safe, Next.js replaces process.env.* with the correct values at build time. This means that process.env is not a standard JavaScript object, so you’re not able to use object destructuring. Environment variables must be referenced as e.g. process.env.PUBLISHABLE_KEY, not const { PUBLISHABLE_KEY } = process.env."

Doing process.env.NEXT_PUBLIC_API_URL works, but not process.env['NEXT_PUBLIC_API_URL']

This is awesome! In a recent project we had various discussions of how to check if mandatory env vars are set and how to handle errors in Jenkins pipelines if the vars are not set on deployment target servers.

Being reminded of such simple and efficient solutions is great :)

I don't really see the point of all this. You received a very common error with a simple to find cause and fixed it. Then you wrote a whole post about environment variables in which you overcomplicate the thing entirely.

Most developers that work with Next are expected to know some way to properly deal with environment variables with things like dotenv but let's assume they don't.

Why should a HTTP request to get a blog post know anything about the process environment?

Although poor choice of words, I know what you mean there and you are right. It makes sense to say that it shouldn't rely on process.env existing in that context. This is why we separate our application logic, especially with JavaScript. You can of course, write a fetchBlog function that takes one or more arguments.

Somewhere in your utils.js or something:

// with one argument like in your example
export const fetchBlog = apiKey => fetch(`https://www.example.com/api/blog?api_key=${apiKey}`)

// somewhere else where process.env is available and the logic is
import { fetchBlog } from './utils.js'
const { API_KEY } = process.env
fetchBlog(API_KEY).then(...)

Often there is not just an API key. With multiple arguments you can do something like this and pass an object.

// with multiple arguments
const fetchBlog = options => fetch(`https://www.example.com/api/blog?api_key=${options.apiKey}&post=${options.postId}`)

You can still insist on throwing exceptions simply inside the fetchBlog function.

// this function still has no idea what goes on in process.env
const fetchBlog = async options => {
    const { apiKey, postId } = options
    if(!apiKey) throw new Error(`Missing API key`)
    if(!postId) throw new Error(`Missing post id`)
    return fetch(`https://www.example.com/api/blog?api_key=${apiKey}&post=${postId}`)
}

Tadaa, no matter if apiKey or postId are undefined or the API endpoint itself returns an error because the key/post does not exist or some other reason, you receive proper feedback error message.

But even then, your post started with a typo case. It is useful to ask yourself if a real world situation exists where that could happen, especially if it is your own application. If your code design patterns and abstractions are correct then you will have dealt with the missing environment variable way before any HTTP request is made.

I think it is a bit early to tell people what will make them a better software engineer.

There exists some drawback to this approach though: if you want to package your app in a docker container, that would mean you need your API_KEY at build time in the docker environment and this is a known vulnerability because you would store your API key in the docker layers and it could be accessed within the docker image.

I'm not saying your method is not a good idea (it is) but it shouldn't be so absolute either as it can backfire at you.

Actually I really like this approach. It sounds like a best practice to me.

I have library to read environment variables as application config. I was thinking to add it to the library, having an option like mandatoryKeys but then I left it to users to validate the keys. Maybe adding that option and making it mandatory to define could force this practice. If they don't want to validate the keys they'll have to define mandatoryKeys: [] for instance. I'll think about it.

const { readEnv } = require('read-env');
// Or
import { readEnv } from 'read-env';
// Or in browser
window.readEnv('EXAMPLE');

npm install --save read-env

yarn add read-env

Thanks for the tip.

Cheers, 🚀🖖

I used to add auto-completing to my env vars using TypeScript like this:

namespace NodeJS {
  interface ProcessEnv {
    NODE_ENV: "development" | "production" | "test";
    APP_URL: string | undefined;
  }
}

While I'm coping your function add a small type:

export function getEnvVar(varName: keyof NodeJS.ProcessEnv): string {
  const unvalidatedEnvironmentVariable = process.env[varName];
  if (!unvalidatedEnvironmentVariable) {
    throw new Error(
      `Couldn't find env variable: ${varName}`
    );
  } else {
    return unvalidatedEnvironmentVariable;
  }
}

But, unfortunately, seems like the keyof NodeJS.ProcessEnv does NOT work.
Do you have any idea how to solve this?

In a case where you forgot to add the environment variable API_KEY the application won't even build/compile, and it will throw an error like this: Couldn't find environment variable: API_KEY.

I believe this statement if factually incorrect. The application will compile and will run into a runtime exception upon startup and crash the server.

Provided approach will not validate if all env variables exist before trying to run the server. Correct me if am wrong.

Can you suggest an approach to validate existence of all Env Vars during
nest build step?

Env Var is a perfect package for this npmjs.com/package/env-var

You can make a variable as required, parse from base64, other types. It’s been my goto recently

Thanks for the idea. To truly get it to throw during build, I added a custom plugin to the webpack config, similar to: stackoverflow.com/a/72277530