Cache Invalidation

[oravecz]

this question revolves around the fetching of a package using semantic versioning. When I deploy a new version of my package, I have to stop/start the server in order for the new version to be served.

I would like to be able to invalidate the cache via API. I can’t find any documentation as to how this might be done, nor is there configuration for controlling how often the server waits before searching NPM for more recent versions of a package.

[ije]

the cache control for semver is max-age=600 (10 mins)

[oravecz]

Are you talking about the client (browser) cache age? That’s not the cache I am referring to (but on my machine I see the Cache-Control header returning max-age=31536000).

I am talking about the caching that appears to be happening when I publish a new version of a package to npm (for example, @mypkg/[email protected]), and my request for https://localesmserver/@mypkg/code@1 still returns the prior package for some time. I assume there is a memory cache of this metadata in the server because a stop/restart enables the new package to be discovered and returned.

[ije]

the server has a cache with 10 mins expires for package lookup:

esm.sh/server/npm.go

Line 351 in 20f7614

body, err := fetchSync(url+token+user+password, 10*time.Minute, func() (body io.Reader, err error) {

[oravecz]

I see. How are people who host the server in a development environment handling that delay? Any chance to make it configurable?

[ije]

in the pr, i added a npmQueryCacheTTL config that allows you to change the default cache duration.

[oravecz]

I would suggest that support for a ?flush parameter be added to the API, which would clear the cache entry for any semver URLs associated with the current request.

For example, if I make a request for https://esm.sh/mypackage/1.2.0?flush, the server would Identify the cache entries for /package/1.2.x and /package/1.x and /package and remove them.

If that seems reasonable, I would create a feature request based on this discussion.

[ije]

make senses to me. besides clear the cache on the server, we also need to purge the cache on CDN provider, for example, cloudflare.