Troubles with server-side caching of hacsfiles

Hi. After a full day struggling with this, I will post my findings in a answer-my-own question format.

Problem: I’m trying to make changes to the Javascript of a HACS-loaded card, and my changes never get effective :angry:

The card in this case is todoist-card, but it could be any other.

The file I’m changing is
/config/www/community/todoist-card/todoist-card.js

This gets referenced in the front-end via this virtual url:
http://hass:8123/hacsfiles/todoist-card/todoist-card.js

Wait! How do I know if this is not a browser caching problem? I mean, those are the most common caching problems…

Correct - this is the first thing you need to check. If you search this community for caching issues, you get answers about that. Solutions typically involve forcing browser refreshes, and sometimes changing the URL by appending something like ?v=0.0.1 to trick the browser into thinking it’s a new file.

But after trying many such tricks, I started getting really suspicious because I was always getting the original version of the js file… never my changes.

So I checked by opening a different browser, in incognito mode, and pasting the URL pointing directly to the js file, without the entire HASS UI. And I still got the original file, which I am sure was not cached in this browser.

So, I knew for sure that the server was serving the old file, which I searched and searched the file system, and couldn’t find anywhere… I could only find my changed version. :confounded:

2 Likes

The answer - it’s server-side, but it’s not caching

Eventually I got to the answer on my own, which I can’t find online anywhere (although now I could probably find it easily… now that I know the answer :roll_eyes: ).

It seems HACS keeps those files compressed in the same folder, and serves the compressed files. So, all along, there had been another file there in the same directory:

➜  config ll www/community/todoist-card/
total 28K
-rw-r--r--    1 root     root       21.9K Apr 10 19:21 todoist-card.js
-rw-r--r--    1 root     root        4.0K Apr 11 19:11 todoist-card.js.gz

And the .gz contained the original file, and that was what was getting served to the client browsers.

So now the simple solution is that after editing the .js file, I always run this to update the zip:

gzip -fk /config/www/community/todoist-card/todoist-card.js

Or, for practical purposes, this two-in-one rebuilding the zip and restarting HASS:

gzip -fk /config/www/community/todoist-card/todoist-card.js & ha core restart >/dev/null &

I just though I’d share this here in case it ever helps someone… :smiley:

4 Likes

Well at least the -fk switches are an easy mnemonic. :slight_smile:

2 Likes

doing lords work here, just spent 2 hrs trying to figure this out. Thank you!

1 Like

Your solution works - and led me to experiment…

For dev speed, i just deleted the .gz file and homeassistant served the js file.
And instead of a painful long reboot, make sure Chrome Dev Tools is open (F12) and right click on the refresh button in Chrome and do Empty Cache and Hard Reload…and boom!

s.

1 Like