import.meta.resolve()

[domenic]

Wotcher TAG!

I'm requesting a TAG review of import.meta.resolve().

import.meta.resolve(specifier) returns the URL to which specifier would resolve in the context of the current script. That is, it returns the URL that would be imported if you did import(specifier).

This is a quite small feature (a single function, with only a few lines of spec text which exposes an already-existing spec algorithm).

• Explainer¹ (minimally containing user needs and example code): https://gist.github.com/domenic/f2a0a9cb62d499bcc4d12aebd1c255ab
• Specification URL: Add import.meta.resolve() whatwg/html#5572
• Tests: Implement import.meta.resolve() web-platform-tests/wpt#34188
• User research: None
• Security and Privacy self-review²: https://gist.github.com/domenic/f2a0a9cb62d499bcc4d12aebd1c255ab#security-and-privacy
• Primary contacts (and their relationship to the specification):
  • Domenic Denicola (@domenic), Google
• Organization(s)/project(s) driving the specification: Google
• Key pieces of existing multi-stakeholder review or discussion of this specification: Proposal: import.meta.resolve (was: import.meta.resolveURL) whatwg/html#3871 Add import.meta.resolve() whatwg/html#5572
• External status/issue trackers for this specification (publicly visible, e.g. Chrome Status): https://chromestatus.com/feature/5086507990777856

Further details:

• I have reviewed the TAG's Web Platform Design Principles
• Relevant time constraints or deadlines: Chrome would like to ship this within a few weeks.
• The group where the work on this specification is currently being done: WHATWG
• Major unresolved issues with or opposition to this specification: There was some opposition from Node.js about how synchronous semantics would conflict with their existing experimental async semantics; see the discussion in the explainer. I believe these have been largely resolved.
• This work is being funded by: Google

We'd prefer the TAG provide feedback as (please delete all but the desired option):

💬 leave review feedback as a comment in this issue and @-notify @domenic

[plinss]

We took a look at this today and are generally favorable. Some questions though regarding the sync/async decision, what happens if the author calls this while there's a pending load for an import map? Does it throw or return the wrong value? If the author needs to wait until the import map(s) are fully loaded, how do they do that?

[domenic]

Right now import maps are always inline and cannot be loaded. It's unclear whether that will change in the future; implementer interest is low, although I personally think it'd be nice.

In such a future, it would return the current value. It would not throw. It's not clear whether the current value would be considered "wrong"; if you do import.meta.resolve(x); import(x); while an import map is being loaded, the import() statement will import the same URL returned by import.meta.resolve(x) (i.e., the current value).

If an author needs to wait for import maps in such a future, it depends on how we expose external import map loading, but probably the simplest way would be to wait for that import map <script> element's load event.

[LeaVerou]

We looked at this again today during a breakout. Even without import map loading, authors can always dynamically add import maps by creating new <script> elements and appending them to the document. So even if the API were async, it could not possibly account for all future import maps. Therefore we're fine with a sync API, that is easier to reason about as resolving the specifier based on whatever the current state of import maps is, and we're going to close this. Thank you for flying TAG!