Add keystone migrate commands

[dcousens]

This pull request adds keystone migrate create and keystone migrate apply. #9090 didn't satisfy the workflow that I wanted when it came to creating migrations. Unfortunately keystone prisma migrate dev --create-only still asks you to reset your database. That need not be the DX, so myself and @molomby discussed a number of different workflows to try and help some developers with a few common scenarios.

If you don't need to think about migrations, or migrations aren't relevant to you for a time, then you should continue using keystone dev as usual.

If you need to rebase on some work, and that work has migrations; you probably want to apply the migrations to your work.
To apply migrations, keystone migrate apply will ask you to RESET your local database. After rebasing and migrating, you continue using keystone dev [--db-push]. Your workflow will probably be something like the following:

keystone migrate apply
keystone dev

If you don't want to reset your local database when applying the migrations, then you are in a situation that is pretty difficult to generalise about. We recommend you use Prisma yourself, potentially leveraging prisma migrate resolve as needed. Your workflow will probably be something like the following:

keystone prisma migrate resolve --applied 20240101.add_new_table
keystone dev

Ready to write migrations?

If you have recently completed some local development, and now you're ready to write a migration for that work; you can now create a migration (similar to keystone prisma migrate dev --create-only, but without the reset) using keystone migrate create. Your workflow will probably be something like the following:

keystone migrate create
# edit ...
keystone migrate apply

To apply and test your migrations, keystone migrate apply will ask you to RESET your local database.

[pc-erin]

Is there an easy way to test this by inserting it into an existing project?
I tried changing the version string in my package.json file to use the repository, but that didn't work, probably because it's a monorepo.

In the meantime, I tried manually running the commands that the migrate command constructs.

For create, it looks like prisma still demands a --shadow-database-url parameter because of --from-migrations being used, so that probably needs to get passed in.

I had been thinking it might also be nice to have an option on apply to use prisma migrate resolve to apply the migration without deleting the database, but after thinking more I'm not sure that's needed.

During dev, just using --db-push is fine. As long as we can keystone migrate create and then check in the migration file so that the production deploy can apply it, updating the local database doesn't really matter.

Even if you need to at some point the manual prisma migrate resolve technique should work fine.

[dcousens]

@pc-erin this feature has been publicly released as part of @keystone-6/core@6.1.0 in https://github.com/keystonejs/keystone/releases/tag/2024-04-30

[dcousens]

@pc-erin your thoughts around --shadow-database-url are already addressed in #9117

[jj-matos]

I created a migration file in dev. Had to backup the database and then import it again in dev. In production, when i try to deploy the database, it tells me tables already created. Couldn't figure out how to do it. Ended up backing up database, import to dev, and then export and import into production. Only way i can update the schema in production for now.