(seeking clarification) Why was support for multiple import maps dropped?

[internettrans]

Support for multiple import maps was dropped back in August in 6f99d47#diff-04c6e90faac2675aa89e2176d2eec7d8.

Before that time, a lot of progress had been made on the merge algorithm, order/priority of the merge, acquiring import maps boolean, etc, so I was disappointed to see that go away. However, I also can understand the desire to make the initial version of the spec as minimal as possible so that the spec is easier for browsers to decide on.

My question is if the change in 6f99d47#diff-04c6e90faac2675aa89e2176d2eec7d8 was related to feedback, and if so, who gave the feedback and what was it?

[domenic]

My question is if the change in 6f99d47#diff-04c6e90faac2675aa89e2176d2eec7d8 was related to feedback, and if so, who gave the feedback and what was it?

This change resulted from several factors:

• I believe that built-in modules are harmful for the web, and will not be developing import maps in a way that supports them. Thus, I removed all built-in modules support.
• With built-in modules gone, the remaining fallback support was only about HTTPS -> HTTPS fallbacks. Since HTTPS -> HTTPS fallbacks were not specced and had many open questions with unclear answers, they instead moved to the "further work" section.
• With built-in modules gone, multiple import maps become less urgent, as they are no longer necessary to preserve some of the virtualizability goals expressed in Cascading Import Map Resolution #137. They are still nice to have, but they are in the same category as many other nice-to-haves, so they too moved to "further work".

Given that this spec work has dragged on for 1.75 years with nothing shipped in browsers, at this point we need to slim down as much as is possible to see if this idea is even feasible to ship anywhere, so moving things from the initial version to future work is an important tool in the toolbox.

I hope this helps.

[internettrans]

With built-in modules gone, multiple import maps become less urgent, as they are no longer necessary to preserve some of the virtualizability goals expressed in #137. They are still nice to have, but they are in the same category as many other nice-to-haves, so they too moved to "further work".

Interesting - I had not read through the cascading import maps proposal well enough to really understand virtualization of built-in modules. Thanks for the links and explanations about fallbacks and multiple import maps.

For me, multiple import maps have been a way of combining an external import map with an inline import map, with the advantage being that the external import map can be controlled / maintained outside of my source code while the inline import map in my source code can fine tune or override things (example). It would be a bummer for me if browsers did implement import maps without that ability, but I concede that this likely falls into the "nice to have" category and is perhaps not as compelling as virtualization was/is.

Given that this spec work has dragged on for 1.75 years with nothing shipped in browsers, at this point we need to slim down as much as is possible to see if this idea is even feasible to ship anywhere, so moving things from the initial version to future work is an important tool in the toolbox.

Fair enough - slimming the proposal for that purpose makes a lot of sense to me. I am quite hopeful that import maps are embraced and implemented by browsers - I think import maps (or whatever spec ends up being embraced) are crucial for many tools and devs to start using in-browser modules at all in their production applications.