3 ms·

Can we get an estimated time of arrival of ES2015 imports in nodejs? I understand that the support needs to come from v8 first of all.

Scarbutt 10y ago
No idea, but for now you can use rollupjs.
grayrest 10y ago
They just had a meeting with TC39 about it. Here's the writeup from the node side: https://hackernoon.com/node-js-tc-39-and-modules-a1118aecf95e https://hackernoon.com/node-js-tc-39-and-modules-a1118aecf95...
- mstade 10y ago
  > Unlike require(), however, import() returns a Promise, allowing (but not requiring) the loading of the underlying module to be performed fully asynchronously. Promises, afaik, are always asynchronous. Maybe the spec changed (I'd welcome it for sure) but last I read it, resolve or rejection handlers must be called in the next tick. Even if something can be executed immediately, it'll still wait till next tick. This obviously means there's always a wait associated with promises, hence they are always asynchronous. I wish this article would go into more detail on what the edge cases are with the unambiguous module syntax – I thought that was an unusually elegant solution in this community.
  - rgrove 10y ago
    > Promises, afaik, are always asynchronous. In this scenario, I believe the idea is that the module could be loaded synchronously, but the Promise would still be resolved or rejected in the next tick.
    - mstade 10y ago
      Ah right, that makes sense. Thanks for clarifying!
  - pitaj 10y ago
    > loading of the underlying module to be performed fully asynchronously Right now, Node uses require(). What he means here is that while this does return a Promise, the underlying loading of the module doesn't have to be asynchronous, you could just do something like this: function import(module) { return Promise.resolve(require(module)); } Which would fill the requirement of returning a Promise, but would actually load the module using the normal synchronous means. > I thought that was an unusually elegant solution in this community. The biggest issue with unambiguous module syntax is that, since you have to parse modules before finishing the resolution, it could drastically lengthen startup time.
    - mstade 10y ago
      Thanks for the clarification! Regarding parsing modules – that's a fair point but surely this has to be done anyway? For ESMs you have to parse them to build the binding map, and for CJS you have to parse to evaluate; either way the modules get parsed at some point so why would this in any way be an additional overhead?
- hiphipjorge 10y ago
  Best articule I've read on the subject. Thank you for posting this. It does seem like it'll be a while before we can use this in an Node.js LTS.
- e1g 10y ago
  TLDR: TC39 and NodeJS people are very friendly, and are cooperating to bring native ES modules into NodeJS ASAP. The delay is due to technical obstacles, and not politics/philosophy/power plays. Some progress has been made, and smart guys&gals are working to make this integration seamless for all complex edge cases, although Node may end up using a different file extension for pure ES modules (.ejs). Currently no timeframe is available, even as a rough estimate.

Scarbutt 10y ago

No idea, but for now you can use rollupjs.

grayrest 10y ago

They just had a meeting with TC39 about it. Here's the writeup from the node side: https://hackernoon.com/node-js-tc-39-and-modules-a1118aecf95e https://hackernoon.com/node-js-tc-39-and-modules-a1118aecf95...

mstade 10y ago
> Unlike require(), however, import() returns a Promise, allowing (but not requiring) the loading of the underlying module to be performed fully asynchronously. Promises, afaik, are always asynchronous. Maybe the spec changed (I'd welcome it for sure) but last I read it, resolve or rejection handlers must be called in the next tick. Even if something can be executed immediately, it'll still wait till next tick. This obviously means there's always a wait associated with promises, hence they are always asynchronous. I wish this article would go into more detail on what the edge cases are with the unambiguous module syntax – I thought that was an unusually elegant solution in this community.
- rgrove 10y ago
  > Promises, afaik, are always asynchronous. In this scenario, I believe the idea is that the module could be loaded synchronously, but the Promise would still be resolved or rejected in the next tick.
  - mstade 10y ago
    Ah right, that makes sense. Thanks for clarifying!
- pitaj 10y ago
  > loading of the underlying module to be performed fully asynchronously Right now, Node uses require(). What he means here is that while this does return a Promise, the underlying loading of the module doesn't have to be asynchronous, you could just do something like this: function import(module) { return Promise.resolve(require(module)); } Which would fill the requirement of returning a Promise, but would actually load the module using the normal synchronous means. > I thought that was an unusually elegant solution in this community. The biggest issue with unambiguous module syntax is that, since you have to parse modules before finishing the resolution, it could drastically lengthen startup time.
  - mstade 10y ago
    Thanks for the clarification! Regarding parsing modules – that's a fair point but surely this has to be done anyway? For ESMs you have to parse them to build the binding map, and for CJS you have to parse to evaluate; either way the modules get parsed at some point so why would this in any way be an additional overhead?
hiphipjorge 10y ago
Best articule I've read on the subject. Thank you for posting this. It does seem like it'll be a while before we can use this in an Node.js LTS.
e1g 10y ago
TLDR: TC39 and NodeJS people are very friendly, and are cooperating to bring native ES modules into NodeJS ASAP. The delay is due to technical obstacles, and not politics/philosophy/power plays. Some progress has been made, and smart guys&gals are working to make this integration seamless for all complex edge cases, although Node may end up using a different file extension for pure ES modules (.ejs). Currently no timeframe is available, even as a rough estimate.