Comments (16)
As mentioned in the readme, package name maps, like service workers, are an app-level thing, controlled by the app developer. Pulling in third-party "modularized" package name maps dynamically is not a use case we'll be supporting.
We can support multiple package name maps, but only if they're all loaded before any modules on the page are loaded. The page author needs to take responsibility for pulling them all in ahead of time when creating their page.
from import-maps.
What happens if a packagemap is created while modules are being loaded? Do you block further loading? or do you just block new module scripts? If the latter there could be module identifiers in both trees that will possibly load different modules.
From prior experience with systems like RequireJS which do allow this: being able to remap modules dynamically has the potential to open up a hornets nest of edge cases created by race conditions that you probably don't want to invite into the system.
The cop-out solution seems most appropriate here: just not to allow it all. Demand that dynamic maps are emitted and registered before module loading starts, and have any attempts to register a package map once module loading has already started simply throw an error.
from import-maps.
Not having a way to load additional package maps ruins modularization, in asynchronous loading scenarios. I'm not talking about remapping existing aliases, but to add new ones.
from import-maps.
The exact semantics for how you can generate import maps via JavaScript are now specified in some detail in the proto-spec. (Basically: you can do so, as long as you do so before any imports ever occur.) So, let me close this.
Nevertheless, my previous comment holds about the use cases we're interested in supporting.
from import-maps.
Agreed this seems useful.
Would this be assuming multiple package name maps support as well?
from import-maps.
This seems problematic. What happens if a packagemap is created while modules are being loaded? Do you block further loading? or do you just block new module scripts? If the latter there could be module identifiers in both trees that will possibly load different modules.
from import-maps.
@matthewp good points... it would be important to carefully define this - if this were restricted to inline packages maps populated synchronously (and not source-based) then there would be no need to have any blocking behaviour, and we could continue to throw for unknown maps.
Basically an online code sandbox would benefit from being able to inject the mappings it needs before injecting the sources.
Edit: in addition to the use cases described above
from import-maps.
If it isn't possible to cleanly separate the time to generate the dynamic map, and for module loading to begin, I agree it does seem problematic. I'm fine with this being closed if it seems at all problematic.
from import-maps.
Let me add a use case to further elaborate on (what I think) @dcleao is suggesting.
The problem with a static packagemap is that I need to know the entire tree when my page is loaded. This works fine if I use npm to install all my packages and can generate a tree.
But a more user-friendly way is to just import my own modules and then load 3rd party pacakges from a CDN.
<script type="packagemap">
{
"packages": { ... },
"scopes": { ... }
}
</script>
<script type="module">
import { main } from './main.mjs';
import { toClipboard } from 'https://cdn.jsdelivr.net/npm/copee/dist/copee.mjs';
main(toClipboad);
</script>
Now imagine that copee.mjs
makes imports to bare specifiers but it's packagemap is not known without reading https://cdn.jsdelivr.net/npm/copee/dist/packagemap.json
.
Is the solution here to just include a reference to https://cdn.jsdelivr.net/npm/copee/dist/packagemap.json
before importing the module and hopefully the whole (sub) tree is defined?
from import-maps.
The thing is that the need for, and location of, the copee module is only known at runtime.
(edit: I meant that the need for loading copee
is only known at runtime, however, a map entry that resolves to its location is known at write time. What would not be known at write time would be the additional package map entries that it has for its own internal use, and that would only be loaded when the package itself was loaded too)
from import-maps.
The thing is that the need for, and location of, the copee module is only known at runtime.
The need not being known in advance; sure. In some scenarios that will be the case. E.g. when applying dynamic polyfills, that can depend on what features the subject browser supports and what features it does not. But shouldn't you atleast know the location of the polyfills à priori in such a case?
Maybe async / dynamic loaded modules are one of those scenarios where different sub-contexts for package maps would make sense? That is: you can add a package map dynamically, but it can only attach to an async 'entry point' module when it is not loaded yet, where it will only apply to module resolution for modules that are directly or indirectly loaded by that specific entry point module and no other.
from import-maps.
Perhaps, I'm not into the technical details of how this could be achieved.
However, I'm not talking about polyfills, but of, for example, plugins of a system, which are loaded on demand, and which are so many that it would be infeasible to load/know, a priori, more than their entry points. When loaded, each may carry a package map that deals with its innards.
from import-maps.
If you know the locations of those plugins' entry points and also know the location of their package maps as relative to those entry points... then you can also at build-time pull in the constituent package maps and assemble the complete one.
(Assuming stable versioning where file structere for each plugin is never modified, atleast.)
from import-maps.
That's too bad :-( I really think that it is an essential feature...
And I don't understand why you don't recognize it, or at least discuss it. It seems that you just dismiss it... Am I missing/misunderstanding something?
Is it a way to start simple?
Is it a use case that you don't recognize as real?
Hasn't anybody else presented this use case?
I don't understand.
from import-maps.
@rjgotten like you say, while you could build a package map at the server containing all of the package maps, up front, I don't think that that would be an efficient solution, as it would result in an arbitrarily big package map.
Additionally, that solution requires the use of a build tool and I think it would be valuable if it were possible to do this by just placing files in certain locations (and registering the entry points somehow).
from import-maps.
SystemJS is moving ahead with dynamic import map loading because this is a necessary feature for our users.
I have put together a rough specification approach in https://github.com/guybedford/import-maps-extensions#lazy-loading-of-import-maps detailing how we ensure immutable import map extension.
Further discussion on this topic or specs here would be very welcome.
from import-maps.
Related Issues (20)
- Modulepreload error caching HOT 9
- Should HTMLScriptElement.supports("importmap") return true? HOT 1
- Fire a load event or an error event when the script element of the import map is from an external file? HOT 2
- preparation-time document check should be done first at #register-an-import-map HOT 2
- Throwing TypeError in resolve a module specifier? HOT 2
- calling onerror of the script element if the import map string cannot be parsed HOT 1
- What should 'parse an import map string' return when it throws an Error? HOT 8
- Speculatively parsing with import map if there's a dynmic import before, HOT 4
- Official file extension? HOT 2
- Support stars in imports besides trailing slashes HOT 1
- `importmap` cannot resolve dependencies entered relatively. HOT 3
- [feat] `script.integrity` and import map HOT 2
- Specification is not restricting address from containing query- or fragment parts not ending with "/" HOT 3
- global variables (f.e. map `"jquery"` specifier to `globalThis.jquery` variable) HOT 1
- Specify package.json path in <script>, and then generate the import map from package.json. HOT 7
- Unable to create folder alias to use in further alias. HOT 2
- ability to specify a default extension for extensionless URLs HOT 3
- Fallbacks for failed URLs? HOT 1
- import maps for `import()` statements HOT 1
- Support for "package.json browser" style file replacement/removal within modules? HOT 2
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from import-maps.