PER_ENV & NODE_ENV?

[ericclemmons]

@willrstern @comamitc Hey, since we're using this + Docker in our projects, I've noticed that this would be useful for me:

diff --git a/bin/per-env b/bin/per-env
index 9e2f884..0aa65c5 100755
--- a/bin/per-env
+++ b/bin/per-env
@@ -5,13 +5,14 @@ var spawn = require("child_process").spawn;

 // Default to "development"
 var NODE_ENV = process.env.NODE_ENV || "development";
+var PER_ENV = process.env.PER_ENV || NODE_ENV;

 var env = Object.assign(
   {},
   // Default NODE_ENV
   { NODE_ENV: NODE_ENV},
   // Override with package.json custom env variables
-  (pkg && pkg["per-env"] && pkg["per-env"][NODE_ENV]) || {},
+  (pkg && pkg["per-env"] && pkg["per-env"][PER_ENV]) || {},

   // Explicit env takes precedence
   process.env

Here's the gist of it:

• NODE_ENV is effectively a "stage" variable (e.g. production, test, staging), primarily because of how it's the de-facto environment variable that the ecosystem relies on to alter behavior (e.g. minification).
• Here, I hacked in support for a PER_ENV variable to define which property to use in package.json's per-env object.
• By doing this, I'm able to basically do "integration" development, using real data.

Is there a better way of doing this?

• PER_ENV isn't immediately clear that it's really just borrowing environment configuration from that object.
• NODE_ENV=integration isn't really ideal, since any non-development NODE_ENV is prepared as if it's going to go to production.

Oh wait. Or am I an idiot and should just copy/paste per-env.staging over per-env.development and call it a day? lol