-
Notifications
You must be signed in to change notification settings - Fork 2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Support top-level await #5371
Support top-level await #5371
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thank you for doing this! A few minor notes and then happy to land.
I've updated the tests to
Happy to make further changes. Update: I just saw your comment saying to not modify |
Further revised the tests to check what they actually care about, which is a |
Thanks. I want to leave this open a little bit in case anyone else wants to review (@helixbass?) and then will land and cut a new release. I added #5372 to add Node 16 support to CI but the tests fail there, so that should also probably be addressed before we land this. cc @helixbass on that too as it looks like it has to do with AST stuff. |
Got CI fixed. Can you please rebase off of FYI besides rebuilding the regular compiler we also need to build the browser compiler ( |
Thanks. I’ll cut a new release branch soon. |
@GeoffreyBooth mentioned that CoffeeScript is missing support for top-level await. This PR adds that support.
Mostly this involves doing fewer checks for invalidity. The only hard part is when the code is wrapped in a top-level IFFE, where we need to detect whether that wrapper should be marked
async
.Fixes #5354 (request from Deno side).
The REPL already supported top-level
await
by explicit wrapping in anasync function
closure. I think it's best to keep that code, because older versions of Node don't support top-levelawait
.