.env files are a different use case than config files.

You can use them together. Config files provide configuration to the application. The config file can read environment variables, so you can deploy the same code across different environments, e.g., your local computer, staging, and production.

Then, each environment will provide system-related configuration, e.g., `DATABASE_URL`.

With this setup, the same code will work on each environment.

Now, .env files should live only on your local machine; on any other environment, they should be set differently, not in files.

The .env file is a convenience, but not the only option for environment variables, nowdays you can use 1Password too.

I think the overuse of .env files is a side effect of the overuse of containers. Working with config files is much more convenient if you're running software normally, but if you're shipping an entire baseline OS along with your application, getting application-specific configuration data into the container becomes non-trivial. Environment variables provide a standardized way of making configuration data set outside the container available from within it.

Same here. What I hate most is the fact how tooling decides what should be hidden files and what not. Hiding important configuration files (also done by some SSGs) is a bad habit which makes it hard to explore a new project. At least such files should be refered to in some README.

Don't people use it with direnv?

I never figured out why they are dot files. Why are we hiding important information from somebody using a shell?

How are they different than a regular config file? .env and .mytoolconfigrc seem like the same thing to me.

What makes you believe that abruptly venting on HN will help?

whats wrong with .env files?

Nothing like chasing a process.env that is undefined.