esm, loader: move to own thread

[JakobJingleheimer]

What is the problem this feature will solve?

• limit contamination
• facilitate synchronous import.meta.resolve()

For the initial implementation, the same loaders thread will be used for all user-land threads. A subsequent enhancement may add a configuration option to the Worker constructor to spawn its own dedicated loaders thread.

What is the feature you are proposing to solve the problem?

Move loaders off-thread

What alternatives have you considered?

No response

---

Per direction from TSC

Following in the vein of babel: babel/babel#14025
And https://github.com/bmeck/using-node-workshop/tree/main/steps/6_async_and_blocking

---

• notify package authors of change (please comment to be added if not already included—sorry I know only so many)
  • esmock
  • jest?
  • mocha (Gil Tayar)
  • ts-node (Andrew Bradley)
  • yarn (Maël Nison)

[JakobJingleheimer]

@bmeck @MylesBorins could either of you speak to the impetus for this?

[aduh95]

Related: #31229

[GeoffreyBooth]

@bmeck @MylesBorins could either of you speak to the impetus for this?

Pros and cons here: nodejs/modules#351 (comment)

[cspotcode]

Can add to the list of package authors:
esmock

I wonder, does it make sense for the loaders team to have a thread somewhere which can be subscribed to for notifications of breaking changes? All relevant discussion can happen elsewhere, the thread would be like an RSS feed. Package maintainers can opt-in to notifications of breaking or potentially exciting/disruptive changes by subscribing to that thread.

Might scale better than us hoping we know a comprehensive list of all loaders.

[JakobJingleheimer]

Since Node.js doesn't maintain anything of the sort, that sounds like a better alternative to "surprise!". It's not full-proof, though.

[JakobJingleheimer]

We have a working Proof of Concept: https://github.com/JakobJingleheimer/worker-atomics