Jacob Smith

Yes? I think the package.json proposal is quite viable and seems an appropriate place. In terms of workspaces and mono-repos, if they're executing together, they would likely share loader state....

We're cognisant of a desire for an API like that, and I do believe there is no philosophical objections in principle. I think addressing those use-cases is _somewhere_ down the...

Thanks for this! I _think_ this is addressed by somehow exposing resolve utils and/or some flavour of createResolve. Looking at this, this seems like it would be covered by the...

Sorry I can't attend this one (it's my partner's birthday). I'm in favour of "Customization API" (despite the incorrect spelling) and related nomenclature.

Ah, yes. That's what I was referring to above. (Works for me, and i voted)

Regarding exposing those utils via a core module (presumably [`module`](https://nodejs.org/api/module.html)), that sounds to me fairly straight-forward and doable with low effort and high reward (and should be transparent to existing...

If only 1 loader does it, that would be fine. But I think as soon as more than 1 claims dominion over mutually exclusive behaviour, we have an unstoppable force...

Sorry, a bit behind and catching up: > If I was tasked with doing something like that I would probably prefer to compose my own single loader from utility packages...

cc: * esmock @bumblehead * mocha, testdouble @giltayar * ts-node @cspotcode * yarn @arcanis

It's possible to access `default` at the end of the chain: `--loader b.mjs --loader a.mjs` `nextResolve` in `A` will be `B`, and then `nextResolve` in `B` will be `defaultResolve`. A...