[Bug?]: Error for packages without any versions

[cd-work]

Self-service

• I'd be willing to implement a fix

Describe the bug

When running Yarn against a package that provides an empty versions object on the metadata, the following error is printed:

➤ YN0027: typescript@unknown can't be resolved to a satisfying range
➤ YN0001: TypeError: Cannot read properties of undefined (reading 'dist')
    at Fv.getCandidates (/home/chris/.cache/node/corepack/v1/yarn/4.5.3/yarn.js:688:7154)
    at process.processTicksAndRejections (node:internal/process/task_queues:105:5)
    at async Pg.getCandidates (/home/chris/.cache/node/corepack/v1/yarn/4.5.3/yarn.js:141:1271)
    at async uH (/home/chris/.cache/node/corepack/v1/yarn/4.5.3/yarn.js:401:9441)
    at async /home/chris/.cache/node/corepack/v1/yarn/4.5.3/yarn.js:401:8776
    at async C (/home/chris/.cache/node/corepack/v1/yarn/4.5.3/yarn.js:401:7127)
    at async T2 (/home/chris/.cache/node/corepack/v1/yarn/4.5.3/yarn.js:401:8456)
    at async /home/chris/.cache/node/corepack/v1/yarn/4.5.3/yarn.js:402:531
    at async Promise.all (index 0)
    at async /home/chris/.cache/node/corepack/v1/yarn/4.5.3/yarn.js:402:488
➤ Errors happened when preparing the environment required to run this command.

This was reproduced with a custom registry, however other package managers like npm and pnpm do not run into errors with this. It seems reasonable to me that an empty versions object should be treated like a 404 on the endpoint, which gives essentially the same output just without the "ugly" backtrace and error.

The endpoint hit here specifically should be https://registry.npmjs.org/typescript, or its corresponding version with the private registry.

To reproduce

It might be possible to reproduce this with a package that had versions completely unpublished, I'm not entirely sure to which degree that is possible with NPM.

The easiest way is likely to run it against a proxy where one has full control over the response. I'd imagine it should be easy to reproduce by just editing the response object in the code itself, even if that is not a "real world" reproduction of this bug.

If more detailed reproduction steps are necessary, please let me know. But I'd imagine this should be quite simple to fix if it is considered to be a bug with Yarn.

Environment

System:
    OS: Linux 6.11 Arch Linux
    CPU: (16) x64 11th Gen Intel(R) Core(TM) i7-11800H @ 2.30GHz
  Binaries:
    Node: 22.10.0 - /tmp/xfs-81f281ff/node
    Yarn: 1.22.19 - /tmp/xfs-81f281ff/yarn
    npm: 10.9.0 - /usr/bin/npm
    pnpm: 9.12.2 - /usr/bin/pnpm

Additional context

No response

[clemyan]

provides an empty versions object on the metadata
just editing the response object

The problem with just removing the versions is that dist tags will now point to versions that do not exist, making the pakument inconsistent.

{
    "_id": "lodash",
    "dist-tags": {
        "latest": "4.17.21"
    },
    "versions": {}
    //...
}

When adding packages without specifying a range (e.g. yarn add lodash), we install the version pointed to by the latest dist tag. The fact that it points to a non-existent version is what causes an unexpected error. We prettify expected errors, but unexpected errors displays the stack trace.

If instead the latest tag does not exist at all (which is an expected error) then the message is prettified

> yarn add lodash
➤ YN0027: lodash@unknown can't be resolved to a satisfying range
➤ YN0016: Registry failed to return tag "latest"

➤ Errors happened when preparing the environment required to run this command.

Adding a specific range that is not satisfiable is also an expected error

> yarn add [email protected]
➤ YN0000: · Yarn 4.5.3
➤ YN0000: ┌ Resolution step 
➤ YN0082: │ lodash@npm:4.17.21: No candidates found
➤ YN0000: └ Completed in 18s 513ms
➤ YN0000: · Failed with errors in 18s 528ms

---

empty versions object should be treated like a 404 on the endpoint

HTTP status codes convey semantics. A registry saying "This package does not exist" and "This package exists but has no versions" is semantically distinct. Reinterpreting a 200 as a 404 will just leads to more problems down the line, especially if the error message says the registry returned 404 which would be very confusing for registry developers.

And FWIW, the npm cli does not treat those two as the same either. For one, with both Yarn and npm, 200s are cached and 404s are not.

[cd-work]

That's a good point, I'm not sure what NPM or PNPM do differently in this case, but this seems like very reasonable behavior.

Filtering out the latest version with the private registry in a scenario where no versions are present seems like the correct choice, however I'm curious if there is a good solution when only the latest version is filtered. The registry at that point has no way of truly knowing what the latest version before that was as far as I can tell, so would the expected behavior be to just sort by semver versions without suffix and pick the highest one? I'd assume this isn't something yarn can do itself?

I appreciate the detailed response, feel free to close this issue any time I think the root of the issue has been resolved.

[yarnbot]

Hi! 👋

It seems like this issue as been marked as probably resolved, or missing important information blocking its progression. As a result, it'll be closed in a few days unless a maintainer explicitly vouches for it.