External import maps support
Opened this issue · 39 comments
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.
We're hoping to implement ASAP, although there may be a 6-week period where they aren't implemented.
Ok, if that's the plan then this can be closed certainly.
What's the current planning on this?
@hiroshige-g, how's the external import maps implementation going?
@domenic thinking about the performance tradeoff here - does encouraging speculative fetching avoid the problem?
I put together some thoughts and a benchmark in this document about this topic: https://docs.google.com/document/d/1IxkNGRIUbvQ0P8Uig9jkFte5gACCn-Y9zO1P5acnE9s/edit#
One of my main points in that document:
External import maps can be controlled and cached separately from the HTML files that reference them, which allows for updating javascript resources without busting the cache for the main HTML resource.
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.
hey everyone just bumping on this - do we have an updated eta on external import maps anywhere?
Hi guys, are there any news on this front? Import maps served via API would give us more options/flexibility.
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.
For clarity’s sake:
- What is the main reason that implementers don’t want to support this?
- How many “thumbs up” would be required for it to be considered for staying in the spec? And for implementation?
- Is there any actual harm in keeping it in the spec even if it’s not implemented yet?
Good questions.
What is the main reason that implementers don’t want to support this?
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.
How many “thumbs up” would be required for it to be considered for staying in the spec? And for implementation?
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.
Is there any actual harm in keeping it in the spec even if it’s not implemented yet?
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.
Thank you for the detailed response. 👍🏼
FWIW Deno has an --import-map flag, that currently accepts a file path or a URL that allows to load both local and remote import map. I know this is not directly linked to the issue at hand but we found ability to load remote import maps useful. Thumbs up from me.
Hopefully there's been enough 👍 to indicate how valuable this feature is for developers, and maybe enough for a manager at Google to assign an engineer to implement it? (Wishful thinking 🙂 )
One of the most common reasons I saw as to why this is important was:
Being able to separate the import map from the HTML would greatly improve developer tooling; it's harder to update an inlined import map and then bust the cache for the HTML page than it would be to have a separate (purely JSON) import map that tools can easily parse and update. That also allows developers to have separate caching strategies for the HTML and the import map, where generally the HTML can essentially have a max-life TTL while the import map can have a shorter one (minutes?) so it can still be updated fairly regularly.
For context, I think the vast majority (+95% ?) of setups we see in single-spa community use a remote import map (through SystemJS) for these reasons.
[edit] Another key point is that remote import maps are sharable; in other words, if you have two websites, both of them can refer to the same import map. You can update a single import map and have those mappings updated at the same time for both websites. [/edit]
In any case, thank you for your work. 🙂
Another reason (which was not mentioned yet AFAIK) would be that, because the importmap is a script tag, you can't use an inline importmap if serving the page with a strict CSP, e.g. without the unsafe-inline keyword:
Refused to execute inline script because it violates the following Content Security Policy
directive: "script-src 'self'". Either the 'unsafe-inline' keyword, a hash ('sha256-...'),
or a nonce ('nonce-...') is required to enable inline execution.
To be consistent, I would rather have no inline script at all, even for the importmap.
I'm having an issue trying to understand why it would be that much work to make it work externally, like every other script tag works internal or external. The only difference here is verifying the content-type of application/importmap+json being returned. It's not reinventing the wheel.... unless chrome is a pile of spaghetti and it is reinventing the wheel.
This isn't "formally" an external importmap, but it works:
test.htm:
<html>
<head>
<script src="./importmap.js"></script>
<script type="module">
import 'my-library'; // will fetch the randomly-chosen URL
</script>
</head>
<body>
</body>
</html>
importmap.js:
const im = document.createElement('script');
im.type = 'importmap';
im.textContent = JSON.stringify({
imports: {
'my-library': Math.random() > 0.5 ? '/path1.js' : '/path2.js'
}
});
document.currentScript.after(im);
I've also found that this does not work with importmaps, though I should probably open a separate issue for this:
<link rel="modulepreload" href="my-library">
This always loads "my-library" verbatim instead of what the importmap depicts.
This breaks some bundlers, like vite, which injects a number of modulepreloads.
{
"imports": {
"a": "/a-1.mjs",
"b": "/b-1.mjs",
"c": "/c-1.mjs"
},
"scopes": {
"/scope2/": {
"a": "/a-2.mjs"
},
"/foo/": "/foo.map.json"
}
}I think external maps should be allowed for different scope.
@masx200 specifically defining scope boundaries for externalization is a nice thought! That said, import map resolutions cannot be individually asynchronous therefore allowing specific resolutions to trigger and wait on async import map fetching work is not possible.
{
"externals":{
"http://example.com/foo/":"http://example.com/foo/import_map.json"
},
"imports": {
"a": "http://example.com/a/mod.mjs",
"scope2/": "http://example.com/scope2/",
"foo/":"http://example.com/foo/"
},
"scopes": {
"http://example.com/scope2/": {
"b": "http://example.com/b/mod.mjs"
}
}
}Has any decision been made on whether external import maps will be supported?
I am using Importmaps as in the below example:
<!doctype html>
<html>
<head>
<title>Demo</title>
<link rel="icon" href="favicon.ico" type="image/x-icon">
<link rel="stylesheet" href="html.style.css">
<script type="importmap">
{
"imports": {
"@browser-modules/dictionary": "../node_modules/@browser-modules/dictionary/lib/dictionary.js",
"@browser-modules/events": "../node_modules/@browser-modules/events/lib/events.js",
"@browser-modules/component.library": "../node_modules/@browser-modules/component.library/lib/library.js",
"@browser-modules/machine": "../node_modules/@browser-modules/machine/lib/machine.js",
"@browser-modules/web.component": "../node_modules/@browser-modules/web.component/lib/component.js",
"@browser-modules/buttons": "../node_modules/@browser-modules/buttons/lib/buttons.js"
}
}
</script>
</head>
<body>
<script src="index.js" type="module"></script>
<task-bar></task-bar>
</body>
</html>However, I realize that the list of imports will soon be extensive, and instead, I prefer to use external import maps.
Can anyone tell me if this GitHub issue will be addressed?
We're hoping to implement ASAP, although there may be a 6-week period where they aren't implemented.
I am LOVING the optimism of this 3-year old comment 😂
Just adding my voice those eagerly awaiting this feature 👀
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).
@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?
@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.
I have no estimate at this time.
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.
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 nginx can be configured somehow to inline/inject import map from an external file into the index.html code on the fly. 🤔
@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.
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.
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... 😉
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 i and in your setup, you specify to run some script after every npm i that will scan all deps and generate an import map file and store it near the package.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.
Currently it seems that import maps simply will not work within a Chrome Extension context until this is addressed.
@klebba can you explain further the chrome extension issue here?
Sure @guybedford —
Surprisingly it does not seem to be possible to declare an importmap in a Manifest v3 browser extension context. Inlining the importmap is disallowed by intrinsic CSP rules (even though the script content is JSON). Modifying the innerHTML or textContent of 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:
We're hoping to implement ASAP, although there may be a 6-week period where they aren't implemented.
link
Oct 2021:
Nobody on the Chrome team is currently assigned to work on import maps.
link
May 2024:
Manifest V2 phase-out begins
link
I guess we should expect the Chrome team will imminently implement this feature or risk enduring ever more thumbs up here?
+1 for the pain of chrome extension CSP !
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