Skip to content

yarn.lock (berry) files are not properly parsed when multiple dependencies were resolved to a single version #55

@michael42

Description

@michael42

Hi there,

kudos for the project, trying it out currently, to hopefully replace some of my shell scripts for sifting through dependency changes.

Unfortunately, v0.8.1 doesn't get far on a yarn (4.10.3) project, because the parser is not correctly parsing common cases like:

__metadata:
  version: 8
  cacheKey: 10c0

"caniuse-lite@npm:^1.0.30001702, caniuse-lite@npm:^1.0.30001746":
  version: 1.0.30001750
  resolution: "caniuse-lite@npm:1.0.30001750"
  checksum: 10c0/aa77ebf264ca8dcfe913fadaa19f06bf839d65dec24498fdb9c45739ab0828b8275ca30c698f4ee86829d38264eaa461edf4577e407753da8205ab1d285e105d
  languageName: node
  linkType: hard

This declares that both caniuse-lite ^1.0.30001702 and ^1.0.30001746 were resolved to 1.0.30001750. Instead, it's currently parsed as "caniuse-lite@^1.0.30001702, caniuse-lite", which then fails to download a very broken looking https://registry.npmjs.org/caniuse-lite@^1.0.30001702, caniuse-lite/-/caniuse-lite@^1.0.30001702, caniuse-lite-1.0.30001750.tgz:

Error: Failed to download tarball from https://registry.npmjs.org/caniuse-lite@^1.0.30001702, caniuse-lite/-/caniuse-lite@^1.0.30001702, caniuse-lite-1.0.30001750.tgz: 404
    at downloadTarball (.../multiocular/server/loader/npm.js:64:11)
    at process.processTicksAndRejections (node:internal/process/task_queues:105:5)
    at async getNpmContent (.../multiocular/server/loader/npm.js:90:25)
    at async Object.findRepository (.../multiocular/server/loader/diffs/npm.js:95:22)
    at async .../multiocular/server/loader/index.js:87:22
    at async Promise.all (index 1)
    at async loadDiffs (.../multiocular/server/loader/index.js:85:3)

For a quick workaround, I added pkg = pkg.split(",")[0].trim() to splitPackage (which avoided the crash, so I could see some UI). But I'm not sure where and how that name is actually used (and I'd assume it would make more sense to consider such cases as separate dependency entries, instead of just throwing away everything but the first package).

I had a look at the unit-tests, too, but struggled to find suitable real packages and got rate-limited soon after. Maybe mocking the API and including some packages just for the tests would help?

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions