Adding out-of-band dependencies for a module

# Ian Hickson (11 years ago)

So I'm trying to figure out how to spec the HTML spec's Loader.

One of the things that we're likely to add as part of this is a generic dependency system. Authors have long asked to be able to do things like define that their scripts depend on CSS or images or whatnot. If we introduce a global attribute for this is HTML, say needs="", then it will be possible to do something like:

<script type=module needs="foo" href="foo.js"></script>

...where "foo" is an ID to some other element.

So far so good. However, I don't see how to actually add these dependencies to the Load Record's [[LinkSets]]. In the instantiate hook, I can either override the behaviour entirely (providing my own dependency list, but also having to evaluate the code myself and return an eventual Module), or I can return undefined and let the ES spec handle all of it, with no way to add explicit dependencies.

I guess since the HTML spec is going to be calling both LoadModule() and EnsureEvaluated() for each module declared by <script type=module>, one

solution is just to handle these myself, and not call EnsureEvaluated() until all the dependencies are ready as well as the LoadModule() promise being resolved. In that the expected behaviour?

# David Herman (11 years ago)

On Aug 11, 2014, at 5:06 PM, Ian Hickson <ian at hixie.ch> wrote:

So I'm trying to figure out how to spec the HTML spec's Loader.

We should coordinate -- I've been actively working on this (not the spec per se, but the design) with people engaged in the JS modules work. The HTML default loader design has some requirements that touch on existing JS ecosystems and practices, so we need to be sure we don't spec it in isolation.

One of the things that we're likely to add as part of this is a generic dependency system.

You've mentioned this to me before, but I'm afraid I haven't seen any clear rationale written up anywhere, nor a good description of what this means. One thing it might mean is a resource-fetching dependency system, meaning that for any two elements A and B that require fetching a network resource, you can state that A depends on B, meaning that whenever A's resource is fetched, B's resource should be fetched too and the system should not consider A's fetch complete until B's fetch is complete. If that's what you mean, I'm skeptical that an attribute is the right level for programmers to express this kind of resource grouping. In particular, HTTP2 and the TAG's work on package management are better approaches to grouping network resources than scattering dependency attributes across a DOM tree.

# Ian Hickson (11 years ago)

On Tue, 12 Aug 2014, David Herman wrote:

On Aug 11, 2014, at 5:06 PM, Ian Hickson <ian at hixie.ch> wrote:

So I'm trying to figure out how to spec the HTML spec's Loader.

We should coordinate -- I've been actively working on this (not the spec per se, but the design) with people engaged in the JS modules work. The HTML default loader design has some requirements that touch on existing JS ecosystems and practices, so we need to be sure we don't spec it in isolation.

I've been chatting with people on #whatwg about this; I encourage you to join us!

One of the things that we're likely to add as part of this is a generic dependency system.

You've mentioned this to me before, but I'm afraid I haven't seen any clear rationale written up anywhere, nor a good description of what this means.

I'm working on a more detailed description to send to the WHATWG list. I hope to be able to send something soon.

One thing it might mean is a resource-fetching dependency system, meaning that for any two elements A and B that require fetching a network resource, you can state that A depends on B, meaning that whenever A's resource is fetched, B's resource should be fetched too and the system should not consider A's fetch complete until B's fetch is complete. If that's what you mean, I'm skeptical that an attribute is the right level for programmers to express this kind of resource grouping.

We probably need a variety of approaches, sure. The attribute in my earlier mail is just a strawman; whatever the approach, if we end up with a way of saying "if you find that you need this module then you should also make sure to apply this style sheet" then the problem I described exists. I'm just trying to figure out how that should be specced.

In particular, HTTP2 and the TAG's work on package management are better approaches to grouping network resources than scattering dependency attributes across a DOM tree.

I'm not familiar with the TAG's work (do you have a reference?). HTTP2's new features are somewhat orthogonal to the issue of saying what resources should be activated together, though. (Also, many people won't be using HTTP2, especially the server-cleverness aspects of HTTP2, for a long time, but may still want to be able to declare dependencies.)

# Rick Waldron (11 years ago)

On Mon, Aug 11, 2014 at 8:06 PM, Ian Hickson <ian at hixie.ch> wrote:

So I'm trying to figure out how to spec the HTML spec's Loader.

One of the things that we're likely to add as part of this is a generic dependency system. Authors have long asked to be able to do things like define that their scripts depend on CSS or images or whatnot. If we introduce a global attribute for this is HTML, say needs="", then it will be possible to do something like:

<script type=module needs="foo" href="foo.js"></script>

...where "foo" is an ID to some other element.

So far so good.

Unless the module has >1 dependency.

# Ian Hickson (11 years ago)

On Tue, 12 Aug 2014, Rick Waldron wrote:

On Mon, Aug 11, 2014 at 8:06 PM, Ian Hickson <ian at hixie.ch> wrote:

One of the things that we're likely to add as part of this is a generic dependency system. Authors have long asked to be able to do things like define that their scripts depend on CSS or images or whatnot. If we introduce a global attribute for this is HTML, say needs="", then it will be possible to do something like:

<script type=module needs="foo" href="foo.js"></script>

...where "foo" is an ID to some other element.

So far so good.

Unless the module has >1 dependency.

That's no problem, we just define the attribute as taking a space-separated list of IDs.