jtoar
commented
3 years ago @peterp at the contributor's meetup today, @mojombo suggested we resolve promises automatically. that could be a lot easier than enabling top-level await. I think we'd have to override the repl's eval, but there's examples for that.
to be more explicit, using the console would just be like:
> db.user.findMany()
// resolve promise automatically
[ { id: 1, email: ... } ]so everyone typing at the console would never have to type await db.user.findMany().
update: this might not be mutually exclusive with enabling top-level await, but just seems like it could be done sooner.
Update (05.28.2021)
Right now we abstract away the need for top-level await in Redwood console by automatically resolving promises. This works but it'd I think it'd still be super nice to have top level await.
Original
Right now the console command requires the
NODE_OPTIONSenv var be set to--experimental-repl-await. This isn't an ideal workflow, especially since the console command will be in the tutorial II, so I tried to fix this by using execa (see this PR: https://github.com/redwoodjs/redwood/pull/1603). But now the repl is starting on every command. It seems that yargs is executing theasyncRepl.jsfile no matter what.The only reason I abstracted the code to start the repl into another file was, you have to pass files to the node CLI:
node --experimental-repl-await asyncRepl.js. Maybe you can just pass a giant string to be evaled (I didn't try) but that doesn't seem sustainable, especially once we add all the services to the repl's context.Another option is to hack the eval the repl uses: https://github.com/nodejs/node/issues/13209#issuecomment-619526317.
Note that the console command breaks if the prisma client isn't generated. This definitely has to be fixed, but isn't the same problem.