Default environment should not be dev

[toymachiner62]

I don't think the environment should default to dev because you can accidently populate your dev db if you forget to specify the env paramater.

An example use case is we have 3 servers - dev, int, and prod, which have those same NODE_ENV's set (so the NODE_ENV=dev on the dev server etc.).

All the developers also have their own local mongo instances installed as well. If I just run $ db-migrate up on my local machine, it's running those migrations against the dev server even though I just want them to run locally.

I'm advocating that the default environment should be "undefined" because that is what the NODE_ENV is by default.

Then in my database.json file i would just have a block for the "undefined" environment which is actually my local environment.

{
  "undefined": {
    "driver": "mongodb",
    "host": "localhost",
    "database": "my_db"
  },
}

Thoughts?

---

Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.

[wzrdtales]

Well, I always used dev for my local database and something like test_environment for the test servers. Because dev means develop to me, so this is definitely a behavior that changes from user to user.

We can default to something else than dev, but I would suggest "default" instead of "undefined". Undefined would be misleading again and nothing were won through this change.

[toymachiner62]

The only reason i suggested undefined is because it is the default NODE_ENV. Otherwise a user will always have to specify their environment with the -e option.

[toymachiner62]

I do agree though that undefined is a confusing env name.

[toymachiner62]

Undefined would be misleading again and nothing were won through this change.

The thing you'd win with this change is that users couldn't accidently populate their "dev" database due to not specifying an environment with the "-e" option.

[wzrdtales]

Yeah, I don't say you're wrong, but I feel like the most devs think that dev is their local database.

Because dev means develop to me, so this is definitely a behavior that changes from user to user.

That leads me to one thought, might this change be a breaking change? Because every user currently using db-migrate and don't have the NODE_ENV set, would have to update his configs.

[toymachiner62]

Yes you're right i think it would be a breaking change.

[wzrdtales]

Ok there are some news on this:
default is already considered https://github.com/kunklejr/node-db-migrate/blob/master/lib/config.js#L40-L46

But for some strange reason the default is dev and not default itself.

[wzrdtales]

Or more specific, default is as long default as it is defined.

[toymachiner62]

I'm just thinking about this some more and what if we had an option in the database.json file to set the default environment to use when no -e or --env option is set? That way I can set it in my database.json to be undefined if that's what I want, you can set it to dev, and the next guy can set it to local if they want.

Thoughts?

[wzrdtales]

That would be a no change, because you can already ;)

Everything that is a parameter is also a config option.

[toymachiner62]

Oh really? How would I specify that in the database.json file? Just with env: 'default'?

[wzrdtales]

Oh well, I see. I'm in fault, everything except env. Will add this though.

[toymachiner62]

Awesome. I like this solution. Thanks.

[wzrdtales]

ah well, ok. But it is already there :D

default: 'data'

[toymachiner62]

what do you mean? So by specifying "default" that actually means the "env"?