Don't do this! What TS is trying to tell you is that this variable may not have been set in the environment, and thus it's value inside of the program will evaluate to `undefined`.

What you are doing when you create the environment.d.ts file is forcing the transpiler to assume the variable will have been set, which is not really true. The program may still end up being executed in an environment in which the variable was not set.

Instead, what I like to do is create a config file in your project where you export an object containing all configuration values for your project. There, you can set default values for variables coming from the environment. In this way, you guarantee a value will be present for the execution of your program:

  export const config = {
    dbConnectionString: process.env.DB_CONNECTION || 'localhost:27017',
    nodeEnv: process.env.NODE_ENV || 'development',
  }

Remember that the NodeJS runtime guarantees the setting of no environment variables. The NODE_ENV variable is simply a convention that was started by express.

Stuff like `dbConnectionString: process.env.DB_CONNECTION || 'localhost:27017'` is a good way to boot your app with the wrong environment variables and potentially cause security issues. I'd advise to make sure your app doesn't start or deploy if expected env vars aren't set.

If you do have some environment variable for which no safe fallback value may exist, you can implement that logic in the config file also. I was just giving a cursory example ;)

Don’t forget the nullish coalescing operator, ??, which is probably nicer than using || here.

https://www.typescriptlang.org/docs/handbook/release-notes/t...

You're right, that is a much better choice for this situation!

> Remember that the NodeJS runtime guarantees the setting of no environment variables. The NODE_ENV variable is simply a convention that was started by express.

You're right that the runtime itself doesn't guarantee any env vars. I'm not sure who used it first, but npm also sets NODE_ENV (and some other env vars I think) in its different lifecycles, depending on if you provide the --production/--no-production flag when running it. But not sure if that came after or before express started using it.

Typescript’s type narrowing is useful for this exact situation:

  // v is any or unknown
  if (typeof v !== "string") {
    throw new Error("oops")
  }
  // v is now string

You can’t get runtime type correctness by deceiving typescript into it.

Rather than declaring it yourself every time, there is an @types/node you can install with all of the Node-specific types including process.env:

https://www.npmjs.com/package/@types/node

(ETA: It's mentioned in the StackOverflow and they still add an extra definition on top of it, but the env in the types today is a Record and you don't have to do it, you just won't get auto-completion on the names.)

This is why I think non-null assertion should be accepted by default. If you forget to set the DB connection string, my backend is essentially useless! I can’t persist anything. I do process.env.DB_CONN! - at runtime I’ll get an error that the string is undefined, but that’s actually what I want - I want my app to throw an error so I can quickly find the error, slap my forehead and put the variable in the .env file.