-
-
Notifications
You must be signed in to change notification settings - Fork 91
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.
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
Caching issues in Development since migrating to Shakapacker #88
Comments
I agree. I'm in the process of migrating to shakapacker, and it took me a while to figure out why my js and css changes were not updating in my browser on development (application.js and application.css were being cached since they no longer had the contenthash) |
Here's a workaround that includes adding the contenthash to css
|
Thanks for reporting. Not entirely sure I would agree with this being unreasonable default in development. For me, it does make sense to skip expensive operations in environment where you'll see frequent changes and recompiles. This being a change to the behaviour from webpacker is unfortunate and I wouldn't be surprised if it wasn't documented properly. The whole road from webpacker to shakapacker, with v6 being in development hell for months did leave us with gaps in changelog and docs. Any suggestion for improvements would be greatly appreciated! What are your development setups? Never thought about it and haven't looked into it fully but I've half expected dev server to get assets out with no cache headers to prevent any browser caching - that feels fairly sensible. If it doesn't do that, then I agree we should address that in one way or another. Will look into it further! |
@AlecRust @bgwilson87 What browsers are you seeing this in? Just tried to replicate and cannot quite get the issue you're seeing. Headers from my dev server response below: Notice that:
There is caching there based on Etag header however I can see this busted fine with changes:
Is the above not what you're seeing? Would be great to get more details about your setups and how the staleness ends up happening. Any repro case would be great if we are to dig into this further |
I added this. It was based on https://webpack.js.org/guides/build-performance/#avoid-production-specific-tooling. Rails "sprockets" also works like this. Maybe there's some interaction with using bundle splitting that doesn't work well? However, @tomdracz, that's a very nice explanation of how this setting is more efficient for development. |
Thanks for the explanations, and also thanks for taking the webpacker torch and continuing to support it. I went through the effort a few years ago to completely get off of sprockets in my project, so I was dismayed to hear that Rails is going in a different direction. I was able to resolve my issues by running this command to toggle caching (I had a caching-dev.txt file in my tmp directory) It may be helpful to mention this in the v6 upgrade docs in case others have caching enabled on development. |
Thanks for the update @bgwilson87 Good detective work! I'm struggling to replicate this behaviour locally. If you could try enabling caching again and attaching the response headers from the asset requests, that would be great! Locally, I still get no |
@bgwilson87 Are you running webpack dev server? I think I got to the bottom of this:
HOWEVER, if I've already managed to run the app once with caching and without dev server running, then I will still get cached version as it will respect the This makes sense now - with dev server running we will proxy everything to express app started by that, without it, we compile on the fly and use Rails public server hence caching applies. Great spot, I will update the docs to take note of all of that!
Yeah, I still don't think content hash should be added to development but I will document that as a feasible option for those who want to keep it. Initially as config override as outlined somewhere above but if we think it's useful enough, I would be happy to get this going as an option on opt-in basis. |
@tomdracz that all sounds right, I am not using webpack dev server. And if I run |
@tomdracz the problem seems related to shakapacker assuming that development means the headers don't use caching. I'm frankly surprised that turning on caching for the Rails server also turns on caching for the browsers. If it does, then maybe webpacker could pick that up and adjust the config? How about if we check that if However, this depends on having that snippet of standard code to be in development.rb. Then again, |
I'd honestly avoid anything more here. We could start picking up the rails config value but that feels bit too magical and us veering towards doing too much again. What we do need is better way to adjust those configs to make stuff like enabling digests in filenames much easier. |
I have caught Chrome multiple times loading undigested packs from memory (devtools show that). I don't know how it gets into such a state but it does. CTRL-F5 snaps it out of it and then it starts revalidating (if-modified-since). But somehow it eventually happens again. The only way to avoid this with 100% certainty is with digests in the file names, so ideally that should be easy to enable with a single .yml config key. |
If:
then it might be worth adding the hashes back as the default. |
@bughit so this problem doesn't exist if "disable cache" is active, correct? |
Haven't checked. |
I tried various things to get this to work, but was unsuccessful in disabling caching. So I added the following to config/webpack/development.js to force fingerprinting of JS & CSS files. Seems to work just fine.
|
@sschafercdd any idea of what the root cause of needing a content hash in development is? |
I don't know exactly why, but JS and CSS files are being served up with caching allowed, no matter what I've tried. So adding the content hash prevents stale JS/CSS from being used. |
See #234. Should we finish this one up, @ahangarha? This is not a blocker for v7. |
@scottschafer Please let us know the result. We are about to release version 7. This might be the last piece to add to the new version. |
We used to run a pretty standard Webpacker 5 setup, which in Development resulted in HTML like this:
We then migrated to (equally plain/default) Shakapacker 6 setup, which in Development now results in HTML like this:
We expected
SplitChunks
to be enabled here, however the contenthash has also been removed from some filenames, likeruntime.js
and most problematicallyapplication.js
/application.css
.This is resulting in caching issues where the e.g.
application.js
file gets updated by Shakapacker during development, but the browser serves a cached version even after page refresh since the filename hasn't changed.I can fix this with the following
config/webpack/webpack.config.js
, but it adds the missing hash only to the JS file, not also the CSS:Is this an expected change in Shakapacker? It doesn't seem a good default?
Edit: Looks like this might be a performance thing? Still, this is unexpected when migrating from Webpacker and probably not a good default.
The text was updated successfully, but these errors were encountered: