bug(yarn): wrong package name when dependenciesMeta field exists

[DmitriyLewen]

Discussed in #5565

Descrtiption

Dependencies under dependenciesMeta field use same pattern as package.
e.g.:

# This file is generated by running "yarn install" inside your project.
# Manual changes might be lost - proceed with caution!

__metadata:
  version: 8
  cacheKey: 10c0

"app@workspace:.":
  version: 0.0.0-use.local
  resolution: "app@workspace:."
  dependencies:
    debug: "npm:^4.3.4"
  dependenciesMeta:
    [email protected]:
      unplugged: true
  languageName: unknown
  linkType: soft

"debug@npm:^4.3.4":
  version: 4.3.4
  resolution: "debug@npm:4.3.4"
  dependencies:
    ms: "npm:2.1.2"
  peerDependenciesMeta:
    supports-color:
      optional: true
  checksum: cedbec45298dd5c501d01b92b119cd3faebe5438c3917ff11ae1bff86a6c722930ac9c8659792824013168ba6db7c4668225d845c633fbdafbbf902a6389f736
  languageName: node
  linkType: hard

"ms@npm:2.1.2":
  version: 2.1.2
  resolution: "ms@npm:2.1.2"
  checksum: a437714e2f90dbf881b5191d35a6db792efbca5badf112f87b9e1c712aace4b4b9b742dd6537f3edf90fd6f684de897cec230abde57e87883766712ddda297cc
  languageName: node
  linkType: hard

[DmitriyLewen]

Hello @brentswisher
I created fix for this bug, but when i tried to add test - I was unable to reproduce your case for the test.
When i use yarn unplag <package name> - yarn adds dependenciesMeta only for my app.
But my app has workspace protocol. We skip workspace protocols.

"app@workspace:.":
  version: 0.0.0-use.local
  resolution: "app@workspace:."
  dependencies:
    debug: "npm:^4.3.4"
  dependenciesMeta:
    [email protected]:
      unplugged: true
  languageName: unknown
  linkType: soft

What am i missing?

[brentswisher]

Yeah, it is a bit tricky to reproduce.

flowchart TD
    A[Package A] -->|hasDependency| B(Package B)
    B --> |hasUnpluggedDependency| C(Some External Package)

Loading

The bug manifests when the package with the dependenciesMeta declaration (Package B) is included as a dependency in another package (Package A). Then when trivy is run on Package A, it reports the version of package B as the version of the external package. So for your test case you will need two packages to be able to reproduce the issue.

[DmitriyLewen]

I tried to do that, but got same result:

# This file is generated by running "yarn install" inside your project.
# Manual changes might be lost - proceed with caution!

__metadata:
  version: 8
  cacheKey: 10c0

"app@workspace:.":
  version: 0.0.0-use.local
  resolution: "app@workspace:."
  dependencies:
    react: "npm:^18.2.0"
  dependenciesMeta:
    [email protected]:
      unplugged: true
  languageName: unknown
  linkType: soft

"js-tokens@npm:^3.0.0 || ^4.0.0":
  version: 4.0.0
  resolution: "js-tokens@npm:4.0.0"
  checksum: e248708d377aa058eacf2037b07ded847790e6de892bbad3dac0abba2e759cb9f121b00099a65195616badcb6eca8d14d975cb3e89eb1cfda644756402c8aeed
  languageName: node
  linkType: hard

"loose-envify@npm:^1.1.0":
  version: 1.4.0
  resolution: "loose-envify@npm:1.4.0"
  dependencies:
    js-tokens: "npm:^3.0.0 || ^4.0.0"
  bin:
    loose-envify: cli.js
  checksum: 655d110220983c1a4b9c0c679a2e8016d4b67f6e9c7b5435ff5979ecdb20d0813f4dec0a08674fcbdd4846a3f07edbb50a36811fd37930b94aaa0d9daceb017e
  languageName: node
  linkType: hard

"react@npm:^18.2.0":
  version: 18.2.0
  resolution: "react@npm:18.2.0"
  dependencies:
    loose-envify: "npm:^1.1.0"
  checksum: b562d9b569b0cb315e44b48099f7712283d93df36b19a39a67c254c6686479d3980b7f013dc931f4a5a3ae7645eae6386b4aa5eea933baa54ecd0f9acb0902b8
  languageName: node
  linkType: hard

[brentswisher]

🤔 hmm, not sure I will try to recreate it again and track the yarn commands it took to get there

[DmitriyLewen]

Thank you! This will help me a lot.