Question: What is the expeected filewatcher functionality?

[mistyn8]

trafficstars

So I been experimenting with the fileWatcher, and whilst it does seem to delete and regenerate the combined and minified file for the bundle it doesn't actually alter the hash appended to the injected css/js bundle url, so we are at the mercy of the browser cache?

Eg the updated smidge bundle isn't served until a hard refresh is asked for or the default 10min cache expires?

Is this the expected functionality? Is there actually a way to actually alter the cachebusting appended string when a file watcher event occurs so that we immediately see the updated bundle?

cheers.

[mistyn8]

https://github.com/Shazwazza/Smidge/issues/91 Also note that if file watching is enabled, this also affects cache busting. If watching is enabled then the actual cache bust value is a combination of the ICacheBuster and the watched hash.

Found this comment.. but I'm not seeing the cache bust value change when filewatching?

[Devansh422]

i can work on this issue

looking forward to get assigned for this bug

[Shazwazza]

@mistyn8 sorry for the super long delay here :/

File watchers will clear the underlying cached files. IIRC I think one of the original intents was to auto cache bust the value too but afair this wasn't implemented and I'm not sure it really should.

File watchers should be used for dev only and then in combination with the timestamp cache buster its should work as expected for dev iterations.

[mistyn8]

So simple use case for file watcher and requiring cache busting on environments other than Development.

Umbraco CMS, or any other CMS for that matter allows for backoffice editor updates of css, the filewatcher cache busting is key here. Theme's for instance might have primary colour selection that involve updating css vars.

Timestamp cache buster, not suitable for production environments, and we can't increment the smidge version, or assembly version whilst the site is running.

I guess there are work arounds to keep the mutable properties feeding into a css vars file that are outside of smidge, and can be kept smallish for no-cache scenarios. Or maybe IOptionsMonitor pattern and Smidge Version but would that be some heavy lifting in Smidge source?

But there is also the possibility, like with Umbraco CMS, where editing directly of the css files is given to the editor via the backoffice and then we are back to really needing cachebusting via a filewatcher.

[Shazwazza]

Yep that is fair. The challenge would be if the filewatcher changes the cache buster for that bundle, we'd need to validate the incoming cache buster value matches the actual cachebuster value + the file watcher (timestamp?) to make sure external people can't trigger additional cache files being generated.

IOptionsMonitor might be pretty tricky since there can be a different cache buster per bundle, but might be doable.