You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Extracted from loaders-agenda labelled issues and pull requests from the nodejs org prior to the meeting.
nodejs/node
console.log failure while working with worker threads. #30491
Invited
Loaders team: @nodejs/loaders
Observers/Guests
Notes
The agenda comes from issues labelled with loaders-agenda across all of the repositories in the nodejs org. Please label any additional issues that should be on the agenda before the meeting starts.
I can add the whole thread as a “meeting” to our meeting notes, but I wanted to save the conclusion here where it could be more easily found:
Next steps, in priority order
Add support for the load hook to understand source returned when type is commonjs.
Add the registerLoader API.
Currently we spawn a new loaders thread for each new application Worker thread. Change this so that there’s always only one loaders thread, no matter how many application (main + worker) threads there are.
Split out the port aspect of globalPreload into its own API, with consideration given to communication between the one loaders thread and the potentially many application threads.
Remove the globalPreload hook, as it should no longer be needed now that registerLoader and the new communications API have landed.
If desired, add support to new Worker for spawning a new loaders thread alongside the new worker thread. Allow either inheriting the loaders defined at initial process launch or defining new ones specific to that new loaders thread.
Finishing all of these (or all but the last, optional, one) will complete the items in https://github.com/nodejs/loaders#milestone-2-stability which are our remaining to-do items before hopefully marking the Loaders API as stable.
Activity
GeoffreyBooth commentedon May 6, 2023
A Slack conversation turned into an impromptu (text-based) meeting: https://openjs-foundation.slack.com/archives/C053UCCP940/p1683406821698669?thread_ts=1683400385.659389&cid=C053UCCP940
I can add the whole thread as a “meeting” to our meeting notes, but I wanted to save the conclusion here where it could be more easily found:
Next steps, in priority order
loadhook to understandsourcereturned whentypeiscommonjs.registerLoaderAPI.Workerthread. Change this so that there’s always only one loaders thread, no matter how many application (main + worker) threads there are.portaspect ofglobalPreloadinto its own API, with consideration given to communication between the one loaders thread and the potentially many application threads.globalPreloadhook, as it should no longer be needed now thatregisterLoaderand the new communications API have landed.new Workerfor spawning a new loaders thread alongside the new worker thread. Allow either inheriting the loaders defined at initial process launch or defining new ones specific to that new loaders thread.Finishing all of these (or all but the last, optional, one) will complete the items in https://github.com/nodejs/loaders#milestone-2-stability which are our remaining to-do items before hopefully marking the Loaders API as stable.
JakobJingleheimer commentedon May 9, 2023
Our active items are:
registerutility node#46826sourcefor format: commonjs