Backport SHA digest file checking to 3-x-stable

[ericboehs]

See #1743

[ericboehs]

@mdesantis @gauravtiwari I backported #1743 here.

[gauravtiwari]

thanks @ericboehs ❤️

[mdesantis]

Thank you @ericboehs!!!

[kjleitz]

Thanks @ericboehs!

Do you guys know when you might release a new version with the changes in this PR? Over here we run multiple app servers under a load balancer (with a Capistrano-style deployment strategy) so I've been pulling my hair out trying to solve the problem we were having with the fact that our public/packs/* fingerprints were different between the servers, whereas our public/assets/* fingerprints were all the same between the servers. Lots of inconsistent 404s for webpacker-compiled files as a result (which is never an issue we had with the traditional asset pipeline).

I'd rather lock to a gem version than a git branch, but I guess that's the option I'll have to go with in the meantime. Is there somewhere I can find a release schedule @gauravtiwari? 😃

[ericboehs]

Lots of inconsistent 404s for webpacker-compiled files as a result

Interesting. Thinking about this, it would seem this would be a much wider spread problem. With sprockets the previous 2 versions of an asset were kept around for active users of the site during a deploy. With Webpacker, currently no packs are caching across deploys if the mtime isn't working correctly (all Heroku builds and it sounds like possibly capistrano as well).

Once you update your app to use this fix, you'll have another problem. All versions of an asset are kept forever. This is the existing behavior for users where mtime is working correctly (or CI is set to true). I have a pull request open to fix this as well.

Do you guys know when you might release a new version with the changes in this PR?

It would make sense to wait to deploy both of these fixes together but I'm not a core maintainer here so I'm not sure what the plan is.

[mdesantis]

@kjleitz why don't you use CI env var till the next Webpacker release?

[kjleitz]

@mdesantis I'm having trouble finding documentation for the CI environment variable you mentioned, or for what it's supposed to help with. Mind pointing me in the right direction?

[ericboehs]

@kjleitz See the last paragraph: https://github.com/rails/webpacker/blob/v3.5.5/docs/troubleshooting.md#compilation-triggered-even-when-files-havent-changed

You can enable this behavior outside of CI environemnts, or in those that don't set the CI env var, by running CI=true bin/webpack

I removed this documentation in this commit by the way.

If you look at the code I removed, you can see what setting the CI variable would do in older versions of webpacker (e.g. 3.5.5).

Edit: Technically @mdesantis removed it, I just back ported it. ;)

[gauravtiwari]

Thanks Both :)

Hey @kjleitz Will make another release over the weekend but in meantime please use the CI var as suggested by @mdesantis

[kjleitz]

Ah, thanks @ericboehs @gauravtiwari @mdesantis! A little bit concerned that the environment variable is named CI—potential clashes there in a big app. But thank you for the tip! I'll check for collisions and try it out if there aren't any.

Side note (and I'm sorry, I know this isn't exactly the venue for this, but): it's pretty rough navigating the docs for Webpacker—any reason they aren't all just in README.md so their contents could be searchable and visible? Or am I missing something? Because IMHO the current structure really obscures a lot of the caveats and configuration options, if you're coming to the GitHub page for documentation. Just my two cents 😄

Thank you guys for the help! I think it'll relieve a big headache/mystery we've been dealing with.