Skip to content
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

Import maps #146

Open
annevk opened this issue Mar 14, 2019 · 3 comments

Comments

Projects
None yet
4 participants
@annevk
Copy link
Collaborator

commented Mar 14, 2019

Request for Mozilla Position on an Emerging Web Specification

This rather fundamentally impacts all fetching infrastructure and it's the way you'd polyfill lack of support for a JavaScript built-in module.

(It doesn't really feel like a primitive however as it's not necessarily available before the first fetch (e.g., one from a Link header), though perhaps if we'd delay those that could be made to work.)

@domenic

This comment has been minimized.

Copy link

commented Mar 14, 2019

This rather fundamentally impacts all fetching infrastructure

I think this is a bit strong :). Here's how I see it, referencing implementation staging notes in the explainer:

  • In "stage 1", with no import: URLs or HTTPS -> HTTPS fallback supported, this only impacts the resolve a module specifier algorithm, by adding a synchronous lookup to an already-parsed in-memory structure.
  • In "stage 2", with HTTPS -> HTTPS fallback supported, this gets trickier. One path is to make resolve a module specifier async and involve calling fetch-a-single-module-script repeatedly. Still not that bad, but a definite step up in complexity.
  • In "stage 3", with import: URLs, this adds a new entry to scheme-fetch (similar to blob: URL fetching steps) which consists of first calling resolve-a-module-specifier, then calling main fetch.

I apologize for this context being spread out throughout a few documents, plus in my head. I am hoping to get a real spec for at least stage 1 over the next week or two. But hopefully this helps explain why I don't think it's as fundamental of a change as all that.

I agree with your assessment that it's not a primitive. It's mainly a way of (a) controlling "resolve a module specifier; (b) via import: URLs, adding an easy way to call that algorithm from anywhere that accepts a URL, without having to go through JavaScript first.

@littledan

This comment has been minimized.

Copy link

commented Mar 15, 2019

(Not a Mozillian, but @annevk suggested I comment here.)

Overall, I like the import maps proposal. I think it does a good job of meeting its stated goals, and could be a good basis future mechanisms for more detailed declarative ways to invoke polyfills (c.f. whatwg/html#4432).

Some issues with active discussion from web developers about whether the goals of import maps are sufficient for their use cases:

  • tc39/proposal-javascript-standard-library#2 discusses requirements and strategies for polyfilling built-in modules; some polyfill maintainers suggest an imperative API for replacing built-in modules.
  • WICG/import-maps#92 discusses potential incremental loading techniques for import maps, including both through imperative APIs and through import maps distributed in HTTP headers of subresources.

Some of these features might be possible to add in follow-on proposals; the concern has been raised that the ability to remap non-bare specifiers might interfere with some future options.

@dbaron

This comment has been minimized.

Copy link
Member

commented Mar 29, 2019

also cc: @bholley

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.