At present this is what the "badges" in the readme look like:

Which means that on NPM https://www.npmjs.com/package/env2 it's not very "re-assuring" ...

see: https://github.com/dwyl/env2/tree/df6a56900b711b44cb0fc6e083ead272c21ce47d

Who has time to type env.json or .env? We should support a default file.

Hi,

I am running a node express server, and have npm i --save env2 (it's in package.json and node_modules folder) but for some reason my sever keeps returning the error that it can't locate env2.

Do you know why this might be happening? Thanks!

APIkey = 1234 (doesnt work)
APIkey=1234 (works)

environment variable isnt available when spaces are included in its definition

If you're getting the following error:

State changed from starting to crashed
Error: Cannot find module 'env2'
at Function.Module._resolveFilename (module.js:469:15)

we should be able to locate the env.json or config.env file irrespective of where it is placed in the project.

I am using env2 for loading env variable in nodejs+graphql setup and call the env loading function at the top of index.js file followed by schema for graphql server.

I am facing a problem where the env2 has not loaded the variable even after the method has been called like just after the line require('env2')(/path/to/env.json).

This allows code gremlins to come in and change perfect code to broken code because they can see your test is imperfect. 😭 😧

Apparently "[t]ypically this is the fully resolved filename" of the requiring module. But why would there be a 'node_modules' in that path when we require from a module in our project? How is the id property different from the filename property?

Should say instructions below, not above (with reference to the git ignore file)

Is there a way to upload the env file to it?

At the moment things like: ENV_TEST_VAR=true read from .env files are string values in process.env.ENV_TEST_VAR.

Converting to primitive types would also make things more consistent with the case of using .json files.

An idea would be to update the add_dot_env_line_to_json function to:

function add_dot_env_line_to_json (json, env_variable) {  
  var environment_parts = env_variable.split('=');  
  try {  
    json[environment_parts[0]] = JSON.parse(environment_parts[1]);
  }
  catch(e){
    json[environment_parts[0]] = environment_parts[1];
  } 
  return json;
}

Let me know if this would suffice or if there's a better solution and I'll create a PR.

env2 looks like a nice way to manage config, it's just not the 12fa way to manage config. As it currently stands, env2 doesn't actually allow you to take in config from the environment! :)

Unless I'm missing something, 12fa explicitly calls out the pattern in env2 as an anti-pattern, and provides good reasons to avoid it:

Another approach to config is the use of config files which are not checked into revision control, such as config/database.yml in Rails. This is a huge improvement over using constants which are checked into the code repo, but still has weaknesses: it’s easy to mistakenly check in a config file to the repo; there is a tendency for config files to be scattered about in different places and different formats, making it hard to see and manage all the config in one place. Further, these formats tend to be language- or framework-specific.

Env vars are easy to change between deploys without changing any code; unlike config files, there is little chance of them being checked into the code repo accidentally; and unlike custom config files, or other config mechanisms such as Java System Properties, they are a language- and OS-agnostic standard.

Story

As a person wanting to know which which environment variables were in the .env file
I would like to have the environment variables that were in the .env file returned as an Object
So that I can check if the var was loaded from a file or from another place.

Currently in our usage instructions: https://github.com/dwyl/env2#use-in-your-code

We hint at the possibility that the environment variables loaded by env2
are assigned to the env constant:

const env = require('env2')('./path-to-your/.env');

But reading the code we can see that no such Object is being returned:

We could return the env on line 38 and it would (before the catch statement):

This would not alter the existing functionality of the package and would add this feature.

why is .env betterer than env.json ?

Calling the file .env appears to be the convention... http://stackoverflow.com/search?q=.env+file
(21k results)
So maybe we should recommend it in the readme/docs ...?

Should we support having the word "export" on a line definition?

So that we can copy-paste the entire env file into terminal and it will load up the env vars...

I don't think that we keep any state within env2 (apart from loading in path and fs; do they keep state?). Why is it necessary to decache the module?

The word Warning is not v. legible on Windows: (click to open the larger version)

Which makes it "unfriendly" to beginners ... 😞

originally reported by @cepm-nate on dwyl/learn-nightwatch#29 (comment)

Note: not so much a "bug" ... just not great for readability.

API keys may be a hard to understand example of using env2 because a lot of API applications would want more than local hosting. However in the case of using codecov, having your keys held locally would not cause problems for a live project and therefore could be a great example for env2.

This code works for me & maintains 100% coverage:

    if(filepath) { // if required without a config.env file we search for one!
      if(called_by_module > -1){
        filepath = path.resolve(parent_directory + filepath);
      }
      else {
        filepath = path.resolve(filepath);
      }
    }

