"the type attribute is used simply for a check"

[jakearchibald]

From the readme:

For example, on the Web and similar environments, when providing a type module attribute, the module type would not form part of the cache key, where modules are always cached by the resolved URL. Instead, the type attribute is used simply for a check, which would cause the module graph to fail to load in the event of a mismatch

This suggests you couldn't do something like:

import jsText from './module.js' as 'text';
import { foo, bar } from './module.js';

I agree these should coalesce at the fetch & HTTP cache level, but they should be different modules.

[littledan]

That text was written with as "json" and as "html" in mind. If we wanted to branch out and add things like as "text" to HTML, I agree, that those would be different modules.

[littledan]

How about this: If we go with a key-value syntax, like

import json from "./foo.json" with type: "json"

then we would say, "the type attribute is a check, but other attributes may change interpretation." This way, type: would be somehow reliable/predictable, while we have space to grow into features like what @jakearchibald suggestions. So, your as "text" could instead be, for example,

import jsText from "./module.js" with reading: "text"

[littledan]

Overall, I think this thread vindicates the decision to go with key/value syntax, rather than a single as attribute: we can design simpler invariants for type: while keeping flexibility for module attributes overall. I don't see a particular additional action to take from here.

[xtuc]

This issue is a bit outdated. Since we decided to only allow "check" attributes and the key value form. The type attribute is not part of the cache.

So

import jsText from './module.js' as 'text';

is now disallowed if module is of type JavaScript.

@jakearchibald we are discussing (whatwg/html#5640) if the host should send an Accept header to the server to indicate the type. What that address your use-case?

[nicolo-ribaudo]

The proposal has now been updated to that import attributes are more than just a check, and hosts can use them to affect how a module is loaded/evaluated (for example, by sending different HTTP headers when loading it).

How modules with different attributes are handled in the HTTP cache is up to the host, since the host defines what the different attributes means. However, the proposal requires that if the same specifier is imported from the same module with the same attributes twice it must then result in the same module.

[jakearchibald]

The proposal has now been updated to that import attributes are more than just a check

Can you give a bit more detail around this? From the readme it still looks like a check https://github.com/tc39/proposal-import-assertions/blob/master/README.md. It's still called an "assert" too.