--loader hooks for require()

[bmeck]

Spawned from a comment on per package hooks .

I'm opening this issue to discuss if we should make the Loader mechanisms we have expand to be able to intercept require() specifiers as well. I think it is doable but requires we split the resolution between sync/async forms. Looking at this as well we might want to split up the resolution of format from path resolution, but that is a lot to discuss for the general first gathering of consensus on if this should be a hook we provide.

[mcollina]

I think this is a must have. We should provide a simple enough mechanism from APMs to hook in both esm and cjs.

cc @watson

[ljharb]

I think if it’s important enough to warrant first-class support in ESM, it’s important enough to have it in CJS. I also think the inverse is true.

[bmeck]

@ljharb within reason, ESM was not made with CJS interop as a first class citizen. I would prefer if something is only viable in CJS and not ESM it not be put as a priority.

[giltayar]

The migration path is CJS => ESM. Whatever needs to be implemented to ease this transition is important. In this case, implementing loader hooks will help moving code from ESM => CJS. Neat, but not terribly important, IMO.

I would prefer using our resources elsewhere.

Actually, having loader hooks only in ESM may make the transition go faster! (people will move to ESM just to have all the goodies that loader hooks will bring...)

[mcollina]

I do not see a short-term future where a Node.js application will not a have a commonjs module in its dependency tree. Having support for cjs loader hooks will provide a safe transition to ESM.
Most enterprise Node.js deployments include an APM solution, which is currently based on monkey patching.
Without cjs hooks, any apm vendor should have two solutions: one for cjs and one for esm. In fact, not supporting this will slow the adoption curve.

[giltayar]

@mcollina - wouldn't the existing solutions they have work with their existing CJS modules? If they do, and they should, why bother migrating to another, albeit newer and better, solution?

Having said that, it would be nice to have a solution that works similarly and is configured similarly. But I would say that it's a nice to have, not a must have. If, in terms of code, it's not a big thing, then, yes. But if it requires significant work, I would prefer investing energy elsewhere.

Also, could you explain what "APM" means? 😳

[devsnek]

@giltayar APM = Application performance management, mostly hooking into node core to time stuff and catch errors

[bmeck]

There are also other common workflows like Mocking or testing that use similar workflows of replacing a module with a virtual/temporary one.

[ljharb]

It's absolutely essential to any adoption of ESM that things like proxyquire and jest.mock and others have a way to function - iow, there needs to be a way to "mock out" a default or named import.

Supporting this natively in node for ESM is a must; if we can also support it in a similar fashion for CJS, that's very valuable for a migration path - iow, if half my modules are CJS and the other half ESM, i'd want to mock out a foo whether it's required or imported.

[bmeck]

@ljharb that seems fine, but various things like setters/getters on the bindings are not possible still even though CJS mocking commonly does that to properties off module.exports. If we have specific cases where they don't work (like having getter/setter named exports) in both I'd prefer not to have the functionality exposed.

[ljharb]

ftr, I'm totally fine with getters and setters on module.exports not working - I find that an absurd pattern and nothing like it should be possible in ESM anyways. CJS mocking is certainly achievable without getters/setters.

[zackschuster]

@bmeck for my own benefit, this is similar to/drawing from npm's loaderhooks spec?

[bmeck]

@zackschuster this existed prior to theirs so idk which should be seen as drawing from which.

[zackschuster]

@bmeck ah, i didn't know that. it sounded similar to their proposal so i wanted to make sure 😄 thanks!