Problem with baseUrl and JavaScriptFetch, JavaScriptServiceWorkerRegistration...

Right now assets have a baseUrl which defaults to their url, or the url of the baseUrl of their nearest non-inline ancestor. However this is a flawed concept for JavaScript as it has a much more complex situation than that. Notably import is resolved relative to baseUrl however fetch, navigator.serviceWorker.register and similar are relative to the URL of the including document. Currently the code treats these as the same, which results in unfortunate results such as navigator.serviceWorker.register('file:///home/kevincox/p/kevincox.ca/build/service-worker.js').

However this problem is basically impossible unless assetgraph knows all possible references to the JavaScript file. There are cases where we can probably assume this such as when using assetgraph-hashfiles however there are also cases where this can not be assumed, such as if you are providing a JavaScript library that you expect users (and possibly your website as well) to access off of a well-known URL.

I encountered this problem with serviceWorker.register but I believe the same issue exists with fetch.

I think the best solution here is to not modify the referenced URL when the URL of the asset containing the reference is changed. There are a couple of cases where we can do something “clever” by handling the case where the only user of the script is moved, however this action at a distance is probably more confusing than it is helpful.

[kevincox]

Ok, I made a test case. It is roughly as simple as expected 🙂

[kevincox]

I’ll see if I can extract it. The setup is fairly simple though.

• index.html has <script src=sw.js>
• sw.js has navigator.serviceWorker.register("/service-worker.js");
• graph.findAssets({fileName: "sw.js"}).forEach(a => a.url = "https://cdn.example");
• graph.writeAssetsToDisc({protocol: "file:"}, "dist/")

Completely untested but that is the gist of it.