3 ms·
> One solution is to version your JavaScript files (first release in a /v1/ directory, second in a /v2/ etc.). Then the rollout simply consists of changing the
by Touche 10y ago
> One solution is to version your JavaScript files (first release in a /v1/ directory, second in a /v2/ etc.). Then the rollout simply consists of changing the resource links in your root pages to reference the new (or old) versions.
I wouldn't take this advise as it's bad for caching. A change to one JavaScript file will then result in breaking the cache of everything.
- mattnewton 10y agoMaybe I misunderstand, but don't you want to invalidate the cache when a new version comes along? Isn't the risk of version skew worse?
- Touche 10y agoIf one.js changes but two.js doesn't, then two.js should come from the cache. Only one.js should be fetched from network. Sticking all assets in an /assets/v2 folder invalidates everything.
- mattnewton 10y agoThat's fair. Most apps I have worked on have very few bundles of JavaScript that we either served inline or in one request, but I can see how this helps in the case of many requests.
- gefh 10y agoIf one.js and two.js are really separate components, they should each get a version. If they're closely coupled, they should be compiled together into one unit, to take advantage of deduplication, inlining, dead code elimination, fewer requests, better compression, etc etc.
- Touche 10y agoVersioning assets separately by sticking them in new subfolders is just re-inventing ETags in a bad way. Just use ETags. The point of the folder versioning scheme the article proposes is to make rollbacks easier. You can easily rollback a /assets/v2 folder to /assets/v1 by updating your server template, but if you have a dozen separate version folders (with different latest version numbers) for each resource then it's no longer easy to roll those all back.