Remove workaround for interactive Prisma #2841
Conversation
| @@ -37,7 +37,6 @@ import qualified Wasp.Generator.DbGenerator.Auth as DbAuth | |||
| import Wasp.Generator.DepVersions (prismaVersion, superjsonVersion) | |||
| import Wasp.Generator.FileDraft (FileDraft) | |||
| import qualified Wasp.Generator.FileDraft as FD | |||
| import qualified Wasp.Generator.JsImport as GJI | |||
There was a problem hiding this comment.
This is unrelated, someone left an unused import here and the compiler was complaining.
There was a problem hiding this comment.
Wow great, they fixed it!
Approved, but one question: will this work ok when prisma migrate-dev asks for a migration name? It can do that when you do initial migration, it often (although I think not always) asks for a name -> will user be able to input it? I think they should, just checking due to using runPrismaCommandAsJob... now instead of runNodeCommandAsJob. But I think the first one uses the second one internally anyway, so if so we should be good. Just being extra cautious here.
Awesome!
|
I did try it before sending the PR 😁 |
|
Awesome! I was sure you did but I remember it not always asking for name so wanted to make sure. Nice stuff! |
Prisma needs shell interactivity for the
prisma migrate devcommand, so it will check if the terminal is a TTY and die if it's not.Prisma used to check if stdout is interactive, instead of stdin. We had a workaround for this, by calling the Prisma executable through the
scriptutility.This has been fixed since Prisma v4.3.0 (prisma/prisma#14649), they now check for a TTY on stdin, which we have always bequeathed to it.
We can remove our workaround code, and close our issue (prisma/prisma#7113).