unpkg @latest does not point to the latest version

[alex-jitbit]

Describe the bug

@latest does not point to the latest version

To Reproduce

1. Install signalr like this

      "provider": "unpkg",
      "library": "@microsoft/signalr@latest",
      "destination": "wwwroot/Scripts/",
      "files": [
        "dist/browser/signalr.min.js",
        "dist/browser/signalr.js"
      ]

2. It will install 5.0.9
3. But the latest version is 5.0.10

Expected behavior

Should be 5.0.10

Unpkg redirects properly: click this link https://www.unpkg.com/browse/@microsoft/signalr@latest/

[jimmylewis]

I think this was a point in time issue, I tried it and it now installs 6.0.0.

[alex-jitbit]

@jimmylewis libman cache clean resolves this.

However I wonder how can it clean the cache faster. We publish OSS parts of our project to npm and want to update it right away, after the CDN picked up the changes

Visual Studio does show that a new version is found if I click the light bulb, however @latest still points to the old one

[jimmylewis]

I think I understand better now. Libman does cache the metadata results for each package for 1 day, so that if you're repeatedly querying the same data, it's already downloaded. This behavior is intended to mitigate flakiness in the requests and is based on the assumption that most users will not need the absolute freshest data. However, your scenario is exactly the opposite of that assumption.

I see two fixes that would both make lots of sense:

1. Add a setting for metadata cache timeout. Currently it's hardcoded here. Allowing this to be set to 0 would always request the provider metadata.
2. Add an option to libman cache clean to clean only cached metadata. This would allow prompter discovery of changes such as new package versions, without removing the locally cached copies of library contents.

[CePur]

Relevant: dotnet/AspNetCore.Doc#31452

[jimmylewis]

@CePur the linked issue sounds different: if I'm reading correctly, using @microsoft/signalr@8.0.0 downloaded the wrong file, but that library ID has an explicit version (8.0.0) specified, not latest.

In this original thread, the equivalent would be using @microsoft/signalr@latest and have that resolve to <8.0.0 due to cached metadata (i.e. libman is locally unaware of 8.0.0 because it had cached metadata from < 1 day that didn't include that version). This issue would resolve after the cached metadata was 1 day old and libman refreshed its metadata cache.

(Side note: if libman didn't know about the 8.0.0 version originally, it would fail to resolve the library.)

The linked threads sounds like either unpkg served the wrong file for https://unpkg.com/@microsoft/signalr@8.0.0/dist/browser/signalr.js, or you somehow had a wrong copy of that file in the libman cache (once cached, it wouldn't be downloaded again until the cache was cleared).

Did clearing the cache resolve the problem? Are you still able to reproduce it?

[CePur]

@jimmylewis When I set @microsoft/signalr@latest, it resolves to the wrong version. However, @microsoft/signalr@8.0.0 resolves to the correct one. I just checked, so it shouldn't be related to 1-day cache but, using the CLI to clear and restore cache resolved the issue. Thanks for the detailed explanation and for pointing out the right direction.

[jimmylewis]

Oooh, I think I see the problem. When libman caches the @latest version, it puts it into a folder named latest within the cache (as the version). Since latest changes over time but the cache doesn't get cleared, a stale file from an older version would be used from the local cache (i.e. if you had used latest when it was 7.0.0, then when latest moves to 8.0.0, you'll still get the 7.0.0 file from the local cache).

Seems like the fix here should be to translate latest to a real version when saving files in the cache (i.e. in this case, ...@latest should save the files in a 8.0.0 folder within the cache).