Orthogonal Environment Variables

[maxbeatty]

That’s a nice way of saying removing variable expansion. I haven’t been presented with a good use case for variable expansion where copying and pasting (TEST=$BASIC) or string concatenation (process.env.TEST_BASIC = process.env.TEST + process.env.BASIC) wouldn’t be a better solution. By supporting these limited use cases, we're encouraging sub-optimal configuration management and forcing people to escape their variables.

• removed variable expansion code, tests, and docs
• removed variable escaping code, tests, and docs
• added license
• added changelog
• removed link to ruby gem of same name to eliminate confusion about feature parity
• add link to process.env in nodejs docs to make it easier to learn about what we're populating
• documented load as an alias to config so documentation is more consistent

This would be a breaking change so outlined the changelog as this being a v2 candidate

[motdotla]

I haven’t been presented with a good use case for variable expansion where copying and pasting (TEST=$BASIC) or string concatenation (process.env.TEST_BASIC = process.env.TEST + process.env.BASIC) wouldn’t be a better solution. By supporting these limited use cases, we're encouraging sub-optimal configuration management and forcing people to escape their variables.

My sentiments as well

Love the changelog

I'm going to think on this. @jcblw let's get your thoughts too.

@maxbeatty this is nicely proposed.

[jcblw]

Im down for this I think we start encouraging people to start building things ontop of dotenv rather then wanting the functionality inside of dotenv. Maybe along with the bump we should try try to formalize the way to integrate things like variable expansion into dotenv. The same way we added the way to load the .environment file when removing that feature.

eg.

// kinda works like arr.map 
function variableExpansion (key, value, keyValues) {
  ...
  return newValue;
}

dotenv.config({mapValues:[variableExpansion]});

[maxbeatty]

We could return the parsed object instead of a boolean from config. This should give someone everything they need to continue setting values on process.env.

const dotenv = require('dotenv')
const variableExpansion = require('dotenv-plugin-varexp')

const myEnv = dotenv.config()
variableExpansion(myEnv)

[jcblw]

I don't know if that would be a good integration point tho. It really still leaves alot that would need to be done to emulate the default behavior of dotenv.

const parseObj = dotenv.config()
for (let key in parseObj) {
  ... // do stuff
  // apply to process.env
}

I pushed up an example of working code that emulates that example I have above. orthogonal-var-intergrations branch. What I like is that it add a new option to the parse as well as expose that same functionality to the config method.

Let me know your thoughts @maxbeatty and @motdotla .

[maxbeatty]

Feels premature to add an integration point with no proposed integrations. I suspect someone will want variable expansion back in the not-so-distance future. The proposed mapping function is good for that, but what happens when someone wants to do more than one thing? parse might start having more code to handle integrations than parsing.

Since we're ultimately working with one object (process.env), "chaining" calls feels more natural (probably because I've spent a lot of time with jQuery and underscore/lodash).

// jQuery
$('p').find('a').each(...)

// lodash
_.pluck(_.filter(users, 'active', false), 'user');

By exposing dotenv's core competency of a parsed object from a text file, we can allow people to easily continue to alter process.env without maintaining hooks into the core part of our logic. There will be some extra for loops, but node is pretty good at those and it's a one time run.

dotenvValidate(dotenvVarExp(dotenv.config()))

[maxbeatty]

Any more thoughts on this? All open issues and PRs could be closed as a result of this change.

[motdotla]

The chaining approach is good. Thanks mucho @maxbeatty. Merging.