Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

serviceWorker serving stale frontend assets #9044

Closed
silverwind opened this issue Nov 16, 2019 · 3 comments · Fixed by #9110
Closed

serviceWorker serving stale frontend assets #9044

silverwind opened this issue Nov 16, 2019 · 3 comments · Fixed by #9110

Comments

@silverwind
Copy link
Member

silverwind commented Nov 16, 2019 •
edited
Loading

The serviceWorker script we use to cache frontend assets is rather hindering during frontend development as it often serves stale content where one does not see JS changes reflected on the running application.

To my understanding, the service worker script is at most fetched every 24h by a browser, but I'm not sure if that is actually the root issue because even if I force-reload (which should invalidate the SW cache), I often see stale assets. The only reliable way that get fresh content I found is to unregister the SW manually and force-reload the page.

For development needs, we can probably set up a separate development server where SW is always unregistered, but I wonder if we can improve the invalidation mechanism of the serviceWorker itself as users might see JS that's up to 24 hours old.
@silverwind
Copy link
Member Author

silverwind commented Nov 16, 2019 •
edited
Loading

One solution I have been using in the past is write the js/css build timestamp into HTML (like <html data-build-time="unix">, store it in localStorage and then conditionally re-register the service worker if those timestamps differ. I think this might be a good solution for us too, but it probably won't be a simple integration as HTML is not handled by webpack currently.

@silverwind silverwind mentioned this issue Nov 16, 2019
Merged
@guillep2k
Copy link
Member

What about having some mechanism to override AppVer from the environment when MODE = development, would that work?

<script src="{{StaticUrlPrefix}}/js/index.js?v={{MD5 AppVer}}"></script>

And change:

navigator.serviceWorker.register('{{AppSubUrl}}/serviceworker.js').then(function(registration) {

into

navigator.serviceWorker.register('{{AppSubUrl}}/serviceworker.js?v={{MD5 AppVer}}').then(function(registration) {

Then we can run Gitea like:

GITEA_APP_VER=$(date +%s) gitea --config ....

Sorry if I'm speaking nonsense; I have only some superficial understanding of modern day UI library composition.

@silverwind
Copy link
Member Author

silverwind commented Nov 16, 2019 •
edited
Loading

I don't think that would work. A SW will not check for a update to itself unless it is being told do (or 24h have passed). I think the only leverage we have is a (inline) script loaded from HTML that will unregister the worker if gitea is started in development mode (maybe via a flag or env var). The next time gitea is started in "production" mode, it would then register again and do regular caching.

Do we have any suitable flags/vars that could be used?

@silverwind silverwind mentioned this issue Nov 21, 2019
Merged
silverwind added a commit to silverwind/gitea that referenced this issue Nov 21, 2019
@silverwind
Add USE_SERVICE_WORKER setting
ee355da 
This will be very useful setting for anyone doing frontend work.

Fixes: go-gitea#9044
techknowlogick pushed a commit that referenced this issue Nov 21, 2019
@silverwind @techknowlogick
Add USE_SERVICE_WORKER setting (#9110)
f0aaffe 
* Add USE_SERVICE_WORKER setting

This will be very useful setting for anyone doing frontend work.

Fixes: #9044

* prevent potential syntax error on old browsers
@go-gitea go-gitea locked and limited conversation to collaborators Nov 24, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

Add USE_SERVICE_WORKER setting silverwind/gitea
2 participants
@silverwind @guillep2k