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

Split into fetch-maps and import-maps? #211

Closed
jakearchibald opened this issue Feb 25, 2020 · 13 comments
Closed

Split into fetch-maps and import-maps? #211

jakearchibald opened this issue Feb 25, 2020 · 13 comments

Comments

@jakearchibald
Copy link

jakearchibald commented Feb 25, 2020

I liked the import: proposal, but making (for example) a CSS image go through an import map felt a little backwards.

Should import-maps be design solely to handle JS module names, whereas another proposal, fetch-maps would handle general URL mapping.

This means import-maps would be mostly used for bare modules (including the prefix feature). Whereas fetch-maps would handle the hash cascade issue. In fact, you could say that import-maps only work for bare modules.

If both an import map and a fetch map existed for a client, the import map would be consulted first, then the fetch map.

This would also remove the Remapping doesn't work for <script> gotcha.

@domenic
Copy link
Collaborator

domenic commented Feb 25, 2020

I'm a little confused by this issue. Import maps are designed soley to handle JS module specifiers.

The issue of handling only bare JS module specifiers was discussed and rejected in #198

@jakearchibald
Copy link
Author

My favourite feature of import-maps is the ability to "map away hashes in script filenames", but this isn't just a problem for script, it's a problem for any resource that references other resources.

In previous versions, import maps proposed solving this using import: urls:

<script type="importmap">
{
  "imports": {
    "/some-script.js": "/some-script.abc123.js",
    "/some-styles.css": "/some-styles.def456.css",
    "/bg.png": "/bg.321cba.png"
  }
}
</script>
<script>import '/some-script.js';</script>
<link rel="stylesheet" href="import:/some-styles.css">

And the CSS:

html {
  background: url('import:/bg.png');
}

I like that this solves the problem, but it seems weird having CSS go via an import map for a background image.

It feels like a more generic "fetch-map" would be less indirection. That leaves import-maps to handle the JS specific stuff.

@domenic
Copy link
Collaborator

domenic commented Feb 25, 2020

import: is no longer part of the proposal, to be clear.

JS is somewhat unique in the web ecosystem in having deep dependency trees, which makes the hashes-in-filenames problem so acute there. Although in theory there can be deep dependency trees of @imports in styles, we don't see that in practice.

@jakearchibald
Copy link
Author

import: is no longer part of the proposal, to be clear.

Yeah, I'm just worried it might feel odd later when we realise we need to solve the same problem for non-JS things.

JS is somewhat unique in the web ecosystem in having deep dependency trees

Sure, but as soon as one of those deep JS resources references an image, font, style, whatever, you've invalidated the tree.

@jkrems
Copy link
Contributor

jkrems commented Feb 25, 2020

Sure, but as soon as one of those deep JS resources references an image, font, style, whatever, you've invalidated the tree.

One example of a potentially common JS-refs-CSS case would be lazy loaded components that may have to reference associated styles (assuming they don't inline all styles in the JavaScript). That's where the issue becomes roughly as big as for scripts.

@developit
Copy link

The decision to limit import maps to JS specifiers seems like it might have to change if imported CSS subresources participate in the module graph (via the module-attributes proposal). If they do, I would imagine folks would expect them to also be covered by import maps.

@domenic
Copy link
Collaborator

domenic commented Feb 25, 2020

To be clear, any import statements or import() expressions use import specifiers, and would be impacted by import maps. It doesn't matter whether they're referencing JS or CSS or whatever. (Assuming non-JS module types ever become a real thing.)

@sashafirsov
Copy link

sashafirsov commented Feb 25, 2020

For some reason developers are focusing only on single side of imports, whether is JS module or css as here. In my reality I never seen cdn or release deployment comprise only few file types. In addition to binary JS, there are css and images of all kind/resolution, source maps and sources themselves, all kind of metadata...
And when we talk about importmaps the dependencies of all types to me are the subject of coherent treatment by url mapping and dependency by import.
Hence the talks specific to js modules applicable to any kind resources including non-module JS, images, etc.
There is a separate thread on waterfall effect when more libs brought to page which make pre-loaded config huge. Treating types separately will increase meta size even more.

@domenic
Copy link
Collaborator

domenic commented Feb 25, 2020

I'll close this as the discussion is starting to meander and this doesn't seem to bring any new points that weren't previously discussed and decided in #198.

@domenic domenic closed this as completed Feb 25, 2020
@guybedford
Copy link
Collaborator

I liked the import: proposal, but making (for example) a CSS image go through an import map felt a little backwards.

@jakearchibald can you dig into this a bit more?

It does seem from this discussion that it would be useful to see import: moving forward for these use cases.

I'm not sure where the best place would be to continue with work on this though.... a direct HTML spec PR?

@domenic
Copy link
Collaborator

domenic commented Feb 25, 2020

(I think generally it's good to try to gather interest for new proposals in a separate repository, issue, or WICG Discourse thread before proceeding directly to the pull request stage.)

@bicknellr
Copy link

w.r.t. import: + procedurally created stuff: IMO, it would be better to abandon fallbacks in this proposal, make import.meta.resolve synchronous, and tell people to interpolate import.meta.resolve(specifier string) with when they're building HTML strings (or JSX, etc.) from 'inside' a JS module. For other proposed module types (HTML, CSS), the module itself provides a clear path / clear relationship to the import map against which (something like) import: URLs in things created declaratively in module's source text could be resolved; as opposed to things created procedurally 'by' a JS module which won't have that clear context unless some pretty heavy magic is involved. (Where 'magic' here is roughly the "inspect the call stack" thing which I think this spec had at one point and was removed.)

@jakearchibald
Copy link
Author

I've made a proposal at https://discourse.wicg.io/t/proposal-fetch-maps/4259

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

7 participants