Re: [w3c/webcomponents] HTML Modules (#645)

I posted a few ideas I had for [generic dynamic exports](https://esdiscuss.org/topic/a-few-module-ideas) so that people could define whatever imported they want, I much prefer the syntax proposed here by for what my import arguments idea essentially was.

In order to be friendly to custom importers I wonder if you could have that the target of `as` could be a string (resolved like any other module) that gets executed *before* the main module graph is executed e.g.:

```js
// ini.js
export default {
    async [Symbol.importer](url) {
        const response = await fetch(url)
        if (!response.ok) {
            throw new Error(await response.body())
        }
        const lines = (await response.text()).split('\n')

        // This isn't actually the full .ini format but you get the idea
        const result = {} 
        for (const line of lines) {
            const [key, value] = line.split('=')
            result[key.trim()] = value.trim()
        }
        // This would be converted to a Module Namespace somehow
        return {
            default: result
        }
    }
}
```

```ini
# example.ini
foo = 10
bar = 20
fizzbuzz = cats
```

```js
// example.js
import config from "./example.ini" as "/importers/ini.js"

console.log(config.foo) // '10'
console.log(config.fizzbuzz) // 'cats'
```

Then stringless specifiers could just be something like `HostImportAs`/`GlobalImportAs` or something like that e.g.:

```js
// This would trigger `HostImportAs`/`GlobalImportAs` with the global 
// DocumentFragment as the importer
import foo from "./document.html" as DocumentFragment
```

-- 
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/645#issuecomment-331062343