Currently, unpkg and jsdelivr support using 'latest' as a version. When files are requested by libman, they redirect (HTTP302) to the URL for the current latest files. We put those files into the cache like any other version (in a folder name 'latest') and all is well.
However, when a new version is released, libman continues to use the now-stale downloaded assets from the cache. There isn't a signal to realize when to purge the latest version from the cache.
This change instead simply turns 'latest' into the latest version we determine from the provider. There is a small risk that we are out of sync with the CDN: for example, since we get the version data from NPM, it might not match the version that e.g. jsdelivr redirects to. But this should be extremely rare.
Doing it this way also allows cdnjs to support 'latest'. I didn't add it to the completion items, but I did verify that it works (CLI install, restore, and the file list in VS all support foo@latest for cdnjs now too).
Currently, unpkg and jsdelivr support using 'latest' as a version. When files are requested by libman, they redirect (HTTP302) to the URL for the current latest files. We put those files into the cache like any other version (in a folder name 'latest') and all is well.
However, when a new version is released, libman continues to use the now-stale downloaded assets from the cache. There isn't a signal to realize when to purge the latest version from the cache.
This change instead simply turns 'latest' into the latest version we determine from the provider. There is a small risk that we are out of sync with the CDN: for example, since we get the version data from NPM, it might not match the version that e.g. jsdelivr redirects to. But this should be extremely rare.
Doing it this way also allows cdnjs to support 'latest'. I didn't add it to the completion items, but I did verify that it works (CLI install, restore, and the file list in VS all support foo@latest for cdnjs now too).
Resolves #748