Repository navigation
feature request: add calling thread ID to loader resolve() context #49472
Description
Activity
Is this something we can start working? Or should we wait for enough opinions?
#30061 (comment) may be relevant.
FWIW, I was referring to using
worker.threadIdhere.I would avoid starting any work until you get some input from the loaders team in case they push back for some reason.
I feel like there's a misunderstanding here (or I don't really understand the use case). If your application has one main thread and two worker threads, then there are three separate loader threads. With this feature, each loader would receive a different thread ID, but always the same one.
If your application has one main thread and two worker threads, then there are three separate loader threads.
Maybe there is a misunderstanding then. I was under the impression that once the loaders were moved off thread, there was a single loader thread for the entire application. If that is not the current state, I thought it was at least the goal state based on #47747 (comment).
Another data point from Slack:
when hooks are registered, node spawns a thread to run them in. when user code creates a thread, node spawns another thread for running hooks; there should just be one hooks thread that handles however many application threads there are
If we will eventually end up with a single hook thread, then it seems like it would be very useful to have the calling
threadIdfor use cases like mocking.Reacted by Michaël Zasso
What is the problem this feature will solve?
Some loaders, such as a mocking loader, should be aware of the thread initiating the operation. For example, it is common for ESM mocking to pass a list of export names to the loader thread, and later resolve those exports on an application thread. If a module is mocked from one application thread, and another thread tries to import the same module, it will be unaware of the export values. The export values themselves cannot be passed between threads because some values, such as function, do not serialize.
What is the feature you are proposing to solve the problem?
The
resolve()loader hook already has acontextobject, which includes theparentURL. I am requesting that the thread ID also be included. If the thread ID were in the context, theresolve()hook could identify the proper mock (or real) implementation to use, depending on the thread.What alternatives have you considered?
No response