External import maps support

[guybedford]

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.

[domenic]

We're hoping to implement ASAP, although there may be a 6-week period where they aren't implemented.

[guybedford]

Ok, if that's the plan then this can be closed certainly.

[LarsDenBakker]

What's the current planning on this?

[domenic]

@hiroshige-g, how's the external import maps implementation going?

[guybedford]

@domenic thinking about the performance tradeoff here - does encouraging speculative fetching avoid the problem?

[jolyndenning]

I put together some thoughts and a benchmark in this document about this topic: https://docs.google.com/document/d/1IxkNGRIUbvQ0P8Uig9jkFte5gACCn-Y9zO1P5acnE9s/edit#

[jolyndenning]

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.

[canonic-epicure]

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]

hey everyone just bumping on this - do we have an updated eta on external import maps anywhere?

[nenadvicentic]

Hi guys, are there any news on this front? Import maps served via API would give us more options/flexibility.

[domenic]

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]

For clarity’s sake:

1. What is the main reason that implementers don’t want to support this?
2. How many “thumbs up” would be required for it to be considered for staying in the spec? And for implementation?
3. Is there any actual harm in keeping it in the spec even if it’s not implemented yet?

[domenic]

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.