Loader locate/fetch/translate/instantiate API
I don't have an answer, but the "metadata" property of the loadRecord object was designed to be the place where you put your own custom metadata so that it's persisted across hooks. And it works in es6-module-loader.
Ok thanks, I see that this was added and I did not notice. (I think this kind of creeping overspecification annoying but inevitable I suppose).
The spec seems inconsistent about the metadata property. The define() function of Loader accepts options.metadata:
26.3.3.2Reflect.Loader.prototype.define ( name, source [ , options ] )
...
8. Let metadata be GetOption(options, "metadata"). 9. ReturnIfAbrupt(metadata). 10. If metadata is undefined then let metadata be ObjectCreate(%ObjectPrototype%).
But the import() function does not:
Reflect.Loader.prototype.import ( name [ , options ]
...
4. Let p be the result of calling LoadModule(loaderRecord, name, options).
...
15.2.4.1LoadModule(loader, name, options) Abstract Operation
...
8. Let metadata be ObjectCreate(%ObjectPrototype%).
That means I can pass .metadata to define() but not import(). I think the metadata should be passed on both.
I wonder if this is related to normalize not having access to the metadata
The Loader hook callbacks all have an API defined like:
My interpretation of this description was that the callback provider should expect the same loadRequest object in to reappear during the load pipeline and furthermore, this being JavaScript, I could add any properties I need to this object as long as they don't collide with the documented properties used by the Loader.
es6-module-loader interpreters the spec to mean each loadRequest parameter is bound to a new object with only the documented properties provided.
Which interpretation we can count on?