Integration with import-attributes

[xtuc]

The proposal https://github.com/tc39/proposal-import-attributes, currently stage 2, provides a way for developers to add attributes to the in the import, for instance:

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

The host will ensure that the resource is of type JSON.

In tc39/proposal-import-attributes#61 we are discussing if the host would send a header indicating the expected type to the server, I suppose that would be Accept. We decided that the type attribute isn't part of the module cache key.

On the other hand, tc39/proposal-import-attributes#16 shows that multiple representation of a resource may exist; BinAST and JavaScript for example.

Does sending a header based on the module type or other semantics make sense to you?

[littledan]

Let's also track the HTML integration PR for module attributes in this issue.

A big issue with sending an Accept header based on the type would be, what should be done if a module is already in the module map, but then it's imported with a different type? Should there be a second fetch in that case? What do we do if the response is different? This issue makes me suspect that we shouldn't send different HTTP headers due to the type attribute.

[domenic]

I think the type should be part of the module map cache key to solve those issues.

[littledan]

@domenic Could you say why? If it's important to send different HTTP headers, which should we send? (Note that the previous JSON module patch didn't send different HTTP headers AFAIK, and the module type was not part of the cache key.)

[littledan]

To be concrete, the conflicting intuition from JavaScript developers about making the type part of the cache key would be that a module specifier points to a unique module; that it's not "cloned" just because different attributes are used. While this rules out a lot of potential use cases for module attributes, I thought it would be consistent with the requirements for type on the Web.

The current proposal draft contains a MUST-style requirement that modules not be cloned, but TC39 understands that hosts might willfully violate this requirement (as HTML has willfully violated the JS spec in the past), and is open to reconsidering this requirement in the future. See this section of the import attributes README for details.

[jakearchibald]

fwiw, we don't make credentials mode part of the cache key, even though it changes the shape of the request.

[domenic]

Different import statements should cause different cache keys, in my thinking. Otherwise we would just use an import specifier microsyntax.

[jakearchibald]

I do like the idea of being able to import the same module twice with different types.

[littledan]

fwiw, we don't make credentials mode part of the cache key, even though it changes the shape of the request.

OK, then maybe it's OK to "race" here and let the first thing that loads the module specifier determine the shape of the request. In this case, how should the request to the server be modified based on the module type?

Different import statements should cause different cache keys, in my thinking. Otherwise we would just use an import specifier microsyntax.

I don't understand this assertion. I'm still not a fan of import specifier microsyntax, for reasons discussed elsewhere (e.g., tc39/proposal-import-attributes#11).

I do like the idea of being able to import the same module twice with different types.

If we want module attributes that can transform the interpretation of a module, while others checked things about the module (like the MIME type), what if we supported two different kinds of attributes? It could be like this:

import { foo } from "specifer" if { checkKey: "value" } with { transformKey: "value2" };

Since some module attributes are checks and some are transforms, making them syntactically separated would let developers understand which parts form part of the cache key/extended specifier and which parts don't.

Based on previous conversations, I thought type was a check. I still don't understand why this isn't the case.

cc @syg

[domenic]

type is definitely a transform. It changes the interpretation of the bytes received.

[littledan]

I also wanted to mention: about @jakearchibald 's suggestion to allow you to import a module as "text" and have that not be a check but rather a change in interpretation (presumably this would only be permitted for same-origin specifiers): My suggestion was that we use a separate attribute for these changes of interpretation, using type to check the MIME type. See past discussion: tc39/proposal-import-attributes#43 . I haven't yet heard an explanation of the downside of this approach, where type checks the MIME type (which is what we need to avoid privilege escalation), and other attributes could change the interpretation of a module.