+esm version of library no longer available for rita package

dhowe commented 8 months ago

Description

I had previously been using the url: https://cdn.jsdelivr.net/npm/rita/+esm to import the rita library, but as of this week the file is no longer found. The only changes in the library since last release were fields of package.json (export). Any reason why this file would disappear with a change to package.json ?

Specific changes

Old (working):

  "main": "dist/rita.js",
  "browser": "./dist/rita.min.js",
  "types": "dist/rita.d.ts",
  "exports": {
    ".": {
      "import": "./dist/rita.js",
      "require": "./dist/rita.cjs"
    }
  }

New (broken):

  "main": "dist/rita.js",
  "browser": "./dist/rita.min.js",
  "exports": {
    ".": {
      "import": {
        "default": "./dist/rita.js",
        "types": "./dist/rita.d.ts"
      },
      "require": {
        "default": "./dist/rita.cjs",
        "types": "./dist/rita.d.cts"
      }
    }
  },

Affected jsDelivr links

https://cdn.jsdelivr.net/npm/rita/+esm

Response headers

Error: Couldn't find the requested file.

Information

OS X 11.7.9 tested in multiple browsers

Requisites

[X] I performed a cursory search of the issue tracker to avoid opening a duplicate issue.
[X] I checked the documentation to understand that the issue I am reporting is not normal behavior.
[X] I understand that not filling out this template correctly will lead to the issue being closed.

Additional content

No response

MartinKolarik commented 8 months ago

This particular change should no break anything, and the posted link works for me:

dhowe commented 8 months ago

The link works again because I reverted package.json to the old entries in version 3.0.27. When I use the new entries, that file disappears. Can you describe what triggers the creation of the file via rollup/terser ?

MartinKolarik commented 8 months ago

Indeed, I can see the problem with 3.0.26. Will take a look.

MartinKolarik commented 8 months ago

The resolver fails with the error Error: Default condition should be last one, see docs:

"default" - the generic fallback that always matches. Can be a CommonJS or ES module file. This condition should always come last.

It should work if you move types to be before default.

dhowe commented 8 months ago

This may indeed solve the specific issue (I'm hesitant to try because I don't want to again break work for downstream users), but the larger problem is that this failure is opaque to the me as library maintainer. I suppose I would need to integrate specific tests of the jsdelivr urls into my build process... But on a failure, where would I find the resolver logs you refer to for debugging ?

MartinKolarik commented 8 months ago

The error logs are not public, unfortunately. In most error cases, the response itself indicates the reason, but resolver errors are not so clear, that's something we might improve in the feature.

In this specific case, if you want to make sure it'll work after that change, a beta release might be a good option. 3.0.28-beta will be ignored for our "latest" link https://cdn.jsdelivr.net/npm/rita/+esm but you can still access it directly via https://cdn.jsdelivr.net/npm/rita@3.0.28...

dhowe commented 8 months ago

Would be ideal if the resolver error could be passed to the generated file

jsdelivr / jsdelivr