> can read files in your project directory, which means a plaintext .env file is an accidental secret dump waiting to happen

It's almost like having a plaintext file full of production secrets on your workstation is a bad fucking idea.

So this is apparently the natural evolution of having spicy autocomplete become such a common crutch for some developers: existing bad decisions they were ignoring cause even bigger problems than they would normally, and thus they invent even more ridiculous solutions to said problems.

But this isn't all just snark and sarcasm. I have a serious question.

Why, WHY for the love of fucking milk and cookies are you storing production secrets in a text file on your workstation?

I don't really understand the obsession with a .ENV file like that (there are significantly better ways to inject environment variables) but that isn't the point here.

Why do you have live secrets for production systems on your workstation? You do understand the purpose of having staging environments right? If the secrets are to non-production systems and can still cause actual damage, then they aren't non-production after all are they?

Seriously. I could paste the entirety of our local dev environment variables into this comment and have zero concerns, because they're inherently to non-production systems:

- payment gateway sandboxes;

- SES sending profiles configured to only send mail to specific addresses;

- DB/Redis credentials which are IP restricted;

For production systems? Absolutely protect the secrets. We use GPG'd files that are ingested during environment setup, but use what works for you.