feat: enable cacheImmutable by default #2247
Conversation
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## next #2247 +/- ##
=======================================
Coverage 95.83% 95.83%
=======================================
Files 13 13
Lines 888 889 +1
Branches 259 259
=======================================
+ Hits 851 852 +1
Misses 37 37 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
src/middleware.js
Outdated
| if (cacheControl.immutable) { | ||
| if (cacheControl.immutable !== false && hasCacheImmutable) { | ||
| cacheControlValue += ", immutable"; | ||
| } |
There was a problem hiding this comment.
Can we refactor this place? Convert boolean/number/string to object value to avoid logic duplication?
becauses undefined !== false (true)
| name, | ||
| framework, | ||
| compiler, | ||
| { cacheImmutable: true }, |
There was a problem hiding this comment.
@bjohansebas Why it was changed? This is a serous breaking change, by default we should cache only immutable (we store it in asset info) , i.e. files witch have contenthash or other hashed, we need to revert it ASAP
Please avoid merge without approve
There was a problem hiding this comment.
It was changed to check how it behaves when that option doesn’t exist, and that’s why I added tests below to verify how it behaves when cacheImmutable is explicitly set to false
There was a problem hiding this comment.
The only breaking change is that now, if an asset is immutable, it will add that header by default. Otherwise, it behaves as before. In the first commit there was an error, but after reviewing the code I realized it was wrong, which is why I added those two new commits that fixed the issue (0f5c4f6, d66f6b8) where the header was being added even when the asset was not immutable yet.
Summary
cacheImmutable
becomestrue` by default, which seems pretty good to me.What kind of change does this PR introduce?
feat
Did you add tests for your changes?
yes
Does this PR introduce a breaking change?
yes
If relevant, what needs to be documented once your changes are merged or what have you already documented?