Node.js Loaders Team Meeting 2024-09-10 #226

Activity

1. mhdawson

   self-assigned this

   on Sep 6, 2024
2. joyeecheung commented on Sep 9, 2024

   

   joyeecheung

   on Sep 9, 2024

   Member

   More actions

   Removed nodejs/node#53787 and #198, PRs are being reviewed on GitHub. Also I am traveling in a different timezone and can't attend meetings this late.
3. JakobJingleheimer commented on Sep 9, 2024

   

   JakobJingleheimer

   on Sep 9, 2024

   Member

   More actions

   Let's skip this one then if both you and Geoffrey won't be there.

   Last I recall, making hooks sync turned out to be a no-go because it would preclude plugins for eslint, vite, etc, (which are async) closing the door on a huge amount of functionality.
4. joyeecheung commented on Sep 9, 2024

   

   joyeecheung

   on Sep 9, 2024

   Last edited by joyeecheung

   Member

   More actions

   Are you talking about adding new synchronous hooks or replacing asynchronous hooks with synchronous hooks? I think there's only been active work on the former.

   Even on the latter I think we have came to the conclusion that users could work around it by just spinning their own workers to run async code and Atomics.wait(). That's what module.register() already does internally to hook into require() and import.meta.resolve() anyway, the code could've been written in user land JS and don't have to be in core. If needed you could even polyfill the asynchronous API in user land on top of a synchronous hooks API by copy pasting most of the internal loader worker code out of core.

   Existing packages like @babel/register have already been running async code in a worker with a synchronous monkey-patched CJS hook on the main thread without the help of the asynchronous hooks too. I think the built-in asynchronous hooks are just helpers that come with their own curse (users not taking control of the loader worker makes it deadlock-prone, mutation on the main thread is very limited since you can't serialize functions), but don't really open any doors feature-wise. If moved in-thread, then it won't be effective for require or import.meta.resolve(), which means users would still need another synchronous in-thread API to fill that gap.
5. JakobJingleheimer commented on Sep 10, 2024

   

   JakobJingleheimer

   on Sep 10, 2024

   Member

   More actions

   Wasn't there discussion about unifying cjs and esm hooks and making the esm ones sync?

   nodejs/node#54769 (bit of a daisy-chain, but this appears to lead to all that)
6. JakobJingleheimer commented on Sep 10, 2024

   

   JakobJingleheimer

   on Sep 10, 2024

   Member

   More actions

   No-one has indicated they will attend, so cancelling this meeting instance.
7. JakobJingleheimer

   closed this as completedon Sep 10, 2024
8. joyeecheung commented on Sep 10, 2024

   

   joyeecheung

   on Sep 10, 2024

   Last edited by joyeecheung

   Member

   More actions

   nodejs/node#54769 (bit of a daisy-chain, but this appears to lead to all that)

   No, that just refactors the already existing off-thread synchronous path, so that we can reuse it in-thread synchronous hooks too. There is already an off-thread hook path for module.register() that's internally synchronous for require() and import.meta.resolve(), if you read some of changes there, that just adds "...and future synchronous hooks" to the comments. And when we add in-thread synchronous hooks, users can even polyfill module.register() with it by just copying the hooks loader code out of core, since that's just written in JS that could be ported to user land. So by then module.register() will just be a helper that could've been polyfilled by users and it's another topic whether it should be kept around.