Node.js Loaders Team Meeting 2022-11-08 #117
Comments
|
Can we rediscuss landing nodejs/node#43772? I don't see a lot of reasons why it should be blocked by nodejs/node#44710, which seems to still require back and forth discussions around performances. Meanwhile, ESM ts-node with PnP cannot work 😕 |
|
Sure, we can discuss it. I wouldn't want to release one PR separately from the other, to minimize disruptions caused by breaking changes; but we can merge it into |
|
Are we meeting today? |
|
I can meet. |
|
Sorry, I meant: Do we need/want to meet? (I can also meet) |
|
The discussion above can be done async if preferred, it's just something that I think is worth talking about, in zoom or not.
My PR isn't exactly a breaking change - it makes possible something that wasn't. Even if it's a breaking change, I can't imagine the user base of people using multiple loaders being very large at the moment (in no small part because of the bug my diff attempts to address). And given that loaders are experimental, why is it necessary to wait 4+ months between two (possibly) breaking changes? Especially when the current release line is Node 19+, which is an odd release, ie already assumed to be more experimental than others? |
|
@arcanis If you’re free, can we chat today? It would be good to catch up regardless. I think the other concern regarding the “affect subsequent loaders” PR is whether it might interfere with or block the effort to move things off-thread. Like if each loader ends up in its own worker thread, would one loader be able to influence another? Hopefully the two features aren’t incompatible, but at the time I was thinking that the off-thread one was the more important of the two if we were forced to choose. |
Sure, I should be free around the time of the meeting 👍
My understanding was that "moving loaders off-threads" only involves moving the full chain of loaders to a separate thread shielded from userland, not each individual loader to a different one. Is it correct, @JakobJingleheimer ? |
|
Each loader would not be in its own thread. All loaders would co-exist in the same separate thread; however, if user-land spawned its own thread, a different loader thread would also be spawned (eg loader thread count = user-land threads + 1). If a loader is stateful, that means separate/multiple states with no point of commonality, unless we specifically connect them (eg via a shared buffer or a MessageChannel), which IMHO sounds like a very bad day, but without it, you have chaos. I think this is likely the scenario for an ambient loader? |
|
The use case for ambient loaders is to make loaders affect subsequent ones. Statefullness isn't related (for all intent and purposes, the PnP loader is stateless). |
|
🤔 Would anyone mind if I poke Gil to join? I think it would cause problems for the likes of testdouble. |
Time
UTC Tue 08-Nov-2022 19:00 (07:00 PM):
Or in your local time:
Links
Agenda
Extracted from loaders-agenda labelled issues and pull requests from the nodejs org prior to the meeting.
Invited
Observers/Guests
Notes
The agenda comes from issues labelled with
loaders-agendaacross all of the repositories in the nodejs org. Please label any additional issues that should be on the agenda before the meeting starts.Joining the meeting
link for participants: https://zoom.us/j/97506450082
For those who just want to watch: https://www.youtube.com/c/nodejs+foundation/live
The text was updated successfully, but these errors were encountered: