Description
I got a scenario here, that I would like to discuss and hopefully create a source for docs, for what a developer should really think about to prevent causing hash changes.
I'm making something, that might seem like a very small change in my code, which has quite large effect on long-term caching.
I'm writing this issue in docs, because I'm sure it's expected, just that I want to be able to understand why this is happening, and hopefully help others as well.
Example repo is here (using webpack@2.2.0-rc.7
and webpack-chunk-hash@0.3.0
):
https://github.com/jouni-kantola/webpack-output-by-build-type/tree/why-hash-change
Here goes the scenario:
- I build:
Asset | Size | Chunks | |
---|---|---|---|
0.9bbf83cf4b0bde5cdd21.dev.js.map | 512 bytes | 0, 6 | [emitted] |
0.9bbf83cf4b0bde5cdd21.dev.js | 756 bytes | 0, 6 | [emitted] |
2.a01031186175de379984.dev.js | 455 bytes | 2, 6 | [emitted] |
3.64a0d1a6257d07bf9c8e.dev.js | 455 bytes | 3, 6 | [emitted] |
vendor.72eb1607924636054b21.dev.js | 254 kB | 4, 6 | [emitted] |
app.d67c37259cfc27adf14e.dev.js | 16.9 kB | 5, 6 | [emitted] |
1.b255a8ecec8dd054c7f3.dev.js | 756 bytes | 1, 6 | [emitted] |
1.b255a8ecec8dd054c7f3.dev.js.map | 512 bytes | 1, 6 | [emitted] |
2.a01031186175de379984.dev.js.map | 424 bytes | 2, 6 | [emitted] |
3.64a0d1a6257d07bf9c8e.dev.js.map | 430 bytes | 3, 6 | [emitted] |
vendor.72eb1607924636054b21.dev.js.map | 335 kB | 4, 6 | [emitted] |
app.d67c37259cfc27adf14e.dev.js.map | 18.9 kB | 5, 6 | [emitted] |
index.html | 6.35 kB | [emitted] |
- I change
module-a.js
from:
import is from 'is-thirteen';
export const a = () => console.log('module a says 12 + 1 === 13', is(12 + 1).thirteen());
to:
export const a = () => console.log('hello world');
- I build yet again:
Asset | Size | Chunks | |
---|---|---|---|
0.3f19b2e7372b486647de.dev.js.map | 512 bytes | 0, 6 | [emitted] |
0.3f19b2e7372b486647de.dev.js | 756 bytes | 0, 6 | [emitted] |
2.a01031186175de379984.dev.js | 455 bytes | 2, 6 | [emitted] |
3.64a0d1a6257d07bf9c8e.dev.js | 455 bytes | 3, 6 | [emitted] |
vendor.503164abc295ee5b7ca1.dev.js | 254 kB | 4, 6 | [emitted] |
app.928d94b1c06014c2234b.dev.js | 16.9 kB | 5, 6 | [emitted] |
1.84b1d26493dcab2a97e9.dev.js | 429 bytes | 1, 6 | [emitted] |
1.84b1d26493dcab2a97e9.dev.js.map | 370 bytes | 1, 6 | [emitted] |
2.a01031186175de379984.dev.js.map | 424 bytes | 2, 6 | [emitted] |
3.64a0d1a6257d07bf9c8e.dev.js.map | 430 bytes | 3, 6 | [emitted] |
vendor.503164abc295ee5b7ca1.dev.js.map | 335 kB | 4, 6 | [emitted] |
app.928d94b1c06014c2234b.dev.js.map | 18.9 kB | 5, 6 | [emitted] |
index.html | 6.35 kB | [emitted] |
So to what I think needs to be documented:
- What types of changes should a developer really be aware of when making changes.
- In this build, is-thirteen changed ID from
59
to85
, and that caused three bundles to be cache busted. In a larger app that could be quite a lot of code that needs to be shipped again to the end-user. Is there anyway to prevent this small change, from having this large effect? - Is there anyway of preventing the vendor bundle from changing hash, when changing consuming code?
I think I've done the most important bit, to extract the manifest, but still it's very easy to get chunks cache busted. There are loads of blogs discussing this, but I still believe the truly nitty gritty is missing to be documented.