Repository navigation
feature request: add calling thread ID to loader resolve() context #49472
Description
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 a context object, which includes the parentURL. I am requesting that the thread ID also be included. If the thread ID were in the context, the resolve() hook could identify the proper mock (or real) implementation to use, depending on the thread.
What alternatives have you considered?
No response
Activity
MrJithil commentedon Sep 27, 2023
Is this something we can start working? Or should we wait for enough opinions?
bnoordhuis commentedon Sep 27, 2023
#30061 (comment) may be relevant.
cjihrig commentedon Sep 27, 2023
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.
targos commentedon Oct 2, 2023
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.
cjihrig commentedon Oct 2, 2023
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).
cjihrig commentedon Nov 13, 2023
Another data point from Slack:
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.