Curious: why commit .env files?

[jliebrand]

Your readme states that .env files SHOULD be checked in to source control, but .env*.local should not. That seem counter to what the dotenv module (or anyone else) recommends.

I'm just curious: why would you ever commit a .env file that contains secrets??

(this doesn't block me; I can and will just use .env.local and ignore .env files, but just thought it was an odd recommendation)

[gaearon]

Because dotenv README is about usage on the server. But on the client all embedded values will be part of client bundle anyway. So those cannot be real "secrets" anyway. Committing these values is more convenient in this case.

[patoncrispy]

Thanks for the explanation @gaearon. It seems so obvious when I stop and think about it. :)

[daniel-lovell]

@gaearon I'm confused. I just set up a new create-react-app with a .env file. The only values that are included in the bundle are the ones with keys that start with REACT_APP_
None of the other values are included in the front end bundle. It appears that these values could still be considered "secret."

Are you suggesting that real secrets shouldn't be included in .env so that .env can be committed for the convenience of sharing REACT_APP_ values? If REACT_APP_ values aren't environment dependent or aren't secret, why put them in .env at all?

[jesslyoung]

It depends on your app. A custom build step, non-public asset, or npm script could all utilize .env for secrets.