Intent to implement and ship: import.meta.url
Sathya Gunasekaran
Contact emails
V8 implementation: gsa...@chromium.org, jan....@groupon.com
Blink implementation: hiro...@chromium.org
Spec: dom...@chromium.org
Explainer
https://github.com/tc39/proposal-import-meta/blob/master/README.md
Design doc/Spec
JavaScript-side spec: https://tc39.github.io/proposal-import-meta/
HTML-side spec: https://github.com/whatwg/html/pull/3141
TAG review: https://github.com/w3ctag/design-reviews/issues/208
V8 Design doc: https://docs.google.com/document/d/e/2PACX-1vSnp6wScoQ7ZzjHXevVSjtadSyCmYZs9ijLuPYwSODSFGwnw-O36gq-yLyaPy884NAhyke1IXuF_Dwb/pub
Summary
import.meta enables host environments to provide useful module-specific information, to code evaluating within a module. (It is only applicable inside module scripts, not classic scripts.)
Our plan is to start with the .url property on import.meta which will contain a string representing the current module’s base URL.
Motivation
import.meta.url allows easy resolution of resources relative to the module file. Without the URL available, resources can only be loaded relative to the current document. This is generally not useful for library authors, who bundle their resources with their modules which could be located anywhere relative to the current document.
Risks
Interoperability and Compatibility
This feature has no compatibility risk; it adds new syntax that would’ve previously been an error.
This is a stage 3 proposal, which per the TC39 process is the appropriate time to implement and ship.
Interoperability risk: this feature has general buy-in from all vendors' JavaScript engines via TC39. The below reflects the work of each vendor's web platform teams on integrating with the HTML-spec side.
Edge: No public signals
Safari: In development
Web developers: Positive
Interoperability tests: https://github.com/w3c/web-platform-tests/pull/7888
Ergonomics
N/A
Activation
This feature is easy to take advantage of, although like other new JavaScript features, using it in a way that also works in older browsers requires tooling (e.g. transpilers). Documentation should be light and focused on practical use cases. We anticipate it being used by libraries extensively, but it won't need a wrapper library itself.
Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?
Yes.
Is this feature fully tested by web-platform-tests?
Yes: https://github.com/w3c/web-platform-tests/pull/7888
Link to entry on the feature dashboard
https://www.chromestatus.com/feature/5637509807603712
Requesting approval to ship?
Yes.