Allow calling `prisma migrate dev` programmatically by adding `--allow-non-interactive` flag

Problem

prisma migrate dev can’t be used programatically due to it refusing to execute when it recognizes it is not running interactively.

Specifically, we are calling it (at https://github.com/wasp-lang/wasp) as a process from our CLI, and we pipe both stdin and stdout, so interactivity is preserved, but prisma migrate dev sees that stdout is piped and refuses to execute.

Suggested solution

Add --allow-non-interactive flag that skips checks that stop execution when environment is not interactive.

Alternatives

Tricking prisma migrate dev when calling it to think it is running in a TTY -> allegedly script command should work, but we haven’t tried it yet and it doesn’t behave exactly the same on all OS-es.

Additional context

I initially wrote about it here https://github.com/prisma/prisma/issues/4669#issuecomment-840814034 . Based on #4669 it seems others are also having issues when wanting to use prisma migrate dev programatically from helper scripts and similar.

I understand that the idea behind the current behaviour is to prevent using prisma migrate dev for production purposes (e.g. during CI), but it is also stopping any kind of programmatic usage. It makes sense to add flag that allows developers to override this behaviour.

[marcelinhov2]

about this one: How would you handle an actual Reset message ("We need to reset the database. Do you want to continue?") @janpio I didn’t get this message yet and now I’m afraid 😄

Do you essentially create the migration automatically after schema changes were commited? Yes, you got the point. We are using docker to create an empty mysql instance, populate all the current migrations we have (before the new change), generate the new migration after any change at schema.prisma and then use a Lambda to run the migrations at the real database. This is basically the ideia, do you think it make sense? As we didn’t go to production yet, it will be good to know your feeling about it.

Thank you 👍

[electrovir]

My current workaround:

1. Use prisma migrate diff to detect when the schema file has been changed
2. Run prisma migrate dev with --name supplied
3. naively assume that if prisma migrate dev fails, then a db reset is needed and run prisma migrate reset --force