depCache preload to support buffers

[guybedford]

Currently we're effectively doing a script preload only. This is fine for script-loaded resources, but for resources that would are loaded as buffers (WebAssembly), we do need to have a fetch-based preloader to support depCache.

[benstevens48]

Maybe this is related. I'm trying to use depCache and http2 instead of bundling. However, looking at the network tab in chrome, anything in depCache has the status (cancelled) and I can see it's fetched later on. As far as I can tell depCache is not making any difference to the timing of the requests. Also a get a lot of warnings in the console saying 'The resource xxx was preloaded using link preload but not used within a few seconds from the window's load event. Please make sure it wasn't preloaded for nothing.' But perhaps these warnings are expected.

[guybedford]

@benstevens48 it sounds like Chrome may be playing around with their preload defaults there, I hadn't seen that before. Perhaps compare with Chrome Canary to see if it still happens there?

[thomas-darling]

@guybedford I'm seeing something similar with this config in SystemJS v0.20.18:

depCache:
{
    "http://localhost/1.13.2/en-gb/bundle.dependencies.js":
    [
        "http://localhost/1.13.2/en-gb/bundle.app.js",
        "http://localhost/1.13.2/en-gb/bundle.shared.js"
    ]
}

For one thing, I can't seem to get this to do anything without having the full URL's in there.
(we're starting the app with System.import("aurelia-bootstrapper"), which live in bundle.dependencies.js)

With the full URL's in there, it at least tries to load the dependencies, but ends up with cancelled requests:

Debugging this further, it looks like it is cancelled because the script tags are injected, and then immediately removed, before Chrome had a chance to start the download.

I believe this matches up with this line:

systemjs/src/common.js

Line 120 in 8afdc93

document.head.removeChild(link);

If I manually comment out the line with the breakpoint, thus preventing it from removing the script tag, then the files seem to be successfully preloaded - although that doesn't stop it from loading them again later:

I'm really not sure what's going on with those second requests for the same files, but I'm guessing that might be related to path normalization in the depCache - something seem to be broken there too :-)

We also get the preloaded using link preload but not used within a few seconds warnings.

[guybedford]

@thomas-darling thanks that seems to have been new behaviour introduced into Chrome. I've added a fix for this in be6d7a6.

[michael-simon]

I am also seeing this behavior (the double-fetching). My chrome actually shows the first set of script loads as coming from common.js, while the second set end up going through fetch.js . (I saw this because I'm trying to debug/prove that depCache is doing what it's supposed to, especially with respect to HTTP2.)

[guybedford]

@michael-simon were you seeing this with 0.20.19? The other thing to check here might be the cross origin settings, as these are supposed to match for preloading to work.

[guybedford]

If you do have a look at this further, any help seeing why things might not be matching up would be appreciated, as Chrome keep adjusting their implementation!