Re: [w3c/webcomponents] HTML Modules: multiple scripts exporting same named export (#831)

Hi Joel,

Considering your example HTML module:
```HTML
<script type="module">
  export const foo = 1;
</script>
<script type="module">
  export const foo = 2;
</script>
```
The above will throw during import/export resolution if and only if the importer of this HTML module imports `foo`.  That is, this will trigger an error:
`import {foo} from "./html-module.html"`
but this will not:
`import "./html-module.html"`

One way of looking at this is that the HTML module example is roughly equivalent to this code written with only JavaScript modules:
**module.js**:
```JavaScript
export * from "./leaf1.js";
export * from "./leaf2.js";
```
**leaf1.js**:
```JavaScript
export const foo = 1;
```
**leaf2.js**:
```JavaScript
export const foo = 2;
```

The following will throw, as the conflict between the two 'foo' exports will be detected during import resolution:
`import {foo} from "./module.js"`
Whereas importing in the following manner will execute the module tree without errors:
`import "./module.js"`

This is because module import/export linking is primarily import-driven; if nothing imports the duplicated name then no ambiguity is detected, which is fine because no one can observe either of the conflicting bindings.

The HTML module case is a little less intuitive because both `export const foo` statements occur in the same file.  However, the module graph built from it contains 3 distinct module records: the HTML module itself, the JS module for the first inline script, and the JS module for the second inline script.

Hope that helps!

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3c/webcomponents/issues/831#issuecomment-526384109

Received on Thursday, 29 August 2019 22:22:37 UTC