Handling of symlinks / redirects

[guybedford]

How would this spec plan to implement 301's and symlinks?

Ideally we should ensure that there is alignment with the way the HTML module tag is implementing this based on its requestURL and responseURL. Is this parity important?

[guybedford]

Ideally a redirect could just be a transparent proxy module in the registry, like an export * with default?

[caridy]

I'm not sure yet if this is important or not, without thinking too much about it, I think parity is important because we don't want to attempt fetching an already existing entry from the registry, and preserving the state-fullness of the module instance itself, instead of having two module records for it.

As for the transparent proxy, a "proxy" is probably the wrong term here, just remember we can have the same ModuleStatus object twice in the same registry :)

[domenic]

HTML's current proposed strategy is to use the request URL as the key in the memoization map. The following are cases that need to generally be considered:

• A: request1.js and request2.js both redirect to response.js
• B: request.js redirects to response1.js the first time it is fetched and response2.js the second time it is fetched

(maybe I am missing some, but I think all problematic cases can be reduced to these...)

The consequence of this in HTML right now is that in case A, given a module that imports both request1.js and request2.js, there will be two distinct module records and the side effects will happen twice. Case B will always evaluate response1.js and response2.js will never be fetched or evaluated.

This seems somewhat OK. You might envision a scheme that tries to avoid the duplicates in case A, but I think it screws up case B. And you can argue that if an author actually writes their code to do import "./request1.js" and import "./request2.js" they should not be surprised if this gives them two different module records.

---

As a separate issue, HTML uses the response URL as the base URL for resolving relative specifiers. This seems necessary; using the request URL would end up just weird. See whatwg/html#443 (comment). This might seem inconsistent with using request URLs as keys, but in the end I think they're pretty unrelated, and the behavior is not surprising.

[guybedford]

As a separate issue, HTML uses the response URL as the base URL for resolving relative specifiers. This seems necessary; using the request URL would end up just weird. See whatwg/html#443 (comment). This might seem inconsistent with using request URLs as keys, but in the end I think they're pretty unrelated, and the behavior is not surprising.

If responseURL is being used as the relative resolution URL, that is something that is not captured by this spec at all, and would need to be integrated as a new feature here in order to provide parity with HTML.

The request URL is the identifier in this spec as well, so there would already be the same behaviours for A and B in the first examples.