Version bundle.js & style.css

[lukeed]

I would call this "mild priority" right now, simply because, as is, bundle.js is the majority of the application weight//network transfer. It's set for a maximum of 1 hour, which means that users will need to redownload an entire application, regardless of any changes it may or may not have had. Plus, this kind of impedes the function of offline/sw-precache.

Also, in the rare event that my app goes from v1 to v2 within the hour that User has cached my bundle, their next request would grab all the v2 chunks & sw.js, which still points to non-versioned bundle.js, which results in User working with a mismatched set of assets... the majority of which (in bundle) is now outdated.

If we're on the same page here, we'd need to:

• Version bundle.js, like everything else
• Update server headers; would up it to 1YR
• Replace the HTML bundle.js link per-build; handled by html-webpack-plugin

This all applies to style.css as well: same tasks & reasoning.

[developit]

this would probably break the serviceworker setup since the html has to change in order to update the bundle url, right?

[lukeed]

I'm not sure what you mean. The html would be different per build, and would be cached alongside the new build assets too. You'd be looking at fully immutable builds, from version to version.

[developit]

Can't do immutable HTML since that's the entry point - its url has to be /. The issue comes when you're on a page and the SW updates, and then have to reload to get the newest version. Maybe I'm thinking of this wrong?

[dstaley]

Correct me if I'm wrong, but if you're not fingerprinting the assets, can't a user find themselves in a situation where their browser has evicted bundle.js from the cache, but not style.css, resulting in a newer version of bundle.js being styled with the previous version of style.css?

[lukeed]

Sorry, "immutable" as in all assets. Only the index.html and sw.js filenames will be the same, but their contents always point to new files.

[lukeed]

@dstaley right, that's what I'm trying to voice. When assets arent uniformly cached and versioned, you give yourself a window of being caught in between states.

[developit]

html-webpack-plugin has a hash option that appends the compilation hash to assets, which might work for this:
https://github.com/jantimon/html-webpack-plugin#configuration

[lukeed]

Correct. Would be the same process and tasks regardless of hash or filename addition

I've been doing this for my projects and preact-starter, haven't run into any issues yet.

[AvraamMavridis]

What's the status of this? It would be great if there is an option in the cli to append hash on the bundle.

[developit]

I think the hash-in-querystring approach is doable in the short term.

[thangngoc89]

I have a fork that added hashing the bundle. I'll send a PR

[lukeed]

@developit What's your hesitation to adding filename-hashes? I'm not sure, but I don't think that the querystring approach is compatible with even all the servers we offer ootb. Certainly more error-prone in userland with user-setup-servers... perhaps.

[thangngoc89]

@lukeed It's true. I'm having a hard time fighting with nginx and querystring caching