Should we have an options object that allows precedence for command-line arguments?

[nelsonic]

Should we allow command-line arguments or system/deployment environment variables to take precedence over values defined in env.json or vice-versa?

[nelsonic]

Closing as we are keeping env2 as simple as possible for now.
Please re-open this issue if you feel strongly about this feature...

[ninjasort]

I think you should. That's what the original env did and https://github.com/kentcdodds/cross-env does.

[nelsonic]

@cameronroe well done for digging out this issue! 😉
I think https://github.com/kentcdodds/cross-env has a slightly different goal than env2 in that cross-env is attempting to make environment variables behave consistently across platforms whereas env2 is just loading variables defined in a file into the process.env object using require('env2')('.env');
but you have reminded us that env2 does not have explicit support for Windows ...

[ninjasort]

Yep, and how would env2 run on the server? With a command, it can be easily put into a CI build to run the service.

[nelsonic]

@cameronroe env2 does not have a "CLI" or "bin script".
it's used exclusively in .js file to load an .env file which contains the list of environment variables.
On our CI service or Heroku we do not load and .env file we define the required environment variables using the interface.
e.g: https://github.com/dwyl/learn-environment-variables#using-environment-variables-with-travis-ci-