| 08:01 | <Rob Palmer> | Good morning, all. I wanted to reiterate a bit on what I said in plenary and also afterwards direct to Kris last week. The layered modules APIs that Kris presented are great at permitting a bunch of use-cases. In particular I like the idea of using them for achieving mocking in a test runner (avoiding the need for code to use DI patterns or custom host hooks). The bigger win (value proposition) is if we can identify features that will allow the wider ecosystem to adopt ES modules. npm & Node mostly ship and execute CommonJS. No one has provided a compelling or easy migration story. So we have a situation that may even be worse than the Python 2/3 switchover. A key specific use-case that CJS still beats ESM on is the ability to ergonomically/quickly achieve fast load times via lazy loading. Meaning the Babel option "lazy" on the ESM->CJS transform that injects conditional synchronous requires to defer loading static imports to instead be just-in-time. ESM has no ergonomic way to achieve this. Instead users are forced to rewrite their app to become async and use dynamic `import() `. Because switching sync->async functions have ripple effects back to the caller. Originally Yulia's defer-eval proposal looked like it might solve this problem. But I understand the sync part of that proposal is now under debate. My purpose in conveying this is not to demand sync loading. It is to highlight that, if you can make migration from CJS to ESM easier, then (1) the community/ecosystem will love you and see the value of your work, and (2) it will be easier to fund this work stream. |
| 12:56 | <littledan> | I really like Rob's idea in the abstract, but I'm having trouble understanding what it means concretely. Would we ask people to write app-specific compartment adapters? Or would there be one in the ecosystem that catches on? |
| 19:29 | <Kris Kowal> | I read the request as one to find a solution to the problem that named imports can’t trigger an export accessor, the way destructuring a module.exports can. |
| 19:30 | <Kris Kowal> | Or to find a different way to solve the problem that export accessors currently do, in a way that helps existing CommonJS code lift into ESM. |
| 19:31 | <Kris Kowal> | Which will be hard and I imagine most solutions to be worse than the problem, but it’s very fair to ask us to think about it. |
| 19:32 | <Kris Kowal> | I personally find it appetizing to force that particular kind of CommonJS to be rewritten into patterns more amenable to tree shaking in ESM, but that’s contrary to the goal of easing adoption. |
| 19:44 | <littledan> | I'm not sure if accessors are the goal here, though they would actually help us with something else! namely the goal of deferred module evaluation, where the module body is only run on the first access of one of the exports |
| 19:44 | <littledan> | (TLA would be handled by running the async subgraph eagerly, and only being lazy about the stuff on top of that) |
| 19:45 | <Kris Kowal> | Sure, that sounds like a similar solution to the same problem. |
| 20:23 | <nicolo-ribaudo> | Wasn't there a proposal for export accessors a few years ago? |
| 20:27 | <guybedford> | Thanks Rob Palmer for the input, very good points raised. My personal take on this perspective would be to ensure we have lazy execution and sync execution as a possibility of the "epiche" (in the spirit of continued mutation of the word). I completely get that these CJS -> ESM scenarios are causing friction for adoption, although a concern here is that this is a Node.js-specific issue that even with a spec unlock won't guarantee progress. Unfortunately Node.js is now caught up in a bind with its own loader system causing asynchronous loading requirements, although there are people actively working on making hooks sync by moving them off thread. Funding on the Node.js side may well speed things up there as well. On the ECMA-262 side, I could imagine a follow-up or new iteration of Yulia's proposal that tackles lazy execution and sync execution to fit into this story and I'd be more than happy to be involved in discussions here. From my perspective I don't see any frictions or concerns regarding the overall picture, short of more features just being more complexity, but I don't personally see an issue with adding complexity to the module system since it also means more control over performance and loading in the hands of users. |
| 21:09 | <Kris Kowal> | Soon: quiche. |