[mattmanser]

A much easier way than this is to append a hash of the file instead of 'versioning' it. Some people add it as a query string, some add it into the filename.

Been doing this for years with infinite (well, practically) cache settings.

These days it's built into most js compression tools afaik.

[benologist]

This is the official way to do that I think -

https://developer.mozilla.org/en-US/docs/Web/Security/Subres...

[Someone1234]

That doesn't work, because no one file exists in isolation. If you're using version 32.14 of this, you want version 32.14 of that, and this other thing. Versioned directories make this kind of grouping natural and easy, co-mingled hashes do not (and you could do both but you have the downsides of both and no real upsides).

Plus semantic versioning can help cross-team communication, there's no human understanding of raw hashes.

[diggan]

You don't necessary need to use a hash based on randomness. Either using the git commit as the version/hash or a hash based on the content of the file itself works.

So as long as your entrypoint and it's references are versioning, everything follows from that. So if I load version A of index.html, it also points to version A of the scripts/styles. If you load version B, you get version B of the scripts/styles, since everything is versioned the same way.

[mattmanser]

Git commit is a bad solution, you want to use the file hash so you can have multiple bundles that version automatically. Also, if you pushed a change to even some comments or something not related to code, your bundle will change.

Often you have a bundle of library code that you rarely ever push changes to, and you don't want your clients to download each time you make minor changes.

[mattmanser]

The file hash of the output file, that's what I meant by hash.

Your way has big downsides and is pretty old-fashioned. It's still used by libraries that only have one javascript file, but not by websites that have to have multiple bundles and multiple CSS files.

Here's webpack's advice about doing exactly what I'm advocating, it definitely works and is the industry standard:

https://webpack.js.org/guides/caching/

Firstly, the file hash mechanism is built in to most bundling tools, and the file hash means you never ever, ever, ever get any collisions or make any mistakes or forget to increase the version number. It's all handled automatically in the build process.

But on top of that, you can also then also have multiple bundles and they will automatically version themselves on the fly. It's common for most sites to have multiple bundles, meaning when you commit a change and rebuild the site, some of those bundles will not have changed. With the automatic hashing, the browser will only download the bundles that changed and you aren't serving tons of unnecessary javascript. You might have one of rarely changing shared libraries, another of the sales part of the website, another for the client part of the website, another for the admin section, you might have a video player that only parts of the site use, etc.

Each release you do would only force the browser to download bundles that actually changed.

For example reddit has:

    https://www.redditstatic.com/_chat.Q8BtxnzGjSI.js
    https://www.redditstatic.com/crossposting.4zJErPF9qdo.js
    https://www.redditstatic.com/reddit-init.en.zJ5ikJ21-Gw.js
    https://www.redditstatic.com/reddit.en.BQfJLVYdPSA.js
    https://www.redditstatic.com/spoiler-text.vsLMfxcst1g.js

Or stackoverflow:

    https://cdn.sstatic.net/Js/full.en.js?v=b45d5b4c957c
    https://cdn.sstatic.net/Js/stub.en.js?v=963cc3083a37
    https://clc.stackoverflow.com/markup.js?omni=Ak4r5CHnPNcIR2AAAAAAAAACAAAAAQAAAAMAAAAAAKpYlh7uXVCYJKM&zc=24%3B4&pf=0&lw=165

Or stackoverflow's CSS:

    https://cdn.sstatic.net/Shared/stacks.css?v=897466c4b64a
    https://cdn.sstatic.net/Sites/stackoverflow/primary.css?v=2d33230dde3d

See how they have a "shared" css they use on all the stackexchange sites, and a "stackoverflow" one, and that they can release each without destroying the cached version of the other?

[Someone1234]

You're talking about something entirely differently than what I am talking about. We aren't bundling at all. We're minifying and relying on H2 for high performance concurrent delivery. Bundling is the only old-fashioned thing here. Semantic versioning is timeless.

You're talking about a mechanism that is purely designed to cache-bust. I am talking about a mechanism for humans to deploy, understand, and utilize libraries across teams (and to group different files into distinct versions). Apples and oranges. The thread was about architecture, after all...

I won't get drawn too far into your post since it has too many strongly held claims without explanation/justification and I don't feel like trying to unravel that. But, yes, if you're automatically generating bundles for HTTP 1.1, append a hash. We aren't, so we don't.

[mattmanser]

And you should still be minifying your CSS and JS, even if it's just to get out the comments, and it's still better to use file hashes than piss around with versioning.

Doesn't matter how much you dance around it, this wasn't a good architectural decision, nor is it standard industry practice.

[Someone1234]

> And you should still be minifying your CSS and JS

We do, as the post you replied to said.

> Doesn't matter how much you dance around it, this wasn't a good architectural decision, nor is it standard industry practice.

Just because you happen to believe something doesn't make it "standard industry practice." Repeating the same unsupported claims with extra conviction doesn't make for an argument (persuasive or otherwise). Semantic versioning and versioning libraries/"grouped by version" is very much standard, in fact the industry's most popular CDN (by far) does exactly that:

https://cdnjs.com/libraries/jquery/

https://cdnjs.com/libraries/angular.js

Your "solution" solves only one issue well: cache busting. Versioned directories solve that issue but also solve other issues (deployment/human understanding/grouping associated resources together).

I'm not sure you yourself even know why you believe this. You just seem to have read WebPack's docs, decided that's how it should work, and view it as a one size fits all solution to completely unrelated problems (i.e. it isn't an architectural/organizational answer, it is a technological one for cache busting, thus irrelevant to the topic).

If you have anything of substance to add, by all means, but so far your post are strong in conviction and weak in justification (technical or organizational). You keep arguing from authority, but forgot to say who the authority is meant to be.