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
My loader analyzes a full module graph during load to determine module shape (the set of exported names). Walking the whole graph is necessary because wildcard exports can add unspecified names. You've got to walk the full graph to determine the names for one module.
exportconstvalue=1export*from'./source.mjs'
To ensure I'm using the full semantics of active CLI options, feature changes across versions, etc plus semantics changes provided by underlying loaders (such as TypeScript transpilation), I use the nextResolve and nextLoad routines in the analysis. They're extracted by the resolve and load hooks.
asyncfunctionresolve(specifier,context,next){// Retain resolver for analysisgear.resolve??=next...
asyncfunctionload(locator,context,next){// Retain loader for analysisgear.load??=next...
I see in the code that these routines actually mutate internal state for the particular import operation they were extracted from. Analysis for a single load may apply these routines to hundreds of modules with all different URLs and context properties. Analysis runs concurrently so many operations are in flight together. So far this doesn't seem to be causing problems, but I'm concerned it's an unsupported use and may break in the future.
When attributes come into use, I wonder if they'll start to drift across concurrent operations.
My loader would like a supported way to run resolve and load of the underlying loaders, independent of any import operations, and capable of running concurrently. Maybe they could be passed to initialize.
Amazing. Yes, it seems to handle everything, even conditions. I was also hoping to get access to the CJS load and it would even provide that. Currently I have that piece fudged.
Issue
My loader analyzes a full module graph during load to determine module shape (the set of exported names). Walking the whole graph is necessary because wildcard exports can add unspecified names. You've got to walk the full graph to determine the names for one module.
To ensure I'm using the full semantics of active CLI options, feature changes across versions, etc plus semantics changes provided by underlying loaders (such as TypeScript transpilation), I use the
nextResolve
andnextLoad
routines in the analysis. They're extracted by theresolve
andload
hooks.I see in the code that these routines actually mutate internal state for the particular import operation they were extracted from. Analysis for a single load may apply these routines to hundreds of modules with all different URLs and
context
properties. Analysis runs concurrently so many operations are in flight together. So far this doesn't seem to be causing problems, but I'm concerned it's an unsupported use and may break in the future.When attributes come into use, I wonder if they'll start to drift across concurrent operations.
Solution
My loader would like a supported way to run resolve and load of the underlying loaders, independent of any import operations, and capable of running concurrently. Maybe they could be passed to
initialize
.The text was updated successfully, but these errors were encountered: