-
Notifications
You must be signed in to change notification settings - Fork 45
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
It should be possible to synchronous retrieve a "loaded and ready" module's export object #130
Comments
I have two use cases for this: |
Are you talking about polyfills by any chance? Who is responsible for importing the code in the first place?
Interesting. In this scenario I suspect you will need a master puppet that will import the modules, wait for them to be ready, and then evaluate the script. Similar scenario happens today with modules compiled with browserify/webpack, and somehow, the communication between the two pieces running a different modes (async vs sync) happens via some global variable or function. Still, you should be able to do:
My argument here is: if your script is already using the loader, and knows the key of the module, why not just use the
|
No, not polyfills, think a optional logging library or some such thing. |
I should be specific about what my original motivation is here: I am trying to build a bridge between current module systems and ES6 modules. My goals were:
My general line of approach was this:
And what I was looking for was the syntax to synchronous access the "load and ready" scripts: except there isn't any. What I was expecting was something like:
Such a system would need to gather needed dependencies server-side but would not need to modify any of the files. However, no such API exists.
It isn't at all clear what the use case a async "resolve" step is trying to support. |
I will discuss the use-case with other folks in upcoming weeks, but for me, it smells. Think about how do you do this today with scripts only? And work your way back from that. If your scripts can't use the loader (it seems), then create your own global registry from where they can get what they need, e.g.:
|
Right, there I have to (a) a new API to use the legacyRegistry (b) create a means of resolving the relative paths used in the script. I want to avoid (a) and in the general case (b) isn't currently possible as the "name" of the script isn't known. |
Is there any update on this? I'm still haven't seen any proposal to solve circular imports in a meaningful way. "import(...).then(...)" has the wrong timing. |
I'm basically looking for a "retrieve X if present" without initiating a load.
In order to lookup a module from the registry, the "key" must be obtained, the "key" is only available via the "resolve" method (the key is loader defined so unpredictable), and the resolve method returns a promise which will never provide a value synchronously.
The text was updated successfully, but these errors were encountered: