Why should .env files be checked into source control

[mlodato517]

This is sort of a continuation of #2560 and a new-visibility avenue for this spectrum question.

Basically, why do the docs say

.env files should be checked into source control (with the exclusion of .env*.local).

? I can definitely see saying ".env files can be safely checked into source control" or something but I'm interested in the position of "they should be checked in". The only thing I can think of is "it's convenient for sharing environment variables between dev" (which is fine! But feels different than the given guidance).

Paste of important bits of Spectrum question

From other sources like 12factor and various devs I am getting strong opinions that .env files should not be committed and each developer/environment should just have whatever .env file or environment variables needed to do their development appropriately. In the linked GH question one user said:

.env files for front-end code should be checked in, because as you said, it contains no secrets. Additionally, these .env files affect build-time, not runtime behavior.

But I don't see how "they have no secrets" means they should be checked in, just that they can be checked in. And if the files are used for tweaking things at build time it's still not immediately obvious why those should be checked in. The discussion is largely semantic but I was interested on the community's opinion on ".env files should be checked into source control".

[stale]

This issue has been automatically marked as stale because it has not had any recent activity. It will be closed in 5 days if no further activity occurs.

[stale]

This issue has been automatically closed because it has not had any recent activity. If you have a question or comment, please open a new issue.

[mlodato517]

🦗 😢

[Louies89]

@mlodato517
Check this

[mlodato517]

Hi @Louies89! Thanks for responding :-) I did link that issue in my original question and I don't think it exactly answers the question. It mentions that:

1. there are no secrets
2. it affects build time instead of runtime

But just because something doesn't have secrets doesn't necessarily mean it should be checked into source control (I don't think) just that it can be checked into source control. Same thing for env variables affecting build time - those can also be set on machines responsible for building bundles.

On the other side I've been given advice to the contrary - that env files should not be checked in. One site that mentions this is 12factor.net but other devs on my team also mentioned that environment variables should be declared by ... the environment ... not by a different set of files checked into source control.

I'm not super aware of the downsides of checking in .env files but it seemed that CRA had a strong opinion and I'm trying to understand the reasoning behind their opinion to better inform myself :-)

[Louies89]

@mlodato517 I am aware of that, when I saw the statement, I was also socked.
But that is conditional, means if you have something secret, then do not push to source control, else use other approch which is generally followed on the backend server code.

[mlodato517]

I'm not sure I understand what you mean.

if you have something secret, then do not push to source control

This, of course, makes perfect sense

else use other approch which is generally followed on the backend server code.

This doesn't seem super clear to me. Also, when you say

when I saw the statement, I was also socked.

which statement are you referring to?