-
Notifications
You must be signed in to change notification settings - Fork 12
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
import *
potentially doesn't need to parse/link
#9
Comments
But we need to throw syntax error or early errors before we run the code. It will be super strange to throw a syntax error at the time of your first visit to the deferred imports. |
One thing I am discussing with various delegates is just how critical early errors are. Do they really add to developer experience if they are at parse time as opposed to execution time? Don't we already have this with dynamically loaded modules, as parse is deferred anyway? |
The proposal moved in a direction that still requires parsing the graph ahead-of-time, to detect top-level await. However, I presented a couple months ago a new feature (see #30/#31) that actually allows skipping loading of provably unused code through re-exports. For now let's keep early errors as eager since some delegates expressed that preference, but they could easily be delayed to execution in the future. Due to the current nature of the proposal, where deferred imports are only through namespace imports, I don't think the "cyclical binding" linking error is a problem anymore. |
Given that there is no linkage required required for
import *
likely it can avoid parsing or linkage if cycles are not present in some way. The only issue is with behaviors that can statically cyclically link:This would let things be done in an even more controlled manner but would need some kind of guard against cycles. Either stating a different kind of linkage or disallowing cycles to modules with lazy behaviors.
It would be good to at least investigate here as ahead of time fetch costs are some of the prohibitive costs still possible with this proposal.
The text was updated successfully, but these errors were encountered: