domenic
2019-01-18
Import maps allows control over what URLs get fetched by JavaScript import statements and import() expressions, and allows this mapping to be reused in non-import contexts. This solves a variety of important use cases, such as:
- Allowing “bare import specifiers”, such as
import moment from "moment", to work on the web - Providing fallback resolution, so that
import $ from "jquery"can try to go to a CDN first, but fall back to a local version if the CDN server is down - Enabling polyfilling of, or other control over, built-in modules
- Sharing the notion of “import specifiers” between JavaScript importing contexts and traditional URL contexts, such as
fetch(),<img src="">or<link href="">
Check out the linked explainer for more details, and some example code!
Currently this proposal has high community and browser vendor engagement, and we are looking to move it into WICG as a result:
- 389 GitHub stars, and lots of activity on the issue tracker
- Guy Bedford is helping with the spec and discussions, and has provided a polyfill as part of his ES module shims project.
- A maintainer of the yarn package manager has prototyped an import map generator (targeting an earlier version of the spec under the name import maps)
- It’s being prototyped in Chrome
- Good collaboration with TC39, including Apple, who is championing the JavaScript standard library proposal. There @littledan (from Igalia) mentions “@domenic 's import-maps proposal has been evolving well into a solution for all of the issues we discussed in this thread. It seems like a technically good solution to me.”
- Discussion at a TPAC breakout session (unfortunately unminuted) about built-in modules, among various members of the web community and browser vendors, was generally supportive.
Looking forward to folks feedback!
