-
Notifications
You must be signed in to change notification settings - Fork 29.6k
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
Modules: Coordinating ESM implementation in Core #8866
Comments
This is the V8 bug tracking Module implementation: https://bugs.chromium.org/p/v8/issues/detail?id=1569 |
/cc @ajklein for V8 plans |
ChakraCore Appears to have 100% implemented but documentation doesn't seem to be available yet. @chrisdickinson has a branch that attempts to use the current V8 API on |
FYI, at the TC39 meeting we were told the html-spec for the loader is "in flux" and is likely to change quite dramatically. In fact, we expect it to change quite a bit based on our feedback. |
Ok, we'd might as well still work backwards from an impl that has anything that may not change already in place though, imo. Idk, we'll have to see what those changes are like but I think the spec as it exists today will be a good enough starting point to prototype with. |
V8 is quite close to a complete implementation of what's in ES2015 (note that it's only implemented in our interpreter, so passing Regarding the design explorations at TC39, we're still early enough that nothing from that conversation is likely to land in V8 as part of our initial modules implementation. So it would be great if we could find a sufficient API surface that experimentation in that area could happen outside of V8. |
I think something was lost in translation there. What's in flux is https://whatwg.github.io/loader/ (a "collection of interesting ideas" about loading in various environments), not https://html.spec.whatwg.org/multipage/webappapis.html#fetching-scripts and related sections (the HTML spec loader). The browser loader is finalized, pending implementation feedback (although implementations have progressed quite far so I don't anticipate much more). I would definitely not bother implementing the collection of interesting ideas, as most of it is going to be removed and changed in various ways. |
@ajklein I think the solutions we described that VMs will need at the meeting are as follows:
We have not discussed the API design for these or some other things discussed like meta-data to declare the shape of a late linked module up front. Would it make sense to give me time to write up a spec for the new type of ModuleRecord / gather the tweaks to spec prior to jumping into a C++ API design discussion? |
@bmeck When I talk about "API requirements", I mean something higher-level than actual C++ code, say, "ability to create a Module Record from outside the API and pass it into V8 to be linked". But it does seem like we may still be at too early a stage for that: your point 2, for example, sounds like big extension to what we discussed at the meeting. |
@ajklein if the values go out of sync for "plucked" variables, it would make more sense just to not support named imports from CJS IMO (though others differ on this); Not having live delegation/named imports changes many parts of this discussion. |
/cc @digitalinfinity @boingoing @kunalspathak re Chakra |
@joshgav Chakra has a compliant implementation of ECMAScript modules now (barring any bugs). We don't have support for the Loader or BrowserLoader objects though we made some progress on the whatwg spec (chakra-core/ChakraCore#1472) which has not been pulled-in to the ChakraCore repo, yet. Looks like we will need to refactor this after the dust settles on a converged design. Since the only way to test ESM is with help from the host (ie: static modules via |
@boingoing is there docs on how we can use those experimental features in chakracore to power a node prototype of ES Modules? |
@Fishrock123 @chrisdickinson for Source Text Module Records (from the 2015 spec) is the main ask from Chakra to provide a shim that matches V8's To illustrate, the way to provide that would likely be to add an experimental /cc @liminzhu |
@joshgav Yes and no, we could shim it (help would be appreciated) but there isn't an expectation to necessarily have any change in Chakra itself for this at the current time.
Is that not already the case? It must be exposed already somehow, tests and such use it IIRC. |
@Fishrock123 Here's an outline of how the Jsrt API for ES modules works and how we use it in our test harness. Jsrt provides a scaffolding of sorts to support loading ES modules. The Jsrt API we need to work with are located in ChakraCore.h:
We need the ChakraCore host to glue these pieces together and provide a little boiler-plate code in order to get full support for loading and running module code. We have a reference implementation in our ChakraCore test host ( Use Use Keep a mapping from module specifiers to module record entries. If we request to fetch a module we already know about, the same module record should be used. We use this in our parse method and fetch method, basically when we need to look up a module record based on a module specifier. This map is implemented by Load a root module. Create a new module record if we need one and use |
Is it useful for this to stay open? |
I think we are fine closing
…On Jul 15, 2017 12:05 PM, "Rich Trott" ***@***.***> wrote:
Is it useful for this to stay open?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#8866 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AAOUo6MIXbeeDC8MmRJWk40SRG9rxD0Vks5sOPFBgaJpZM4KLXlr>
.
|
@nodejs/tc39 @nodejs/v8 @nodejs/node-chakracore ... following the TC-39 meeting this week, there is a proposed path forward for getting modules implemented in core. While the node-eps documents need to be updated, it would be good to begin coordinating the various threads that would need to be pulled together for working out an actual implementation.
@nodejs/v8 and @nodejs/node-chakracore teams... can you please respond to this thread with details or links to each VM's plan and timeline regarding ECMAScript Module implementation. Pointers to existing documentation is perfectly fine, I just want to use this issue as a coordination point.
The text was updated successfully, but these errors were encountered: