#746: import.meta.resolve()

Visit on Github.

Opened Jun 6, 2022

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).

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

Discussions

Discussed Jul 18, 2022 (See Github)

Lea: seems very incremental - something developers do frequently - pretty small feature, small abstraction.

Peter: Looking at the "sync vs async" discussion in the explainer. Whether import maps are loaded or not.

Lea: supposed to be syntactic sugar for what devs are doing already which is sync. So tending to agree with Domenic.

Peter: wonder if import maps haven't loaded yet what's the behavior? would you get an answer that's wrong?

Dan: leave that as a comment / question?

Peter: i can leave the comment.

Peter: [in the issue] a lot of background to the sync vs async decision. Seems like a lot of other dependencies on this. Not sure it's a simple thing.

Comment by @plinss Jul 18, 2022 (See Github)

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?

Comment by @domenic Jul 21, 2022 (See Github)

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.

Discussed Aug 22, 2022 (See Github)

can we progress it this week?

Peter: another sync vs. async feedback... To me this feels like - it makes sense to have it sync now but we'll probably regret it at some point.

Dan: is it satisfied with concerns? Or not resolved?

Peter: I don't know. Need Lea's feedback as well.

bumped to next week

Discussed Aug 29, 2022 (See Github)

punt to plenary

Discussed Oct 31, 2022 (See Github)

Dan: talked about this with Chris H. He wanted to know what he could do to help nudge this. Should we close it, or push more?

Lea: the issue is that this wouldn't work for externally loaded import maps which we don't yet have right?

Peter: yeah

Lea: but can you dynamically create a script element and append it with an import map? Then you have the same issue of import maps being created afterwards. If that works, and if you can create importa mpas at any point in time, even if this was async it still wouldn't account for that. So maybe it's okay that it's syntactic sugar over what authors can do already and therefore it's sync?

Peter: leaning toward it just being sync, a snapshot of the current state. TC39 already dealing with this. node shipped an async version and they're changing over to a sync version. I don't think we were complaining about it being sync, I think we were just curious about some behavioural issues.

Lea: looks like we're okay with this being sync? [leaves closing comment]

agreement to close

Comment by @LeaVerou Oct 31, 2022 (See Github)

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!