-
Notifications
You must be signed in to change notification settings - Fork 55
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Multiple import maps #980
Comments
This is very exciting stuff! 😍 1 As a very initial comment, could you please add usage examples to the explainer (or a move it to actual, separate explainer) that show what design is actually being proposed? We simply don't have the bandwidth to be wading through pull request diffs to hunt this information down, and I really wouldn't want something like this to fall off our radar because of this. Footnotes
|
Thanks!! I added a usage examples section to the explainer.
Yup, totally understandable! Let me know if the above helps, or if you'd like me to pull the explainer to its own doc. (The current form felt more "discoverable", but happy to move it if that helps) |
@yoavweiss, at first glance, this looks great. We had a few questions:
|
I don't know if it needs support from this proposal directly, but I do think that the edge cases we talked about wrt inlined style modules that populate the module map are the same and should be handled consistently - probably by referring to common steps? The main edge cases are race conditions between an import from a module in the module graph, and the handling of an inline module (or dynamic import map here), ie a fetch of a module is in-flight while an inline entry for the module is discovered. Assuming this proposal specifies what happens in those cases, it'll be a big help for the inline modules proposal. |
Apologies! That part has changed as part of the PR review, and I failed to update the relevant part in the explainer. I agree that we can't get rid of non-determinism here entirely. As you say, async top-level modules where the import map is defined later may resolve their dependencies either before or after the map is processed. The same can be true for dynamic imports. At the same time, I wouldn't expect this to be a problem in practice:
Can you expand on this? I'm not following..
Injecting inline modules into the module map seems largely orthogonal to import maps. I played around with it a bit (as a prototype for some interesting loading experiments that I need to get back to), and I think the main question there is "how do we determine the specifier?". Once we've answered that, I don't know that it makes sense to use import maps to translate that specifier to a URL, where there is no such URL in practice.
While there are some similarities, relying on a specifier to be in the module map for resolution and defining specifier mapping in the import map seem like different problems, at least at first glance. For the latter, I think we can safely ignore rules which overlap with past import maps or past resolved modules. For the former, we'd need to decide what we do when the required modules are not (yet?) there at resolution time. |
OK, with respect to non-determinism, it would be good to have some text on that in the specification. Or even some way to manage it (can a script that performs dynamic loading test whether a particular import map has been seen?). The spec PR seems to be a little out of sync with what you just said (it's written in the usual impenetrable language, so I'm not 100% here) with what you say. It says something about the map being fixed and then propagated throughout each top-level module load.
I think that you indirectly answered this one with your non-determinism answer. My question, expanded: It appears as though there is a requirement that the map, once queried, cannot change. Does that apply only in cases where the query results in a successful resolution, or does it apply in other cases:
These are not particularly obvious to me from the explanatory material, though I'll admit to not having gone through all of your updated examples. |
Good catch. I removed that processing model, but left in an inaccurate note. I'll fix that.
Good points! The addition of a module to the resolved module set happens when the module is resolved, but before any import map rules are applied. That doesn't seem like what we'd want here. I'll change the addition to only happen after a successful import map resolution (if any). At the same time, for 404s, I don't think we should change future resolution for them, as they were properly resolved. |
Glad to be of assistance. Do you have any thoughts on providing assistance with managing any non-determinism? I missed a step above, but the idea is that if a script performing a dynamic load depends on the presence of a specific import map, how would it guarantee that the map has been seen and integrated? It seems like your resolution here would ensure that a missing mapping only gets committed once it is resolved (whether it fails or not), but that isn't ideal because a missing mapping would then permanently enter that state if the dynamic load acted before the mapping was in place. "Don't do that" is a perfectly fine response if there are obvious ways to manage that. |
Given that import maps are loaded synchronously (inline) that doesn't seem hard to manage from a developer perspective, as long as they control both pieces of code. But this is something we can add in the future as a function of developer demand.
My intention is to make it so that a failed resolution (missing mapping) doesn't get added to the "resolved module set", so that it can be added in the future. I'll push a commit to that effect shortly. |
whatwg/html@dd0ff09 handled that logic. I'd appreciate a review to see that we're aligned on this point. |
I don't know if I understand well enough to review. As far as I can see, you commit something if |
|
Thank you for the discussion. We're happy to see this proceed through the HTML review process. |
Thanks for reviewing!! :) |
こんにちは TAG-さん!
I'm requesting a TAG review of multple import maps (née "dynamic import maps").
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 the become a large blocking resource, as the entire map for all possible modules needs to load first.
This proposal is to enable multiple import maps per document, by merging them in a consistent and deterministic way.
Further details:
The text was updated successfully, but these errors were encountered: