25

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?

Rikesh
  • 26,156
  • 14
  • 79
  • 87
Oleg
  • 24,465
  • 8
  • 61
  • 91
  • 4
    You can try playing around with http://www.html5rocks.com/en/tutorials/developertools/sourcemaps/ However, it is not supported by cassette - the issue is still in open state. Also might be worth looking into chrome extension api - e.g. rewriting urls before they are requested.. – bushed Apr 27 '14 at 16:51
  • @bushed: hmm, good point, I haven't thought of using sourcemaps for css in this scenario (less/sass maybe)! – Oleg Apr 27 '14 at 21:53

2 Answers2

1

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

Cody MacPixelface
  • 1,348
  • 10
  • 21
  • Thanks for the link, that's useful! Changing the link href wouldn't work in this scenario since modifying it would see the resource re-loaded from the new url - and that url will not be cache busted. – Oleg Apr 27 '16 at 22:02
-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]
Victor Radu
  • 2,262
  • 1
  • 12
  • 18