Consider finding a new tool for migrations

[slifty]

https://github.com/ThomWright/postgres-migrations seems to be a dead project. I have a PR to fix a bug that affects us which has been open for about 18 months: ThomWright/postgres-migrations#93

It also is not being kept up to date more generally / the last commit was made 2 years ago.

We might consider:

1. Forking, merging the fix, and publishing on our own.
2. Finding a different migration tool.

[slifty]

This is coming up now because graphile-worker creates its tables in a separate schema, and has a migrations table in that schema. The presence of a migrations table in ANY schema causes postgres-migrations to fail because it incorrectly thinks that its own migrations table exists (this is the bug I opened a PR to fix last year).

[slifty]

I opened ThomWright/postgres-migrations#108 just in case there's a chance we can help maintain upstream (which I think would be explicitly better than forking and maintaining our own version).

[bickelj]

I have no objection to forking if you don't hear back soon. I guess the downside is integrating the fork, right? Either having to publish a newly-named fork to npm or to use a different integration mechanism from npm for this one library?

[jasonaowen]

Darn, that is limiting!

A third option would be to explore the forks, and perhaps collaborate / contribute there. It looks like the @dzangolab/postgres-migrations repo has published to npm, and the zakpatterson/postgres-schema-migrations repo has a schema fix but is not (obviously?) on npm.

[slifty]

zakpatterson's library is probably a good bet -- and they also did respond to the original issue pointing out that they had a fork. I'm fine with it; I suppose the only real risk is that it might not be maintained in future... which is already the current state! I'll try making the swap today. If upstream ends up being interested in help maintaining we can cross that bridge (and I suspect zakpatterson might even be interested in joining that team)