This repository was archived by the owner on Feb 26, 2025. It is now read-only.
Repository navigation
This repository was archived by the owner on Feb 26, 2025. It is now read-only.
External import maps support #235
Description
Currently external import maps are specified here, but in Chrome these still give the error:
External import maps are not yet supported.
I think it could be useful to clearly indicate in the spec that this is an optional feature of the implementation here, or possibly even split it out, given the current movements - especially when other browsers are being asked to consider implementation work.
Activity
domenic commentedon Oct 30, 2020
We're hoping to implement ASAP, although there may be a 6-week period where they aren't implemented.
guybedford commentedon Oct 30, 2020
Ok, if that's the plan then this can be closed certainly.
LarsDenBakker commentedon Jan 22, 2021
What's the current planning on this?
domenic commentedon Jan 22, 2021
@hiroshige-g, how's the external import maps implementation going?
guybedford commentedon Mar 3, 2021
@domenic thinking about the performance tradeoff here - does encouraging speculative fetching avoid the problem?
internettrans commentedon Mar 3, 2021
I put together some thoughts and a benchmark in this document about this topic: https://docs.google.com/document/d/1IxkNGRIUbvQ0P8Uig9jkFte5gACCn-Y9zO1P5acnE9s/edit#
internettrans commentedon Mar 3, 2021
One of my main points in that document:
canonic-epicure commentedon May 21, 2021
I believe "external" import maps of course needs to be supported. Its the developer's decision, which one to choose.
Just stumbled upon this issue. I thought Chrome supports import maps fully. Just when, oh when, web will finally switch to bunder-free development?
Spend whole day yesterday trying to make Snowpack to work with my app, trying Vite today. Keep filing github issues. Feel my pain. All I need is a simple bare specifier support in few places.
davidmarkclements commentedon Jul 7, 2021
hey everyone just bumping on this - do we have an updated eta on external import maps anywhere?
nenadvicentic commentedon Oct 8, 2021
Hi guys, are there any news on this front? Import maps served via API would give us more options/flexibility.
domenic commentedon Oct 14, 2021
We have continued to fail to gather enough implementation bandwidth in Chromium to ship external import maps, despite them being specified. At this point we're considering removing them from the spec, at least temporarily, and moving them to the "future extensions" section of the README for whenever we have time. Otherwise the spec is just misleading.
It would be helpful if people who want this feature were able to add a thumbs-up emoji to the original post here. That would help us track developer sentiment on this potential future extension, versus others.
frehner commentedon Oct 14, 2021
For clarity’s sake:
domenic commentedon Oct 14, 2021
Good questions.
I don't think anyone doesn't want to support this. Speaking for Chrome at least, the issue is that it's a good amount of work, and we have limited engineers. (E.g. the time I'm spending on import maps today is taking away time from app history, where I know you're also involved.) Nobody on the Chrome team is currently assigned to work on import maps.
I don't think we can give a concrete number. Rather, this is a question of us going to our bosses and saying "please assign an engineer to work on import maps". If we do that with 5 thumbs-up, it's pretty weak-sauce. If we do that with five thousand thumbs up, they're going to be excited about making that many developers happy, and probably give us the resources. I assume the real number will be somewhere in between.
There's also the issue that if we do get that engineer to work on import maps, how do we prioritize external import maps vs. the other future extensions listed in the README, or other open issues (which I'm working on triaging now)? For that, the relative weight of the thumbs-up on different issues can help, although of course it is only a factor and not some sort of binding ranking.
Yes. Specifying fiction is harmful to the ecosystem in a number of ways; it misleads developers about what's implemented, and it misleads implementers about what behaviors are solid and debugged and battle-tested. We try to make sure specifications are backed by implementations as part of the working mode for the WHATWG; although this is not a WHATWG spec yet, it hopes to one day graduate to become one.
frehner commentedon Oct 14, 2021
Thank you for the detailed response. 👍🏼
23 remaining items
FluorescentHallucinogen commentedon Nov 19, 2023
As an idea, what about a simple polyfill that takes external import map file and inline its content into HTML code? This would allow developers to use external import maps now. This could be implemented both in runtime and at build time (e.g. as a Rollup plugin).
FlippieCoetser commentedon Nov 19, 2023
@FluorescentHallucinogen I believe the challenge with the approach you outline is that any javascript that fetches an external file runs async, which runs only after the importmap has been loaded. Ideally, we need support by default for external importmap. Or am I missing something here?
FlippieCoetser commentedon Nov 19, 2023
@domenic, I noticed that in the second comment in the list, you provided an estimated timeline. Since it is a rather old comment, could you share your thoughts on when external import maps will be supported? No pressure; I want to calibrate my expectations. Such functionality will really be helpful.
domenic commentedon Nov 20, 2023
I have no estimate at this time.
FluorescentHallucinogen commentedon Nov 20, 2023
@FlippieCoetser
Not sure about run-time polyfill, but it's definitely possible at build-time (including serving project while developing). I've developed a dirty proof-of-concept, and it works! See modernweb-dev/web#2562 (comment) for more info. 😉
All tools I know (https://github.com/jsenv/importmap-node-module, https://www.npmjs.com/package/importly) generate import maps as external files.
BTW, maybe
nginxcan be configured somehow to inline/inject import map from an external file into theindex.htmlcode on the fly. 🤔nenadvicentic commentedon Nov 20, 2023
@FluorescentHallucinogen, what you are describing, is not browser polyfil. Your build-time polyfill is a build step, tied to a specific development environment and perhaps specific type of projects and/or project structure. Browser polyfill should be independent of backends and backend tools.
It is good to know that such tools exist, but let's not mix up build transformation step and discussion about general browser support of a feature.
hjabbing commentedon Dec 29, 2023
As a workaround, I point the import value to an index.js file where I re-export the modules (and versions) I want. That way I don't need to modify the page with the importmap which is out of my control, only the index.js which I do have control over. I'm aware that, once a single exported module is imported in the page, all modules are.
bitifet commentedon Feb 17, 2024
Regarding performance issues I understand that external import maps require an extra network request which may imply an unnecessary delay in SPAs
But in the case of multi page applications, from my point of view, that small delay in the landing page will be so worth having the rest of pages the user visit will just get it from cache...
I'm aware that nowadays most developers are tied to one or another framework all of them SPA based*, but MPA's do exist too and, in my opinion, they deserve our attention too.
(*) I myself love the SPA concept even I believe a mix of both worlds is possible (through multiple entry point SPAs and History API), but that's another history...
Anyway, don't take me wrong: I'm not voting for or against native support of external imports: I understand it could be a noteworthy amount of work and, hence, it's important to know if it's going to be useful to so many people beforehand.
But, even it can be polyfilled, it would imply the use of a bundler or, at least, some manual setup.
And bundlers are great, but they require an extra setup and maintenance effort and not all web applications are Facebook or Twitter. There are also lots of small apps that deserve to see the light and many times they doesn't just due to the time we need to invest in their initial setup.
In fact I got here while investigating the convenience of adding support for external import maps to esmrouter which is a small package I implemented to ease making all browser-enabled npm packages directly available client side in Express applications.
And, by the way, it works perfectly with inlined import maps. But I still feel like there's something missing... 😉
canonic-epicure commentedon Feb 18, 2024
The external import maps are the final step towards the bundlers-free web development. Such a shame, that step is still not done. After ~20 years of web/js existence, you still can not install your dependencies and run your code directly, w/o passing it through the bundlers "meat grinder".
The workflow that will hopefully exists one day, is simple: you run
npm iand in your setup, you specify to run some script after everynpm ithat will scan all deps and generate an import map file and store it near thepackage.json. Then in your web page, you just include that import map - and you can use your dependencies immediately.Bundlers should only be used for creating a production build of the app. Using bundlers for development is a legacy practice from the CommonJS times, which still dominates because of the lacking imports map support.
klebba commentedon May 30, 2024
Currently it seems that import maps simply will not work within a Chrome Extension context until this is addressed.
guybedford commentedon Jun 1, 2024
@klebba can you explain further the chrome extension issue here?
klebba commentedon Jun 6, 2024
Sure @guybedford —
Surprisingly it does not seem to be possible to declare an
importmapin a Manifest v3 browser extension context. Inlining theimportmapis disallowed by intrinsic CSP rules (even though the script content is JSON). Modifying theinnerHTMLortextContentof a<script>tag is also disallowed by the intrinsic CSP rules in Manifest v3. In seeking alternatives I found this perpetually disappointing thread.There is apparently no method for using an import map that functions today in a Manifest v3 Chrome Extension.
Related SO thread: https://stackoverflow.com/a/78557452
Oct 2020:
Oct 2021:
May 2024:
I guess we should expect the Chrome team will imminently implement this feature or risk enduring ever more thumbs up here?
devingfx commentedon Jul 13, 2024
internettrans commentedon Sep 30, 2024
For anybody looking for a workaround: import-map-injector is a 3kb npm package that supports external import maps by downloading them and then injecting them as a native inline import map
stopsopa commentedon Feb 23, 2025