nodemon, babel-node: how to set environment variable?

Question

Dev environment starts with this command:

nodemon -w src --exec \"babel-node src --presets es2015,stage-0\"

How do i create a global variable (or process.env variable) __DEV__ = true?

Kerguelen

If you're running in bash, it's just __DEV__="true" nodemon -w src --exec \"babel-node src --presets es2015,stage-0\". It'll probably come in as a string, you'll have to parse it or rely on it's absence for truthiness/falsiness. – Caa

Thank you! I've tried this just without quotes, as suggested in all discussions i've seen and it didn't work. – Kerguelen

where do you want create this variable? – Edmead

Answer 1

You can either add "env" property to nodemon.json, like this:

...
"env": {
    "__DEV__": "true"
}

Or you can prepend __DEV__="true" to start script in package.json. Both worked for me.

Monocyte

This is not a good approach because the environment variables will be pushed in the repository. The best way is using env files and ignoring in the gitignore file. – Uptotheminute

Answer 2

You can add a "nodemonConfig" property to package.json with your env info. Then execute nodemon in your scripts section.

"nodemonConfig": {
  "restartable": "rs",
  "ignore": [
  "node_modules/**/node_modules"
  ],
  "delay": "2500",
  "env": {
    "NODE_ENV": "development",
    "NODE_CONFIG_DIR": "./config"
  }
}

Bragg

This is not a good approach because the environment variables will be pushed in the repository. The best way is using env files and ignoring in the gitignore file. – Uptotheminute

@Uptotheminute No. That's only if you want to override env for local configuration. There are plenty of reasons to want to set an environment variable that is the same for everyone that uses it. Using .env is outside the scope of this question. – Hypochlorite

Answer 3

For windows: set __DEV__ = true&&nodemon -w src --exec \"babel-node src --presets es2015,stage-0\"

Kym

Answer 4

If you don't want to handle the env variables in the nodemon call, you can do something like this.

1. Create a file called '.env' and put something like this in it:

   DEV=true

2. Then in your application entry file put the following line in as early as possible:

   require('dotenv').config();
   

Bibliotheca

If you are going to take this approach, there are better ways to include the values and keep them in scope instead of setting them to environment variables. – Sewn

Answer 5

I normally use the dotenv module on my projects.

We just need to create a .env file and require the dotenv module in our project:

.env file:

 __DEV__="true"

your-script.js file:

require('dotenv').config();

console.log(process.env.__DEV__)

Creating .env files is normally a good option since we can prevent to commit our environment files using .gitignore

Uptotheminute

Answer 6

just define in codes (server file) like this proccess.env.VARIABLE="true"

Edmead

@AsadSaeeduddin why defeats? – Edmead

Because the purpose of an environment variable is to allow your process to be controlled by whichever agent is starting it, i.e. its environment. If you hardcode the value in the code, there is no point to even using environment variables, since the process environment can no longer have any control over the process. – Caa

no you can use this variable every where in project @AsadSaeeduddin – Edmead

I don't think you're understanding what I'm saying. If I define the value of the environment variable in my code, then someone else who takes my code and tries to start it cannot pass any values for said environment variables. They're no longer variables, but rather constants. – Caa

ok i get it, your right, but in this case of using you have not to define variable every time you start the script,specially if you have one agent for project – Edmead

@AsadSaeeduddin, you are right in general, environment variable has to be set by some external agent, but the thing is that the nodemon is the external agent that starts you application, it especially helpful when you are running application for development purposes on you local machine, it helps you to rely on the same environment variables always. The difference it only could be in the ways how you set them on production and on your local machine. – Bregma

A set of preset scripts can be a good idea if you know what you're doing. Some people are way too quick to dismiss an idea. – Swope