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
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); }`;
The text was updated successfully, but these errors were encountered:
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.
Extracting these ideas into a separate thread, since #94 is not focused on the challenges of using the helper functions in multiple loaders.
#94 (comment)
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)
The text was updated successfully, but these errors were encountered: