Modules and dependencies known before the load

Kevin Smith zenparsing at gmail.com
Fri Aug 15 10:50:39 PDT 2014


>
>
> I think it would be reasonable for us to say that all the dependency
> declaration mechanisms are equivalent in that they all cause the target
> dependency to be "executed" (whatever that means in the context).


OK.  The "instantiate" hook allows you to specify arbitrary dependencies,
but only if the module in question is not coming from ES6 source code.
 There's currently no way to say:  "instantiate this module from source as
a normal ES6 module, but add A, B, and C to the dependency list."  AFAIK,
anyway.


> This
> might need careful management around some resource types, though. In
> particular, CSS imports don't de-dupe, so we'd have to say what it means
> if you do:
>
>    <style depends-on="my-other-stylesheet">
>      @import url(my-other-stylesheet);
>    </style>
>
> Does this cause "my-other-stylesheet" to be loaded twice?
>

This is from your other post, right?

If you're going to use the ES module loader as a general dependency
management framework, then each resource will need to have a corresponding
ES module "image".  What if the corresponding ES module for a stylesheet,
instead of initializing and exposing a stylesheet object, exposed a factory
function for creating stylesheet objects?


> But that's probably out of scope for this list.
>

Sometimes it seems like much of ES is out of scope for this list : )
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20140815/77d52212/attachment-0001.html>


More information about the es-discuss mailing list