Question

131

Using NODE_ENV with multiple environments in JavaScript projects

rated 0 times [ 133] [ 2] / answers: 1 / hits: 20289 / 7 Years ago, wed, march 1, 2017, 12:00:00

I work on many projects that run on Express servers, whether they are front-end (i.e. React.js) codebases or server-side Node.js codebases.

Many times with the front-end codebases I would load conditional configuration based on NODE_ENV, such as the URL of the restful API that the front-end makes requests to.

I many times also used NODE_ENV to conditionally load things like DB configuration for server-side Node.js projects.

On a project that consisted of development, staging, and production (3 environments), I would usually set up my code to load configuration based on the NODE_ENV being set to any one of those 3 environments (and maybe also local).

I was recently working on a project that was referring to the production environment as live.

When I decided to set the NODE_ENV=live for this environment, a coworker pointed out a major flaw with this approach.

It seems that Express and some other libraries for Node.js latch onto the fact that you will either be using production or development as your NODE_ENV and using other names for your environments can have unexpected effects.

For example, Express needs NODE_ENV=production in order to run in production mode. According to the Express docs Tests indicate that just doing this can improve app performance by a factor of three!

Basically, I'm curious if it is considered common practice to set the NODE_ENV to values other than development and production, like I've been doing in my projects.

I feel that if I'm going to deploy my code to the development or staging environments on the cloud, I don't think they should run in a different Express mode than the production environment.

Does it make more sense to maintain configurations separate from NODE_ENV?

For example, does it make sense to base your configuration off of a variable like APP_ENV, while ensuring that NODE_ENV is either development or production for frameworks/packages like Express.

Answers

Only authorized users can answer the question. Please sign in first, or register a free account.

eden

Add To Favorites

Follow

Total Points: 730

Total Questions: 117

Total Answers: 117

Location: Peru

Member since Fri, Oct 14, 2022

2 Years ago

answered 7 Years ago domeniccolti · Accepted Answer

NODE_ENV is used to differentiate between development and production instances. It is not a good idea to run production code without NODE_ENV=production. NODE_ENV=development is usually not that important, because libraries usually just check to see if NODE_ENV !== 'production'. So if you want to have multiple production node environments, or production-like environments, each of them should set NODE_ENV=production. That said, you can definitely set other environment variables to whatever values you desire, and read them back from node at runtime.

A reasonable example would be to have a local staging and production versions of your configuration. In this case, I would recommend having NODE_ENV be just one of the parameters you set up for each environment. For instance, you might want three different databases for each of local, staging and production but set NODE_ENV to development on local, and production for both staging and production.

Since the variables will be shell variables, you will need a way of loading certain environment variables on the target operating system prior to running the server. Modules like https://www.npmjs.com/package/dotenv look promising for this purpose.