Access attributes by import.meta?

[Jack-Works]

A.js

import './b.js' with {a: 1}

B.js

console.log(import.meta.attributes.a) // 1

[ljharb]

B could be imported many times with different metadata, and it’s only evaluated once, the first time. it wouldn’t make much sense to me for it to have access only to the metadata provided by the first importer.

[MylesBorins]

I think this would depend on the caching model. If there was an attribute such as "meta" that was part of the key for the cache this could effectively make different instances

…

On Wed, May 20, 2020, 12:25 PM Jordan Harband ***@***.***> wrote: B could be imported many times with different metadata, and it’s only evaluated once, the first time. it wouldn’t make much sense to me for it to have access only to the metadata provided by the first importer. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#58 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AADZYV7XKQOT6FS53UEHH53RSP77ZANCNFSM4NF7ELBA> .

[ljharb]

Sure, but then the importer is forcing the module to be re-evaluated again in a way the author may not have intended. For example, if my web server rejects any query strings and only allows a single URL, then you can’t invalidate that cache and evaluate it twice on the same page (afaik). Giving the importer runtime cache control seems concerning; are there any other examples in the web platform where this is the case? In node it can be done, but anyone would assume they’re risking voiding their warranty by doing that - i don’t think the same would apply if it was first class syntax.

[littledan]

My inclination right now is to leave both things--the interpretation of unknown attributes, and the set of import.meta properties--up to the host. Is "leaving it up to the host" an acceptable path for this decision, or do we need to make a requirement on hosts about import.meta here?

I agree with others here that this is only acceptable if these unknown attributes are considered part of the cache key; this shouldn't be a contest about who imports first. The current draft spec text does permit hosts to use module attributes as part of the cache key (though not type, which is required to just be a check). If I were to design a host, here's an ordered list of my preferences, from most preferred to least, when it comes to these aspects:

• Most preferred: Reject unknown module attributes, to ensure maximum future-proofing for flexibly adding interpretations later
• Middle: Ignore unknown module attributes, but use the same copy of the module. This implies that import.meta.attributes cannot be exposed.
• Least preferred: Ignore module attributes and generate a separate copy of the module, just so that import.meta.attributes is different. It's hard for me to imagine when you'd actually want this cost tradeoff. Maybe use cases would push it up in my personal host-designer calculation.

@xtuc has previously suggested that we expose this kind of thing through import.meta, but I didn't think it through as much as now.

[nicolo-ribaudo]

The proposal allow hosts to expose attributes on import.meta, however there are currently no plans in known hosts (HTML, WinterCG hosts) to expose them.