Node.js setting up environment specific configs to be used with everyauth

Question

I am using node.js + express.js + everyauth.js. I have moved all my everyauth logic into a module file

var login = require('./lib/everyauthLogin');

inside this I load my oAuth config file with the key/secret combinations:

var conf = require('./conf');
.....
twitter: {
    consumerKey: 'ABC', 
    consumerSecret: '123'
}

These codes are different for different environments - development / staging / production as the callbacks are to different urls.

Question: How do I set these in the environmental config to filter through all modules or can I pass the path directly into the module?

Set in env:

app.configure('development', function(){
  app.set('configPath', './confLocal');
});

app.configure('production', function(){
  app.set('configPath', './confProduction');
});

var conf = require(app.get('configPath'));

Pass in

app.configure('production', function(){
  var login = require('./lib/everyauthLogin', {configPath: './confProduction'});
});

? hope that makes sense

Cabana

Found a solution that is using some of the ideas from below, by having the module = function rather than an object I can evaluate process.env.NODE_ENV and return the correct object for the environment. A little messy but works. – Cabana

Pardon the shameless self-promotion, but I wrote a module for node.js that will do this via separate files and a command-line switch: node-configure – Rationality

Answer 1

My solution,

load the app using

NODE_ENV=production node app.js

Then setup config.js as a function rather than an object

module.exports = function(){
    switch(process.env.NODE_ENV){
        case 'development':
            return {dev setting};

        case 'production':
            return {prod settings};

        default:
            return {error or other settings};
    }
};

Then as per Jans solution load the file and create a new instance which we could pass in a value if needed, in this case process.env.NODE_ENV is global so not needed.

var Config = require('./conf'),
    conf = new Config();

Then we can access the config object properties exactly as before

conf.twitter.consumerKey

Cabana

Why are you using new here? – Dimorph

I second @bluehallu. Is new necessary? – Addressee

the equivalent in Windows would be SET NODE_ENV=development – Alyssa

Instead of doing new. I do following in the config.js .... Config = function(){...}; module.exports = Config() – Ministry

What if I have 50 web servers in which case its going to be difficult to go on to each server to manually initiate the script – Rosemarierosemary

Answer 2

You could also have a JSON file with NODE_ENV as the top level. IMO, this is a better way to express configuration settings (as opposed to using a script that returns settings).

var config = require('./env.json')[process.env.NODE_ENV || 'development'];

Example for env.json:

{
    "development": {
        "MONGO_URI": "mongodb://localhost/test",
        "MONGO_OPTIONS": { "db": { "safe": true } }
    },
    "production": {
        "MONGO_URI": "mongodb://localhost/production",
        "MONGO_OPTIONS": { "db": { "safe": true } }
    }
}

Terti

Hi, could you please explain why you think this is better way to express configuration settings (as opposed to using a script that returns settings). ? – Indispose

I guess it doesn't make too much difference. Mentally, when I see JSON I think 'static data' vs when I see a JS file, I think there's some logic inside it. Also, another benefit of using .json type is that other languages can import the same file. – Terti

@VenkatKotra configuration is generally considered static, and therefore best expressed declaratively with things like json, yaml, ini, etc. Done imperatively, with a script that yields that state, sortof implies something dynamic is happening, which would be bad. – Zelaya

Be aware that this method exposes credentials in source control. – Sophistication

can i make diffrence url for staging and production? – Monomial

Unfortunately, this doesn't work. Please see: #46756352 – Stalker

Answer 3

A very useful solution is use the config module.

after install the module:

$ npm install config

You could create a default.json configuration file. (you could use JSON or JS object using extension .json5 )

For example

$ vi config/default.json

{
  "name": "My App Name",
  "configPath": "/my/default/path",
  "port": 3000
}

This default configuration could be override by environment config file or a local config file for a local develop environment:

production.json could be:

{
  "configPath": "/my/production/path",
  "port": 8080
}

development.json could be:

{
  "configPath": "/my/development/path",
  "port": 8081
}

In your local PC you could have a local.json that override all environment, or you could have a specific local configuration as local-production.json or local-development.json.

The full list of load order.

Inside your App

In your app you only need to require config and the needed attribute.

