Chrome workspaces with fingerprinted assets

Question

Chrome workspaces: let's say I map local CSS files to those served by my local http server. Everything works great and I can modify the files in-browser and upon page refresh my changes persist.

We happen to fingerprint our assets so that they are referenced via urls like styles.css?longuniquehash. Great practice - this way we can use aggressive caching and be sure the most recent assets will be used by the client.

However, this backfires a little with workspaces as the mappings get lost whenever the url is updated. In a nutshell: we map styles.css?123 to the local resource, we change it and on page refresh it comes back as styles.css?234 which has to be mapped again.

We're using cassette, but the problem can be reproduced on any setup with fingerprinting. Is there a setting or a workaround I'm missing?

Answer 1

I assume you do not develop on your live server (and if you do please stop and develop on your local machine or at least on a test server) so you activate the "cache buster" only on your live environment. We always have a quick way of checking the environment we are running on all our projects so just check before appending the "?123" query. I you do not what to solve this in code you can also add this in your htacces (if you are using apache)

SetEnvIf Host 'local.domain.com' runenv=local

RewriteCond %{ENV:runenv} ^local$
RewriteCond %{REQUEST_URI} .*\.css
RewriteCond %{QUERY_STRING} !^$
RewriteRule ^(.*)$ /$1? [R=301,L]

Answer 2

According to Chromium, the support for mapping URLs with query params (i.e. style.css?123) was only partial up until Chrome 49 - where it was removed completely.

If you can't manually remove the params from your code, a temporary workaround is to remove the ?123 param from the stylesheet reference in the Chrome inspector once the page has loaded. Then your workspace mapping and auto-refreshing should work fine until you load the page again.

You can star and follow this issue here: bugs.chromium.org