Geoffrey Booth
Geoffrey Booth
If I’m remembering correctly, part of the theory of the current hooks design was the expectation that the ESM loader would eventually become the _only_ loader, as it can handle...
> instead of having no way to opt out of a slow abstraction that they don’t necessarily need or could do better themselves. Is the “slow abstraction” the fact that...
> Users still need to provide both CJS loader hooks via monkey patching and ESM loader hooks via `module.register()` when they intend to provide universal support. They shouldn’t, though, when...
Also, presumably the hook would run before the module is linked, right? So the exports could get patched by the hook before they’re registered in V8. They would be immutable...
I think what we want in the end is this: - A single API where users can define `resolve` and `load` module customization hooks that apply to any module (CommonJS...
> I am OK to add support after npm adds support for it. We already support the `engines.pnpm` field which supports a range, unlike the `packageManager` field, so I don’t...
> I see that the devEngines.packageManager field allows an array. So if we were to support this new field, could we have two entries? One for the pnpm package with...
> Sounds fair. I’ll develop an API soon. Possibly related: https://github.com/un-ts/synckit
Closing now that #198 has landed. That seems to be the consensus on the direction we want to go.
> also - since the output is truncated in the middle of a line, I am pretty sure it is not on node’s side. Please ignore the truncation for the...