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 <johnjbarton at google.com>
wrote:

> 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.
>
> jjb
>
>
> On Wed, Jul 30, 2014 at 7:20 AM, Juan Ignacio Dopazo <
> jdopazo at yahoo-inc.com> wrote:
>
>> 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
>>
>
>
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>


-- 
-Calvin W. Metcalf
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20140730/14b2202d/attachment.html>

I wonder if this is related to [normalize not having access to the metadata](http://jsbin.com/pazovohi/1/)