-
-
Notifications
You must be signed in to change notification settings - Fork 83
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
Top level await #5
Comments
@littledan yes that is not only useful, but necessary to fix the WASM 4KB limit as well. I'd be keen to work on this if top-level await is looking likely to proceed. |
See #1 (comment). |
I hope we can clarify things soon, e.g., at an upcoming TC39 meeting. In theory, Stage 2 should mean it's eventually coming, though. |
I've been putting some thought to how this might be implemented. Proposed outline:
The above would be a comprehensive and fast top-level await polyfill! I don't have the resources to work on this right now, but if anyone would like to push things forward I'd be very open to either helping a contributor or to sponsorship of my time to implement this feature. |
Any updates on this issue? |
None currently but it remains a core part of the roadmap of this project. The problem is just one of prioritization. |
No one mentioned it, but just in case, Node.js already has built-in top-level await, as well as all browsers. 🎉 |
Top-level await was shipped so quickly by browsers that it has ended up not being a problem for this project. |
Would it make sense to implement top-level await within this project? It can be accurately simulated by exporting a Promise from each module, and waiting on Promise.all of these exports.
The text was updated successfully, but these errors were encountered: