Intent to Ship: import.meta.resolve()

Skip to first unread message

Domenic Denicola

Jun 30, 2022, 12:13:33 AM6/30/22
to blink-dev

Contact emails




import.meta.resolve(specifier) returns the URL to which the given 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).

Blink component


Search tags


TAG review

TAG review status



Interoperability and Compatibility

This feature has low interoperability and compatibility risk. Both Gecko and Safari are supportive, and it should be easy for all engines to implement. It is also quite simple and unlikely to change in the future. If it needs future extension, we can add an options bag as the second argument.

Gecko: Worth prototyping (

WebKit: Positive (

Web developers: Mixed signals (, In general web developers are positive on this addition. It is fulfilling a long-standing feature request and closing a gap with non-browser module systems. The Node.js core team has given negative signals as the synchronous import.meta.resolve() in the HTML Standard conflicts with their asynchronous import.meta.resolve(). See for a summary of that debate and links discussing Node's plans to align with the HTML Standard going forward.

Other signals:


This API will often be used in tandem with APIs to fetch the associated URL. It is also especially useful on pages that use import maps. This API will not make it hard for Chrome to maintain good performance. It exposes an existing simple algorithm, which if web developers were to emulate would involve lots of extra work on their part to parse the relevant import maps.


Polyfills for this feature would mostly take the form of module bundlers rewriting import.meta.resolve() calls, or possibly injecting `import.meta.resolve = ...` at the top of each module.


None. This exposes only information and code paths that were already available via more indirect means.

WebView application risks

Does this intent deprecate or change behavior of existing APIs, such that it has potentially high risk for Android WebView-based applications?



No special support needed.

Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?


Is this feature fully tested by web-platform-tests?


Flag name

Requires code in //chrome?


Tracking bug

Estimated milestones

No milestones specified

Anticipated spec changes

Open questions about a feature may be a source of future web compat or interop issues. Please list open issues (e.g. links to known github issues in the project for the feature specification) whose resolution may introduce web compat/interop risk (e.g., changing to naming or structure of the API in a non-backward-compatible way).

Link to entry on the Chrome Platform Status

This intent message was generated by Chrome Platform Status.

Yoav Weiss

Jul 6, 2022, 4:50:16 AM7/6/22
to blink-dev, Domenic Denicola

This seems like a small and useful addition, that has reasonable consensus behind it.

Mike Taylor

Jul 6, 2022, 9:07:35 AM7/6/22
to Yoav Weiss, blink-dev, Domenic Denicola
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to
To view this discussion on the web visit

Daniel Bratell

Jul 6, 2022, 9:33:08 AM7/6/22
to Mike Taylor, Yoav Weiss, blink-dev, Domenic Denicola
Reply all
Reply to author
0 new messages