ES6 module loader and de-duping across language semantics

Ian Hickson ian at hixie.ch
Mon Aug 18 13:24:29 PDT 2014


Assuming we use the ES6 module loader to handle all the loads in an HTML 
document, in the Web context, there are some interesting questions to 
resolve around the issue of de-duping.

Suppose you had this markup snippet:

   <style>
    @import "http://example.com/foo.x";
   </style>
   <script href="http://example.com/foo.x"></script>

This causes foo.x to be evaluated once as a style sheet, and once as a 
script. In the new world, though, if every load goes through the ES6 
module system, how do we distinguish them in the module registry?

Similarly, consider this case:

   <script type=module>
    import "http://example.com/foo.x";
   </script>
   <style>
    @import "http://example.com/foo.x";
   </style>

After the module's import, foo.x is in the registry as an ES6 module. But 
the semantics of the @import rule are that it must be interpreted as CSS,
so that doesn't work.

It would be great if it was possible to attach metadata to the key that is 
used in the registry that would be part of the registry key but not 
exposed in the module API. For example, @import could tag all its modules 
as "CSS", so that the above would be keyed as {"http://example.com/foo.x", 
CSS}. Regular imports wouldn't key anything, so that in this case:

   <style>
    @import "http://example.com/foo.x";
   </style>
   <script type=module>
    import "http://example.com/foo.x";
   </script>

...the second import would find the pre-existing CSS import rather than 
try to introduce a new one.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'


More information about the es-discuss mailing list