Repository navigation
Fallback Support Removed in Import Maps #385
Description
Activity
My personal take is: As long as we can map the data in
exportsto a reasonable "today import map", assuming a modern build tool, we shouldn't be blocked by import map iterations. We'll hopefully be able to leverage future features in import maps themselves (potentially even using them directly in node) but for now we have good reasons to support existing use cases covered by require & today's ecosystem.Is one possible reading of your 2nd question "Should we rename
exportstoentriesto officially disassociate them from import maps?"? I'd still hope that we would keep it "import maps compatible" but I can see the appeal.Aside: By "import maps compatible" I mean that with environmental data like a
browserslistandprocess.envvalues etc. a tool could turn the data into a simple string-to-string import map to be used in a browser.The name doesn’t tie us to compatibility with import maps; users will expect parity regardless of what it’s named.
I think keeping the array syntax makes sense solely because we can’t safely add it later, and import maps will likely still end up with it eventually.
I think while
importmaprelates to the target,exportsrelate to the module system(s).There have been no objections to leaving this is in, so let's go with that for now. We can reopen this discussion at any time as well.
Import Maps are currently being stripped down to a more minimal spec an implementation. See the in-progress PR here - WICG/import-maps#176, which removes support for array fallbacks.
We've currently followed the import maps spec compatibility by allowing
"exports"targets to be arrays following the similar fallbacks pattern, but this should be reconsidered now that import maps are changing.My concern though is that I think it is important that it should be possible to use
"exports"to provide mappings that are browser-specific, and previously this was being marked to be implemented through an array fallback-like approach.See for example, the package targets proposal which was aiming to fill this gap - https://github.com/guybedford/proposal-pkg-targets#target-maps.
If we ship
"exports"without a way to provide browser-specific exports, then we would effectively be encouraging userland to come up with solutions like"exports.browser"etc etc. which ends up causing the same issue as the"main"-proliferation issue we had before.Questions: