Laravel-mix: How to config use file hashing instead of query strings ?

[maimake]

I prefer use file hashing, when I publish assets files to CDN.
Specifically, I publish assets files to CDN first, and then publish php code to my servers one by one.
So some server may be using old version assets file of CDN.

Is there a way to config use file hashing?

[dnunez24]

Agreed. It seemed to work this way in a previous version but I just upgraded and, to my dismay, we now have query strings for cache busting. I was under the impression that query strings had potential issues as a cache busting method. See other discussions of cache busting techniques and why query strings should be avoided:

https://www.stevesouders.com/blog/2008/08/23/revving-filenames-dont-use-querystring/
https://css-tricks.com/strategies-for-cache-busting-css/
https://www.alainschlesser.com/bust-cache-content-hash/

Unless there's some new knowledge that I'm not privy to, I would strongly vote in favor of returning to the static file name with content hash as the default.

[JeffreyWay]

I did a good bit of research and found that query string based caching should be more than adequate. Much of the research, as you linked to, is from pre-2010 and doesn't 100% apply anymore. For example, Squid has no issues anymore. If you use something like Cloudflare's CDN, you only have to click a button to activate query string busting.

There is no way in Mix 1.0 to use file-based hashing unless you want to implement it yourself within mix.then().

[dnunez24]

Fair enough. I understand that the library version is now stabilized and unlikely to make a change like that. Do you have any resources that you can point to that support your findings? I'd like to make sure I'm up-to-date as well, because two of the three articles I linked were actually from 2015 or later.

[devcircus]

The second link provided actually recommends query strings. It also links to a maxcdn site that recommends them. Here's Jeffrey's tweet asking for feedback:
https://twitter.com/jeffrey_way/status/871052698233298944

[dnunez24]

The second link doesn't "recommend" anything. It's merely a comparison of different strategies and asking for feedback. It says that most CDNs support and recommend them, but even the example linked to from that article doesn't actually recommend anything. It simply explains how to use query strings for cache busting and how to configure the CDN to support it. I think the main trouble, in general, is that the majority of opinions on the subject are just that. There isn't much hard evidence to support a best practice without having a comprehensive review of the impact across various browsers, servers, CDNs, etc. Asking for opinions on Twitter is hardly scientific. I was hoping for some supporting hard evidence that would disprove my possibly outdated opinion on the matter.

[devcircus]

Quoting the article

Most browsers these days will see a URL with a different query string as a different file and download a fresh copy. Most CDN's even support and recommend this.

The last sentence then links to maxcdn's recommended approach.

However you interpret that, any modern cdn supports it. A non-issue.

[devcircus]

Also, I'm sure the Twitter question was merely a small piece of the investigation done before making a change that affects thousands of websites. I'm sure if any real issues actually ever arise, appropriate action will be taken. To now, the only evidence is second-hand info.

[maimake]

So, my opinion is: Let the users to choice which one to use with a configuration.

Some users maybe not use any Modern-CDN, or maybe even just use their servers instead for some reasons and no switching ability. The reality is more complex.

Hope for adding a way to fallback if it's not hard to U, as acting like pre-version Mix. So that we can update to the latest Laravel happily. Thanks

[san-kumar]

You are right about it because a lot page optimizers (including Google's) complain about using query string in static assets. I hope they add it back too.

[tomsisk]

I don't really think this is a "non-issue". There are cases where you need both versions of the code, mainly during a deployment to multiple servers. We are doing one-at-a-time deployments to about 10 servers. We send our assets to S3/Cloudfront before deploying any backend code. In most cases, this probably isn't an issue. There are a couple different types of users that can hit the site during a deployment:

1. Everyday user.
2. A new unique user.

User 1 should have no issues, the old version will very likely be in their browser cache, so they can continue to use the site on whatever code is on the back end server they happen to be hitting. User 2, however, is only fine if the old cached version exists in the Cloudfront edge they are hitting. If it does not, they have new assets with old backend code, which is potentially a messed up site. Granted, this should only be for a few minutes max, but it's not exactly the ideal situation I want to show new users.

That is with a CDN in front. Remove that, and the problems become much worse. User 2 could end up caching old assets with the new hash.

Perhaps our deployment strategy is garbage. I know there are other options here, but not without either losing server power or adding it during a deployment (neither of which I think are ideal, but options nonetheless). Hashed file names just work in so many more different situations.

[octoxan]

Really disappointed in this solution as query string cache busting doesn't work 100% of the time for our users. Shouldn't have to tell a client to shift refresh to see changes. Changing the file name works, query strings do not. Should at least be an option.

[terryupton]

Any update on this? is this feature/option likely to make it into Mix?