db-migrate does not respect database.json when DATABASE_URL is specified

[troygoode]

related to #308

A best-practice for developing Heroku apps is to set a .env file and then execute heroku local (https://devcenter.heroku.com/articles/heroku-local), which will populate process.env using that file. A common .env file will look like so:

DATABASE_URL=postgres://localhost:5432/example

In general, usage of a .env file and leveraging something like https://www.npmjs.com/package/dotenv is a common practice even when not deploying to Heroku. Many other deployment enviornments, including AWS BeanStalk, now use environment variables for specifying the configuration of the deployed application. Because of this it makes sense to use environment variables for your local development configuration as well. Configuring via environment variables is the recommendation of the 12 Factor App methodology.

Unfortunately db-migrate does not play nicely with this common practice. By specifying a DATABASE_URL environment variable, db-migrate will no longer read any options from database.json, including options like "sql-file": true.

[troygoode]

I'm currently working around this by adding the following to my package.json:

"scripts": {
    "create-migration": "db-migrate create --sql-file --",
}

This allows me to create migrations via npm run create-migration EXAMPLE, but having such inconsistencies in the configuration of db-migrate is rather frustrating. If you prefer to only have one configuration source at a time (rather than supporting a layered configuration), then shouldn't the additional options be configuration via environment variables as well? Example: DBMIGRATE_SQLFILE=true. Having certain options only supported via certain configuration sources does not seem like a principled choice – it feels like a bug.

[wzrdtales]

To resolve #308 we will introduce a new dependency: https://www.npmjs.com/package/rc
It is very likely to cover your issue too if I'm not too wrong, as it also provides an interface mapping configs to environment variables.

[ivarconr]

gah, I used almost an hour on the same issue today, not understanding why my tests wouldn't migrate the test-database correctly.

[troygoode]

@wzrdtales any ETA on when this will make its way to npm?

[wzrdtales]

@troygoode Ah sry, I'm currently busy moving to a new accomodation so I'm not as responsive as I wish to be. I can push out another beta release the next days, I wanted to finalize everything and push the stable 0.10.x out, but the move eat way more time than I expected in the beginning.

[wolever]

+1 - I've just spent a bunch of time debugging an issue where I was calling db-migrate and passing in an environment explicitly through the programatic API, but it was being ignored and the DATABASE_URL was being used. This was very surprising and annoying to debug, especially because the log message shows that it's using the programatic env, just with different values.