[Feature] Allow users to specify a custom `experimental-loader` when using `esm`

• I’d be willing to implement this feature (contributing guide)
• This feature is important to have in this repository; a contrib plugin wouldn’t do

Sadly can’t contribute without jumping through some significant hurdles.

Describe the user story

Using yarn with the .pnp.loader.mjs experimental loader prevents users from adding their own loader. If we specify it on the command line, we lose yarn’s loader. Node doesn’t currently support multiple loaders, and even if it did, not sure how this will look in future. Since yarn expects the loader to be called .pnp.loader.mjs (hard coded in the source), and this file is automatically generated - users of yarn don’t have an option but to use it.

Describe the solution you’d like

Allow users specify the experimental loader to use in yarmrc or something similar. Yarn can still generate the .pnp.loader.mjs file, but advanced users can import from the original .pnp.loader.mjs file and re-export their custom hooks (which build on top of the .pnp.loader.mjs hooks).

Describe the drawbacks of your solution

This is an opt-in feature, and using it essentially means you know what you are doing. More config is never better, but my request is basically for the name of the experimental loader to use not to be hard-coded.

Describe alternatives you’ve considered

We could always incorporate the experimental loader and override it ourselves, e.g:

yarn node --experimental-loader ./.pnp.loader-extended.mjs ./main.mjs

But the above only complicates things (sometimes yarn is run as a script, do we manually add this everywhere?). What if yarn is run in another processes?

[arcanis]

If and when loader chaining is implemented, would the expectation be for users to manually include Yarn’s loader via the CLI?

I’d expect it to work the same as for commonjs: Yarn adds --loader .pnp.mjs to the NODE_OPTIONS variable (just like we do with --require), and to add more loaders you’d add more --loader options to your own command line. But it’s not specific to Yarn, it’s how Node works.

[arcanis]

It’s not a bug, it’s a separate feature: loaders can be composed, but don’t yet leverage earlier loaders when resolving subsequent ones. I submitted a RFC and there’s been reasonable support for fixing that, but I didn’t get the chance to implement it yet.