Providers are unreliable

[spongessuck]

Functional impact

Builds fail because required lib files don't exist in project.

Minimal repro steps

1. Install files from a library (i.e. ladda@1.0.6, files: dist/ladda.min.js)
2. Ensure it works successfully
3. Later on, try to restore

Expected result

Files that restore successfully once should always restore successfully

Actual result

LibMan intermittently fails with error LIB002 or LIB018, or doesn't load the correct contents of the package (i.e., index.html instead of dist/**).

[ExcaliburVT]

I strongly suspect this is something with the cache. Our Azure DevOps Builds are working, but when i tried to restore again in Visual Studio it reported the same error as before. I cleaned the cache and restored and everything worked.

So more than likely the cdn is failing at some point and the cache is invalid but still believes its "ok". Might look at the code that internally tells the cache that something has been properly retrieved from the cdn and ensure that it doesn't mistakenly set the cache as valid if a failure occurs.

[josuemb]

I am having a lot of messages with CDNJS that suddenly appears:

My limbman.js is something like:

{ "version": "1.0", "defaultProvider": "cdnjs", "libraries": [ { "library": "jquery@3.4.1", "destination": "wwwroot/lib/jquery/", "files": [ "jquery.min.js" ] }, { "library": "twitter-bootstrap@4.4.0", "destination": "wwwroot/lib/twitter-bootstrap/", "files": [ "css/bootstrap.min.css", "js/bootstrap.bundle.min.js" ] }, { "library": "jquery-validate@1.19.1", "destination": "wwwroot/lib/jquery-validate/", "files": [ "jquery.validate.min.js", "localization/messages_es.min.js", "additional-methods.min.js" ] }, { "library": "jquery-validation-unobtrusive@3.2.11", "destination": "wwwroot/lib/jquery-validation-unobtrusive/", "files": [ "jquery.validate.unobtrusive.min.js" ] }, { "provider": "jsdelivr", "library": "axios@0.19.2", "destination": "wwwroot/lib/axios/", "files": [ "dist/axios.min.js" ] }, { "library": "vue@2.6.11", "destination": "wwwroot/lib/vue/", "files": [ "vue.min.js" ] }, { "provider": "jsdelivr", "library": "primevue@1.1.0", "destination": "wwwroot/lib/primevue/", "files": [ "resources/primevue.min.css", "resources/themes/nova-light/theme.min.css", "resources/themes/nova-light/fonts/open-sans-v15-latin-regular.ttf", "resources/themes/nova-light/fonts/open-sans-v15-latin-regular.woff", "resources/themes/nova-light/fonts/open-sans-v15-latin-regular.woff2", "resources/themes/nova-light/fonts/open-sans-v15-latin-700.ttf", "resources/themes/nova-light/fonts/open-sans-v15-latin-700.woff", "resources/themes/nova-light/fonts/open-sans-v15-latin-700.woff2", "components/datatable/datatable.umd.min.js", "components/datatable/tableloadingbody.umd.min.js", "components/column/column.umd.min.js", "components/columngroup/columngroup.umd.min.js", "components/inputtext/inputtext.umd.min.js", "components/button/button.umd.min.js", "components/dialog/dialog.umd.min.js", "components/panel/panel.umd.min.js", "components/calendar/calendar.umd.min.js", "components/dropdown/dropdown.umd.min.js", "components/autocomplete/autocomplete.umd.min.js", "components/inputmask/inputmask.umd.min.js", "components/listbox/listbox.umd.min.js", "components/sidebar/sidebar.umd.min.js", "components/breadcrumb/breadcrumb.umd.min.js", "components/tooltip/tooltip.umd.min.js" ] }, { "provider": "jsdelivr", "library": "@fortawesome/fontawesome-free@5.13.0", "destination": "wwwroot/lib/fontawesome-free/", "files": [ "css/fontawesome.min.css", "css/brands.min.css", "css/solid.min.css", "webfonts/fa-solid-900.ttf", "webfonts/fa-solid-900.woff", "webfonts/fa-solid-900.woff2" ] }, { "provider": "unpkg", "library": "primeicons@2.0.0", "destination": "wwwroot/lib/primeicons/", "files": [ "primeicons.css", "fonts/primeicons.ttf", "fonts/primeicons.woff" ] }, { "provider": "cdnjs", "library": "moment.js@2.24.0", "destination": "wwwroot/lib/moment/", "files": [ "moment-with-locales.min.js" ] }, { "provider": "cdnjs", "library": "moment-timezone@0.5.28", "destination": "wwwroot/lib/moment/", "files": [ "moment-timezone-with-data.min.js" ] } ] }

[josuemb]

Even when libman is pretty good, the CDNs are not. Forcing my team to change to another option like npm+gulp even when it's a most complex option.

[ygoe]

I wouldn't call it "good" without a solid local cache, like NuGet. Or does LibMan have such a cache meanwhile?

[jimmylewis]

LibMan does cache all the content files it downloads, except when using the FileSystem provider. Library metadata (package names/versions/contained files) is not cached as aggressively (I think it's one day), as it needs to be refreshed to detect when newer versions are released, etc.

A failing request for metadata could be the cause for the original error in this thread (e.g. "The 'foo' library could not be resolved by the "unpkg" provider" indicates that the library metadata couldn't be found). But the recent reports in the last couple days sounds more like corrupted metadata (e.g. ""jquery-validate@1.19.1" does not contain the following: ..." indicates that the metadata was resolved but incomplete).

[RomainLagardette]

I fixed my Azure DevOps pipeline errors by update the package Microsoft.Web.LibraryManager.Build from 2.0.96 to 2.1.76

But still have the same problem when i try to restore the package in visual studio. When i want to add a package with cdnjs, it found it but not the files

[ExcaliburVT]

Install the libman command line tool and use it's clear cache command and you should be able to restore.

On Sat, Apr 25, 2020, 1:46 AM Romain Lgrdtt notifications@github.com wrote:

I fixed my Azure DevOps pipeline errors by update the package Microsoft.Web.LibraryManager.Build from 2.0.96 to 2.1.76

But still have the same problem when i try to restore the package in visual studio. When i want to add a package with cdnjs, it found it but not the files [image: image] https://user-images.githubusercontent.com/6604926/80272342-ac44e980-86c8-11ea-9494-2fa14b5fd38c.png

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/aspnet/LibraryManager/issues/370#issuecomment-619326229, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAP37WQPXUPOB7OWGYTPOO3ROJ2KXANCNFSM4FTNJAGQ .

[jimmylewis]

If someone is in the state where cdnjs is not showing files in VS, or you're getting the "<library name>" does not contain the following error, I'd be interested to see your %localappdata%\.librarymanager\cache\cdnjs\<library name>\metadata.json and to know what library you're trying to use (libman.json is handy, but just library@version is enough).

[RyanTaite]

I'll try to get you that information the next time it happens to me or a teammate

[beleester]

I'm still experiencing the "Could not be resolved" error intermittently with version 2.1.76.

The "bootstrap-table@1.16.0" library could not be resolved by the "unpkg" provider

[RyanTaite]

I'm still experiencing the "Could not be resolved" error intermittently with version 2.1.76.

The "bootstrap-table@1.16.0" library could not be resolved by the "unpkg" provider

I ran into this issue before as well with unpkg and it turned out that I was being rate limited by the cdn. I believe I only found that out when I could see the failed response in either my browsers network tab or with Fiddlr. My solution was to switch to a different cdn

[ole1986]

Same for me

It seem to only occur when building while doing it from GUI these files are correctly stored UPDATE: Possible proxy issue?

Below is my libman.json

{
  "version": "1.0",
  "defaultProvider": "cdnjs",
  "libraries": [
    {
      "library": "twitter-bootstrap@4.5.0",
      "destination": "wwwroot/lib/bootstrap"
    },
    {
      "library": "font-awesome@5.13.0",
      "destination": "wwwroot/lib/font-awesome"
    },
    {
      "library": "popper.js@1.14.3",
      "destination": "wwwroot/lib/popper"
    },
    {
      "library": "jquery@3.1.1",
      "destination": "wwwroot/lib/jquery",
      "files": [ "jquery.min.js", "jquery.min.map", "jquery.js" ]
    },
    {
      "library": "jqueryui@1.12.0",
      "destination": "wwwroot/lib/jquery-ui",
      "files": [ "jquery-ui.js", "jquery-ui.css", "jquery-ui.min.css", "jquery-ui.min.js" ]
    },
    {
      "library": "bootstrap-datepicker@1.9.0",
      "destination": "wwwroot/lib/bootstrap-datepicker"
    },
    {
      "library": "jszip@3.1.5",
      "destination": "wwwroot/lib/jszip"
    },
    {
      "library": "bootstrap-select@1.13.11",
      "destination": "wwwroot/lib/bootstrap-select"
    },
    {
      "provider": "jsdelivr",
      "library": "JavaTMP/bootstrap-modal-wrapper@af22578098c97cb74057b477bd7eb5bdd7f882c1",
      "files": [
        "dist/bootstrap-modal-wrapper-factory.min.js"
      ],
      "destination": "wwwroot/lib/bootstrap-modal-wrapper"
    },
    {
      "provider": "jsdelivr",
      "library": "drvic10k/bootstrap-sortable@2.1.0",
      "files": [
        "Contents/bootstrap-sortable.css",
        "Scripts/bootstrap-sortable.js"
      ],
      "destination": "wwwroot/lib/bootstrap-sortable/"
    },
    {
      "provider": "jsdelivr",
      "library": "jquery/jquery@1.12.4",
      "files": [
        "dist/jquery.min.js"
      ],
      "destination": "wwwroot/lib/jquery-1.12.4/"
    }
  ]
}

[ardalis]

Running into this issue today as well. No proxy set up. Just a plan .NET solution using libman that normally works fine but is now failing every other build with errors like this:

Severity Code Description Project File Line Suppression State Error LIB002 The "bootstrap@3.3.7" library could not be resolved by the "unpkg" provider Web C:\dev\Github\eShopOnWeb\src\Web\libman.json 1

[gbjbaanb]

I reckon if the error message was changed to "failed to connect to xyz provider" then most of these problem reports would stop coming in. Everyone assumes the CDN will be 100% available, but that's just not going to be possible.

Cache, check in the files or otherwise stop trying to re-fetch the same files every time you build and you might not get rate-limited by the providers or hit by the occasonal internet connectivity glitch.

I think rate-limiting by the CDNs are most likely - they're designed around serving files once in a blue moon to users, not serving the same files every 5 minutes to a build server.

[Ghosts]

I reckon if the error message was changed to "failed to connect to xyz provider" then most of these problem reports would stop coming in. Everyone assumes the CDN will be 100% available, but that's just not going to be possible.

Cache, check in the files or otherwise stop trying to re-fetch the same files every time you build and you might not get rate-limited by the providers or hit by the occasonal internet connectivity glitch.

I think rate-limiting by the CDNs are most likely - they're designed around serving files once in a blue moon to users, not serving the same files every 5 minutes to a build server.

Or using a local version if the CDN call fails and issuing a warning that the files may not be up to date. Shouldn’t break a build for rate limiting issues, or institute a delay or retry on failed calls.

[beleester]

Agreed. If it's got the files downloaded already, failure to redownload the same thing shouldn't cause the build to fail. Maybe add a command line switch to force it to redownload if that's important for some reason.

[EdiWang]

I also encountered this issue for almost 6 month. I have to manually go to Azure DevOps and hit rebuild failed jobs every time the libman fails, until it have a success restore. I have 15 libs in my project, any one of them can fail to restore.

The "could not be resolved" doesn't mean the provider website is down, in fact every time I have a LIB002 error, the provider site is working fine, no matter cdnjs or unpkg.

I don't know if any retry mechanism was already implemented in libman, if not, could we just add a retry when a package restore fails because of so called "could not be resolved".

I don't really want to use NPM for simple ASP.NET Core project. It's like killing a fly with a missile. Libman was working fine years ago, what happened?

[kjkrum]

Part of the problem is that if a restoring single file in a large library fails, it does not retry and the whole build fails.

[ExcaliburVT]

Just got this again on our Azure DevOps Build:

[error]libman.json(0,0): Error LIB002: The "underscore.js@1.9.1" library could not be resolved by the "cdnjs" provider

[jimmylewis]

I think there's a few actionable items to take from this thread:

• The error message is unclear or, worse, giving a false impression of the issue. A blanket "could not be resolved" isn't clear what's going wrong.
• We cache library file contents locally, but for some providers we don't cache the metadata. This causes us to make some requests on every restore using those providers, which should be unnecessary. We can address this by caching the metadata as well (even just to use as a fallback).

@kjkrum we do have retry logic when downloading files to the local cache. Are you still seeing reliability issues? Can you get a trace of the traffic so we can try to see what responses are causing the failure?

[kjkrum]

@jimmylewis I may have just assumed there were no retries because I didn't see any messages about them, just the final failure. When I first encountered these reliability issues, I set up a test project with a dependency on AdminBSB. I forget which providers offer that package. AdminBSB contains a huge number of files, thousands IIRC, and is never successfully restored.

[ardalis]

This continues to be very frustrating.

[nickalbrecht]

I had an error from an AzureDevOps job the other day from this. Basically had to re-queue the job a handful of times until it finally solved itself. Not sure if it finally went through because of the job getting assigned to a different machine that didn't have caching issues or what though.

[SmRiley]

I wonder if I can customize the mirror source like Nuget, which is too reliant on the cloud, and I think my hard disk is more reliable than the cloud.Libman is a good tool, but CDN isn't

[rwasef1830]

To any mortal soul in eternal torture by this shockingly unfixed bug, here's a workaround:

1. Remove the NuGet package Microsoft.Web.LibraryManager.Build from your project.

2. Install dotnet tool: dotnet tool install Microsoft.Web.LibraryManager.Cli

3. Put this in your csproj that contains libman.json:

<!-- Workaround https://github.com/aspnet/LibraryManager/issues/370 -->
  <Target Name="RestoreFrontEndLibraries" BeforeTargets="BeforeBuild">
    <Exec Command="dotnet tool restore" />
    <Exec Command="dotnet tool run libman restore" LogStandardErrorAsError="true" ContinueOnError="true">
      <Output TaskParameter="ExitCode" PropertyName="ErrorCode" />
    </Exec>
    <Exec Command="dotnet tool run libman restore" LogStandardErrorAsError="true" ContinueOnError="true" Condition="$(ErrorCode) != '0'">
      <Output TaskParameter="ExitCode" PropertyName="ErrorCode" />
    </Exec>
    <Exec Command="dotnet tool run libman restore" LogStandardErrorAsError="true" ContinueOnError="true" Condition="$(ErrorCode) != '0'">
      <Output TaskParameter="ExitCode" PropertyName="ErrorCode" />
    </Exec>
    <Exec Command="dotnet tool run libman restore" LogStandardErrorAsError="true" ContinueOnError="true" Condition="$(ErrorCode) != '0'">
      <Output TaskParameter="ExitCode" PropertyName="ErrorCode" />
    </Exec>
    <Exec Command="dotnet tool run libman restore" LogStandardErrorAsError="true" ContinueOnError="true" Condition="$(ErrorCode) != '0'">
      <Output TaskParameter="ExitCode" PropertyName="ErrorCode" />
    </Exec>
    <Exec Command="dotnet tool run libman restore" LogStandardErrorAsError="true" ContinueOnError="true" Condition="$(ErrorCode) != '0'">
      <Output TaskParameter="ExitCode" PropertyName="ErrorCode" />
    </Exec>
    <Exec Command="dotnet tool run libman restore" LogStandardErrorAsError="true" ContinueOnError="true" Condition="$(ErrorCode) != '0'">
      <Output TaskParameter="ExitCode" PropertyName="ErrorCode" />
    </Exec>
    <Exec Command="dotnet tool run libman restore" LogStandardErrorAsError="true" ContinueOnError="true" Condition="$(ErrorCode) != '0'">
      <Output TaskParameter="ExitCode" PropertyName="ErrorCode" />
    </Exec>
    <Exec Command="dotnet tool run libman restore" LogStandardErrorAsError="true" ContinueOnError="true" Condition="$(ErrorCode) != '0'">
      <Output TaskParameter="ExitCode" PropertyName="ErrorCode" />
    </Exec>
    <Exec Command="dotnet tool run libman restore" LogStandardErrorAsError="true" ContinueOnError="false" Condition="$(ErrorCode) != '0'" />
  </Target>

This code retries up to 10 times, you can copy / paste one of the middle <Exec> tags to add more retry attempts. May you find peace at last.

[SmRiley]

对于任何因此令人震惊而无法修复的错误而遭受永远折磨的凡人灵魂，这里有一种解决方法：

1. 从您的项目中删除NuGet包Microsoft.Web.LibraryManager.Build。
2. 安装dotnet工具： dotnet tool install Microsoft.Web.LibraryManager.Cli
3. 将其放入包含libman.json的csproj中：

<！-解决方法https://github.com/aspnet/LibraryManager/issues/370- > 
  <目标 名称 = “ RestoreFrontEndLibraries ”  BeforeTargets = “ BeforeBuild ” >
    < Exec  命令 = “ dotnet工具还原” />
    < Exec  命令 = “ dotnet工具运行libman restore ”  LogStandardErrorAsError = “ true ”  ContinueOnError = “ true ” >
      <输出 TaskParameter = “ ExitCode ”  PropertyName = “ ErrorCode ” /> 
    </ </ Exec > 
    < Exec  命令 = “ dotnet工具运行libman restore ”  LogStandardErrorAsError = “ true ”  ContinueOnError = “ true ”  Condition = “ $（ErrorCode）！='0' “ > 
      < 输出 TaskParameter = ”ExitCode “  PropertyName= “ ErrorCode ” /> 
    </ Exec > 
    < Exec  命令 = “ dotnet工具运行libman restore ”  LogStandardErrorAsError = “ true ”  ContinueOnError = “ true ” 条件 = “ $（ErrorCode）！='0' ” > 
      < 输出 TaskParameter = “ ExitCode “  PropertyName = ” ErrorCode “ /> 
    </ 执行 >
    < Exec  命令 = “ dotnet工具运行libman restore ”  LogStandardErrorAsError = “ true ”  ContinueOnError = “ true ” 条件 = “ $（ErrorCode）！='0' ” > 
      < 输出 TaskParameter = “ ExitCode ”  PropertyName = “ ErrorCode ” /> 
    < / 执行 > 
    < 执行 命令 = “dotnet工具运行libman restore “ LogStandardErrorAsError = “ true ”  ContinueOnError = “ true ” 条件 = “ $（ErrorCode）！='0' ” > 
      < 输出 TaskParameter = “ ExitCode ”  PropertyName = “ ErrorCode ” /> 
    </ Exec > 
    < Exec  Command = “ dotnet工具运行libman恢复“  LogStandardErrorAsError = “ true ” ContinueOnError =“ true ” 条件 = “ $（ErrorCode）！='0' ” >
      <输出 TaskParameter = “ ExitCode ”  PropertyName = “ ErrorCode ” />
    </ exec >
    < Exec  命令 = “ dotnet工具运行libman restore ”  LogStandardErrorAsError = “ true “  ContinueOnError = ” true “ 条件 = ”$（ErrorCode）！='0' “> 
      < 输出 TaskParameter = “的ExitCode ” 属性名 = “错误代码” /> 
    </ Exec的 > 
    < Exec的 命令 = “ DOTNET工具运行利布曼恢复”  LogStandardErrorAsError = “真”  ContinueOnError = “真” 条件 = “ $（错误码）！=' 0' “ > 
      <输出 TaskParameter = “ ExitCode“  PropertyName = ” ErrorCode “ />
    </ </ Exec >
    < Exec  Command = ” dotnet工具运行libman restore “  LogStandardErrorAsError = ” true “  ContinueOnError = ” true “  Condition = ” $（ErrorCode）！='0' “ >
      <输出 TaskParameter = “ ExitCode ”  PropertyName = “错误代码“ />
    </执行 > 
    < 执行 命令 = “ dotnet工具运行libman restore ”  LogStandardErrorAsError = “ true ”  ContinueOnError = “ false ” 条件 = “ $（ErrorCode）！='0' ” /> 
  </ 目标 >

此代码最多重试10次，您可以复制/粘贴其中一个中间<Exec>标签以添加更多重试次数。 愿你终于找到和平。

I don't think it can solve the problem that cdnjs cannot connect

[rwasef1830]

It doesn't solve the problem of connect failure, but it just does retry, it works after some times. Better than build server random failure due to this issue.

[SmRiley]

It doesn't solve the problem of connect failure, but it just does retry, it works after some times. Better than build server random failure due to this issue.

I think it is more important for subsequent versions to customize the mirror source like Nuget. Now everything is built on the damn cloud

[gbjbaanb]

It doesn't solve the problem of connect failure, but it just does retry, it works after some times. Better than build server random failure due to this issue.

It won't help you one bit if the CDN providers rate-limit you because your build server is fetching from their servers too often. Its hardly a responsible practice either, if you're building using this service, then commit your libraries or the relevant files.

[nickalbrecht]

Typically when this happens for me, LibMan may claim it can't be reached, but if I navigate to the URL manually in a browser it will come up. I'm more inclined to believe it's an inconsistent behavior with the caching in LibMan versus the CDN refusing to fulfill the request. Every time that I can remember navigating to the URL manually, the resource was found.

[gbjbaanb]

Perhaps if libman reported the http status code it might be a little more obvious, if it is rate-limited rather than generally failed to fetch the data. I don't think the caching is at fault, as libman will be attempting to fetch something (that 'metadata') from the CDN to determine if its cache is up-to-date.

Stick wireshark on, and see for yourself what happens in the meantime.

[EdiWang]

Today on my computer, I have The "tinymce@5.7.1" library could not be resolved by the "cdnjs" provider, but my build server is fine.

So I download and debug Libman source code, in my case, it is caused by an exception when trying to parse JSON.

Unterminated string. Expected delimiter: ". Path 'assets[104].files[32]', line 1, position 2398115.

The requested URL was https://api.cdnjs.com/libraries/tinymce

The json string has an invalid ending:

I request the URL from Microsoft Edge browser and use notepad++ to view the JSON and found the same thing

But when using Google Chrome to request the JSON, to my surprise, it is fine:

I RDP into my build server, request the same JSON from Microsoft Edge, it is also fine.

So I guess it may be a network issue or CDN issue that give me a bad json. I try to switch to a different network using a VPN, but libman still fails. After debug, I found it is caching the old bad json.

The cached file is located in "C:\Users\Edi\AppData\Local\.librarymanager\cache\cdnjs\tinymce\metadata.json"

After clean up the local cache, everything works fine.

So I would suggest libman DO NOT cache bad json file when having an exception during the installation.

[gbjbaanb]

That suggests its not Libman at fault at all but the networking subsystem, which is not surprising as all Windows http stack is built on the same internet management stuff. So once you have a malformed download, it sticks in the browser cache (that libman is leveraging). The cache will contain this json as it will have assumed a correct download - I doubt any http get will cache a failed request!

So now you're looking at the duration these items stay in the cache for. The only thing Libman can do in this situation is to give a better error message that the file is corrupt. If it can (and this is doubtful) remove it from the cache so it gets refreshed, so much the better.

[kjkrum]

That's still Libman's fault, just in a different way. If the system cache doesn't work the way Libman needs it to work, Libman shouldn't be using the system cache.

[jimmylewis]

@gbjbaanb libman has its own cache, so we can be smarter here about not caching a broken response payload.

@EdiWang thanks for the detailed writeup, I've opened #630 to track this specific behavior.

[EdiWang]

@gbjbaanb @kjkrum It's not in the system cache or browser cache, it's libman's own cache located in "C:\Users\<Username>\AppData\Local\.librarymanager\cache\"

The problem is libman downloaded the broken json file (which http status code is still 200), did not validate it's format before caching it.

[EdiWang]

To clear the cache, we can either manually delete C:\Users\<Username>\AppData\Local\.librarymanager\cache or from libman CLI:

dotnet tool install -g Microsoft.Web.LibraryManager.Cli

then

libman cache clean

Reference: https://docs.microsoft.com/en-us/aspnet/core/client-side/libman/libman-cli?view=aspnetcore-5.0#manage-library-cache

[pynej]

https://api.cdnjs.com/libraries/ace is now broken. (the CDN version, not my local cache.) I will reiterated the improved error messages, as this was giving "library could not be resolved" when it should be able to see that it's corrupted and have a more clear message indicating that it's not user error and the package proovider needs to be notified. I made ticked with ace but I'm not sure if they are pushing the cdnjs package themselves, or if it is just a bad cached file in the cdn network or something.

[hoshinokanade]

A year passed the providers are still very unreliable: It randomly fails the CI and we can do nothing but to speed up plans to migrate away from Libman as soon as possible.

[maxt3r]

The issue is still happening:

libman.json : error LIB002: The "font-awesome@4.7.0" library could not be resolved by the "cdnjs" provider

Running libman cache clean seems to have helped.

[jimmylewis]

@maxt3r if this just recently started happening for cdnjs, it's probably due to #685

[vivekthangaswamy]

One of the actions that helped me solve this problem was updating project packages with stable releases. Some of my packages were running in depreciated version.