You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Hooking resolution helper functions in multiple loaders #104
You could use them in a sorta-compositional way by having one loader override these helpers, so that when the next loader imports them they get the custom versions.
I'm worried that we don't realize how complex this is, and if anyone sits down to attempt it in a loader, they'll realize they don't like it, and they'll propose that we offer a better API for composition.
Maybe I'm thinking about this wrong, but to customize a single export of a native module, you need to redirect incoming resolutions to a virtual wrapper, but allow the wrapper to itself import the un-wrapped native version. (or a wrapped version from a subsequent loader)
// pseudo-code// Goals:// Wrap a single helper function// Be compatible with other loaders before or after us in the chain that also wrap helper functionsconstguid=`${Math.random()}`;// avoid conflicts with other loadersfunctionresolve(specifier,ctx,next){if(specifier==='node:module')returnnext(`node:module-wrapper-${guid}`,ctx);if(specifier===`node:module-next-${guid}`)returnnext(`node:module`,ctx);returnnext(specifier,ctx);}functionload(url,ctx,next){if(url===`node:module-next-${guid}`)returnnext(`node:module`,ctx);if(url===`node:module-wrapper-${guid}`)returnwrapperText;returnnext(url,ctx);}constwrapperText=` export * from 'node:module-next-${guid}'; import {functionToWrap as _functionToWrap} from 'node:module-next-${guid}'; export functionToWrap(a) { if(conditional) return _functionToWrap(a + 1); return _functionToWrap(a); }`;
You could use them in a sorta-compositional way by having one loader override these helpers, so that when the next loader imports them they get the custom versions.
I’m worried that we don’t realize how complex this is, and if anyone sits down to attempt it in a loader, they’ll realize they don’t like it, and they’ll propose that we offer a better API for composition.
What I meant there is that you could do this, overriding the helpers for subsequent loaders to use, not that you should. In general I think we should provide specific APIs for customizations rather than expecting or encouraging people to monkey-patch or override. The nature of the module hooks we already have is that just about anything can be overridden, so that’s an option, but it’s a sucky one. We absolutely should provide dedicated APIs for customizing filesystem calls if that’s a use case that we want to support.
Activity
GeoffreyBooth commentedon Jul 26, 2022
What I meant there is that you could do this, overriding the helpers for subsequent loaders to use, not that you should. In general I think we should provide specific APIs for customizations rather than expecting or encouraging people to monkey-patch or override. The nature of the module hooks we already have is that just about anything can be overridden, so that’s an option, but it’s a sucky one. We absolutely should provide dedicated APIs for customizing filesystem calls if that’s a use case that we want to support.