- From: Dan Clark <notifications@github.com>
- Date: Thu, 29 Aug 2019 15:22:15 -0700
- To: w3c/webcomponents <webcomponents@noreply.github.com>
- Cc: Subscribed <subscribed@noreply.github.com>
- Message-ID: <w3c/webcomponents/issues/831/526384109@github.com>
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