Verbosity/synchronization challenges

[bmeck]

Both URL band and source text band solutions require potentially large duplication of these attributes. This is a challenge as it increases shipping size for web, which is the primary target of this proposal, and means keeping all location of the attributes in sync. Additionally, if the attributes are in multiple locations due to using a solution that allows/requires such, it should clarify how mismatches are resolved.

Example given a URL band solution:

// x.mjs
import a from 'import+json://foo.json';
import b from 'import+javascript://foo.json';
import c from 'import://foo.json';

// y.mjs
import d from 'import+json://foo.json';

Could all 3 in x.mjs succeed? They have separate request URLs in web spec terms, so it seems like they would resolve independently.

I think solving for the verbosity impacts synchronization of these in non-trivial ways. E.g. SRI being defined per source text would mean invalidating the whole dep graph when an SRI changes. Out of band solutions/single location solutions could preserve parts of the dep graph that were unchanged still.

I think having more attributes and their use cases discussed would increase the visibility of this concern.

[xtuc]

I suppose the type JavaScript would be the default, only new module types would require an attribute. Compression will help with repeating the same attributes many times in a file, but will fail project-wide.

An advantage of the out-of-band format is that the type would be specified only once per file, as opposed to every file that imports it.

[bmeck]

@xtuc the update for every file that imports it would apply to any attribute that would require updating. Changing the format of a file for type or changing the content of a file for integrity. This means updating dependencies and transitive dependencies would require updates to all dependent source files if done in band for every operation that needs to synchronize with an attribute.

[littledan]

The SRI concerns that @bmeck mentions are exactly why we don't focus on inline SRI in this repository, and why there's a good chance it would never happen at all. We could discuss technical details more in #8 . On the other hand, for module type, I think it's important to be in-band and not out of band because that is indeed the place to do the update where appropriate. Finally, if you want to discuss the form of putting metadata inline in the module specifier, let's discuss this in #11 .

[bmeck]

@littledan regardless of where it is located and what the attribute key/value pairs are, the issue here is the duplication and potential mismatches of attributes. Other attributes outside of SRI are interesting here if we don't want to discuss SRI, like language, no-top-level-await, and/or mobile. I can think of many varieties of useful attributes, and do not want this proposal to only focus on essentially specifying a single accept: header key/value pair.

[ljharb]

The appropriate place to determine what type a module is is in the module itself, not in its consumers, which is why i also prefer out of band.

[littledan]

Sorry, my last comment got a bit off topic. Let's centralize the discussion about out of line attributes in #13