import.meta.url does not include fragments

[Constellation]

While upgrading WebKit module loader, @youennf noticed that we are using response's url when creating module-script[1].

Let module script be the result of creating a module script given source text, module map settings object, response's url, and options.

However, response's url does not include fragments[2,3]. This means, import.meta.url does not include fragments, and this behavior does not agree with what WPT is testing[4].

Shouldn't we include fragments in import.meta.url? Or should we do that by fixing the current HTML spec? I'm thinking that we should expose fragments because each module w/ URL+different fragments is distinct. But this means we cannot use response's url for import.meta.url in the HTML spec though.

/cc @domenic

1: https://html.spec.whatwg.org/multipage/webappapis.html#fetch-a-single-module-script
2: https://fetch.spec.whatwg.org/#ref-for-response-url
3: https://fetch.spec.whatwg.org/#response-url
4: https://github.com/web-platform-tests/wpt/blob/master/html/semantics/scripting-1/the-script-element/module/import-meta/import-meta-url.html#L54-L57

[wanderview]

I think there might be a bug in the fetch spec at [3] above since @annevk landed a change to explicitly start allowing fragments:

whatwg/fetch@53de36a

[domenic]

Yeah, the intention is to include the fragment. There is even a test for it. https://wpt.fyi/results/html/semantics/scripting-1/the-script-element/module/import-meta/import-meta-url.html?label=master&label=experimental&aligned&q=script

This was previously discussed in #3622.

I will assign to @annevk to update [3] since it seems like the processing model is generally correct and includes the fragment, it's just that the text in [3] is not updated.

[Constellation]

Thanks!

since it seems like the processing model is generally correct and includes the fragment, it's just that the text in [3] is not updated.

This makes sense :)

[annevk]

@wanderview that commit is part of an open PR at whatwg/fetch#696 and an open issue at whatwg/fetch#505. I'm not really sure why that did not move forward. It might have happened because I moved countries, nobody else cared, and I forgot about it. (There's various test PRs linked that do not have review.)

[dcleao]

@Constellation, I wonder why you say:

I'm thinking that we should expose fragments because each module w/ URL+different fragments is distinct.

If the network layer ignores fragments to fetch module files, then how can modules with different fragments be distinct? Is this a way to enable instantiating a module many times and the fragment serves as arguments to the module?

[dcleao]

Ok, so light has come to my mind...

I checked and classical scripts can use console.log(new URL(document.currentScript.src).hash) to know the fragment which was used to instantiate the script. In the network tab, however, I only see one network access for the script, even if I write several <script> tags with different fragments (at least for when loading scripts in a web server; for local html and JS files, the script was fetched every time...).

Now, for module scripts, this capability is way more powerful, as these can export values. If no additional network fetches are really made, then... this is almost like AMD loader plugins...

// consumer.js
import bundle from "./i18n.js#path=a/b/c");

// i18n.js
const args = new URL(import.meta.url).hash;
const path = ...;
const locale = ...;
const bundle = await fetch(...);

export bundle;

I wonder if this was intended...

Now, what puzzles me is why the example in https://html.spec.whatwg.org/multipage/webappapis.html#module-map says:

the following code will create three separate entries in the module map, since it results in three different URLs:

import "https://example.com/module.mjs";
import "https://example.com/module.mjs#map-buster";
import "https://example.com/module.mjs?debug=true";

That is, URL queries and fragments can be varied to create distinct entries in the module map; they are not ignored. Thus, three separate fetches and three separate module evaluations will be performed.

Why 3 separate fetches and not 2? The first two imports are the same "web resource", no? Isn't this example incorrect, in the spec?

Now, if only import maps allowed bare names with fragments, this would really be useful:

// consumer.js
import bundle from "@my/i18n#path=a/b/c");

For reference:

• What paths are allowed? WICG/import-maps#10
• Propagation of search/hash fragments WICG/import-maps#38
• Values with trailing slashes not in path part WICG/import-maps#173

[annevk]

The Fetch PR landed and fragments are generally preserved now.