Lockfile generated with Yarn Berry is invalid

[veimox]

Current Behavior

When using Yarn 3 in a Nx workspace, running @nx/next:build with generateLockfile generates a lockfile that contains an empty package name:

"":
  version: 1.22.3
  resolution: "resolve@patch:resolve@npm%3A1.22.3#~builtin<compat/resolve>::version=1.22.3&hash=c3c19d"
  dependencies:
    is-core-module: ^2.12.0
    path-parse: ^1.0.7
    supports-preserve-symlinks-flag: ^1.0.0
  bin:
    resolve: bin/resolve
  checksum: ad59734723b596d0891321c951592ed9015a77ce84907f89c9d9307dd0c06e11a67906a3e628c4cae143d3e44898603478af0ddeb2bba3f229a9373efe342665
  languageName: node
  linkType: hard

This forces an error when running yarn install over that lock file.

Expected Behavior

The generated lockfile should be valid.

GitHub Repo

https://github.com/veimox/nx-next-lockfile-issue/tree/main

Steps to Reproduce

1. Run yarn install to install dependencies with Yarn 3
2. Run nx run my-app:build:production
3. Look at dist/packages/my-app/yarn.lock

Nx Report

>  NX   Report complete - copy this into the issue template

   Node   : 18.17.1
   OS     : darwin-x64
   yarn   : 3.6.0
   
   nx                 : 16.7.2
   @nx/js             : 16.7.2
   @nx/jest           : 16.7.2
   @nx/linter         : 16.7.2
   @nx/workspace      : 16.7.2
   @nx/cypress        : 16.7.2
   @nx/devkit         : 16.7.2
   @nx/eslint-plugin  : 16.7.2
   @nx/next           : 16.7.2
   @nx/react          : 16.7.2
   @nrwl/tao          : 16.7.2
   @nx/web            : 16.7.2
   typescript         : 5.1.6

Failure Logs

No response

Operating System

• macOS
• Linux
• Windows
• Other (Please specify)

Additional Information

This issue is the cousin of #17873 and the reproducible repo is an extension of the original in that issue from @ganlhi.

I've done some investigation as per #18192 and this issue is within the same 'logic error' but with another flavour. This is my research:

1. An external dependency (in this case node-elastic-apm) requires the dependency [email protected]
2. This one is then resolved with 1.22.3 such as:

"resolve@npm:^1.22.1":
  version: 1.22.3
  resolution: "resolve@npm:1.22.3"
  dependencies:
    is-core-module: ^2.12.0
    path-parse: ^1.0.7
    supports-preserve-symlinks-flag: ^1.0.0
  bin:
    resolve: bin/resolve
  checksum: fb834b81348428cb545ff1b828a72ea28feb5a97c026a1cf40aa1008352c72811ff4d4e71f2035273dc536dcfcae20c13604ba6283c612d70fa0b6e44519c374
  languageName: node
  linkType: hard

3. For some reason that goes beyond my knowledge, this needs of a so called @patch situation where it is resolved as above, with an empty key.
4. This comes the delete key function due to the existingKey is resolving to 1.22.1 and the normalised key is 1.22.3.

Probably the error comes from the idea that we are removing data from the final set (the snapshotMap) from a different set (the existingKeys). The first one does some black magic to resolve the keys whilst the second one is just getting the version from the key of the yarn.lock.

All in all I am a bit lost into what the proper solution would be but I am happy to make a PR if @meeroslav can give some input 😄

[meeroslav]

Hm... this is interesting. Our unit test was supposed to catch this.

I will look into it asap.

Thank you for reporting the issue @veimox

[github-actions]

This issue has been closed for more than 30 days. If this issue is still occuring, please open a new issue with more recent context.