search

WICG / import-maps

How to control the behavior of JavaScript imports
https://html.spec.whatwg.org/multipage/webappapis.html#import-maps
Other
2.66k stars 69 forks source link

Speculative parser and dynamic import maps #234

Closed annevk closed 3 years ago

annevk commented 3 years ago

For https://github.com/WICG/import-maps#dynamic-import-map-example it seems that a good speculative parser might also fetch my-library (parsed with the relevant base URL). This risk seems worth highlighting.

This also relates to #218.

domenic commented 3 years ago

Hmm, that'd be pretty surprising. Bare specifiers like 'my-library' have never (and will never) be treated as relative URLs. Before import maps, they were errors; after import maps, they require a lookup in the import map.

What would alleviate the concern here? A section spelling out how speculative parsers currently could work, and explaining how import maps change them?

annevk commented 3 years ago

The concern is with dynamic import maps and specifiers that are treated as relative URLs. You're right that my-library is a bad example. (It seems like static import maps could be supported by the speculative parser just fine.)

LarsDenBakker commented 3 years ago

Wouldn't this speculative parser already break today with patterns like this:

<!DOCTYPE html>
<html>
<head></head>
<body>

  <script>
    const base = document.createElement('base');
    base.href = '/base/';
    document.head.appendChild(base);
  </script>

  <script type="module">
    import './foo.js';
  </script>

</body>
</html>
domenic commented 3 years ago

@LarsDenBakker that's a good point, and I think you are right. I'd be curious if @annevk sees something we might be missing though.

Regardless, it speaks toward how it'd be a good idea to document the pitfalls of doing speculative parsing of JS module specifiers. Maybe formally as part of https://github.com/whatwg/html/pull/5959, and informally in a section in this repo's explainer?

annevk commented 3 years ago

Inserting a base element dynamically would indeed be another way of getting incorrect fetches. I suspect that's already the case in user agents today if you used <script src> for the second script element.

I'm not sure why that would be a pitfall for JS module specifiers though.