Is it because it's more node-y / self-contained than a bash-y .env?

Readme needs some help...

• badges specifically codecov
  

• What section appears to have been affected by a PR/Merge conflict:
  

Anything else you think could be improved. (please comment in this issue before making changes. thanks!)

Currently I am using travis's repository environment variables, and these work perfect for the build process. However, upon trying to deploy (to app engine managed vm's in my case) those are not carried over. I see everywhere people suggesting to use a .env file or similar methods to store them. This makes sense for local, but if I want them to be available for deployment what is the best method?

I have one idea, but not sure how secure or ideal it is.
Basically since I don't want my .env on a public git repository, I have it added to my .gitignore. However, this means when a travis build triggers, there will be no .env cloned into the build enforcement. However, in theory I could put all my env's on the travis repository settings, and then as part of the travis script before deployment, copy those values and generate a .env file each build that will be deployed (of course making sure not to display them in the build output). This way no one would have access (I think) and I could manage all my variables from the Travis web interface.

Concerns:

1. Not sure how to go about accessing them, but I found this regarding travis access token which seems like it would work. (https://github.com/travis-ci/travis.rb#build-environment-variables)
2. Assuming I can access them, what is the best way to output them to a temp file securely.

Thank you

If you are using a .env version of the file and have a '=' in the value of the environment variable, you will not get the correct value of the environment variable, because of the fact that only the second segment is used after splitting on '=' (

I will fix this.

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

I npm installed env2 into a project to configure and access my environment variables. When I go to run the build with webpack, it keeps throwing an error:

WARNING in ./~/env2/lib/env.js
Critical dependencies:
31:69-76 require function is used in a way in which dependencies cannot be statically extracted
 @ ./~/env2/lib/env.js 31:69-76

ERROR in ./~/env2/package.json
Module parse failed: /node_modules/env2/package.json Line 2: Unexpected token :
You may need an appropriate loader to handle this file type.
| {
|   "name": "env2",
|   "version": "2.0.6",
|   "description": "Environment Variable Loader",
 @ ./~/env2/lib/env.js 82:18-44

I included a plugin in the webpack.development.config.js file but the problem still persists. Plugin:

new webpack.DefinePlugin({
    'process.env.NODE_ENV': '"development"'
    })

I was wondering if anyone has had a similar issue?

(ie path begins with ./ or ../ and is relative to the package.json or run directory)

It is non-intuitive within a complex file structure whether env vars are failing to load due to the wrong path being included or due to:

�[1m�[43m�[30m WARNING: �[22m�[42m�[30m env2 was required to load an .env file: �[46m�[30m ./.env �[1m�[43m�[30m INVALID JSON! �[22m�[42m�[30m Please see: http://git.io/vG3UZ�[49m�[39m�[22m

Documenting the above would help.

https://david-dm.org/dwyl/env2#info=devDependencies

What problem are they solving?

Need to update the devDependencies in this module to latest and confirm tests work as expected.
https://david-dm.org/dwyl/env2#info=devDependencies

also, we could Remove codeclimate-test-reporter as we are no longer using it...?

I know you can source a file like this but would there be any value in a command line tool?

At present we are printing out a large block of text:

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Error: ENOENT, no such file or directory '/home/travis/build/nelsonic/hits/config.env'
Your app has invoked env2 to load a configuration file but 
we could not find the configuration file: /home/travis/build/nelsonic/hits/config.env
please follow the instructions in the README to create your
env.json file and/or ensure that you give the correct path to it 
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

This is an eyesore. lets fix it.

See:

• env2/lib/env.js

  Lines 41 to 48 in a55f917

  	var msg = '\n- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -\n'
  	msg += e
  	msg += '\nYour app has invoked env2 to load a configuration file but \n'
  	msg += 'we could not find the configuration file: ' + filepath + '\n'
  	msg += 'please follow the instructions in the README to create your\n'
  	msg += 'env.json file and/or ensure that you give the correct path to it \n'
  	msg += '- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -\n\n'
  	console.log(msg);

• https://travis-ci.org/nelsonic/hits/builds/77237644#L213-L219

Hey @nelsonic, check out my defaultenv package I've created to solve the same problems -- I think you might like my approach:

• It also allows you to use .js files to export default variables, so you can compute values dynamically if need be
• It doesn't touch your app code -- instead it sets environment variables and then runs any command (e.g. defaultenv env/dev.js env/local.js -- npm start)

There is not try / catch around the JSON.parse. So parse errors cause env2 to output a not found error

Anyone have a strong view on this? if not, I'm going to put in the change today.