var conf = require('config'); // it loads the right file
var login = require('./lib/everyauthLogin', {configPath: conf.get('configPath'));

Load the App

load the app using:

NODE_ENV=production node app.js

or setting the correct environment with forever or pm2

Forever:

NODE_ENV=production forever [flags] start app.js [app_flags]

PM2 (via shell):

export NODE_ENV=staging
pm2 start app.js

PM2 (via .json):

process.json

{
   "apps" : [{
    "name": "My App",
    "script": "worker.js",
    "env": {
      "NODE_ENV": "development",
    },
    "env_production" : {
       "NODE_ENV": "production"
    }
  }]
}

And then

$ pm2 start process.json --env production

This solution is very clean and it makes easy set different config files for Production/Staging/Development environment and for local setting too.

Majors

npm install config --save , it's not better? – Meathead

Answer 4

In brief

This kind of a setup is simple and elegant :

env.json

{
  "development": {
      "facebook_app_id": "facebook_dummy_dev_app_id",
      "facebook_app_secret": "facebook_dummy_dev_app_secret",
  }, 
  "production": {
      "facebook_app_id": "facebook_dummy_prod_app_id",
      "facebook_app_secret": "facebook_dummy_prod_app_secret",
  }
}

common.js

var env = require('env.json');

exports.config = function() {
  var node_env = process.env.NODE_ENV || 'development';
  return env[node_env];
};

app.js

var common = require('./routes/common')
var config = common.config();

var facebook_app_id = config.facebook_app_id;
// do something with facebook_app_id

---

To run in production mode : $ NODE_ENV=production node app.js

---

In detail

This solution is from : http://himanshu.gilani.info/blog/2012/09/26/bootstraping-a-node-dot-js-app-for-dev-slash-prod-environment/, check it out for more detail.

Goldsberry

Answer 5

The way we do this is by passing an argument in when starting the app with the environment. For instance:

node app.js -c dev

In app.js we then load dev.js as our configuration file. You can parse these options with optparse-js.

Now you have some core modules that are depending on this config file. When you write them as such:

var Workspace = module.exports = function(config) {
    if (config) {
         // do something;
    }
}

(function () {
    this.methodOnWorkspace = function () {

    };
}).call(Workspace.prototype);

And you can call it then in app.js like:

var Workspace = require("workspace");
this.workspace = new Workspace(config);

Hypocotyl

I would rather keep all the logic inside the app.js app.configure('development code, but will have a look to see if I can use this solution with that – Cabana

Update to this answer: Architect is a dependency management framework that solves this in a way nicer way. – Hypocotyl

Answer 6

An elegant way is to use .env file to locally override production settings. No need for command line switches. No need for all those commas and brackets in a config.json file. See my answer here

Example: on my machine the .env file is this:

NODE_ENV=dev
TWITTER_AUTH_TOKEN=something-needed-for-api-calls

My local .env overrides any environment variables. But on the staging or production servers (maybe they're on heroku.com) the environment variables are pre-set to stage NODE_ENV=stage or production NODE_ENV=prod.

Hentrich

Answer 7

Set environment variable in deployment server (ex: like NODE_ENV=production). You can access your environmental variable through process.env.NODE_ENV. Find the following config file for the global settings

const env = process.env.NODE_ENV || "development"

const configs = {
    base: {
        env,
        host: '0.0.0.0',
        port: 3000,
        dbPort: 3306,
        secret: "secretKey for sessions",
        dialect: 'mysql',
        issuer : 'Mysoft corp',
        subject : '[email protected]',
    },
    development: {
        port: 3000,
        dbUser: 'root',
        dbPassword: 'root',

    },
    smoke: {
        port: 3000,
        dbUser: 'root',
    },
    integration: {
        port: 3000,
        dbUser: 'root',
    },
    production: {
        port: 3000,
        dbUser: 'root',
    }
};

const config = Object.assign(configs.base, configs[env]);

module.exports= config;

"base" contains common config for all environments.

Then import in other modules like:

const config =  require('path/to/config.js')
console.log(config.port)

Happy Coding...

Pantechnicon

this should be ignored by git right because it contains sensitive info? If this file is ignored then how to include this file during deployment? – Chartography

that's a very good question, in this case you can have environent specific file stored in respective servers. then while deploying just pull configs from local server. – Pantechnicon

Answer 8

How about doing this in a much more elegant way with nodejs-config module.

This module is able to set configuration environment based on your computer's name. After that when you request a configuration you will get environment specific value.

For example lets assume your have two development machines named pc1 and pc2 and a production machine named pc3. When ever you request configuration values in your code in pc1 or pc2 you must get "development" environment configuration and in pc3 you must get "production" environment configuration. This can be achieved like this:

1. Create a base configuration file in the config directory, lets say "app.json" and add required configurations to it.
2. Now simply create folders within the config directory that matches your environment name, in this case "development" and "production".
3. Next, create the configuration files you wish to override and specify the options for each environment at the environment directories(Notice that you do not have to specify every option that is in the base configuration file, but only the options you wish to override. The environment configuration files will "cascade" over the base files.).

Now create new config instance with following syntax.

var config = require('nodejs-config')(
   __dirname,  // an absolute path to your applications 'config' directory
   {
      development: ["pc1", "pc2"],
      production: ["pc3"],

   }
);

Now you can get any configuration value without worrying about the environment like this:

config.get('app').configurationKey;

Know

Answer 9

This answer is not something new. It's similar to what @andy_t has mentioned. But I use the below pattern for two reasons.

1. Clean implementation with No external npm dependencies

2. Merge the default config settings with the environment based settings.

Javascript implementation

const settings = {
    _default: {
       timeout: 100
       baseUrl: "http://some.api/",
    },
    production: {
       baseUrl: "http://some.prod.api/",
    },
}
// If you are not using ECMAScript 2018 Standard
// https://mcmap.net/q/40399/-how-can-i-merge-properties-of-two-javascript-objects
module.exports = { ...settings._default, ...settings[process.env.NODE_ENV] }

I usually use typescript in my node project. Below is my actual implementation copy-pasted.

Typescript implementation

const settings: { default: ISettings, production: any } = {
    _default: {
        timeout: 100,
        baseUrl: "",
    },
    production: {
        baseUrl: "",
    },
}

export interface ISettings {
    baseUrl: string
}

export const config = ({ ...settings._default, ...settings[process.env.NODE_ENV] } as ISettings)

Cerussite