A question about managing test and development on the same machine

[juanpaco]

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]

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]

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]

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]

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]

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]

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]

yep looks good to me

[juanpaco]

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]

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

[juanpaco]

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

[lapinskicho]

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]

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.