Suggestion: A way to list pending migrations

[Tethik]

I would like to improve my fellow devs experience by giving them a warning if their database is outdated. Quite often it happens that you pull in the latest branch from source control and forget to reapply migrations for your local environment, and usually this won't present itself clearly as an outdated database issue, but the app misbehaving in some odd way.

To this end, I think it could be useful if there was some exposed function for simply listing the migrations that have not yet been applied.

import { pendingMigrations } from "postgres-migrations";
const migrations = pendingMigrations(client);
if (migrations.length > 0) {
  log.fatal(`Psst ${process.env.user}, there are ${migrations.length} migrations that 
you haven't applied yet to your database.`)
}

Just a small suggestion, I would understand if you don't want this due to scope creep. I can always just implement this in my own project by copying some code from the library itself.

[ThomWright]

Thanks for the suggestion.

My initial reaction is, yes I'm hesitant to include due to scope creep! That isn't to say I couldn't be persuaded, but I would need to know more about how you use the library.

Some context and questions:

The way I imagine this library being used, and the way I use it, is that the application runs it at start up. In this case, there simply won't be any pending migrations to warn about.

Can I ask:

• How do you run it, if not at start up?
• Why?
• Would running the migrations at start up be a better option?

Thank you 🙂

PS: Nice flower hat 😉 💮

[Tethik]

Sorry for the delay, weeks flew by quick!

• We run it during startup when we deploy to staging and production. Otherwise for our local development and test environment we do it manually. For dev and test we run the migrations using npm run migrate.

• Mainly we don't run it on startup in dev I guess because we don't want it running our unfinished migrations yet and have to clean up. This happens easily because we automatically restart the project on any file save via forever. Cleaning up the created resources is more tedious than creating them (could be multiple queries to "undo" the latest migration).

• I guess another approach would be to add a configuration option to disable the migrations. When writing new migrations we could toggle it off for development.

Thanks <3

[ThomWright]

Thanks, I see where you're coming from and that makes sense. I think I like the idea!

TBH I'm probably not going to get around to it any time soon, but would consider merging in a PR (with tests etc.).