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:
http://jsbin.com/kutey/2/edit?js,output.
Juan
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).
jjb
On Wed, Jul 30, 2014 at 7:20 AM, Juan Ignacio Dopazo jdop...@yahoo-inc.com
wrote:
I don't have an answer, but the metadata property of the
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
I wonder if this is related to normalize not having access to the metadata
http://jsbin.com/pazovohi/1/
On Wed, Jul 30, 2014 at 12:21 PM, John Barton johnjbar...@google.com
wrote:
The spec seems inconsistent about the metadata property. The define()
function of Loader accepts
The Loader hook callbacks all have an API defined like:
Reflect.Loader.prototype.locate ( loadRequest )
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,
5 matches
Mail list logo
