dshaw/env

Herding invisible cats

env's Issues

npm WARN package.json env No license field.

Hi @dshaw,
We would prefer not to see the npm warning when install env.

Would you consider adding the default ICS or do you have a preference for a different license?
Thanks! 👍

CLI for validation / install

Would be cool to have a CLI for:

• validating an environment before starting the process.
• listing currently set values for required and specified env vars
• setting or modifying env vars.

Extend Functionality to Export the vars loaded from env.json into process.env Object ?

Hi @dshaw,
We would really like to extend _env_ to make all configuration loaded from env.json available as process.env.VAR_NAME would you accept a PR for this extension.
This would simply be a loop to itterate over the entries in env.json and add them to the process.env object using your env.set method.

(100% backward compatibility will be maintained and 100% test coverage)
Let us know.
Thanks!

Enumerate appropriate values? Validation rules?

I'm assuming the "1" values in the JSON file are just "truthy" values for now. What would you think of enumerating possible values? Perhaps even validation rules, (though that may be pushing it). For instance:

{
  'ENVIRONMENT' : {
    'values' : [ 'dev', 'prod', 'test' ]
  },
  'PORT' : {
    'validate' : function(value) {
      return value < 9999 && val > 1000;
    }
}

I don't think this validating impl "feels" right; it probably belongs in the biz logic, but there's something to be said for having it in the env spec for clarity. You get the idea. Thoughts?

Use case for "optional" vars?

Would there ever be a use case for optional env variables? Would that need to be in the env spec?

Would you accept an update PR with tests?

Hi @dshaw we are needing an environment variable manager for our project dwyl/app#93
would you accept a PR with tests?