Contact emailsyoavwe...@chromium.org Explainerhttps://github.com/whatwg/html/pull/10528#issue-2437162429
Specificationhttps://github.com/whatwg/html/pull/10528 Summary Import maps currently have to load before any ES module and there can only be a single import map per document. That makes them fragile and potentially slow to use in real-life scenarios: Any module that loads before them breaks the entire app, and in apps with many modules they become a large blocking resource, as the entire map for all possible modules needs to load first. This feature is to enable multiple import maps per document, by merging them in a consistent and deterministic way. Blink componentBlink>HTML>Modules <https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3EHTML%3EModules> Motivation Import maps in their current form provide multiple benefits to web developers. They enable them to avoid cache invalidation cascades, and to be able to work with more ergonomic bare module identifiers, mapping them to URLs in a convenient way, without worrying about versions when importing. At the same time, the current import map setup suffers from fragility. Only a single import map can be loaded per document, and it can only be loaded before any module script is loaded. Once a single module script is loaded, import maps are disallowed. That creates a situation where developers have to think twice (or more) before using module scripts in situations that may introduce import maps further down in the document. It also means that using import maps can carry a risk unless you’re certain you can control all the module scripts loaded on the page. Beyond that, the fact that import maps have to be loaded before any module means that the map itself acts as a blocking resource to any module functionality. Large SPAs that want to use modules, have to download the map of all potential modules they may need during the app’s lifetime ahead of time. Initial public proposalhttps://github.com/whatwg/html/pull/10528 TAG reviewhttps://github.com/w3ctag/design-reviews/issues/980 TAG review statusPending Risks Interoperability and Compatibility None *Gecko*: No signal <https://github.com/mozilla/standards-positions/issues/1058> *WebKit*: No signal <https://github.com/WebKit/standards-positions/issues/381> *Web developers*: Shopify developers would need this in order to use ES modules proper. I haven't yet gathered a signal beyond that. *Other signals*: WebView application risks Does this intent deprecate or change behavior of existing APIs, such that it has potentially high risk for Android WebView-based applications? None Debuggability None Is this feature fully tested by web-platform-tests <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md> ?Not yet, but it will be Flag name on chrome://flagsNone Finch feature nameNone for now, but I'd add a flag before shipping. Non-finch justificationNone Requires code in //chrome?False Estimated milestones No milestones specified Link to entry on the Chrome Platform Status https://chromestatus.com/feature/5121916248260608?gate=5075513421594624 This intent message was generated by Chrome Platform Status <https://chromestatus.com/>. -- You received this message because you are subscribed to the Google Groups "blink-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscr...@chromium.org. To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOmohSJrxQj19LattoOyE3Af5dn%3D50UD9ecpHZWjVZ5-GrMr9w%40mail.gmail.com.
