An environemnt variable based replacement of Meteor.settings
which exposes process.env
on both server and client. Supports .env files and a twelve-factor app application architecture.
========================================
meteor add clinical:env
========================================
You can create a .env
file in the root directory of your project, which acts somewhat like an application specific bash_profile
file. Simply add the environment variables you want for the app, as if you were specifying export
or setenv
commands. A sample .env
file might look something like this:
DEBUG=true
TRACE=false
DOMAIN=http://www.foo.com
METEOR_ENV=development
SECRET_KEY=ao8v7d8c8vcdi98vekd
========================================
Server usage is fairly straightforward, with all the environment variables being exposed through process.env
. There are a number of helper functions, such as isDevelopment
and isTesting
and Env.display()
which provide a rich programming API for environemnt-aware applications.
var secret_key = process.env.SECRET_KEY;
Meteor.startup(function(){
console.log("Starting up " + process.env.DOMAIN + " in " + process.env.METEOR_ENV);
if(process.env.DEBUG){
Env.display();
}
if(Env.isDevelopment){
console.log("Logged in user is: " + Meteor.userId());
}
});
For environment variables to be exposed on the client, you have to explicitly opt-in by using the Env.allow()
function.
Env.allow({
DEBUG: true,
TRACE: true,
METEOR_ENV: true,
DOMAIN: true,
SECRET_KEY: false
});
========================================
The client API is mostly isomorphic to the server, with variables being exposed on process.env
, and all the same helper booleans available.
if(process.env.METEOR_ENV){
console.log("Running in " + process.env.METEOR_ENV);
}
if(Env.isDevelopment){
console.log("Logged in user is: " + Meteor.userId());
}
if(process.env.DEBUG){
Env.display();
}
You can also use the API within templates, like so:
<template name="foo">
<span>Some lorem ipsum...</span>
{{#if isDevelopment}}
<span>This is Development!</span>
{{/if}}
</template>
========================================
The complete API appears below.
Function, Anywhere
Function, Anywhere
Function, Server
Boolean, Anywhere
Boolean, Anywhere
Boolean, Anywhere
Boolean, Anywhere
Boolean, Anywhere
Boolean, Anywhere
Boolean, Anywhere
Spacebars, Client
Spacebars, Client
Spacebars, Client
Spacebars, Client
Spacebars, Client
========================================
We can specify environment variable in a few different ways (which is exactly why environment variables are so handy); each with a different precedent.
####1. Environment Profile
The most insistent way to define the variable. Will override any other setting.
nano ~/.profile
METEOR_ENV="development"
As insistent as setting the variable in the ~/.profile
file, but is temporary to the shell session.
export METEOR_ENV="staging"
Probably the most convenient way of specifying an environment variable; particularly for debugging and development purposes. Setting an inline variable will override a .env
file, but will be ignored if the variable has been specified in ~/.profile
or defined via export
.
METEOR_ENV="testing" meteor -p 4000
The .env
file is similar to ~/.profile
, but is application specific. Think of it as a way to mix-and-match a ~/.profile
file on a per-app basis.
METEOR_ENV="dev"
NODE_ENV takes precedent over METEOR_ENV
========================================
Try not to commit your .env file to version control. It is best to keep it local to your machine and local on any machine you deploy to. Keep production credential .envs on your production machines, and keep development .envs on your local machine.
Also, beware environment variables that have been sent to the client, and which wind up getting stored in cache. You may need to debug using incognito mode.
========================================
This package is a mashup and synthesis of a number of other packages.
pauldowman:dotenv mrt:environment-hooks mrt:allow-env panphora:environment-template-helpers jboulhous:dev
A big shout out to Mike Bannister, Tom Wijsman, Paul Dowman, David Miranda, Neil MacMunn, Jamal Boulhous, Gadi Cohen, and Arunoda. This package wouldn't have happened without their work.
========================================
When running tests, make sure to specify the METEOR_ENV
environment variable!
METEOR_ENV=development meteor test-packages clinical:env
========================================