fix(sync-engine): replace pg-node-migrations with custom runner - #234

Thanks for the contribution already!

For the new migrations, what would be very useful is to also support some type of placeholders - i.e. the stripe schema is technically configurable to be any other schema, but all migrations are hardcoded to stripe. We should instead pass in the configured Stripe schema to the migrations and make use of that. The migrations would need to contain some type of placeholder logic and the placeholders would need to be replaced before applying the migrations. This does not have to be overly complex

Good point on the schema placeholder. Two approaches come to mind:

Option 1: Multi-pattern regex

sql
 .replace(/"stripe"\./g, `"${schema}".`)
 .replace(/\bstripe\./g, `${schema}.`)
 .replace(/'stripe'/g, `'${schema}'`)
 .replace(/\bstripe_/g, `${schema}_`) // index names

Fragile - easy to miss edge cases.

Option 2: Explicit placeholders
Update all migrations to use {{schema}} (or similar), then:

sql.replace(/\{\{schema\}\}/g, config.schema)

More upfront work but explicit and safe.

I'm leaning toward Option 2 - cleaner and less error-prone. Which direction would you prefer?

One more thought: Option 2 would make the migration files invalid SQL on their own - can't just run them with psql. Option 1 keeps them valid and defaults to stripe, though it requires some care when writing future migrations to follow the same patterns.

I'd still opt for option 2 as option 1 can lead to accidental replacements

When someone tries running the SQL files directly, it would be easy enough to do a manual replacement and it also leads to making a more explicit choice of the schema

Could also have a utility function to print out all schema files with placeholders replaced, but that is more of a nice to have

Done, went with Option 2 - all migrations now use {{schema}} placeholders.
Also added getMigrations(schema) for inspecting migrations.

Also normalized quoting across all the migrations files while at it.

I've been thinking, probably getMigrations({ schema }) would be more consistent with runMigrations({ ... })?

Ok, converted params api to getMigrations({ schema })

This PR has the change I need to get this running for my use case (i.e. two separate Stripe accounts, two separate stripe-sync-engine writing the same PostgreSQL database, two different schemas). Is there anything I can do to help land this sooner?

CLA assistant check
Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.
_{You have signed the CLA already but the status is still pending? Let us recheck it.}