mavoweb
[plugins] jsDelivr doesn't deliver the latest plugin version
I released a new version of the Firebase plugin. But when I include it via the mv-plugins attribute, jsDelivr delivers me the old version. Do we have to wait a bit for changes to propagate? What if we use the https://cdn.jsdelivr.net/gh/${plugin.repo}@latest/${filename} URL to include plugins instead? For not to wait.
Yes, we have to wait for the changes to propagate even if we use the @latest suffix (so there is no need to use it). I believe we should warn plugins authors somehow about this jsDelivr “feature” and not make them panic as I was. 😂
It looks like jsdelivr might only work with releases, e.g. this link produces a 404: https://cdn.jsdelivr.net/gh/valterkraemer/mavo-firebase/mavo-firebase.js
and the file is not in the directory listing: https://cdn.jsdelivr.net/gh/valterkraemer/mavo-firebase/
I opened an issue in their repo here: https://github.com/jsdelivr/jsdelivr/issues/18225
It looks like we may need to find an alternative if there's no jsdelivr syntax that will give us the latest commit. @DmitrySharabin any ideas?
To my mind, we might have two options here.
Plugin authors are skilled enough so they can enable GitHub Pages. If they haven’t done it before, it won't be a big problem for us to give them a link where they can find full instructions on how to do that. So we can deliver plugins from GitHub directly.
Since plugin authors can use custom domains for GitHub Pages or host their plugins somewhere else, we can provide an optional parameter (property) for plugins, e.g., pluginURL. If it's empty, we use the default URL—https://author.github.io/plugin-repo/mavo-plugin-id.js. Otherwise, we use the URL provided by a plugin’s author.
As a fallback (for plugins that are not maintained anymore), we can use the approach we used to have before jsDelivr—embed a plugin’s code directly into HTML.
What do you think?
Yeah, I was wondering about requiring Github Pages. But this doesn't solve anything about existing plugins, many of which are unmaintained so we can't chase down their authors and force them to enable Github Pages. Btw I just pushed a fix that fixes the URL to get the latest commit on master, I wonder if this also addresses the long wait?
@latest/no version work with commits too but releases have higher priority, so if a release exists, you have to be explicit. Otherwise, @latest falls back to @master if there are no releases.
That's actually a good heuristic. I wonder whether we should go back to @latest if we can compel @valterkraemer to release a new version with the 10 commits after 2.0.1.
We could also adopt the @ syntax to allow for specific versions of plugins to be used (e.g. mv-plugins="[email protected]").
Btw I just pushed a fix that fixes the URL to get the latest commit on master, I wonder if this also addresses the long wait?
We don't have this directly in the docs but here are some details from one of the recent issues:
There's purge API that can be used to force update cache at the CDN edge servers but the files may still be cached for a short time at our origin servers.
The closest you can get to realtime updates is with publishing to npm, using a link like
/npm/package/filethat references the latest release, and using the purge API to force update the cache right after release. npm releases should be available everywhere within seconds.
A similar thing should work with GitHub releases, where the propagation time is within minutes. When using
@branchreferences, our origin servers may cache individual files for up to 12 hours.
Note that "propagation time is within minutes" applies when you use the purge API, otherwise, there's still the CDN cache (12 hours).
That's actually a good heuristic. I wonder whether we should go back to
@latestif we can compel @valterkraemer to release a new version with the 10 commits after 2.0.1.
Hey, not used Mavo in a long time, so it's hard for me to make improvements to the code because I'm not familiar with it anymore. But I could make a release with existing code if that would help out ☺️
@valterkraemer Yup, just a release with the existing code is all that's needed! Thanks Valter!
TIL: jsDelivr has a tool to help with that — https://www.jsdelivr.com/tools/purge