major version pinning is not suitable for production - cache is too long with up to 14 days of cache

[samuelstroschein]

Edit

This seems like a bug rather than a feature request. The major version pinning caching times with 7 days, leading to worst case 14 days of cache are too long for a production use case. I updated the issue accordingly.

---

Is your feature request related to a problem? Please describe.

JSDelivr's caching is unsuited for major version pinning, where a module should update as soon as a new minor version is released.

We are recommending JSDelivr for inlang plugins. The fact that a JSDelivr link only updates after approximately 1 week due to JSDelivr's caching itself and the response headers leads to numerous bugfixes that are not immediately deployed. See https://github.com/inlang/monorepo/issues/1404#issuecomment-1750701476 as an example.

In the worst case, it takes 14 days until a user receives the latest version.

2023-01-01 plugin v1.0 is released (jsdelivr caches for 7 days)
2023-01-02 user requests plugin@1 -> receives 1.0 (browser caches for 7 days)
2023-01-03 plugin v1.1. is released
2023-01-03 user requests plugin@1 -> receives outdated browser cache hit 1.0 
2023-01-04 user requests plugin@1 -> receives outdated browser cache hit 1.0 
2023-01-05 user requests plugin@1 -> receives outdated browser cache hit 1.0 
2023-01-06 user requests plugin@1 -> receives outdated browser cache hit 1.0
2023-01-07 user requests plugin@1 -> receives outdated browser cache hit 1.0 
2023-01-08 user requests plugin@1 -> receives outdated browser cache hit 1.0 
2023-01-09 user requests plugin@1 -> browser refetches jsdelivr which is on day 6 of cache) -> receives 1.0 (!)
2023-01-10 jsdelivr purges cache. resolves 1.1 now
2023-01-11 user requests plugin@1 -> receives outdated browser cache hit 1.0 
2023-01-12 user requests plugin@1 -> receives outdated browser cache hit 1.0 
2023-01-13 user requests plugin@1 -> receives outdated browser cache hit 1.0 
2023-01-14 user requests plugin@1 -> receives outdated browser cache hit 1.0 
2023-01-15 user requests plugin@1 -> receives outdated browser cache hit 1.0 
2023-01-16 user requests plugin@1 -> browser refetches jsdelivr -> receives 1.1

Describe the solution you would like.

Reduce the cache time to a day or 12 hours like branches.

Describe alternatives you have considered.

Moving off of JSDelivr.

Requisites

• [X] I performed a cursory search of the issue tracker to avoid opening a duplicate issue.
• [X] I understand that not filling out this template correctly will lead to the issue being closed.

[MartinKolarik]

Hey, have you tried the purge API? It should work well in this case: https://github.com/jsdelivr/jsdelivr#purge-cache

[samuelstroschein]

hey @MartinKolarik, purging doesn't help since jsdelivr is also setting response max time headers of 7 days. hence, the browser will cache a link for 7 days in addition to jsdelivr caching 7 days. The worst case result is a close to 14 days cache.

I updated the issue. The solution seems obvious. Reduce the caching time for version pinned modules to 12/24 hours.

[MartinKolarik]

Quick note: the CDN cache time is only 12 hours already, as indicated by s-maxage. The problem in your case is indeed likely the client cache.

[samuelstroschein]

Good remark. In that case, the problem seems mostly jsdelivr purging-related.

Lowering the JSDelivr cache time to 12 hours for major versions seems beneficial as we can't, and therefore jsdevlivr too, require developers to set up CI/CD to purge (too long) JS deliver caches.

Would lowering the JSDelivr cache time from 7 days to 12 hours for major/minor versions be okay for JSDelivr?

[mfcc64]

max-age=604800, s-maxage=43200, is this really intended? (7 days client cache, 12 hours CDN cache) Or should it be max-age=43200, s-maxage=604800? (12 hours client cache, 7 days CDN cache)