A system of priority of which environment variable value to choose. However, if no value exists at a level of priority, it is not overwritten as an empty value.

Some toolchains will only use the standard environment names:

Thus, it is best to avoid other non-standard environment suffixes (as a convention, not a rule):

You can read more about flow priority on the 

Adding or using the complexity of dotenv-flow is not always necessary, but it is important to understand. The two situations that benefit from dotenv-flow:

# local env files
.env.local
.env.*.local

---
title: dotenv flow
isPublicLesson: true
useMdx: true
privateVideoUrl: https://stream.mux.com/U5MPYIL8cnC01BitoPuDkLMd6CXfpOjuPHqhwcW74it4.m3u8
code: https://gitlab.com/fullstackio/books/newline-course-apps/environment-variables-for-web-developers-app/-/tree/main/code/module_01/lesson_01.03/App?ref_type=heads
---

## What is dotenv-flow

A system of priority of which environment variable value to choose. However, if no value exists at a level of priority, it is not overwritten as an empty value.

Some toolchains will only use the standard environment names:

-   development
-   production
-   test

Thus, it is best to avoid other non-standard environment suffixes (as a convention, not a rule):

-   dev
-   develop
-   local
-   prod
-   staging
-   stage

You can read more about flow priority on the [npm dotenv flow page](https://www.npmjs.com/package/dotenv-flow#variables-overwritingpriority).

## When to use dotenv-flow

Adding or using the complexity of dotenv-flow is not always necessary, but it is important to understand. The two situations that benefit from dotenv-flow:

A)

-   automated deployments
-   if you need environment-specific defaults

Usage:

-   `.gitignore`: `.env.local`
-   set defaults in `.env`, `.env.production`, `.env.development` and commit
-   during development, set env vars in `.env.local`

B)

-   compilations being done locally, or you are testing production settings locally

Usage:

-   `.gitignore`: `.env.local`, `.env.production.local`, `.env.development.local`
-   commit `.env.*template` or `.env.*example`
-   during development, set env vars in the environment-specific file(s), i.e., `.env.development.local` or `.env.production.local`

## Validating your environment variables

-   [`dotenv-extended`](https://www.npmjs.com/package/dotenv-extended): validates your `.env` files using regex and schema files
-   [`envalid`](https://www.npmjs.com/package/envalid): validates the values of your environment variables, can co-exist with dotenv

## .gitignore

    # local env files
    .env.local
    .env.*.local

## Links

-   [What is regex?](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Guide/Regular_expressions)
-   [What is gitignore?](https://www.atlassian.com/git/tutorials/saving-changes/gitignore)
-   [ChatGPT: Dotenv-flow for Node.js](https://chatgpt.com/share/885036dd-a632-43bc-9a33-373af738b7df)
-   [ChatGPT: Env Var Validation Tools](https://chatgpt.com/share/c31f9c0b-9070-45a2-b827-9c61686d863c)
-   [Using dotenv to manage environment variables in Nodejs](https://dev.to/vyasriday/using-dotenv-to-manage-environment-variables-in-nodejs-3ja1)
-   [How to Use Node Environment Variables?](https://www.knowledgehut.com/blog/web-development/node-environment-variables)


Kemal Ahmed

dotenv flow

So in the last video we have talked about how to set one set of configurations,

like if you have your local environment, what if you also want to do automated

test your production environment at your own machine? What do you do when you

sets of configurations? In 1.2 we're going to talk about when, why, and how to

technique called dot n flow. So what is dot n flow? It's a strategy to

of a variable to use when you have multiple configuration sets. It's actually

a numerous front end tool chains, but also has a standalone library, which is

today. As you can see, we're picking up from the end of the last lesson. And we

go ahead and show you how to use it. First thing I'm going to do is actually

actually use this instead of dot n. So you'd first uninstall dot n. And then

dot n dash flow. You also configured in almost exactly the same way, where it

n dot config, you just say dot n flow dot config. And it actually runs the same

going to do is make a copy of my dot n. So we now have two configuration sets,

put at the end of the file dot n dot production. The way it works is when the

matches the suffix of dot n dot whatever, that file is chosen. In this case, I

production. The standard environment names are test, production, and

these built in environment names that flow provides, because it's a convention

libraries use, such as just, Babel, etc. And we'll go through those two in a

flow hierarchy documentation in the lesson docs below. However, you can

any name that you want. So the way to take advantage of multiple configuration

of course, to have multiple different sets. So for now, I'm going to show you

We have a use course value in our dot n. So in our dot n dot production, I'm

value to true. I'm not going to change the server URL for now. And that's okay.

back to that. Next thing that I'll do is I'll go to my package JSON and make

two start scripts, one for production, and one, that's just without any, any

Now let's see the difference and see what happens. If you run start, so that

served to all domains, which means that the use course is off. And then we'll

production. And it says exclusively served to local host. One problem with this

you may want to check in standard variables to get like the use course and not

variables, like the server URL. What you can do is you can create a dot n dot

So instead of overriding it here, I'll make a copy of dot n, call it dot n dot

And I'll keep the server URL value and remove it from dot n dot production.

way to specify these local values because it is never supposed to be checked

Make sure you add it to your get ignore. And dot star dot local dot n dot local

Dot local takes even higher precedence than dot n. So even if you have values

n or your dot m dot production, the dot local will override that. You can also

that is dot m dot production dot local. Although I'm not sure that's too

you get a bit complicated, but it is a feature that you can use. We're not

Some of you are probably finding this whole flow process a little bit tedious

So let me explain why having multiple layers is useful. It's help. It isn't

useful. It isn't always helpful. I'd say there's only about two types of

help with. And for this lesson, let's call them a and b. A is for default. If

values that aren't secrets that you want to keep in your dot n file and plan on

into get flow would allow you to use the dot n dot local for setting the values

development. In production, you'll still be able to set the environment values

of your automated deployments, which will go over in module two. It can also be

lot of non-secret configuration values that differ between development and

such as toggling a set of features for a beta environment. If you don't have

defaults and you're doing automated deployments, you can already set

without dot and flow by setting the values in your dot n file for local testing

dot getignore, and then for production, setting the real values through your

Learn

The newline Guide to Building Your First GraphQL Server with Node and TypeScript

Teach

Amelia Wattenberger

Author of Fullstack D3

Community

Masterclasses

Tutorials

Fullstack React with TypeScript