Martin Kolárik

> This completely breaks standard module semantics. One huge reason to even make a separate module is so you can have common state like caches. Packages I maintain, like lit-html...

> Yes, absolutely. This is what modules enable, and we've been doing this with lit-html for 4+ years now. Ok, well, it's definitely a valid pattern, just a very problematic...

Right now this doesn't always work as you expect when using `@branch` refs because purging applies only to the edge CDN servers, while the files may be cached - for...

`https://cdn.jsdelivr.net/gh/UnlyEd/stacker-public-scripts/dist/univers-pps.js` will check for valid semver tags first and use master branch only as a fallback, see https://github.com/jsdelivr/jsdelivr#use-a-version-range-instead-of-an-exact-version-only-works-with-valid-semver-versions. So you can make releases `1.0.0`, `1.0.1`, etc.

> I need to make some tests with this, it might be simpler and more reliable than purging. Note that if you want immediate updates without changing the URL to...

In this case, it was because there is also a 5 - 10 minutes cache time for metadata (list of versions). It won't always work when there are many updates...

> If I understand what you've said correctly, the "test10" should appear in ~12h. That should be the upper limit yes. Or it would update now if you purged it...

> I wonder if it wouldn't make sense to optionally provide the latest version when purging, so that if JSDelivr doesn't have such version in its "versions cache" then it...

The repository has 3,232 tags. I'm afraid it got to the point where they can't be reliably fetched and sometimes fail. At the same time, you don't refer to a...

You could use https://cdn.jsdelivr.net/gh/solana-labs/token-list@latest/src/tokens/solana.tokenlist.json, which will work as described in my previous comment. The caveat is that updates may take longer if the process sometimes fails, or eventually, it may...