@fakiolinho I see what you mean about leaking this information into the client, however I also would love to fix this so that it doesn't bundle the whole .env file and only loads the variables you use...

One of the cool things about webpack is its ability to minify your code in an impressive way:

const test = true
if (test) {
  console.log('yes')
} else {
  console.log('nope')
}

// becomes...
if (true) {
  console.log('yes')
} else {
  console.log('nope')
}

//becomes
console.log(yes)

That being said, it would be great if we could somehow resolve the plugin to determine which env variables are loaded, and only bundle those.

i.e.

//instead of:
console.log({"DB_PASSWORD":"test1234", "NODE_ENV":"production"}.NODE_ENV)

//it would just simply do:
console.log("test1234")

@mrsteele i 'd like to help with this but i am not sure i got you 100%. Let's say we have this .env:

DB_USER='root'
DB_PASS='root'

API_URL=http:https://someurl.com:9000

I need to use just 1 .env for my app and i need to inject in client's bundle only API_URL so i can create a middleware for my client-side HTTP request library and pass that API endpoint in a dynamic fashion. So far so good but i definitely don't need DB_USER & DB_PASS to be injected into my bundle. Right now after parsing them, we get all these into an object and then DefinePlugin is used accordingly. What is your proposal at this very step? How can we bundle specific vars? We should remove them from that object we get after parsing .env? Sth like:

const varsToBundle = _.omit(parsedVars, ['DB_USER', 'DB_PASS']);

Am i correct or i am missing sth?

Have a look here in the second example: https://webpack.js.org/plugins/define-plugin/

I think all we would have to do is map over the keys appropriately in the define plugin portion:

https://github.com/mrsteele/dotenv-webpack/blob/master/src/index.js#L58

should be:

    return new DefinePlugin({
      'process.env.var0': var[0],
      'process.env.var1': var[1],
      // etc...
    })

@fakiolinho (and @j-feng13 this effects you too), I was able to resolve any leaky data be defining each env variable individually. Please have a look at let me know what you think.

@fakiolinho with my enhancement to the approach with DefinePlugin, you can have include all ENV variables and not have to worry about leaking sensitive information because the bundler only writes things that you use.

dotenv-webpack v1.4.3 is now released and addresses this concern. Please let me know if this does or doesn't so I can sleep better at night 😄

@mrsteele thanks for your great solution. It works like a charm!!!!! Thanks.

Now you can sleep tight, hahaha!!

I think this is a dangerous foot gun. I think the .env.example should work as a whitelist. Only environment variables mentioned in there should be accessible in the clients code. Everything else is too dangerous because people might use it wrongly.

@levino a lot of people create a “client.env” and use that instead of sharing that with server stuff to avoid that situation.