There is no reason anyone would ever use this instead of a regular config file.
Discussion Highlights (8 comments)
the_real_cher
Don't people use it with direnv?
myst
What makes you believe that abruptly venting on HN will help?
vincentabolarin
Nothing like chasing a process.env that is undefined.
ktpsns
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.
tacoooooooo
whats wrong with .env files?
Gormo
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.
righthand
How are they different than a regular config file? .env and .mytoolconfigrc seem like the same thing to me.
thinkxl
.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.
Related Discussions
Found 5 related stories in 48.3ms across 3,471 title embeddings via pgvector HNSW
Discussion Highlights (8 comments)
the_real_cher
Don't people use it with direnv?
myst
What makes you believe that abruptly venting on HN will help?
vincentabolarin
Nothing like chasing a process.env that is undefined.
ktpsns
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.
tacoooooooo
whats wrong with .env files?
Gormo
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.
righthand
How are they different than a regular config file? .env and .mytoolconfigrc seem like the same thing to me.
thinkxl
.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.