- 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