Intent to Ship: import.meta.resolve()
Domenic Denicola
Contact emails
dom...@chromium.orgExplainer
https://gist.github.com/domenic/f2a0a9cb62d499bcc4d12aebd1c255abSpecification
https://html.spec.whatwg.org/#hostgetimportmetapropertiesSummary
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
Blink>JavaScriptSearch tags
import, modules, esmTAG review
https://github.com/w3ctag/design-reviews/issues/746TAG review status
PendingRisks
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 (https://github.com/mozilla/standards-positions/issues/647#event-6817757001)
WebKit: Positive (https://github.com/WebKit/standards-positions/issues/2#event-6907169928)
Web developers: Mixed signals (https://github.com/whatwg/html/issues/3871,https://github.com/whatwg/html/pull/5572) 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 https://gist.github.com/domenic/f2a0a9cb62d499bcc4d12aebd1c255ab#sync-vs-async for a summary of that debate and links discussing Node's plans to align with the HTML Standard going forward.
Other signals:
Ergonomics
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.
Activation
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.
Security
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?
None
Debuggability
No special support needed.
Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?
YesIs this feature fully tested by web-platform-tests?
YesFlag name
Requires code in //chrome?
FalseTracking bug
https://bugs.chromium.org/p/chromium/issues/detail?id=1296665Estimated 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
https://chromestatus.com/feature/5086507990777856
Yoav Weiss
Mike Taylor
--
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 blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/a3c6636e-3255-449b-ba9f-96c8c308b6ben%40chromium.org.
Daniel Bratell
LGTM3
/Daniel
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/a0d49eb8-174c-6f5a-a1ea-535149226520%40chromium.org.