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

A question about managing test and development on the same machine #150

Closed
juanpaco opened this Issue Aug 10, 2016 · 16 comments

Comments

Projects
None yet
8 participants
@juanpaco

juanpaco commented Aug 10, 2016

I apologize in advance for posting what isn't actually an issue with the library. I wasn't sure what other channel to ask this question through.

v1 removed auto .env.${ NODE_ENV } overrides, and so forth, and this was a fine change IMO. I buy into the separate deployments. My question is more about your workflow as the library owners.

When I'm developing an app on my machine, I'm generally doing stuff in development and test, and these each have their own database they work with. I've had it in my head that I need separate databases for those "environments," so that my unit tests don't clobber when I'm just poking around in a browser.

I do a branch on process.env.NODE_ENV to find the correct file for dotenv to load. It works well enough, but still feels like a hack to support 2 separate "deployments" on a single machine.

So, I'm just wondering how you folks deal with doing development and testing on the same machine. Do you do a similar branch on an env var? Do you just do development and testing in the same DB? Feed the db connection stuff in through the command line? Something else?

I read through all the closed issues, and when this subject was touched on, branching based on an env var was mentioned. Just wondering if there's something more refined.

@maxbeatty

This comment has been minimized.

Collaborator

maxbeatty commented Aug 10, 2016

TIMTOWTDI so do whatever works best for you 🌠

When we have target resources like a database or S3 bucket that varies per environment, we use the convention of appending the environment.

const mysql = require('mysql')
const conn = mysql.createConnection({
  host: process.env.DB_HOST,
  user: process.env.DB_USER,
  password: process.env.DB_PASS,
  database: 'application_name_' + process.env.NODE_ENV.toLowerCase()
})
const AWS = require('aws')
const s3 = new AWS.S3()
s3.getObject({
  Bucket: 'my-gifs-' + process.env.NODE_ENV.toLowerCase(),
  Key: 'kangaroo-party'
})

I've been using Docker more and more so if I want to load different databases I can usually just change the mounted data volume on the database container without changing anything in the app.

@juanpaco

This comment has been minimized.

juanpaco commented Aug 10, 2016

With those different names I do the same thing, but I still have to have different .env files to have them. When you're not doing Docker, do you just edit your .env before doing the thing that uses the other resources?

@maxbeatty

This comment has been minimized.

Collaborator

maxbeatty commented Aug 10, 2016

I don't quite follow your setup. If you could share some simplified code, that's a big help.

My test runner sets NODE_ENV to test which takes precedence over whatever I have in .env (usually 'development') so I don't have to change anything.

@juanpaco

This comment has been minimized.

juanpaco commented Aug 12, 2016

Sorry for the delay in getting back.

Right now I have something like

var envFromRealEnvironment = process.env.NODE_ENV || 'development'
var path = `.env.${ envFromRealEnvironment }`

dotenv.config({ path, silent: envFromRealEnvironment === 'production' })

For running in dev mode, I have a .env.development and for running in test I have .env.test. I got the impression from reading the docs that having different .env files on the same machine was frowned upon.

Should I have multiple .env files?

No. We strongly recommend against having a "main" .env file and an "environment" .env file like .env.test. Your config should vary between deploys, and you should not be sharing values between environments.

I haven't found a great way to separate my development environment from my test one. I'm essentially having 2 "deployments" on the same machine, and I don't see how to do that without multiple .env files. I was just wondering in light of that recommendation in the FAQ how other folks do test vs. dev. What I have works, but whenever I read the FAQ, I keep thinking I'm missing something that's obvious to others.

That comment may have been about not having a main one that gets overridden in a few values by an environment-specific one, in which case I'm just misreading it. I took it to mean that even though one is developing and running tests on the same machine, ideally there should only be 1 .env file.

@maxbeatty

This comment has been minimized.

Collaborator

maxbeatty commented Aug 12, 2016

That comment may have been about not having a main one that gets overridden in a few values by an environment-specific one

Bingo. "In a twelve-factor app, env vars are granular controls, each fully orthogonal to other env vars." I understand why people want to define "defaults" and customize per environment, but like 12factor says, it leads to more brittle deploys so dotenv tries to keep you disciplined.

@juanpaco

This comment has been minimized.

juanpaco commented Aug 12, 2016

I gotcha. So having the separate ones as I do is totally in line with the recommendation, because there's no overriding or anything like that. There's one complete set for development and another complete set for test, and there isn't any crossover between them. Is that correct?

@maxbeatty

This comment has been minimized.

Collaborator

maxbeatty commented Aug 12, 2016

yep looks good to me

@juanpaco

This comment has been minimized.

juanpaco commented Aug 12, 2016

Oh cool. Thank you for the clarification. Would you be open to a PR clarifying that point in the documentation? I've had this nagging feeling that I had this dirty hack going on (because I do have multiple distinct .env files), but it stemmed from a misreading of that part in the FAQ.

@maxbeatty

This comment has been minimized.

Collaborator

maxbeatty commented Aug 12, 2016

Thanks but I'm content leaving it as-is for now

@maxbeatty maxbeatty closed this Aug 12, 2016

@juanpaco

This comment has been minimized.

juanpaco commented Aug 12, 2016

kk. Sounds good. Thanks again for the explanation and for the library!

@lapinskicho

This comment has been minimized.

lapinskicho commented Jan 6, 2017

Should I have multiple .env files?

No. We strongly recommend against having a "main" .env file and an "environment" .env file like .env.test. Your config should vary between deploys, and you should not be sharing values between environments.

I had the same feeling as @juanpaco from reading the FAQ that having different .env files on the same machine was frowned upon...

@machineghost

This comment has been minimized.

machineghost commented Jan 5, 2018

One more "me too". I don't understand why you'd want to keep confusing your users (four in this thread, another in #150, and who knows how many more that didn't file an issue) when you could make a change in just ten seconds (we're only talking about a sentence or two) and make everything so much clearer. Heck, even just changing the title of the question from "Should I have multiple .env files?" to "Should I create a hierarchical structure of .env files?" would do wonders.

But really, since "test" and "dev" environments are almost universal, and since separating the config for those environments is one of the main reasons people start using environmental variables in the first place (probably the second most popular reason, right after "dev" vs. "live"), it's strange that the documentation makes no mention of them whatsoever ...

... except for a single sentence that can very easily be interpreted as "don't do the thing that you came here to do in the first place (ie. separate dev and test configs)":

We strongly recommend against having a "main" .env file and an "environment" .env file like .env.test.

Even just adding a paragraph that explains the most common setup I can imagine (three environments: test, dev, and live) or the second most common (four environments: test, dev, staging and live) would make a HUGE difference in reducing the time and effort needed to learn this library.

@NealHumphrey

This comment has been minimized.

NealHumphrey commented Mar 19, 2018

Bump on putting this in the docs! I also was confused by the docs statement cited above, and Google'd around until I found this thread. The comment in #200 makes it clear and would be a great addition to the docs.

@stouf

This comment has been minimized.

stouf commented May 8, 2018

Same here, I also find the current docs misleading. A few lines to clarify the matter as it is explained in this issue wouldn't hurt and would avoid many wonders in my opinion.

@cristiboariu

This comment has been minimized.

cristiboariu commented May 8, 2018

+1 me too. Spent 2 hours until this was clarified for me here because from README it's totally unclear.

@mjlehrke

This comment has been minimized.

mjlehrke commented Jun 13, 2018

...The comment in #200 makes it clear and would be a great addition to the docs.

Wow, the README is the exact opposite of that comment. Glad you posted it because I too was confused.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment