-
-
Notifications
You must be signed in to change notification settings - Fork 869
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Clarification in README #200
Comments
I had the same question. You can see the discussion on it here: #150. The short answer is that as long as each .env.X file has a full set of the settings, then it's okay. |
Your dev, staging, and prod "environments" can be thought of as "deploys" where each deploy expects a What the README is advising to avoid is cascading variables or grouping or defaults because it's harder to manage and more error prone as you have more environments. For example, your application expects a database host and a database name. In development, your want the database name to be How you should not structure your app:
require('dotenv').config({ path: './env' });
require('dotenv').config({ path: './env.' + process.env.NODE_ENV });
const db = require('./db');
db.connect(process.env.DB_HOST, process.env.DB_NAME);
// ... more app logic using database connection To run in "dev" environment: A "better" way to structure your app:
require('dotenv').config({ path: './env.' + process.env.NODE_ENV });
const db = require('./db');
db.connect(process.env.DB_HOST, process.env.DB_NAME);
// ... more app logic using database connection To run in "dev" environment: dotenv as a module is very flexible and can be used in many ways so do whatever makes your life easier. We try to provide some guidance in the docs to save people headaches we've already gone through. |
Thanks for clarifying! |
would be great to have link to this clarification in readme. |
Regarding this:
https://github.com/motdotla/dotenv#should-i-have-multiple-env-files
These statements seem to be contradictory. I may want to have
.env.development
and.env.staging
(separate API keys), but the above sentence says it's strongly discouraged, but then says we shouldn't be sharing values between environments.. which is why someone would want separate.env
files for dev/staging/prod.The text was updated successfully, but these errors were encountered: