Add NPM as a provider

[Piedone]

Is your feature request related to a problem? Please describe.

Using LibMan puts the chosen provider as a critical dependency of your build. This is expected, but also risky, especially since we're talking about unofficial ones. If the provider fails, all your builds will fail (unless there can be a secondary one: https://github.com/aspnet/LibraryManager/issues/806). NPM can have outages as well, but I'd consider using it an easier sell than community projects, even if they're awesome.

Furthermore, using NPM feels a bit more secure as well to avoid supply chain attacks.

Describe the solution you'd like

Add NPM as a new provider. While not obvious, you can also download the packages from NPM via HTTP. E.g. this one is for the current latest chart.js package: https://registry.npmjs.org/chart.js/-/chart.js-4.5.1.tgz.

Describe alternatives you've considered

Having secondary providers: https://github.com/aspnet/LibraryManager/issues/806.

Additional context

Nothing else.

[jimmylewis]

The biggest challenge with this is to generate the file catalog efficiently. When adding/editing a library, we need a complete list of all files in that library. We can't even do a restore without this list, as the restore operation validates that the files to be installed exist within the package. All of the other providers offer a manifest that we can download and list all of the files available very cheaply. To my knowledge, NPM does not offer this, so we would need to download the tgz file locally and extract it before we could catalog its contents.

Tradeoffs:

• Pro: an NPM provider is considerably a source of truth for packages
• Pro: for large libraries, the download might be faster as a single request and compressed content
• Con: for sparse installations (e.g. I only want a couple files), we need to pay the full download cost
• Con: we have to pay a large delay up front (download + extract archive). This may cause unexpected perceived responsiveness issues, as the download would block
  • validating the files or fileMappings in the libman.json file, or offering completions
  • showing the file list in the Add Client-side Library wizard. This one could spiral into triggering multiple unnecessary downloads if the user is editing the version multiple times.

It might be possible to use the unpkg catalog instead to avoid the overhead, but then you depend on unpkg and NPM separately. It could also break if unpkg ever supported different features (like JSDelivr does, see next line).

JSDelivr's catalog cannot be used, as their catalog includes extra files for every package (minimized) that don't existing in the original. Cdnjs' catalog cannot be used, as their library contents do not match the layouts of NPM packages.

[Piedone]

I see. So NPM could be a most certainly slower provider. While I'd consider that an acceptable compromise to use the authoritative package registry for some, I can't honestly say my team would choose that.

[jimmylewis]

Yeah, exactly. This is something I've thought about doing for exactly the reasons you suggested, but I'm hesitant to offer it as an equal to the others because the dev experience would vary dramatically.