Support the /+esm endpoint on jsDelivr packages

[jennierose]

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

Some libraries available through jsDelivr have no default JS file specified by the package author. Libraries packaged for NPM are often meant to be included as CJS modules, with the expectation that the developer will use a tool like webpack or Rollup.js to prepare the code to run client-side. On jsDelivr packages sometimes have this disclaimer under the "install" code snippet:

No default JS file set by the package author so the URL is guessed. You can always browse all package files to use another one.

Luckily jsDelivr provides a more reliable option - fetching the library as an ES module, as illustrated in this example:

<script type="module">
    import coreJs from 'https://cdn.jsdelivr.net/npm/core-js@3.45.0/+esm'
</script>

jsDelivr uses Rollup.js to generate the ESM version of the package and exposes the result when it sees /+esm appended to the URL. This is a very helpful feature provided by the CDN, but as far as I can tell there is currently no way to leverage this feature with LibMan.

Describe the solution you'd like

It would be a nice convenience if there was some way to tell LibMan to fetch pre-bundled libraries from jsDelivr. I think the simplest syntax for this would be:

    {
      "provider": "jsdelivr/esm",
      "library": "core-js@3.45.0",
      "destination": "wwwroot/lib/core-js/index.mjs"
    }

The file name, [library name]/index.mjs, could be inferred, though I believe that is a separate issue.

Describe alternatives you've considered

I did try "tricking" LibMan into fetching a generated ESM for me with something like this:

    {
      "provider": "jsdelivr",
      "library": "core-js@3.45.0",
      "files": [ "/+esm" ]
    }

Of course, that doesn't work because there is no literal "/+esm" file in this package. A more sensible and straightforward alternative syntax might be:

    {
      "provider": "jsdelivr",
      "library": "core-js@3.45.0/+esm"
    }

Additional context

I've found a few examples, like parse and locutus, where the /+esm endpoint is the only install option shown on the download page.

Locutus is an odd example, because the package contains a very large collection of submodules. I've found that jsDelivr supports a form of tree shaking by allowing /+esm to be appended to individual files in the library:

<script type="module">
        import pcre from 'https://cdn.jsdelivr.net/npm/locutus@2.0.32/php/pcre/+esm'
        import sprintf from 'https://cdn.jsdelivr.net/npm/locutus@2.0.32/php/strings/sprintf.js/+esm'
</script>

LibMan might be able to take advantage of this feature as well:

    {
      "provider": "jsdelivr/esm",
      "library": "locutus@2.0.32",
      "destination": "wwwroot/lib/locutus",
      "files": [
        "/php/pcre/index.js",
        "/php/strings/sprintf.js"
      ]
    }

[jimmylewis]

Personally, I like the jsdelivr/esm provider approach. It clarifies that it's not going to behave the same way as jsdelivr does for fetching individual files or globs; and it does allow the flexibility to use for the whole library (a sensible default) or for the advanced tree-shaking case.