Feature request: client-side vars

[shankie-codes]

Hot damn, this is a useful thing. Love it.

What would be ever more super-er is if there was a way of specifying which vars got sent to the client. I guess this could be accomplished with separate files, though the dotenv readme seems to advise against this.

Thoughts of how this might be accomplished? I'm happy to put a bit of time into a PR if you can guide me to an approach

[nwinch]

@shankiesan Thanks for the suggestion! Could you elaborate a little more on the use case you have? Are you thinking of some kind of filter file that manages which env var will be passed through (after checking) depending on which environment?

[shankie-codes]

Yes @nwinch that's exactly what I was thinking. In the end in my use case I didn't end up needing it as I ended up using Auth0 for both the client and server auth, however, I can imagine a use-case for in an isomorphic app (where both the client and server side are sharing the same repo) and wants to say, store database credentials for their server side webpack bundle (say, the bundled server.js) but doesn't want to expose those to the client (say, client.js).

Thoughts?

[nwinch]

I like the idea and agree that isomorphic apps would be an ideal scenario for such a feature.

The tricky thing is how to toggle between server/client/whatever? Perhaps a reserved env bar could be used to act as switch if it exists, and then loads the relevant vars. Where they are loaded from is another hurdle. As you mentioned @shankiesan, multiple files are discouraged, though that does feel like it could possibly work.

[shankie-codes]

Hmm that is a tricky question of how to split them. What do you mean by the idea of a 'reserved env bar'?

I'd be keen to hear @motdotla 's opinion on this. I understand the Twelve-Factor-App rationale for not having separate .env files for separate environments (as dev, test, etc should have their own configs); however, this is a somewhat different usecase as it's one "environment" (e.g. prod) that needs its variables split.

Perhaps if that's still an unpalletable solution, we could add something to the DotEnvPlugin webpack config, e.g.

new DotenvPlugin({
      sample: './.env.sample',
      excludeFromClient: [ 'MY_VAR_TO_NOT_SEND_TO_THE_CLIENT' ],
      path: './.env'
    }),